Article says people wanted native apps on top of iOS because the Javascript engine was slow.

That's not the only or the most important reason - the integration of the browser with core functionalities of the iPhone (like location awareness, taking pictures, uploading those pictures, handling keyboard input) -- absolutely sucked and still sucks. Creating a web app on the iPhone that has to behave like a regular app, with some of the core iPhone standard functionalities, goes somewhere between an exercise in frustration and impossible.

And another reason - Apple clearly provided (useful) native apps, with which you could never integrate, or if the integration is available (like dialing a phone number, or opening Google Maps), iOS doesn't return the user to the originating app.

Building something like Skype in the browser would be clearly doable, if only Apple provided the hooks. Otherwise the only web apps you're going to see on the iPhone are the traditional web apps, minus important functionality available on the desktop (like you're not able to upload freakin' images, or focus automatically on freakin' form inputs; how fucked up is that?).

I'm fairly certain that Apple's suggestion (for building web apps) was tongue-in-cheek, more as in "get off my lawn".

People got native apps because hackers were like "neat!" and cracked that sucker wide open. Apple stemmed the loss somewhat by offering a path for native apps.

Then everybody was like "neat!"

The difference between then and now is HTML5. Particularly the parts of HTML5 that Google has been pushing. Webcam integration, video, webgl, canvas, svg, gps, etc etc etc

You can now write software on the web that can do anything non-web software can do. The only issue for Google has been that it wasn't written yet ... so they wrote it. That's what Google Apps is about.

They also pushed Angry Birds on Chrome for a reason and made it free. Games are an integral part of the experience. Ro.me is also along that vein. Hardware acceleration was the last piece of the puzzle.

They are definitely in position for success, although that is certainly no guarantee of it.

As an analogy, tablet devices took two decades and at least 5 attempts.

The steam engine took hundreds of attempts and at least 2000 years.

I think that leasing plans (such as the $20/mo student plan) and the fact that all your data is stored on the cloud are bigger factors here.

There's more to Google's new approach than just a browser-based OS. Hardware is completely interchangeable, and the prospect of accessing all your data anywhere has become increasingly popular in recent time.

The WebOS example is reaching. It's still an OS with local apps, just with a web technology stack to build the apps. It also has tight web integration, but it's not overly different than using webviews in iOS or Android for local apps except that there was no native architecture language support initially. I don't think you can blame the HTML/CSS/JS toolset for Palms's lackluster market performance.

Yeah, all 4 of the examples are reaching, really. There hasn't been anything like Chrome. Chrome doesn't offer any non web apps. Even the FileManager is html/js.

Except for NaCl.

Apart from the fact that the necessary web APIs have only recently started to materialize, it's taken this long because it's taken this long for developers to "get it".

Programming multi-user software that spans the network, i.e. is partition-tolerant, is different to the last few decades of single-user, single-node software we've been writing. It's a new paradigm. We've known about the fallacies of distributed computing for some time. But as developers we're taking our time coming to understand them.

For example, there are very few web apps today that can manage the synchronization/consistency/migration/offline access/memory/authorization/versioning/database implications of say 4GB of text data per user on multiple devices, whilst facilitating sharing between hundreds of user accounts.

It's Distributed Systems 101. Up until now, these ideas have been tried out in privately managed data-centers. Now they must be rolled out to the web and the code must run in different browsers on devices of varying capability. The frameworks for doing that do not yet exist. They're being built.

The Virgin Webplayer (http://en.wikipedia.org/wiki/Virgin_Webplayer) was actually very, very similar to the Chromebook.

  • It was cheap and even free for many of us 
  • It came with an internet connection included
  • It only ran applications off the web

This article sounds like someone who hasn't actually even used a chrome os device. The utility of the chrome book vanishes dramatically when you aren't on the web the notebook is useless.

As the guy in charge of the NYT web app said at a Google I/O session a few days ago "These are the worst web apps you'll ever see. Think about that.", implying that even the webapps that impress the most right now, are the worst we'll ever see and we should see much better ones in the near future.

This is just the beginning. Six or 12 months from now we should see a lot more web apps that use offline cache and be completely usable offline.

I love how you just need to "download" the Angry Birds web app in Chrome, and later you can play it directly just like you would play a native game on a PC, offline.

well as the device exists now, you cannot even finish booting/logging in without internet access.

Untrue. I have a cr48, and after you've done the initial setup it is possible to boot and log into your Google account before the wifi kicks in.

Yes you can; you only need internet for the initial setup.

I don't understand how someone can count that as a downside, realistically.

That's like saying your browser doesn't do much if you're not connected to the net, or your fireplace doesn't work without wood. Of course it doesn't, why would it? Google's not misleading anyone about what a Chromebook can and can't do, you know going in that they're pretty much just web browsers.

And, to be fair, the things even come with 100MB of cell-network access each month for free (on the not-just-wifi versions anyway).

I am surprised to find a lot resistance to the idea of chromebooks on HN. They are not chasing the market. They are creating in a space that the market is only currently lukewarm. They are creating and letting the market move to them.

And what (computing) use is an iPhone or WebOS without network? Calculator?

At least I can use an iPhone or a WebOS as a notepad.

Google removed offline support from google docs last year, but they are bringing it back now.

This is the fifth attempt, if you count Oracle's Network Computer from the late 1990s: http://en.wikipedia.org/wiki/Network_Computer

The NC was a thin-client, where apps would run over the network.

There have been lots of thin-clients around.

Yes, the NC (or at least the models I saw back in the day) was basically an X Windows station with a Java engine bolted on.

It's also, in a larger and more historical sense, the bastard child of the dickless X workstation. Which is quite an achievement for that old eunuch, come to think of it.

It is interesting that he says the Everex machines (from 2007) were "pretty much intended as a way to get up and running in your Chrome browser".

It's funny how quickly things get ingrained into us, such that we barely remember not having them (Chrome was introduced in late 2008).

Isn't NaCl the backdoor into this problem?

App Cache is more of a backdoor than NaCl. Web apps using NaCl are still reliant on network connectivity, they just use native code.

I think NaCl is the least likely product to survive in this equation. It feels like Google Gears in 2007.

That's a good point, it kinda does.