Thursday, June 17th, 2010

The march to a more client-centric Web; Will the mobile Web, HTML5, and Chrome Web Apps be the tipping point?

Category: Editorial

Progressive enhancement.

Disconnected offline applications.

There is a tension brewing in how we deliver applications on the Web. This isn’t a new tension. It has been around ever since we started to do more than just throw HTML down the pipe for the hypertext document runtime to render.

With the Ajax revolution we talked a lot about “Web applications”. Gmail. Google Maps. Those are written in a very different manner. The architecture isn’t one of: client asks for a URL…. server does all of the work: business logic, and view logic, since it sends back the entire view as HTML. A popular Ajax pattern was that of still keeping the client kinda dumb, and having the server return interface elements and behaviour in the form of HTML/CSS/JS that the client would eval/innerHTML/etc. This continues to be used a lot as it is flexible (especially if the bulk of the team is on the server side) and sometimes easier to do (chop up the functionality on the backend into more discrete tasks). This is a progressive enhancement style of richer Web applications.

When I was working with Gears I saw first hand how reluctant developers were to move from the progressive enhancement style into a more aggressive client server-esque style of Web application development. The Gears APIs themselves are trivial. Nicely implemented. Simple APIs. We get to use them these days in the form of App Cache, SQL database API, Web Workers, GeoLocation, etc. Taking your application and sprinkling a GeoLocation API is very simple and fits into progressive enhancement easily. Even doing what the WordPress guys did early on, and using App Cache as an aggressive fast cache is easy.

The harder sell to developers was: If you want to have your Web application work offline, you need to re-architect it to enable that. Instead of having your PHPs firing down interfaces, you need the client to coordinate the work and just speak REST to services that give you the data, and then have a layer of abstraction that can get the data locally etc. Then you can look at handling sync and the like. This is real work. This is moving code from point A to point B. It is a big deal. Many developers didn’t see the value proposition. Do they REALLY care about the offline use case? Getting some performance improvements by taking out latency is nice (hit cache first etc) but is that worth the rework?

For many people, it just wasn’t worth it.

As I look at what is changing in the world, I see a few things that may add up collectively to a tipping point:

“HTML5” hype

HTML5 has a lot of great functionality. There will be pressure for developers and sites to raise the bar. Expectations of what a Web application “can do” is drastically going to change, and as soon as that change happens you don’t want to be left behind. MapQuest was fantastic. Until Google Maps came out. Then, on that day forth, it felt archaic. All of that with XHR++….. what will happen with all of the HTML5 functionality available? A lot of code we will be rewritten and changed for “HTML5ication”, which is an opportunity for a change in how things are done.

“Apps” and the Web as a unified device platform

I haven’t been quiet with my concern at the rise of the proprietary app platforms. The Web needs to fight back, and it has the opportunity to actually solve developer problems (rather than just rant about how the world should be more open damn it!).

As a developer, do you want to port experiences between incredibly varied platforms such as Web, iPhone, Android, WinPho 7, RIM, Kindle SDK, [insert many others!]? No. The Web has the opportunity to share a lot of that code and development. It has to compete with the native platforms on features, performance, and the like…. but I would argue that it is doing a great job and getting better FAST.

Within the apps ecosystem there are some very interesting things happening:

Chrome Web Store: The Chrome Web Store is happening. I know of other Web store efforts in various stages of life too. A lot of developers want to get into the app distribution bandwagon, and will be looking at the notion of a “web app” in a new light because of this. This will give a lot of momentum, along with the fact that HTML5 is the first real spec envisioned for “app” functionality versus documents, to the web app movement.

Mobile Web: As developers want to get applications to as many devices as possible, they are finding that the Mobile Web is an attractive development platform. But, how do you do it? If you think about Web distribution, then you have the progressive enhancement world again (device and layout tweaks via CSS, JS, etc) all the way up to a mobile framework. We see the two worlds with jQTouch on one side and Sencha Touch on the other.

Take a look at how an app looks in Sencha Touch:

templates in HTML

  1. <textarea id="legislatorbrief" class="x-hidden-display">
  2.     <div class="legislator-brief">
  3.         <div class="legislator-tnail" style="background-image: url({govtrack_id}-50px.jpeg)"></div>
  4.         <h3>{title} {firstname} {middlename} {lastname} ({party})</h3>
  5.         <p>{state} {district:this.ordinal}</p>
  6.     </div>
  7. </textarea>

OO app framework with layout and components


  1. Geo.App = Ext.extend(Ext.Panel, {
  2.     cls: 'app',
  3.     fullscreen: true,
  4.     layout: 'card',
  5.     activeItem: 0,
  7.     initComponent: function() {      
  8.         this.startScreen = new Geo.views.StartScreen({
  9.             flex: 1
  10.         });
  11.         this.splash = new Ext.Container({
  12.             cls: 'splash',
  13.             layout: {
  14.                 type: 'vbox',
  15.                 align: 'stretch',
  16.                 pack: 'end'
  17.             },
  18.             listeners: {
  19.                 deactivate: this.onSplashDeactivate,
  20.                 scope: this
  21.             },
  22.             items: [this.startScreen]
  23.         });
  24.         this.detail = new Geo.views.LegislatorDetails();
  26.         this.items = [this.splash, this.detail];
  29.         this.startScreen.on('legislatorselect', this.onLegislatorSelect, this);
  30.     },
  32.     afterRender: function() {
  33.         Geo.App.superclass.afterRender.apply(this, arguments);
  34.         Ext.getBody().on(Ext.isChrome ? 'click' : 'tap', this.onLinkTap, this, {delegate: 'a.goOutside'});
  35.     },
  37.     onLinkTap: function(e, t) {      
  38.         e.stopEvent();
  39.         Geo.Util.openUrl(t.href);
  40.     },
  43.     onSplashDeactivate: function() {
  44.         this.startScreen.list.clearSelections();
  45.     },
  47.     onLegislatorSelect: function(govtrack_id) {
  48.         this.setCard(this.detail, Geo.defaultAnim);
  49.         this.detail.update(govtrack_id);
  50.     }
  51. });

This looks similar to how we build apps on webOS with Mojo and other frameworks like Jo. Rich full featured mobile frameworks.

Once you have built your Web application, technology such as PhoneGap and Appcelerator Titanium can package it for the various app distribution platforms.

So, when I put this all together, I see the opportunity for the growth of Web applications through both progressive enhancement, but also via rich client frameworks. The tension will be there between the two, and I am sure that there will be more solutions that blend the best of both worlds.

What do you think? What are you seeing as you build richer Web applications for a variety of devices and form factors?

Posted by Dion Almaer at 3:25 pm

1 rating from 1 votes


Comments feed TrackBack URI

Yes. In general, I think you’ve summed up the current transition-in-waiting quite well.

The thing that’s driving me nuts right now is the “when” of it all.

The product/application I work on (Flex/Flash RIA) is getting heavy pressure to be built “for” the iPad. I have no interest in maintaining two code-bases – so converting to a truly cross-environment (device?) codebase is the right move. So I cobbled a JS/CSS library of iPad-esque features and merged them with my custom app functionality as a proof of concept.

Then comes Sencha-touch. And in my 10 minute preview, I can see it does more than my cobbled-together code will ever likely do. So that’s great! But what’s coming out tomorrow?

It makes me want to jump into the future – even just 6 months.

How does a developer who is working on an application with a 2,3,4+ year lifespan move forward today? Sencha-touch? Maybe, but tomorrow Apple, Google, somebody could release it’s own library that is even better.

It’s a tough time to be making long-term decisions.

That being said – the direction feels right. So I guess I’m willing to struggle through this transition period (is that what this is…?)

Comment by CR4 — June 17, 2010

Many developers didn’t see the value proposition. Do they REALLY care about the offline use case? Getting some performance improvements by taking out latency is nice (hit cache first etc) but is that worth the rework?
The reason I chose such an architecture (ExtJS on JSON-RPC) had little to do with offline, and nothing at all to do with mobile. The biggest reason for me was that the server became free to implement an API that isn’t heavily tied to the UI. This allows client/server API’s that are clean and sparse, which makes them easy to maintain and easy to secure. Since maintenance (and web app security) is the majority of the project cost, this saves real money. Since the API is clean enough, it can actually be used as a foundation for other apps (e.g. native iphone apps). The switch from PHP-centric development to ExtJS-centric was worth it, even if the learning curve was steep.
Maybe we also need to review the “why” behind progressive enhancement. It’s no longer needed for accessibility, and no longer needed for widespread browser compatibility. It basically assumes that HTML is a given, and javascript is optional. That’s no longer the web of today. In today’s web, javascript is a given. So, why is it still necessary?

Comment by Joeri — June 17, 2010


Comment by sixtyseconds — June 18, 2010

it seems like the web is definitely going down against apps in the next 2 years, then maybe it will raise again after that cold winter.
As you’re perfectly mentioned, we’re facing challenges and I think that the web simply can’t address them :
1/ top graphics with many animations UIs running on slow devices (don’t talk to me about modern JS framework that try to build full UI toolkits and run dog slow. Sproutcore basic demos don’t even run on an iPad, and never will). You can’t compare native speed on a carefully crafted and optimized framework (Cocoa) with something running on top of a virtual machine assembling poorly designed HTML elements to try and build a descent UI.

2/ Offline support, meaning the full MVC on the client-side : to address this, the web would need perfectly standardized browsers, and I don’t mean “common default values for obscure css properties”, I mean common offline database implementation, with similar performances, common behaviors related to security, error management, etc. We would also need a heavy framework and IDE capable of dealing with complex data structures, screen logic, and business logic.
Javascript is a nice plastic toy, but it’s not typed, not safe, and doesn’t have (to my knowledge) any IDE capable of descent auto-completion. That is what developpers are used to when they develop for server-side, for flash, for objective-C, or for android. Everything the “web” tries to compete with.

Comment by BgSimple — June 18, 2010

Hi Dion, nice post, although I obviously insanely disagree with your main thesis. About the ‘offline problem’, I think 37signals and David sums that up better than I would be able to do if I spent my entire life explaining it;
Now back to your main thesis about client-driven apps. Most ‘Ajax guys’ today thinks that ‘JavaScript is difficult’. So they try to ‘make JS easier to develop in’. Without realizing that they’re effectively moving away from the original problem, which you actually hints towards in your post, which is; ‘how do we create rich internet applications’…
People are still wanting to create apps, or…?
When you ask yourself this questions, meaning; ‘how do we create rich internet applications’, obviously using *web* and not ActiveX2.0, then the answers and possible solutions changes drastically. Sometimes I feel like a kinder-garden uncle, stuck in a kinder-garden, gone completely wild, where no one wants to listen to the ‘grown ups’. Obviously I am not alone in this position, but the majority are instead of asking themselves; ‘how do we easier create web apps’, asking themselves; ‘how do we make it easier to develop in JavaScript on the client’ …
Quite ironic indeed …!
… ‘when will they ever learn’ …
— Bob Dylan!

Comment by ThomasHansen — June 18, 2010

@BgSimple: that’s the miracle of JIT compilation. There’s no technical reason why “dog slow” javascript running on top of “poorly designed” HTML can’t be just as fast as hand-coded C, or even faster. I also see a lot of potential in accelerated graphics, like IE9’s accelerated DOM, and webgl. Once they get OpenCL running in the browser, and I suspect it’s only a matter of time before they do, I guarantee you we’re going to see a javascript client for Seti@Home.
Besides, javascript is faster than PHP, and PHP is what the world’s most used application runs on (facebook). Performance matters, but not that much. Some parts have to be native, and for that google is working on native client, but 99% of source code is perfectly fine on a dynamic language, even interpreted.

Comment by Joeri — June 18, 2010

Good post. I’m a big fan of web apps taking full advantage of the client platform with js and the various DOM exposed browser features. Our web apis project at work (Intel) is in this area..

I’m fascinated by the direction of things like the Chrome web store, installable web apps, NPAPI::Pepper etc. Some of it is packaging – but the right kind IMHO. Some of it is better functionality and security.

Re: the post’s title – I don’t think we’re going to move to a “client centric” web though. These technologies are just bringing much better client support back to the web app. At work, I’m always chatting to folks about how web apps run “on the web” ..not just a client or server :)

Joeri++ from me too – especially on the webgl side. I can’t wait to start messing with webgl.

Comment by andyidsinga — June 18, 2010

Nice Article.
How about a slightly related post on the topic of scaling JS Frameworks? I know HTML5 can do wonders for that, but in the meanwhile, for the rest of the world? For instance, if one has to scale extjs (I love extjs – but just using that as an example), the markup and the css are so intertwined that creating an over-sized button / tab requires hand stands :)

Comment by kram — June 19, 2010

@Joeri : PHP don’t run real-time UI on a ARM 7 processor with 256 Megabytes of RAM and no virtual memory. I’m sorry, but VM include very useful and convenient programming features at a cost.

One example : iPhone’s most well-known UI component is the table view, fluidly scrolling rich graphical elements when the user slide his finger on top of it. Tell me how would something like that be able to run using today’s HTML / javascript on the same kind of slow hardware with the same kind of fluidity. Once again, every fancy GUI javascript demo i’ve seen is painfully slow on mobile devices.

VM, and especially garbage collection is also why, in my opinion, you don’t see the same fluidity on Android Java apps as in iPhone. Another hint toward that is that Apple didn’t include garbage collection in iphone’s sdk (only manual reference counter), although it is present in MacOS X. That must be for a reason.

Comment by BgSimple — June 21, 2010

@BgSimple: Phones are a different discussion. I was talking about the desktop. Even then, phones are catching up fast to desktops in hardware. The newer crop are all 1 ghz devices with 512 mb ram. That’s fast enough for a VM.
Fluid scrolling has _nothing_ to do with being native code. It’s a matter of offering an API to hardware-accelerate panning a surface within a clipping region, which is exactly what the iphone does with css animations. For example, here’s a fancy javascript demo that’s not painfully slow:
Apple doesn’t add garbage collection to the iphone’s sdk because the way it was added to objective-c isn’t all that useful. Objective-c was designed a quarter of a century ago, and allowing a garbage collector wasn’t part of its design parameters. The best they could do after the fact was refcounting, which is a close facsimile but not the same thing.

Comment by Joeri — June 21, 2010

@joeri : The problem with tableview is not only a matter of updating the graphical parts, it’s a matter of memory management. You can’t load data for all the cells of the table at the same time because you’re memory constrained and have no memory “swapping”, so you’ll have to create those cells “on the fly”. But then you’re faced to memory allocation being extremely slow on those devices. Cocoa provides a very carefully designed API to let you reuse cells, optimize image loading into memory, etc… Memory management is one of the reason why videogames are still programmed using low-level languages. It’s a pre-requisite whenever you’re dealing with advanced UI.

Yet, I completely agree with you when you say that it’s just a matter of time until those mobile devices become powerful enough to handle the overhead of modern programming languages features. My original post talked about apps ruling for the next 2 years, not forever.

PS : objective-c does support garbage collection, but only on the MacOSX API, so I think it has nothing to do with the language. They do provide what they call “autorelease pools” on the iphone sdk, but they warn developers against using it all the time, since this has a cost.

Comment by BgSimple — June 22, 2010

I still don’t see the problem with replicating tableview in javascript. You can use the same “load+render data subsets on demand” trick there. The ExtJS live grid component does this:
My point is simply that there is nothing “magical” about native code. Any design trick to offer better performance that is available to you in native code is also available to you in managed code.

Comment by Joeri — June 22, 2010

Leave a comment

You must be logged in to post a comment.