This morning I naively asked on Twitter: “Can someone write a post-mortem on HTML5 taking over mobile? Was it a technical performance failure, or a business strategy failure?” The collection of responses were almost unanimous in saying: it was performance. Users want their apps to be fast, and HTML5 apps weren’t performing well enough. Compiled language implementations (native code like Objective-C on the iPhone) perform better than interpreted language implementations (like HTML5 for mobile web).
Quick, very basic primer on what that means:
Compiled language sends directions directly to the machine. Interpreted language sends directions to another program, which then adjusts the machine code. The former allows you to optimize, runs faster (and in some cases much faster), and scales with fewer performance issues. The latter allows for faster, easier implementation, and since it has at least one extra layer of abstraction, can be used cross-platform much more easily.
It’s still early in HTML5’s life, and mobile interfaces are moving quickly enough that today’s status quo in devices, leading programming paradigms, and applications, won’t be tomorrows. But there’s a lesson in the above for other aspects of a start-up’s processes.
As a builder, if you can get a system up and running quickly and easily, there’s an apparent advantage, because you can test quickly, iterate, and stay lean. But it comes with a real cost. Those builders who optimize more carefully, build more fundamental systems, may end up with a user experience that is simpler, faster and easier, and that’s where the long-term advantage lies. Companies of all sizes struggle with this bargain, not only in their technical infrastructure, but across the user experiences that they design.
The answer to this challenge is not so simple as one or the other. My hypothesis: move quickly to learn, but then choose a point of view, and move slowly to manifest that point of view well.
Musings 