As a developer you have one resource that is more valuable than any other. It is also the scarcest resource you have. That resource is time.
The Maximizing your DROIT, or: why you should learn HTML5, CSS3, and JavaScript for mobile development. article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Given such a limited and valuable resource, you should be looking to make the most of how you invest it. In other words, which tools and technologies should you devote this limited resource to learning?
If you want to develop on mobile devices, you have a plethora of choices: do you invest time, like I did, into learning Objective-C and Cocoa to develop native applications for the iPhone? Or do you devote that same time into learning Java to develop for the Android? Or do you devote that same time instead into learning C++ and some proprietary framework that will only let you develop for Samsung's upcoming smartphone platform?
The question you should be asking yourself as a developer whenever you decide to invest your most valuable resource is this: how much of a return can I get from this investment? In other words, you need to calculate your Developer's Return on Investment on Time (DROIT).
Developers considering ROI, has the world gone mad?
These are not the DROITs you're looking for
Here's a very simple guide to help you decide whether or not you should invest time in learning a new tool, technology, or platform:
Seek: open standards and open platforms.
Avoid: proprietary platforms and walled gardens.
Let's examine why proprietary platforms and walled gardens constitute bad investments of your time and why open standards and platforms are the logical alternative.
Avoid: proprietary platforms and walled gardens
A proprietary platform is a platform that is developed and controlled by one (or primarily one) commercial entity. While there may be short-term economic incentives for learning and developing on proprietary platforms (for example, the evangelizing company may offer economic incentives or run high-cash-prize contests, or there may be lucrative enterprise contracts), their long-term return may be less certain. More dangerously, you will be locked into developing for a single platform and may have a harder time re-using your knowledge elsewhere. And what if the company in question decides to abandon the technology or stop investing in it?
Case in point: say you decided to learn the proprietary platform that Samsung is building for its next generation of smartphones. You cannot use those skills to develop for the iPhone or Android devices (or for the Web, or for desktop applications). This is a bad investment with a very low DROIT. This is one of the reasons why Samsung will fail dramatically in smartphones – they don't understand developers or the importance of maximizing DROIT.
Semi-open and Openwashing
Unlike Samsung, most companies with proprietary platforms are usually well aware of how unattractive lock-in can be for developers and this is why they often to embrace – at least superficially – open standards. Of course, just because a platform supports XML or some other open technology or standard, it doesn't mean that the platform is open. Most proprietary platforms feature some degree of Openwashing wherein the owners of the platform go to great lengths to make the platform appear more open than it truly is. Adobe did this for a long with the Flash Platform, stating that SWF was an open standard while actively barring anyone else from creating a Flash Player (this has now changed, and the SWF format has truly been opened up but its development and future direction are still primarily controlled by Adobe.)
When in doubt, of course, prefer proprietary platforms that do support as many open standards as possible to increase the reusability of your knowledge and maximize your DROIT. So, a good rule of thumb is:
Prefer semi-open over closed.
But there's an even better rule:
Prefer open over semi-open or closed
Open standards, technologies and platforms – by their very nature – offer you the highest DROIT.
As a developer who wants to maximize her DROIT, you owe it to yourself and your career to invest time in learning these open technologies. The advantages of open over closed are the following:
- No lock-in and skill reuse: the technologies you learn will be applicable across different platforms and devices; both today and in the future
- No walled gardens: to paraphrase Oliver, you don't have to ask "please, sir, may I deploy my app" to deploy or sell your apps
So, as a developer looking to enter the exciting world of mobile development, what technologies should you learn?
Based on the simple guide, above, and on a desire to maximize your DROIT, the answer is plainly clear:
Learn HTML5, CSS3, and JavaScript
The web is the best example of an open platform that we have today. It is the antithesis of a walled garden: you can deploy what you want, when you want, and don't have to ask anyone for permission.
While iPhone developers wait months on end for a response from Father Apple, you can deploy dozens of apps to the web without hassle.
And the technologies of the web, open standards all, have the highest reusability of any technology to date. Perhaps the saying should go: Learn HTML, CSS, and JavaScript and you shall never go hungry.
"But, Aral," I hear you say, "surely there are drawbacks to building apps using web technologies."
"Surely someone like yourself, with such a strong focus on User Experience, should understand that it would be untenable to create experiences using such generic technologies that match the experiences possible with native tools and technologies on mobile platforms."
Thus, surely, an iPhone web app must offer a lesser experience than the same app built using Objective-C and Cocoa Touch. Thus, surely, we must embrace the Lowest Common Denominator and sacrifice UX if we develop using cross-platform technologies.
Not at all.
Embracing Write Once, Compile Anywhere, not Write Once, Run Anywhere.
The ability to re-use code and easily port your applications between platforms and devices does not imply that we take a Lowest Common Denominator, Write Once, Run Anywhere (WORA) approach to UX.
Write Once, Run Anywhere has long been seen as the Holy Grail of software development. Sun promised us this elusive ideal years ago with Java and failed to deliver on it. Flash managed to deliver it across browsers and operating systems insofar as the web was concerned but Adobe then decided to embark on a futile mission to replicate this success across desktop applications and mobile devices. And browsers – and HTML, CSS, and JavaScript – were, and continue to be, criticized for failing to deliver on this due to the many browser incompatibilities that plagued developers in the early days of the web before we had better standards support in browsers and JavaScript libraries like JQuery that abstract out the more painful inconsistencies in the DOM.
But what do we mean by Write Once, Run Anywhere in today's world? And is it even a goal worth having?
No, it's not.
Not as the term has traditionally been understood in any case.
Defining Write Once, Run Anywhere (WORA)
Write Once, Run Anywhere implies that you create an application once and it runs the same way (or similarly) on anything. If you're Adobe, pushing Flash, "anything" may include the Web, desktop, and mobile devices.
If you have any understanding of User Experience, you will instinctively realize that regardless of whether or not WORA is technically attainable, it is definitely not a desirable goal to have as far as the user experience is concerned.
User Experience is about focus and optimization. You cannot write a web application and have it be a great user experience on the iPhone, for example, without optimizing the user experience for the iPhone. Optimizing in this sense of the word doesn't just mean scaling your interface down to fit within the dimensions of the iPhone's screen. It may mean having to completely recreate the UI of your app, including user gestures and interactions, to give your iPhone users the best possible experience on their device.
The same goes for when you want to run that same application on an Android phone or the Palm Pre. Where the changes may be less pronounced than those required to go from Web or Desktop to Mobile, the difference in feature sets and operating system expectations between the devices will require UX optimizations that may dramatically affect the structure of your user interfaces.
So while you can port an application that uses open web technologies across platforms and devices, you must still optimize the User Experience for each platform and device that you support. I won't downplay the importance of this: it may mean that you have to do a lot of work and invest a lot of time and money into altering your user interface radically to best support the unique features of the platform or device you are supporting.
However, it will mean that you do so without changing technologies and without changing your entire codebase (this is where maintaining a clear separation of concerns between your View and Model begins to pay real dividends.)
Even though Write Once, Run Anywhere is undesirable insofar as UX is concerned, it doesn't reduce your DROIT in open technologies. While the re-usability of your applications may not extend to the UI layer (or may apply less to it depending on how similar your various target platforms are), it will still apply to other parts of your application.
Using open technologies will make it easier to port your applications across platforms and devices. This does not mean, however, that there is a magic bullet that will make your applications usable on every platform. The concept of Write Once, Run Anywhere is a relic from the Age of Features that has no place in the Age of User Experience.
But what about the argument that applications built using web technologies cannot be as optimized for UX as native applications?
In a nutshell, it fails to hold water, and brings us to the alternative to WORA.
The alternative to WORA: Write Once, Compile Anywhere (WOCA)
There are currently a plethora of tools and technologies – both open and closed – that allow you to re-use your DROIT in open technologies to build native applications across various platforms without sacrificing UX. In fact, this is one the most exciting trends of our time and one of the reasons why it's a great time to be a developer.
Examples abound: the open source Phonegap framework, for example, lets you build applications using your existing DROIT in open web technologies while compiling your app into native applications on iPhone, Android, and Blackberry.
And it's not the only one. Check out Titanium and Appcelerator, and also look at web frameworks like iUI, xUI, Magic Framework, and JQTouch – all of which increase your DROIT.
Commercial and proprietary platforms are also embracing WOCA. Adobe, for example, realized that WOCA was the way to stay relevant with the iPhone and their upcoming Flash IDE in CS5 allows developers to create iPhone applications by re-using their DROIT in the Flash IDE while outputting native iPhone apps. (I hope Adobe wakes up and realizes that it has a far brighter future if it focusses on its development tools and native compilation with WOCA instead of spending time and money on trying to get native support for Flash on devices. Flash support in mobile browsers is necessary for a faithful rendering of today's web but native Flash support for applications adds absolutely no value to a platform.)
(Another proprietary WOCA solution to keep an eye on is Unity3D.)
Beyond WOCA: Palm leads the way with WebOS
The WOCA solutions we have today are a wonderful way of increasing DROIT in open web technologies. But mobile platforms can do better by actually embracing web technologies as first class citizens on their platform. (Not as crippled subsets like Apple's initial foray on the iPhone.) In fact, one company is already doing that and doing it beautifully.
While Microsoft drifts aimlessly with Windows Mobile trying to play a fruitless game of cat and mouse with Apple, and while Google – the defender of all things open and web – invests in Java with Android, one company has come out of left field with a solid vision to embrace open web technologies for its mobile platform. That company is Palm and its platform is called WebOS. And you should stand up and take notice because it is one of the most important developments in the mobile world today.
With WebOS, you don't need to compile your HTML, CSS, and JavaScript to native applications because they are the native technologies of the platform.
Beyond supporting open web technologies, Palm also supports the ethos of the Web. You are not bound to Palm's store (even though they have one) and can deploy your apps to the web without asking permission from anyone. (If you do want to use their store, you can do that also and get the best of both worlds – the impulse buys and worry-free purchasing that the store provides coupled with the freedom to also distribute your apps yourself.)
More than that (and this is a personal point), having been to the Palm developer event in London recently and met Dion and Ben (who head up Palm's developer relations), I have to say that Palm has some genuinely nice people working for them. I love their approach and their vision. They have hired developers who have contributed to the open web and believe in its future. In other words, Palm has the right people running the show. And I wish them all the success.
(And this has nothing to do with the fact that they gave me a free Palm Pre to play with. In fact, if anything, I find it unfortunate that the hardware of the Pre doesn't allow the software and Palm's vision to shine currently. But it is a Version 1.0 phone and I look forward to seeing how the hardware evolves with the Palm Pixi.)
In conclusion
As a developer, your scarcest resource is time. It is thus of paramount importance that you invest this time wisely in learning the relevant open web technologies of today – namely HTML5, CSS3, and JavaScript – in order to maximize your DROIT.
Thanks to WOCA solutions like Phonegap and native web platforms like Palm's WebOS, you no longer have to sacrifice either your investment in open web technologies or your commitment to creating great user experiences. In other words, you can have your cake and eat it too!
Bon appetite!
The Maximizing your DROIT, or: why you should learn HTML5, CSS3, and JavaScript for mobile development. article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Certainly a familiarity of HTML, CSS and JS is important for any developer working with web-enabled technologies. But I’d say we’ve got a ways to go before these technologies become the king technologies of native mobile development. They’re still not even the king technologies of desktop app development as we’ve been promised by Google, MS, Adobe, et al for years.
I agree that time is a precious resource for any developer. However I’d also argue that one’s ability to learn a new platform is as important as time. HTML/CSS/JS are trivial insofar as syntax and semantics, it’s the platform’s SDK APIs that are what truly need to be learned. It’s important for a developer to know how to quickly and efficiently wrap his mind around any new SDK that is thrown at them.
An understanding of the native SDK that you are building for is also important to have. The limiting factor in mobile development is hardware (processor speed, etc). The WOCA technologies you list above, Unity3D, Phonegap, and Flash CS5 -> iPhone are all tremendous feats of development, but applications built with native frameworks will still beat the pants off applications built with these WOCA tools in terms of speed and application size (I’m told the compile time for CS5 -> iPhone is between 5 and 15 minutes, and building an empty Unity3D app for iPhone will produce a ~10MB binary). Having a working knowledge of a native SDK’s APIs can only help when using a WOCA tool. Much like knowing the limits of each browser’s JavaScript interpreter can help a web-developer create optimal DHTML interactions. I’m a fan of the WOCA idea, but unless you know what’s going on behind the scenes at compile-time or run-time, you’re going to be limited in how far you can push a WOCA tool.
Thank you for your thoughtful comment, Brian. You raise two very important points: learning the SDKs as well as capabilities of the devices that you are developing for are, definitely important, time consuming, and very much a requirement regardless of the language you author in.
And I do agree that the ability to learn new technologies is an essential skill for a good developer. Heck, I have a propensity to overdo it even, what with Python and Google App Engine last year and Objective-C and Cocoa this year, it’s been quite a ride! (And I love it!)
Your point on performance and file size regarding WOCA is also well stated.
One topic I didn’t touch upon in this mammoth post (WriteRoom is good but maybe too good) is hybrid applications as they carry many of the advantages of cross-platform code re-use while also benefiting from the advantages of native frameworks. In fact, we’re already at a point where a large number of apps on the iPhone at least are hybrid apps and the question becomes how much of the app do we keep in HTML/CSS/JS and how much do we keep native? If the native app becomes simply a wrapper around a browser component then we essentially have Phonegap.
I do truly believe, however, that HTML, CSS, and JavaScript (HCJ) are cornerstone technologies to learn for mobile development. It is then up to you to compliment that knowledge with an understanding of native SDKs, and quite possibly the other native technologies for the platforms that you are developing for. Given the number of available WOCA solutions, as well as the hybrid nature of a lot of mobile development today (and initiatives like WebOS by Palm), your DROIT in learning HCJ will be higher than any other comparable language.
Yes, widespread, highly engaging web experiences is a likely future of mobile across devices and platforms.
There are lots of players emerging … but obviously some stand outs that could compete … such as webOS, Flash, etc.
For the most part, right now, however … it remains a fragmented world of native platforms across multiple devices. Step right up, and pick your platform poison, folks.
No doubt about it.
Mobile services are still in a 1995-like ‘Compuserve’ infancy – handset app stores, carrier gardens and the like.
Ah – the good old days of WinCIM. But in retrospect, who would have bet against TCP/IP and the web it bore?
So… history probably repeats. Not long now and the mobile web will be *the* app store.
15 years on, who wants to bet against that?
Okay, technicallly HTML5 may be the answer. But you failed to address the issue of deployment.
Just because you develop using HTML5 doesn’t mean Apple will now rush your app through the approval process. So this leaves you with creating a webapp. Nothing wrong with those, except you can’t convince people to pay for them and you have running costs.
People learn Objective-C just to sell on the App Store.
I agree wholeheartedly with your “higher-level” argumentation, but disagree in your [ab]use of these arguments to promote HTML at the expense of Java (which seems to serve as the “old-fashioned antagonist” for the article).
Yes, Java’ WORA is not perfect, remarkably JavaME. But for the most part, the imperfection in JavaME is a result of the different feature set of each device, and developers work around this by doing exactly what you preach – WOCA + per-device customization. We can write a ME application that’s mostly portable but uses some custom code/resources for each major device’s features like input capabilities, connectivity, screen size, and availability of advanced APIs (JSRs). There are tools like J2MEPolish to help filling these platform gaps (even to the point of unifying J2ME and Android). Even the standard JavaME kit actively supports conditional compilation, although that’s still taboo in JavaSE. All in all, it’s not ANY different/worse from advanced HTML5 development which often needs major effort to adapt to different browsers (true even for full-featured desktop browsers, let alone mobile ones…).
JavaME is backed by open standards just like HTML5. Yes, the JCP is not a ideal world’s standards group, but the same can be said of the W3C for different reasons.
JavaME has a major problem of not being universally supported, remarkably in the popular iPhone platform. OTOH, web apps will have a hard time competing with normal apps for a long time, even with HTML5. The JavaME platform (and also Android) typically allows full access to the device’s features, even if you have to use some proprietary API for stuff that’s not yet blessed by some standard API – that’s the WOCA model, just write some extra code for that device. But the same is typically not true for HTML; I didn’t look at the Pre, but at least in more traditional smartphones like WinMob and iPhone, the browser is clearly a ghetto with severely restricted access to the device’s full range of features, and you can’t count on the device makers to provide some kind of proprietary extension so you JavaScript-happy webapp can tap into every advanced/device-specific feature.
Finally, even the last generation of advanced JavaScript JITs cannot match the performance of Java code (at least JavaME – Android is still interpreted); and this is not expected to change any time soon because JS is so intrinsically inefficient (dynamic-typed, prototype-based); even in desktop browsers where the JIT has a relatively generous allowance of resources for compilation, JS is and will always be significantly slower than Java. The disadvantage is not important for many apps – my GMail was already snappy in Firefox even before TraceMonkey – but it’s surely important for many others, e.g. how competitive will be WebGL for nontrivial animations/games that must be driven by a large chunk of slow JS code doing complicated stuff like physics?
On a last note, it’s interesting that Java can even benefit of the HTML5 platform due to code generators like Google’s GWT and Eclipse’s RAP. This allows both techs to go together in the WOCA model.
I don’t disagree with you as learning HTML, JS, CSS is quite good, but I think mobile web development is going to get really difficult with such a huge growing fragmentation of browsers out there on mobile devices. Peter-Paul Koch from Quirksmode.org recently did a test of WebKit mobile browsers and out of the 19 mobile devices he tested found 19 very different browsers: http://bit.ly/1n1K1x
As for Adobe, there’s recently been announcements with them teaming up with RIM to streamline Blackberry development. Not just with Flash but with their other CS tools. Looks like Adobe is trying to position themselves in a spot where you can easy target all mobile devices with their tools. Certainly getting Flash on as many platforms as possible is the first step for them wanting to get Adobe AIR on mobile devices, to bring about a write once, run everywhere environment. However, this only works where any major device that doesn’t support AIR has an alternative like the iPhone where you will be able to create a native application.
Also from what I’ve read of Adobe’s new mobile Flex framework, it sounds like Adobe are taking the right steps to create an Flex applications that will adapt to fit different mobile devices.
Hi Sivan,
On the subject of deployment, I should have been clearer: when you use Phonegap to create your application, yes you have to still go through Apple’s App Store review process, however, you can also deploy your app to Android and Blackberry. So you are hedging your bets. If Apple takes three months to get back to you with a cryptic one-liner about what you need to change, you can still pay the rent with the Android version that went live months previously.
Of course, you can also circumvent the whole process by deploying to the web and, say, making your app ad-supported but that’s not what I’m advocating here. I’m advocating the use of open web technologies so that you can keep your options open and not be tied solely to Apple’s whims and the iPhone platform.
Believe me, I know first hand how frustrating it can be to have your app finished after lots of hard work and not be able to deploy it because of the whims of a gatekeeper. It gets worse if you rely on selling apps to pay the rent.
Hi Osvaldo,
Thank you for your spirited defense of Java; you make some very good points.
My own personal dislike for the verbosity of the language aside, I do agree that Java is definitely a more desirable alternative to proprietary platforms. I do see Java ME/J2ME as a dead-end mobile technology, however – stillborn and a relic from the days of Nokia, if you will; an example of UX failure. Android, on the other hand, has loads of promise (in fact, just yesterday I dissuaded a student from doing his thesis project in Java ME in favor of Android).
One topic I didn’t touch upon in the article, however, is the learning curve for these various technologies – and this is an area that web technologies have an advantage over Java.
At the end of the day, you are going to have a much harder time trying to convince a web developer to learn Java to develop for Android when Palm tells them that all they need to enter the club is HTML, CSS, and JavaScript.
Matthew,
I feel that Adobe’s current efforts are based on an outmoded horizontal business model where the focus is on quantity not quality: let’s get our VM on a gazillion handsets across a bazillion manufacturers. In other words, lets provide the same crappy experience across a billion handsets.
Adobe’s approach to mobile at the moment is about quantity – Lowest Common Denominator UX. This is a relic from the Age of Features not the Age of User Experience.
What Adobe desperately needs to do is to get Flash running wonderfully on one handset (I don’t care which one). Prove to the world that you can create an amazing user experience using Flash on a single handset and then move on to the second and then the third.
personally, i have high hopes for W3C widgets, particularly once the issue of which device API to support (JIL, BONDI, other?) is cleared up. Vodafone’s 360 platform, for instance, already uses these, there are new web-connected TVs with widget managers built-in, and even on desktop you can run them (for instance with Opera – full disclosure: my employers).
Hi, Aral,
I enjoyed reading this article about web technologies for mobile, but i admit i spend the whole session waiting to see when you were going to talk about the maemo platform.With the launch this month of the new N900 by Nokia, isnt it a great right step into open platform development? It features a full spectrum of web mobile ready for the developers to step in, no?
Been following your articles (and tweets) with interest, and hear about iphone, palm pre, android mobiles, but never about the maemo. Is it that forgettable?
I admit it doesnt have the followers the iphone has, but we have to be fair and separate “fascination for apple and its new gadgets” and development/geekness and open source.
Forgive my rant, but have been looking with interest at maemo/N900 and since i value your opinion and views on the subject of mobile dev, it cant hurt to leave this here.
Hey manifesto42,
First off, thank you for your kind words
Regarding the Nokia N900 and the Maemo, I have to admit that it has been off of my radar (thanks for bringing it to my attention, I will check it out.) The thing is, I could probably spend all my time (and budget) playing with new gadgets and I am assuming that this is true for other developers also. Nokia has been off my list for the longest time since I have just not been impressed with their offerings. I see them as the Microsoft of mobile.
That said, after your spirited championing of the N900, I will take a look at it and have a play in a store (here’s hoping that they have demo models and not plastic mock ups).
[...] messages, and the latest news. I recently read about something called “droit” ( see Aral Balkan’s article ) where it’s encouraged to: Seek: open standards and open [...]
I can relate to Nokia being the Microsoft of the mobile industry, and i am a Palm Treo (had a few, love the thing) guy myself, but have been looking on options on how to turn my mobile life around, and this maemo device, with all its tinks, pros, cons, and twirls, might just have all i need. And it all comes as a surprise because i had the iphone on the top of my list.
My background is geek, flex/flash – all in between – web developer, so i am not the average joe that goes for eye candy and runs in the same direction of the heard.
Still havent taken the plunge, but even you have to admit – and yes, jokes aside about the cpu raw super ultra power (same as iphone) – it does look interesting on the developer geeky side of things, no?
Aral,
I think what you describe is Adobe’s previous attitude with FlashLite and I think things have changed at Adobe with the new mobile Flash Player 10.1. I could be wrong since we’ve yet to see Flash Player 10.1 anywhere beyond strictly controlled Adobe demos. The first beta should be available before the end of this year for Palm’s WebOS, with other devices to follow early next year. So we will have to see how that turns out.
Also while Adobe obvious missed the boat on the first round of powerful smartphones, it’s good to see them keeping on a eye with what’s coming and working to get Flash on top-set boxes, blu-ray players and internet-enabled televisions. However, that’s another area where keeping up your HTML skills could prove to be very helpful.
This is a very good run-through of the current state of mobile application development, in my opinion; thank you. James Pierce made a good point comparing the current situation to “Compuserve”; I would go further and say it is more akin to AOL as Compuserve went away largely because there was a paradigm shift in the underlying technology = Microsoft Windows. Going back a bit further, pre PC, there was a plethora of computers, Commodore, BBC, Dragon etc that is also similar to the present situation and Apple holds the same position they always have, to this day. The iPhone is a totally closely coupled, closed device and it is unfortunate for the development world that so developers slave to create apps for the iPhone only to have them rejected or lost in to 99,999 other apps and them have them run on nothing else; we need to stop worshiping the iPhone it is an out of step unergonomic brick and totally uncool as Verizon recently pointed out. My opinion is that the trio of CSS3, HTML5 and JavaScript are absolutely compelling for all the reasons you state here. Flash (ActionScript) is a different beast as it runs in a virtual machine which is largely predictable (iPhone excepted). The good news is that writing mobile apps in Flash or the web triumverate means they are portable. One last point, I am still trying to grasp why Google Android has gained so much ground, webOS really should be in that place.
Appcelerator Titanium is another option to consider for DROIT. We support building multiple device/OS based applications using pure open standards and open source. http://www.appcelerator.com