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

By: Joeri

Joeri — Tue, 22 Jun 2010 15:18:02 +0000

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: http://www.ext-livegrid.com/
.
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.

By: BgSimple

BgSimple — Tue, 22 Jun 2010 09:19:50 +0000

@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.

By: Joeri

Joeri — Mon, 21 Jun 2010 21:53:46 +0000

@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: http://vimeo.com/12459719
.
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.

By: BgSimple

BgSimple — Mon, 21 Jun 2010 13:36:10 +0000

@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.

By: kram

kram — Sat, 19 Jun 2010 07:26:52 +0000

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 :)

By: andyidsinga

andyidsinga — Fri, 18 Jun 2010 22:49:56 +0000

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.

By: Joeri

Joeri — Fri, 18 Jun 2010 17:28:52 +0000

@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.

By: ThomasHansen

ThomasHansen — Fri, 18 Jun 2010 16:44:35 +0000

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; http://37signals.com/svn/posts/347-youre-not-on-a-fucking-plane-and-if-you-are-it-doesnt-matter
.
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’…
.
…right…?
.
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!

By: BgSimple

BgSimple — Fri, 18 Jun 2010 12:10:17 +0000

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.

By: sixtyseconds

sixtyseconds — Fri, 18 Jun 2010 06:29:04 +0000

Joeri++;

By: Joeri

Joeri — Thu, 17 Jun 2010 21:32:24 +0000

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?

By: CR4

CR4 — Thu, 17 Jun 2010 20:59:19 +0000

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…?)