Will the ‘Appification Of Everything’ Transform The World’s 360 Million Web Sites?

I don’t think so…

OK, so I want to be slightly provocative here.

Forbes recently wrote a great article called the “The Appification Of Everything Will Transform The World’s 360 Million Web Sites“.

We can’t deny that the web has been appified in recent years, largely driven by Apple. The cynical (and honest) amongst us would believe this is purely so content can be controlled and monetized. However, I don’t believe this is the sole reason. Innovation around the browser and web standards did stagnate for a long time, but that tide has shifted now with HTML5 and CSS3. Adobe Flash and its cohorts Flex and AIR plugged the gap for a while, but they too stagnated and failed to innovate in-line with the needs and aspirations of users, developers, and businesses. I think the bloody nose that Adobe suffered in the ungraceful, and rapid, demise of Flash will ultimately be a good thing for us all. Adobe has shifted their focus to web standards and has regained it’s innovation foothold. Just look at their web platform site and blog. They are not alone. Google is innovating web standards as are other companies large, small, and new. There is also a buoyant open-source community which has contributed an overwhelming amount of innovation.

I often use Java as my baseline. There was a community that exploded and dominated for a long time. The web standards community feels bigger, and it feels like it is in its infancy. Building web apps, and in particular single-page apps, has never been easier. The web has been commoditized by the likes of Heroku and GitHub. The web has never been more expressive. I’m blown away by HTML5 and CSS3. As I think back to my Flex days and the difficulties we had changing simple aspects of the experience, for example the rendering of validation errors on input fields, or adding a placeholder. It’s just so easy now. It’s also providing a clean separation of responsibilities between the designer and the developer, and better still giving ownership of the experience to the designer. I’m seeing more and more of a new breed of designer, who doesn’t just design the experience, but they code it!

So coming back to appification, and in particular mobile. It’s a fragmented market. We have iOS and Android dominating. Windows Phone and BlackBerry are fighting for market share. There’s a new wave of OS’s on its way, Firefox OS, Tizen, Ubuntu Phone OS. They are all proprietary. Even if HTML5 is a supported language, the code is littered with proprietary references to the underlying SDK, which binds the app to the hardware. At most we can claim the language is common, but I have yet to see a truly portable app. The fact that some of these are open-source makes very little difference. To reach my users I have to build a native app for each platform I want to support. This is a huge investment and creates a maintenance headache. My main option for reuse comes from my back-end services, which I can exploit across all platforms.

Well may be it’s not all that bad – or is it? There are many cross-platform languages and tools for packaging web apps as native apps. This is a big problem and there are lots of people working on solving it. However, the problem doesn’t just disappear, it simply moves the burden from the app developer to someone else, and hopefully that someone else has the deep pockets to deal with the fragmentation. But who cares, this is great news for the developer, it has to be! Well, from my experience it comes with compromise. The reason we usually build a native app is to access to the capabilities of the hardware (and in many cases performance). It’s a BIG job to support all these capabilities and the nuances that exist across all these OSs. Often the cross-platform thingamajiggy has to opt for the lowest common denominator. Often they lag as they can’t keep pace with new updates. This can become very frustrating for the developer and the end-user experience begins to suffer. Ultimately the user pays the price. Not good.

It not always compromise though. If I pick on my old friend Adobe AIR, it was just too big a job to support all the capabilities of all the platforms. The strategy to combat this is typically native extension. But hold on, that means I still have to write native code and I still have to incur an element of cost for each platform. The community does help as there are libraries of native extensions. However, I’m in a funny place. There’s a threshold I cross where my non-native app is mostly native. So why suffer all the compromises, is it not just simpler to suck it up and to build a native app in the first place?

My hypothesis, the tide will turn from appification back to the browser.

At the end of the day the browser has far greater penetration in the market and broader reach. We also have greater control over our app and the experience. When we make an update we reach all our users. No more app store approval and no more waiting on users updating the app.

There are still wrinkles. We still have to deal with browser compatibility. I feel this is the lesser of two evils though. I also wonder if in the future we will be comfortable only targeting a single browser…that’s another topic of discussion for another day.

There is also the wrinkle of mobile and incorporating hardware capabilities such as geo and the accelerometer in to our experiences. I bring us back to the fast pace of innovation, just look at WebRTC as an example. I suspect it won’t be too long before we have parity and web standards shift to the position of influencer.

Only time will tell.


Ember and the Designer

For the last 7 years I’ve worked with User Experience designers and I have a huge respect for their craft. I’m also loving how designers are embracing HTML5 and CSS3, and how it is giving them ownership over the experience.

It’s affording deep collaboration between the designer and developer, and asserting the need for frameworks and tools to play to our respective crafts, and to be sensitive to the designer-developer-workflow.

With this in mind I struggled for a while with Ember. I wanted a clean separation between my HTML and my code. Ideally I didn’t want to change the HTML, and I really didn’t want to pollute it with proprietary code belonging to Ember (or any other framework).

I was really disappointed as the only solution offered up was to use Ember.TextField.


<input type="text" id="firstName" placeholder="First" autofocus required>


{{view Ember.TextField valueBinding="firstName"}}

It breaks the clean separation between designer and developer. It makes my code difficult to maintain. I loose the expressiveness of HTML5. Why?

I get the binding goodness it may bring, but…

At this point I did consider walking away from Ember, but I did persevere. In the end I opted to use plain old JQuery in my code. I’m intrigued to see how this plays out as I grow my codebase, but in the meantime it keeps my HTML as pure as it can be.


<script type="text/x-handlebars" data-template-name="registration">
   <form autocomplete="on" id="registration" {{action createUser on="submit"}}>
      <input type="text" id="firstName" placeholder="First" autofocus required>
      <input type="text" id="lastName" placeholder="Last" required>
      <input type="email" id="primaryEmailAddress" placeholder="hello@mydomain.com" autocomplete="on" required><br>
      <label>Password <em>Minimum 6 characters</em></label>
      <input type="password" id="password" autocomplete="off" required pattern=".{6,}" title="Passwords must have a minimum of 6 characters."><br>
      <input type="submit" value="Create account" onmouseup="form.className='submitted';" />


App.UsersController = Ember.ObjectController.extend({
    createUser : function () {
        'use strict';
        var user = App.User.createRecord({
            firstName : $("#firstName").val(),
            lastName : $("#lastName").val(),
            primaryEmailAddress : $("#primaryEmailAddress").val(),
            password : $("#password").val()