In the beginning, Apple wasn't going to let anyone develop apps for the iPhone. If you wanted to target the iPhone, you needed to write HTML5 for Safari. It was an elegant answer with a well-understood sandbox for developers to use.
Alas, no one was happy with the locked-down platform. People wanted to write native code, a pathway certainly essential for fast games and useful for slower applications that let you browse information. Apple relented, and now we have the App Store.
The trouble is that the code for the iPhone won't work on other smartphones and vice versa. Any company that wants to target multiple manufacturers must rewrite their application -- a long, slow process prone to incompatibilities. Plus, it's double or triple the work.
HTML5 is a nice option. If you can write your application as a Web page, there's a good chance your users can pop them open in the smartphone's browser. There are already a number of great frameworks that make this a bit smoother.
The trouble is that it's not necessarily in the interests of the smartphone manufacturers to embrace this interoperability. If the phones are going to stand out, they'll need to offer something special, and that usually means something different. That won't happen if everyone runs the same HTML5 apps.
There are plenty of rumors that the performance of HTML5 on the smartphones is not as good as it could be. Some suggest that the HTML5 engines are a bit slower. There is no easy way to test this or even understand the motivation behind any sloggy code. In many cases, the HTML5 is slower because it's interpreted instead of compiled directly for the hardware.
The answer to this dilemma is guessing how important performance will be to your mobile app. If it's essential, then custom-compiled native code is the answer. If it isn't, you have some leeway to explore HTML5.
Software users are like teenagers, it's said: They want all of the freedom they can get, but they expect you, the good parent, to rescue them from harm. They want all of the advantages of the walled garden, but insist on being able to slip through some backdoor whenever it suits their fancy.
The issue of control is a difficult one for programmers. The ethos of open source permeates the culture, with its insistence that everyone should be able to recompile the stack and tweak anything to fit. Alas, the average user can't make use of this power no matter how much they want it. Even most programmers have to spend hours finding the right versions of the libraries and the latest edition of the compiler. Control means nothing if you don't have the time to use it.
Some companies are pushing the ideal of open databases. We're all supposed to be able to download the information about us. Alas, most of us can't do anything with the information, and the only ones with the time and energy to use these open doors are other companies.
There is no answer to this dilemma. If you give your users control, they'll complain about the UI and the features they didn't get. If you don't, they keep nagging you for it.
- 7 programming myths -- busted
- 10 hard truths developers must learn to accept
- Programmer personality types: 13 profiles in code
- 11 programming trends to watch
- 12 programming mistakes to avoid
- 7 programming languages on the rise
- 10 programming languages that could shake up IT
- "Hello, world": Programming languages quiz
- Programming IQ test: Round 1
- Programming IQ test: Round 2
- From PHP to Perl: What's hot, what's not in scripting languages
- 13 essential programming tools for the mobile Web
- Open source programming tools on the rise
- Download: InfoWorld HTML5 Deep Dive
- 11 hard truths about HTML5
This article, "Top 7 dilemmas facing today's developers," originally appeared at InfoWorld.com. Follow the latest news in programming and mobile technology at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.