July 11, 2009

chrome os follow-up

John Gruber over at Dring Fireball says, "It makes no sense to me why Chrome OS isn’t based on Android. "

I wonder whether he though about and discounted (and if so, why?) the seemingly obvious reason, that Android is a Java platform and Chrome OS is intended to be an Open Web (HTML+CSS+images+JavaScript) platform.

If that's not an obvious distinction and sensible differentiation to smart folks like John, maybe I'm the one that's missing the right answer here.

Still, it sounds to me like Android is a platform for installed Java apps and Chrome OS is supposed to be a platform for hosted Open Web apps. Java really isn't at all the same thing as Open Web tech. Local and remote apps aren't really the same thing either.

I think this is Google betting on the Open Web, the way the that Palm did with WebOS on the Pre, rather than betting on native apps the way Apple, Linux, and Microsoft have.

Posted by asa at 5:24 PM

 

reactions, thoughts, comments, etc.

well, Apple also tried to bet on web apps with its original iPhone, but that obviously failed, so they opened up to native apps in iPhone 2.0

I think Google has also left themselves a chance of native apps when they decide to build the Native Client thing into their Chrome browser, so if the whole web apps thing flounders again, they can open up to native apps too.

Posted by: soshimi | July 11, 2009 7:31 PM

Very good analysis, Asa. I hadn't heard that angle on the Chrome OS move yet. And good point, soshimi about the first iPhone. However...maybe Apple was too early? I think people are warming up more and more to web based applications. But developers...not sure. I think if Google allows enough interaction with the machine through web based Chrome apps, it will work. One of Apple's problems was (and continues to be) that they restrict developers too much. If Google has little to no restrictions (while keeping things secure, of course), I think Chrome OS could work.

Posted by: Jake Munson | July 11, 2009 8:05 PM

soshimi, yeah. Apple tried with the iPhone in June of 2007. Google appears to be ready to try again with Chrome OS in July or August of 2010. A lot can change in three years. Web capabilities are already significantly better than they were two years ago and they're moving quite a bit faster than they were then too.

Palm Pre seems to be doing OK with Web apps and they're doing it right, I think. They're not saying "native apps for us, Web apps for you" like Apple did with the iPhone launch. Palm is actually building its apps using Web tech.

I'm actually kind of excited that Google's going to give this a shot. I don't think it will have any earth-shattering effects on the incumbent OS vendors, but it's going to test Web capabilities and expose (hopefully for fixing by the modern browser vendors) where Web capabilities are not up to par with the desktop.

- A

Posted by: Asa Dotzler | July 11, 2009 8:06 PM

Hi Asa,

Why couldn't Android be engineered to do the extra bit of running Open Web Apps? Lots of J2EE app servers already do that!!!

Regards,
Ravi

Posted by: Ravi | July 11, 2009 8:12 PM

Ravi, if you were trying to build the best possible Web-based OS, why would you carry along an entire native platform with all of its downsides just to hide it from the user. If the real goal is a native web platform, you don't want any of that other stuff.

What APIs are missing from the Web? What can't you access on the computer/device through a Web app that you need to? What drove iPhone developers away from Safari as the platform and to native apps? Let's fix those things. Let's add those capabilities to the Web and we'll soon have a platform that doesn't just work well for tiny mobile devices like the Pre, but for much more general purpose computing.

- A

Posted by: Asa Dotzler | July 11, 2009 8:34 PM

Well Andy of Android told that the reason is because Android has to do some stuff like managing network, taking excepitonal care of batteries, etc. which netbooks don't. It doesn't seem to me like good answer - if Android does this, what is the problem in disabling this and launching Chrome OS? And the same goes about its ability to run Java applications - its just ability, and you should be able to stripe it.

I think that main point is scalability - Google claims that Android is OS that should work not just on smartphones, but on feature phones as well (though it is just a claim, we currently have only 2-3 Android smartphones, many more announced, and no news on any feature phone). And while nebooks and smartphones are coming increasingly closer in hardware, feature phones are still far away, and I don't think you can expect the same OS to scale well on both platforms.

Posted by: Ivan Ičin | July 11, 2009 11:54 PM

John Grubers main point is that Google now has two platforms to serve. Sure, Chrome OS is based on the Chrome browser, which Google will develop anyway, but it still creates two distinct user communities (Chrome OS and Android).

Yes, Apple tried to base the iPhone on web apps and failed, but Google is also a web app provider. I see Chrome OS mainly as a way to push Google app suite. I have no doubt more web apps are on the way

So, maybe Google truly plans to serve to distinct communities. Chrome OS could work very nicely on cheap office workstations with a enterprise edition of the Google apps, while Android would serve the far more dynamic market for private telecom devices.

Posted by: ADAXL | July 12, 2009 1:56 AM

I don't know whether Google will be successful.

But I can say, that Microsoft failed to make MS-Windows a real consumer
product.

When I worked for Philips Electronics, they explained some case about
Philips Audio. The Philips engineers always tried to copy Sony (comparable
with Microsoft now copying Apple). The Philips brand is just less sexy than
Sony. However, the market share of Philips Audio that time was twice as
Sony. So, they changed their policy and targeted the average user, instead
of copying Sony. The change was highly profitable.

Currently, it is still a problem to learn someone of age 70+ to operate a
computer.

So, I don't whether Chrome OS is the answer, I do agree with Google, that
there is a market gap, that Microsoft fails to take.

I would like an OS with the following properties:
- Fast start
- Open, if I want Firefox, I should be able to run Firefox.
- Installation fully supervised by OS. No installers that messes up your
computer. I want clear few what is run at startup and easy removal of it,
without getting a dis-functioning PC. That is only possible with installers
supervised by OS software.
- Good security model. A word processor with a bug, should not be a security
risk.

Lucas

Posted by: Lucas | July 12, 2009 10:36 AM

Is HTML5 powerful enough that you can have a phone conversation through a webpage? Because until it is, you'll still need Android for smartphones.

In order to make a website into a phone, the browser needs:
* native audio
* native access to microphone
* realtime streaming in both directions
* a notification system for incoming calls even when the webpage is not open
* (probably) peer to peer support for audio traffic, instead of via a web server

Hopefully one day browsers will be good enough to handle all this but even by 2010 it won't all be ready yet.

Posted by: Chris | July 12, 2009 1:23 PM

Chris, there are plug-in based solutions for soft phones running in a browser. There's nothing preventing browsers from adding that native capability in the future.

Google hasn't shown any reticence about including plug-in solutions so I'd imagine if they thought that this was important for Chrome OS, they'd build it or use a 3rd party solution.

HTML 5 is _my_ ideal Web platform, but Google's been OK with building and using plug-ins so I think it's a stretch to suggest that a Chrome OS wouldn't be able to do this because it's not a part of HTML 5 (yet?)

- A

Posted by: Asa Dotzler | July 12, 2009 2:54 PM

The main problem is whther HTML5+CSS3 will be able to come out of wroking draft status in 2010? I doubt they'll be finalized any time soon.

Also I don't think the web browsers are developing as fast as you think. Even in 2010, I doubt Chrome will have anything near full HTML5, CSS3, SVG 1.2, and ECMAScript 5th Edition support.

Another problem about web apps is that you have to do it in HTML+CSS+Javascript (and possibly SVG), which is much more cubersome than, say, just C++ or Java. And it means a lot of existing developers will have to throw their current programming/developing experiences away and learn web app developing from the start again.

Posted by: Hikerseven | July 12, 2009 7:44 PM

Hikeseven, you think there are more C++ programmers than Web programmers? I think that's highly unlikely.

I think you're also mistaken if you think that HTML 5 and CSS3 have to be completed standards before there are very functional implementations. In many cases, the implementations are what prompted the specifications.

I'm not saying this is a slam dunk and I'm not discounting the hurdles. I'm just saying that I think that's where Google's headed with this thing and that I don't think it's unreasonable.

(By the way, did you know that the majority of the Firefox application front end is written using XML, CSS, and JavaScript? It is, and it works pretty well. Want to know why there are like 10,000 extensions for Firefox and only a handful for IE? Because there are a lot more Web developers than C++ developers.)

- A

Posted by: Asa Dotzler | July 12, 2009 8:12 PM

There are many web developers, sure, but most of the web apps are currently much simpler than native apps. And I do think there are more C++/Java developers than HTML+CSS+Javascript developers. Even for web developers, there are many who mostly code in Java, C#, php, etc.

and to develop extensions for Firefox, one needs to use XUL, something that doesn't work on non-Mozilla platform. Again you have to learn a new language that only works in Mozilla platform. And a lot of those more complex Firefox extensions contains native code (Cooliris/PicLens for example).

The thing is, currently the underlying technologies behind web apps are so uncertain, and vary greatly from implementation to implementation, for example even if I want to implement something as simple as border-radius, I have to write different lines for webkit and gecko, and I don't know if that can be settled by 2011.

So if you write a web app that uses some experimental implementations of HTML5+CSS3, then it won't be cross-browser compatible, and it may just break when the final specs come out. In the end you have to go back to the lowest common denominator if you want to ensure your web apps actually work for most of the people.

On another note, it seems client-side storage is removed from the latest version of the HTML5 spec.

I doubt pure web apps (ie. without plugins) can match native apps in terms of feature and functionality in five years time. And it's hard to attract developers to code complex apps for the HTML+CSS+Javascript(+SVG?) platform when they don't know when the more advanced features can be supported by all the major browsers/clients. At least when they make a Flash app (which is also coded in ECMAScript), they know it'll work as long as the flash plugin is installed.

Posted by: Hikerseven | July 12, 2009 10:05 PM

"I doubt pure web apps (ie. without plugins) can match native apps in terms of feature and functionality in five years time."

Google Maps destroys Microsoft Encarta Atlas or any other local atlas app I've ever used, ever. Gmail kicks Outlook Express' butt. Facebook is lightyears ahead of any desktop IM and email client for an entire generation of users. Flickr and Photobucket trounce my local photo album software. BaseCamp beats any desktop PM clients I've used. Delicious beats most Web browser client bookmark managers.

Salesforce and Zimbra and the list goes on and on.

Ask anyone in the travel industry about their native apps versus Kayak or Orbitz. Ask anyone in the Real Estate industry about their native apps versus Zillow.

And don't even get me started on search services, dictionaries, translation services, encyclopedias, and all the other Web apps that have wiped out entire lines of desktop software.

Web apps are already kicking native app butt in terms of features and functionality. It's just not evenly distributed yet and it's not all about performance or UI features.

- A

Posted by: Asa Dotzler | July 12, 2009 10:41 PM

"Google Maps destroys Microsoft Encarta Atlas or any other local atlas app I've ever used, ever. Gmail kicks Outlook Express' butt. Facebook is lightyears ahead of any desktop IM and email client for an entire generation of users. Flickr and Photobucket trounce my local photo album software. BaseCamp beats any desktop PM clients I've used. Delicious beats most Web browser client bookmark managers."

You are mistaking online services with web apps. And native apps does NOT mean local apps. Google Maps/Gmail/Facebook/Flickr/Photobucket/Delicious are all great online services, but that doesn't mean they are better than native apps. For example I use Thunderbird to access and organize emails, Thunderbird is a native app, it can access gmail the online service, and the gmail web app is really not that good at organizing emails. And although Flickr/Photobucket are great online image hosting service, their image management web apps are not nearly as good and full featured as image management native apps like Picasa.

"Salesforce and Zimbra and the list goes on and on.

Ask anyone in the travel industry about their native apps versus Kayak or Orbitz. Ask anyone in the Real Estate industry about their native apps versus Zillow.

And don't even get me started on search services, dictionaries, translation services, encyclopedias, and all the other Web apps that have wiped out entire lines of desktop software."

Again, like you yourself have said, those are online services, not web apps. And as long as those online services provide open APIs, you can code native apps to access info from those online services too.

"Web apps are already kicking native app butt in terms of features and functionality. It's just not evenly distributed yet and it's not all about performance or UI features. "

Nope, your examples are just showing that online services are providing features and functionality impossible for local storage media, that's nothing about web apps against native apps. Of course now we have internet, we have much better access to information than when we could only rely on local storage media. Those online services are great, but those online web apps that access the services are still quite primitive in comparison to native apps, for example Google's own web app for accessing the gmail service is nowhere near the feature and functionality of Thunderbird.

Posted by: Hikerseven | July 12, 2009 11:23 PM

Hikerseven, I just disagree with you that these apps are primitive.

I use Gmail's web app AND Thunderbird to access Gmail and the web app kicks ass. It's a much more intuitive interface with easier features that do more than my Thunderbird. (Not to mention that searching is blazing f'ing fast at Gmail and dog slow in Thunderbird) The same for Google Maps' interface. I find it far superior to the desktop atlas apps I've used. What it loses in performance, it more than makes up for in features -- features that haven't and aren't coming to native clients! It's a better interface AND it has more capabilities for being a hosted service.

You are drawing a line that doesn't exist in the minds of 99% of the population. My wife looks at Facebook as an application that replaces her desktop IM client, most of her email needs, and much of her local photo gallery needs. She views her Google calendar as far more useful to the native client calendar that came with her laptop. She _prefers_ the interface of these apps and their capabilities. She's more comfortable with these interfaces. She gets more done and uses them more often than she did their native desktop counterparts. It's a better experience. They are better apps.

They're not just Web services waiting for a native app to come along. They are Web apps with great interfaces and lots of great features.

I think that if you spent some time with people who aren't likely to read blogs like this and pontificate over Google's vaporware, people whose first experience with computers was with Web-connected computers, people in their 20s, for example, you'd have a very different view on all of this.

- A

Posted by: Asa Dotzler | July 12, 2009 11:45 PM

Oh, and find me a better feed reader than Google Reader. I've tried every desktop feed reader for Mac and Windows and none of them come close for almost every use case for feed reading that I have.

And because it was kind of buried in there, I want to repeat, Gmail's "native" search kicks the shit out of Thunderbird searching Gmail via IMAP. Also Gmail's archiving feature is way more intuitive and much easier to use than Thunderbird's. And Gmail's filters are easier and it's autocomplete is better and moving messages just destroys Thunderbird in terms of speed and its conversation view is lightyears ahead of Thunderbird in terms of interface design. Come to think of it, I can't think of anywhere, other than multiple account aggregation, that Thunderbird actually beats Gmail.

- A

Posted by: Asa Dotzler | July 12, 2009 11:52 PM

searching gmail in its native interface is faster than IMAP access has little to do with the quality of the apps, but more about the fact that it's accessing Google's own servers directly instead of via IMAP access.

And Google Reader is a very primitive RSS reader that lacks a LOT of features and functionality. For example it doesn't support title image and descriptions, it doesn't allow three-panel layout, lack of customizations, etc.

It looks like you are saying those web apps are better not because they have more feature and functionality, but because they are connected to internet and they have simpler interface. Now first there's no rule saying native apps can't connect to internet. Heck browsers themselves are native apps that connects to internet. And second there's no rule saying you can't make a native app with a simple, streamlined UI, just that most native apps out there has more complex UI and more customization ability. Besides UI design has nothing to do with whether it's web app or native app.

And your examples actually show currently that web apps are more primitive and simple than native apps. all those web apps you mentioned, email client, RSS reader, photo gallery, IM, etc. are indeed simple apps. Their functionality are mostly just fetching data and present those data to the users. They don't need to access advanced hardware features, they don't need to have complex manipulation and computation with those data. Basically those web apps you have described here are little more than some simple UIs that display some data fetched from online sources.

Like I said, the main advantage of those web apps are actually their respective online services. yes they have some nice-looking simple web apps to interface with those online services, and the fact that they integrate directly with those online services and running on their own servers can make interaction easier. But that doesn't mean they have more features and functionality. Unless the online service providers intentionally block certain features from third-party client, those features and functionality can be just as easily done in native apps.

But it's not the other way around, for more complex apps like Photoshop, 3D Studio, 3D Games, Video Calling/Meeting etc. It'd be near impossible to implement those kind of complex apps in the current HTML+CSS+Javascript platform. Plugins, maybe, like Quake Live.

The fact is, for those web apps, it's easy to implement them in native apps, you don't really see them in native apps is either because those web apps are already sufficient, or those online services block certain features from third-party access. After all those online services get money from online ads, so they'd want you to use their web apps to see their ads.

It'd be ridiculous to say Google Search is a great web app, since it's just some HTML forms that retrieves data from Google's server and displays them in lists, with some ads added. The real work is the data mining and indexing part, which is run in Google's servers. Same to Google Maps, and actually Google has a more complex native client to the Google Maps data, called Google Earth.

Posted by: hikerseven | July 13, 2009 1:03 AM

hikerseven, you're making at least four arguments I think are silly.

First, you're saying that because someone might or could make a native desktop app to rival my actual and real web app that the actual and real web apps aren't superior to their imaginary and hypothetical desktop rivals. When there's an awesome desktop client for Facebook, please let me know.

Second, you're claiming that Web services which do have Web apps and don't have popular desktop clients are not actually Web apps but are a distinct thing called Web services. Pretty much everyone on the planet but you sees them as the same thing.

Third, you're claiming simpler and faster is worse than more complicated and slower. How many users does Thunderbird have compared to Gmail? Perhaps you were one of the SeaMonkey users complaining when we replaced it with the faster and simpler (and yes, less featureful) Firefox browser?

and finally, you're claiming that a few professional, enterprise, or specialty desktop apps that haven't been replicated well (or at all) in Web apps proves that native apps are better. What percentage of computer users do you think depend on PhotoShop and 3D Studio?

I disagree with all four of those assertions and I think if you were to poll the fastest growing segments of computer users today, they'd back me up. You and I are being replaced by younger and more Web happy users and their needs are already moving to the front and pushing yours and mine to the back.

- A

Posted by: Asa Dotzler | July 13, 2009 1:42 AM

Oh, I somehow missed your final paragraph when I read through the first time.

"It'd be ridiculous to say Google Search is a great web app, since it's just some HTML forms that retrieves data from Google's server and displays them in lists, with some ads added."

I access it in a Web browser exclusively and so do about a billion other users. I interact with it with a mouse and a keyboard. It even stores my preferences for me so when I return, it behaves the way I've customized it. It's a Web app. You can dispute that all you want, but your semantic argument doesn't hold water with any but the geekiest among us.

"The real work is the data mining and indexing part, which is run in Google's servers."

Indeed. But so what. That means it will probably be a faster app than if it was running on my local machine. It's got all the Google hardware that surely beats my lowly laptop. Another win for Web apps -- powerful hardware.

"Same to Google Maps, and actually Google has a more complex native client to the Google Maps data, called Google Earth."

Great point. Google Earth is a lot more complex and complicated and difficult to use and caters to a much smaller audience. Perhaps you'd like to follow up by telling me what you think is the ratio of Google Earth desktop app users is to Google Maps Web app users. :D

Web applications are winning. You can't undo that with semantics.

- A

Posted by: Asa Dotzler | July 13, 2009 1:52 AM

Asa, you obviously can't read what others are actually saying, but keeps imagining things.

"First, you're saying that because someone might or could make a native desktop app to rival my actual and real web app that the actual and real web apps aren't superior to their imaginary and hypothetical desktop rivals. When there's an awesome desktop client for Facebook, please let me know."

It's not about some "imaginary and hypothetical desktop rivals" of yours, but the fact that all the features and functionality of web apps can be done in native apps, but not vice versa.

After all the web apps and the whole HTML+CSS+Javascript platform are just running on top of native apps called web browsers, all their features and functionality are in the end realized by native apps. So it's basically logic that native apps can implement all the features and functionality of web apps, but the current HTML+CSS+Javascript platform lacks many advanced features and functionality of native apps.

"Second, you're claiming that Web services which do have Web apps and don't have popular desktop clients are not actually Web apps but are a distinct thing called Web services. Pretty much everyone on the planet but you sees them as the same thing. "

I never said anything like that, you are imagining things. I said there are online services, and the online service providers also provide simple web apps as clients to interface with their online services. Some of them also provide APIs for third party client access, some don't. Pretty much everyone on the planet but you knows email servers and email clients are different things. The gmail service is the server, the gmail web app is a client to the service, and Thunderbird can also act as a client to the service.

Your "Web services which do have Web apps and don't have popular desktop clients are not actually Web apps" is just nonsense and self-contradictory. online services and web apps are two different things. One can provide online service but not any web apps as online client, so you have to use some native client to access the service. Or one can provide online service and their own web apps as a client to their service. online services are online services, web apps are web apps, you are trying to talk those two different things like one and the same, which is wrong. When you use Thunderbird to access gmail, you are not using the gmail web app client, but you are still using the gmail service. Simple as that.

"Third, you're claiming simpler and faster is worse than more complicated and slower. How many users does Thunderbird have compared to Gmail? Perhaps you were one of the SeaMonkey users complaining when we replaced it with the faster and simpler (and yes, less featureful) Firefox browser? "

Again you are imagining things. I didn't say anything about being "worse". I only said that native apps can implement more features and functionality than the current web apps platform. You need to read better. Whether you decide to make a simpler app (Firefox) or a more complex app (SeaMonkey), that's design decision, not platform capability.

"and finally, you're claiming that a few professional, enterprise, or specialty desktop apps that haven't been replicated well (or at all) in Web apps proves that native apps are better. What percentage of computer users do you think depend on PhotoShop and 3D Studio? "

It seems you keep helplessly imagining things. I haven't said anything about whatever being "better". How good an application is depends on how well it is designed and developed, but I was talking about the platform's capability. I said "I doubt pure web apps (ie. without plugins) can match native apps in terms of feature and functionality in five years time." and it's a fact that the current HTML+CSS+Javascript platform can't match native apps in terms of feature and functionality, and I doubt it will be able to implement the more advanced feature and functionality of the native platform any time soon. And the existence of "professional, enterprise, or specialty desktop apps" with feature and functionality not available to the web platform indeed shows that.

"I disagree with all four of those assertions and I think if you were to poll the fastest growing segments of computer users today, they'd back me up. You and I are being replaced by younger and more Web happy users and their needs are already moving to the front and pushing yours and mine to the back."

All four of those assertions are out of your imaginations.

"I access it in a Web browser exclusively and so do about a billion other users. I interact with it with a mouse and a keyboard. It even stores my preferences for me so when I return, it behaves the way I've customized it. It's a Web app. You can dispute that all you want, but your semantic argument doesn't hold water with any but the geekiest among us. "

You really need to read better. I said "It'd be ridiculous to say Google Search is a great web app", I never said it's not a web app. There's nothing great in some HTML forms that can retrieve some data to display and remember some preferences. The great thing about Google Search is the database backend, not the front end web app. The HTML+CSS+Javascript part of Google Search is web app, just that there's nothing too great about it.

"Indeed. But so what. That means it will probably be a faster app than if it was running on my local machine. It's got all the Google hardware that surely beats my lowly laptop. Another win for Web apps -- powerful hardware."

The data-mining and indexing apps running on Google's powerful servers are not web apps, but native apps. And that has nothing to do with whether the client accessing the search data are web apps or native apps. You can eaisly code a C++ program to access the search data with Google's APIs, and you are still taking advantage of Google's powerful hardware, while the client is a native app. Actually there are lots of native apps out there that embeds Google's search service in them, that they also have the win of Google's powerful hardware and search data. So your "Another win for Web apps -- powerful hardware" is completely wrong, it has nothing to do with being web apps or not, native apps can also access Google's search data and benefit from Google's powerful hardware.

"Great point. Google Earth is a lot more complex and complicated and difficult to use and caters to a much smaller audience. Perhaps you'd like to follow up by telling me what you think is the ratio of Google Earth desktop app users is to Google Maps Web app users. :D "

You are completely (and most likely intentionally) missing the point. The point is that native apps can implement feature and functionality not available to web apps, and Google Earth shows that. The fact is, to realize certain advanced features and functionality, you have to code in native apps, running outside of browser or inside plugins. Perhaps you can tell me what you think is the ratio of Google Earth desktop app users is to Google Maps Web app users, and what that ratio stuff has anything to do with my point here.

"Web applications are winning. You can't undo that with semantics."

Web apps do have a lot of users, they can do simple tasks well, and it has its advantages, mainly as they don't need to download and install (but strictly speaking they are still being downloaded and run in the browser). However the current web apps platform is still quite lacking in terms of feature and functionality compared to native apps, that's why you people are busy adding all kinds of new features to the web platform. And I don't think this situation will change any time soon. And certain things will likely never migrate to the web platform, for example I don't think people will try to implement database engines in Javascript, they'll still use native apps like MySQL and sqlite. And I doubt people will try to implement video/audio decoder in Javascript, they'll just use native decoders.

Anyway considering that the capability of the current HTML+CSS+Javascript platform is still quite lacking compared to native apps platform in terms of features and functionality, and that the cross-browser compatibility for advanced features and functionality in HTML+CSS+Javascript+SVG is still a bitch, and it doesn't look like it'll settle soon. I doubt this whole "web apps only" thing will fare much better for Chrome OS in 2010 than it did for iPhone in 2007.

Posted by: hikerseven | July 13, 2009 4:02 AM

"HTML+CSS+images+JavaScript"

Too big, too complicated, too messy. Sigh.

Posted by: VanillaMozilla | July 13, 2009 5:23 AM

hikerseven, I don't disagree that some existing native apps are better than their existing Web app counterparts. The inverse is also true and more often than not the trend is toward the Web app.

I don't know if Chrome OS will succeed next year. I don't know if Palm's Web OS will succeed this year. I do know they've got a much better shot than iPhone's Safari did a couple of years ago. (in a big part because their vendors are actually genuine about the Web platform)

I still think you fail to understand how regular people see these things. They don't know or care that there are big back-end native apps and databases powering Google's Calendar or Zoho's spreadsheet app. They don't care that Google earth has more bells and whistles than Google Maps. The Web apps, and if you access them in a Web browser they are Web apps, work for hundreds of millions of users, often far outpacing adoption of their desktop counterparts where those counterparts exist.

Regular users don't look at Gmail and think to themselves "this could be so much better if it was a native app." They use it and they like it and they think it's more than sufficient for their needs. That's why Web apps are winning.

You seem to be under the impression that the more capable or technically superior platform matters. It doesn't. What matters is the end user experience and the experience of Web apps is increasingly unmatched for most regular people. Sometimes it's unmatched because an equivalent desktop app doesn't exist, or is priced out of their reach. Sometimes it's unmatched because more and more users don't bother to seek out and use desktop software when their Web apps are sufficient.

That bodes well for the future where most users experience most of their computing in a Web browser. I don't know if Google will have a lot of success (which I define as whole point gains in market share over a few years) with Chrome OS. I think that if they get the user experience right that regular people (who think very differently than you) will not be fretting that their apps are all delivered to them in a browsing context.

- A

Posted by: Asa Dotzler | July 13, 2009 8:22 AM

I am hoping Chrome OS eventually finds its place. We need the competition. I personally am glad they did not base it on Android. Android has its place on mobile phones and such, but for full blown remote apps, I do not want them to be java based. That is why Google had to go a different route.

Posted by: Tattoo Ed | July 15, 2009 10:29 AM

"HTML+CSS+images+JavaScript" Too big, too complicated, too messy. Sigh.

If you think that's "big" and "complicated", you're in for a horrible shock when you try to write a desktop application.

Posted by: ant | July 16, 2009 9:46 AM










Remember personal info?


















asa2008.jpg