Macrobius
09-06-08, 00:38
The big internet story this week is of course Google's new entry in the browser market, Chrome. Many reviews are upbeat, pointing to the technical innovations, the fast and responsive interface, and the minimalist, 'clean start' approach to the design that, quiet rightly in 2008, re-invents the browser. The launch was certainly a marketing coup as well -- the comic book and Google's global advertising reach translated into 1-2% market share in a day, making the browser the 4th most popular browser on the internet on its very first day, behind only IE, FireFox, and Safari. All this and opened source too (well, if it can be compiled and re-distributed by someone).
And that's where the good news for Google ends. We'll ignore, for the moment, the quickly corrected faux pas in the End User Licence Agreement (EULA). We'll sidestep the griping about beta quality code and cut to the chase -- what does it mean? It means that the battle for the client side is over, and Google has lost.
Here we have a company worth billions, with an 80% share of online advertising revenue -- a Microsoft-esque monopoly in its 0wned space, possessed of technologists without peer -- executing a what appears to be a multi-year project. Parts of it went well, but let's take a more jaundiced and experienced look at what was accomplished and what was not. Brilliant execution for a lesser player can still be a defeat for the likes of Google. We have higher expectations when you say 'billions of dollars' than for even a largish corporation.
Let's tally up the score with a few observations:
-- All the early gripes centred around Flash. Flash (and other plugins as if they mattered) don't work as well as they might. This means early adopters will eventually abandon their new pash for something that works. Middle adopters will never materialise. If Google can't fix it, this is a deal-killer. It's not as if Flash is an optional luxury. For many users, it is the entire point of the web.
-- Leave aside the security flaws (old Safari version, others just as amateurish) that earned, rightly, Google the world's quickest 'Do Not Deploy' directive from every large corporation on the planet -- at least about the fastest I've seen. We're talking sluggish bureaucracies moving at crisis speed here. Enterprise IT will crack down on this baby faster than you can imagine.
I know one company -- think many tens of thousands of desktops -- that had 200 unauthorised downloads the first day. That earned every 'early adopter' engineer who couldn't way for the company vetting process -- and this company uses a *lot* of Open Source -- a nasty job-threatening email. This isn't blind-eye wink wink time. This is Network Ops will act decisively or die time and believe me they know it. The proxies will detect browser versions and block it cold by hand manually, if they have to. Business will 'Just Say NO to Chrome!' for any number of reasons. This is *very* bad for Google. Why release a product that alienates all of Enterprise IT on its very first day??! Do you think this will happen if Flash 10 beta isn't approved by management yet? Did it happen a few months ago for FireFox 3? Only the wusses, puritans, and pansies cared about unauthorised stealth downloads of those -- this one, they'll care. There's a *reason* for that. The security flat out sucks. This in a product that is actually quite innovative about browser security -- and rightly so. It's time for change.
-- Then there are the nagging privacy issues: the EULA (which was corrected), the key strokes going to a search engine -- usually Google but Yahoo! or Microsoft if you choose -- the 404 pages that get 'help' from Google (alerting them to what you were surfing that you wanted to be there, but wasn't), and I'm sure the list goes on.
-- Far worse is the lack of innovation in the rendering engine. This is smart for a smaller company, and dumb for Google. We laugh when the best a 'playa' like Yahoo! can do is borrow the Hadoop map-reduce implementation for their 'search' engine. It's the sort of thing that has 'snigger snigger' written all over it. A proprietary company that can't implement a core technology, and resorts to an open source copycat is frankly Number Two -- and that means A Loser. As in, NOTHING. Google just did that with Safari/Webkit. That means, on the client side, they're NOTHING.
Now, there are a *couple* mitigating factors here (but easily dismissed), which I will discuss in due course: the innovative multiprocess design is really sharp, and the tie in with Google Android is certainly of the essence. But there is nothing in the project -- especially an open source project -- that the competition will not be able to adopt, and use to move even further ahead of Google than they are today -- which is to say, at least a year, probably a light-year.
Unless, of course Google plays patent wars. But then they can't pretend to be Open Source, can they? And that, I think, is the only redeeming factor here.
Let's add in a bit to the jaundice-flavoured colouring by comparing Google to Adobe's Integrated Runtime (AIR), to see what Adobe today has that Google doesn't and probably won't. Adobe has Flash -- the poor Flash execution out of the box is, as I said, a deal killer for pretty much everyone, eventually. Hell, Google *owns* YouTube. Has anything bigger than YouTube happened on the net, in like the past decade? Certainly no one among the masses who aren't early adopters. YouTube redefined Media Concentration. It (and the iPod and iPhone) entirely re-defined the purpose of the web, so far as everyone under 30 is concerned. You'd think Google would *get* the importance of Flash, at least in general terms.
Guess what: Adobe's AIR works with Flash. It eats PDF for lunch. Guess what browser AIR offers as a widget or control? They use WebKit. If it works on Google, it works on AIR. I've tried Google's tech on AIR -- works like a dream. Chrome won't work any time soon; AIR does and has for a year. Game over.
Now AIR is a proprietary (but also zero cost) runtime -- like Sun's Java. Gee -- a lot of enterprises use Java for some reason. Cheap development, free runtime, commercial support. Now, AIR is not Open Source. Google can play Open Source hero if they want -- but does Linux own the Desktop? By so much, Google will own the client side. By so much, Enterprise IT will care. In other words: NOT.
Adobe understands the importance of Asian markets -- of CJKV languages and others, of Unicode and all that. Even Sun got that. Will Google work better than Adobe in that area? I sure doubt it.
Now, Google's releasing of a *product* (with a comic book no less) was smart marketing, compared to Adobe AIR's developer-centric SDK release -- but there are a lot of AIR applications out there. AIR runs on MacOS X and Linux today -- Google doesn't. Adobe has technology that beats Google today, and they are about a *year* ahead, in terms of developer base, market, everything that counts. Not to mention they have a working implementation and Google, for all it's billions, just issued amateurish proof they probably never will.
That reminds me that Adobe should do the obvious -- build a 'Chrome clone' with their WebKit browser widget, just to remind the early-adopter world it can be done, and show how much better it can integrate with Flash and all that. If Google's multiprocess design and Webkit-running-on-the-bare metal is a performance win they can't match for some reason, then read the source and fix AIR and Flex libraries. There's nothing Google's shipping today you can't read the source for, if I understand it right. Adobe should raise the ante, get in the game, call, and then raise the stakes. Microsoft eats Open Source for lunch using the same technique. A *serious* client-side company will do that. Did I mention that Adobe AIR displays PDF files like a dream? Of course it does. Adobe understands the client side. In such a bidding war, Google will go bust -- they have no hole card on the client side.
And speaking of runtimes, Adobe has one -- that's what AIR is, after all. Does Google have one? Now I'll bet Google *gets* virtual. In fact, their Android phone has it in spades -- a smart Java ME implementation called 'The Dalvik'. But, the Dalvik was never intended to scale to the desktop, and besides it's just Java, really. *Another* copy.
Now, maybe Google's disdain for a virtual machine (except on a cell phone??!) is merited by the performance. But then they aren't shipping today on MacOS, on Linux, or on the iPhone are they? Like I said: Chrome is irrelevant to the future of client-side tech.
This is a very bad thing, for Google -- bad because Android is Google's big client-side play to begin with! -- portability of the 'legacy' desktop and web applications to mobile target platforms, and most especially the Android, is the only reason Chrome exists. Obviously, a smaller browser component and more capable (read: not hobbled) application environment is the wave the future -- we didn't need Google to tell us that. The VM and the Browser App has to be small enough to run on a cell phone battery-powered CPU, and that's really, really small in a world where IE8 is bigger, codewise, than Windows XP. The browser needs to stop being an entire platform, and become an application again. Users are *dying* for responsiveness on low-memory, lesser-CPU platforms. They want all that, and Ajax too.
Small means fast, and Chrome is damn fast, like any other light-weight browser component in its space. Yes, we will give up some CSS compliance to get it -- good call Google. But. But. But. Who the hell is going to buy the Android instead of an iPhone? It's another Java-based cell offering, dead from the get-go. You can quote me in January.
Google owns the server, but they don't own the client. Microsoft couldn't own the server -- but they owned the client for a long time. Victory -- even the absolute sort of grind-your-enemies-into-the-dust-and-sprinkle-them-on-your-breakfast-cereal-
the-next-morning victory, like Microsoft and Google have shown us, *in* their fields of competence, is not enough to conquer how the other half live. Google has flat out *lost* the client side. They don't get it. Not even close.
The problem with Google's play is that the desktop is a problem to be solved for them, not something they are willing to deign to like, and they have no solution for it but illusory standardisation -- that old developers' shibboleth. Google would *like* us all to write to the Chrome platform. But we won't -- because our users won't let us. Let's think a bit about users: they'll bitch about every little thing. No mouse gestures? Goodbye. Doesn't support my favourite plugin? Adios. But I *like* Firefox extension such and such. Why do you think 'quirks mode' exists? WTF does Google think all that CSS compliance about, and browser sniffing? Yahoo! at least understands that part, and gives us (http://developer.yahoo.com) the libraries to make it work -- even for Safari, Google. It's about the end user. They won't *let* us not support their whims, their quirks, and yes -- every damned bug that has ever been worked around, in a backwater website, somewhere in Backward Compatible Global Hypertext Creation. You don't get to ignore that. Even if you *are* Google.
Now you may think I've been critical of Google so far in this review -- but I haven't even gotten started. What I've been throwing so far are the soft balls, the things they might fix. Let's talk about the *real* problems. Let's start with what they didn't do.
Ouch. They missed an opportunity: what is their strategy again? Make everything JavaScript, and then run the easy performance gain, for native code. It reminds me of the Google Widget Toolkit (GWT) -- take JavaScript, call it a problem to be solved, and build a compiler to makes Java Swing into JavaScript. JS as assembler. JS as Intermediate Language (IL). Now we see the rest of the vision: JS as intermediate language is where Google is going, positioning JavaScript between Java (or whatever) and Assembler. This is just Dot-Net all over again, with all that implies for platform lock-in. OK -- so far so good.
But guess what -- JavaScript is ECMAScript, and Adobe is already there with the IL-on-a-VM shtick. They have ECMAScript too, only they call it ActionScript3 (Flex is free and Open Source, together with their proprietary extensions to show they have their thinking caps on for this one). They have a Java-like VM for it too -- called AIR. Remember that part about being a year ahead? Google is copycat again, only they just cobble together other peoples' tech and retread it, like Yahoo! with Hadoop. Again. Clear evidence they are clueless, and have lost. Right out of the gate.
But that's not the bad part: Google could have been innovative. They *could* (for billions of dollars and years of effort remember) given us something to separate Presentation from their intermediate language, or IL. They could have learned from such innovative Open Source projects as ZK or Echo2/3 (nextapp.com), what is becoming clearer to us now, that the server side generates *only presentation*. We need an intermediate language yes -- so we can interpret it, not at the client (like Chrome), but at the server.
I know Google understands Inversion of Control -- they build Guice after all -- but do they get this? This is basic MVC design. All that criticism from the user comes down to this: the user has to have a pluggable presentation, or some sort of interpreted intermediate code that caters to every presentation-side whim. Standardising on WebKit -- a non-compliant browser as far as CSS is concerned, which is a regression from even FireFox -- just won't cut it. There is no way to satisfy the user except to learn that we have to compile to a presentation-centric intermediate language. This is what Adobe taught us with PDF. You can make documents [read: presentation] portable, but the cost is you have to have the Distiller phase. The runtime works on every platform -- but every platform, every printer, has its quirks. Define the intermediate language, and let the presentation side presentation be built from the IL with drivers, with plugins.
Google could have given us a Distiller for the client side, and a nice assembler-based runtime, the equivalent of Distiller/Reader, with a defined format to write to (like compressed PostScript, which we call PDF). They could even use their compiled JavaScript as the IL if they wanted -- but they didn't. Not even close.
Google basically made the same mistake Sun did with its first, Java 1.0 AWT -- they gave us a cookie-cutter, one side fits all, client-side implementation, and asked us to embrace portability at the expense of all the quirky behaviour we, the users, demand. Guess what -- no one uses Applets today, and the AWT is dead. Chrome and WebKit will be too, unless we learn that.
So far, I've been negative. Google has indeed proven beyond a shadow of a doubt it is clueless on the client side. Now let's talk Server -- and the story is entirely different there, of course. There, Google is not clueless, but smart. Scary Smart. First, we have the multiprocess design -- this proves that Google thinks, effortlessly, about scalability. They just taught us all a lesson. The Desktop is dead -- and Microsoft is really, really dead. So listen up.
Let's think about what we just learned: browsers function better as a swarm of processes. We can launch one, and see it for ourselves now. We may have understood it in an abstract, theoretical way a week ago, but after Chrome, we know it in our bones. The computing world can never be the same. Chrome did that, and that is something. It is a lot more than nothing, this Google Chrome.
Imagine, if you will, your home network with say four computers on it, connected by a hodge-podge of wire and wireless connections, and hooked up to a dual WAN router with no less than two ISPs -- because you are the very model of the modern major telecommuter, and you cannot live if just one ISP goes South. Certainly, I can't.
So let's learn this lesson well: suppose you replace those computers with Linux running an 'Single System Image' (SSI) like OpenMosix, that is a grid or cluster -- this is what Google eats for lunch. They have about 500,000 at a guess. You have 4. Now, they just taught you your browser is a swarm of processes -- and they did that because they are farming out tasks, with Google Gears, to several processes -- one for your GUI, of course, but also worker processes to manage downloads, AJAX callbacks, indexing of webpages, background invasion of your privacy, whatever they want.
Did you get that? You could use *all four* of your computers simultaneously to browse. Is your wife and one child doing something else? Their computer is an idle resource. It has a network card. As an SSI, your process could run on their computer, and with a bit of tweaking use multiple network interface cards (NICs), and a bonded channel -- you have two ISPs after all -- to make your home network into a SuperBrowser that would be responsive beyond your wildest dreams. You can 'level the load' across your available resources, or even those of all your neighbours, to get a better experience for all of you. Wow.
What does this mean for the White Race? Google is the enemy of course -- one big corporation, a single point of failure, one place to control us all. But we have to learn their tech -- their way of thinking. They own the server.
On the server, we are all playing catchup. The string of techs is simply amazing: map-reduce, BigTable, sawzall, a distributed file system, task management. We see the fruit of that thinking in everything they release -- the APIs, Google Gears, the GWT. We see copy-cat wannabes like Hadoop (map-reduce), HyperTable, Yahoo! Pig Latin (sawzall).
The whole world is playing catch up. We are learning -- yet after all, even 500,000 nodes is a small fraction of 700 million CPUs. The Source is open, and we will learn because we have to. But one thing we don't have to bother with: Google doesn't get the client side. Thank God.
And that's where the good news for Google ends. We'll ignore, for the moment, the quickly corrected faux pas in the End User Licence Agreement (EULA). We'll sidestep the griping about beta quality code and cut to the chase -- what does it mean? It means that the battle for the client side is over, and Google has lost.
Here we have a company worth billions, with an 80% share of online advertising revenue -- a Microsoft-esque monopoly in its 0wned space, possessed of technologists without peer -- executing a what appears to be a multi-year project. Parts of it went well, but let's take a more jaundiced and experienced look at what was accomplished and what was not. Brilliant execution for a lesser player can still be a defeat for the likes of Google. We have higher expectations when you say 'billions of dollars' than for even a largish corporation.
Let's tally up the score with a few observations:
-- All the early gripes centred around Flash. Flash (and other plugins as if they mattered) don't work as well as they might. This means early adopters will eventually abandon their new pash for something that works. Middle adopters will never materialise. If Google can't fix it, this is a deal-killer. It's not as if Flash is an optional luxury. For many users, it is the entire point of the web.
-- Leave aside the security flaws (old Safari version, others just as amateurish) that earned, rightly, Google the world's quickest 'Do Not Deploy' directive from every large corporation on the planet -- at least about the fastest I've seen. We're talking sluggish bureaucracies moving at crisis speed here. Enterprise IT will crack down on this baby faster than you can imagine.
I know one company -- think many tens of thousands of desktops -- that had 200 unauthorised downloads the first day. That earned every 'early adopter' engineer who couldn't way for the company vetting process -- and this company uses a *lot* of Open Source -- a nasty job-threatening email. This isn't blind-eye wink wink time. This is Network Ops will act decisively or die time and believe me they know it. The proxies will detect browser versions and block it cold by hand manually, if they have to. Business will 'Just Say NO to Chrome!' for any number of reasons. This is *very* bad for Google. Why release a product that alienates all of Enterprise IT on its very first day??! Do you think this will happen if Flash 10 beta isn't approved by management yet? Did it happen a few months ago for FireFox 3? Only the wusses, puritans, and pansies cared about unauthorised stealth downloads of those -- this one, they'll care. There's a *reason* for that. The security flat out sucks. This in a product that is actually quite innovative about browser security -- and rightly so. It's time for change.
-- Then there are the nagging privacy issues: the EULA (which was corrected), the key strokes going to a search engine -- usually Google but Yahoo! or Microsoft if you choose -- the 404 pages that get 'help' from Google (alerting them to what you were surfing that you wanted to be there, but wasn't), and I'm sure the list goes on.
-- Far worse is the lack of innovation in the rendering engine. This is smart for a smaller company, and dumb for Google. We laugh when the best a 'playa' like Yahoo! can do is borrow the Hadoop map-reduce implementation for their 'search' engine. It's the sort of thing that has 'snigger snigger' written all over it. A proprietary company that can't implement a core technology, and resorts to an open source copycat is frankly Number Two -- and that means A Loser. As in, NOTHING. Google just did that with Safari/Webkit. That means, on the client side, they're NOTHING.
Now, there are a *couple* mitigating factors here (but easily dismissed), which I will discuss in due course: the innovative multiprocess design is really sharp, and the tie in with Google Android is certainly of the essence. But there is nothing in the project -- especially an open source project -- that the competition will not be able to adopt, and use to move even further ahead of Google than they are today -- which is to say, at least a year, probably a light-year.
Unless, of course Google plays patent wars. But then they can't pretend to be Open Source, can they? And that, I think, is the only redeeming factor here.
Let's add in a bit to the jaundice-flavoured colouring by comparing Google to Adobe's Integrated Runtime (AIR), to see what Adobe today has that Google doesn't and probably won't. Adobe has Flash -- the poor Flash execution out of the box is, as I said, a deal killer for pretty much everyone, eventually. Hell, Google *owns* YouTube. Has anything bigger than YouTube happened on the net, in like the past decade? Certainly no one among the masses who aren't early adopters. YouTube redefined Media Concentration. It (and the iPod and iPhone) entirely re-defined the purpose of the web, so far as everyone under 30 is concerned. You'd think Google would *get* the importance of Flash, at least in general terms.
Guess what: Adobe's AIR works with Flash. It eats PDF for lunch. Guess what browser AIR offers as a widget or control? They use WebKit. If it works on Google, it works on AIR. I've tried Google's tech on AIR -- works like a dream. Chrome won't work any time soon; AIR does and has for a year. Game over.
Now AIR is a proprietary (but also zero cost) runtime -- like Sun's Java. Gee -- a lot of enterprises use Java for some reason. Cheap development, free runtime, commercial support. Now, AIR is not Open Source. Google can play Open Source hero if they want -- but does Linux own the Desktop? By so much, Google will own the client side. By so much, Enterprise IT will care. In other words: NOT.
Adobe understands the importance of Asian markets -- of CJKV languages and others, of Unicode and all that. Even Sun got that. Will Google work better than Adobe in that area? I sure doubt it.
Now, Google's releasing of a *product* (with a comic book no less) was smart marketing, compared to Adobe AIR's developer-centric SDK release -- but there are a lot of AIR applications out there. AIR runs on MacOS X and Linux today -- Google doesn't. Adobe has technology that beats Google today, and they are about a *year* ahead, in terms of developer base, market, everything that counts. Not to mention they have a working implementation and Google, for all it's billions, just issued amateurish proof they probably never will.
That reminds me that Adobe should do the obvious -- build a 'Chrome clone' with their WebKit browser widget, just to remind the early-adopter world it can be done, and show how much better it can integrate with Flash and all that. If Google's multiprocess design and Webkit-running-on-the-bare metal is a performance win they can't match for some reason, then read the source and fix AIR and Flex libraries. There's nothing Google's shipping today you can't read the source for, if I understand it right. Adobe should raise the ante, get in the game, call, and then raise the stakes. Microsoft eats Open Source for lunch using the same technique. A *serious* client-side company will do that. Did I mention that Adobe AIR displays PDF files like a dream? Of course it does. Adobe understands the client side. In such a bidding war, Google will go bust -- they have no hole card on the client side.
And speaking of runtimes, Adobe has one -- that's what AIR is, after all. Does Google have one? Now I'll bet Google *gets* virtual. In fact, their Android phone has it in spades -- a smart Java ME implementation called 'The Dalvik'. But, the Dalvik was never intended to scale to the desktop, and besides it's just Java, really. *Another* copy.
Now, maybe Google's disdain for a virtual machine (except on a cell phone??!) is merited by the performance. But then they aren't shipping today on MacOS, on Linux, or on the iPhone are they? Like I said: Chrome is irrelevant to the future of client-side tech.
This is a very bad thing, for Google -- bad because Android is Google's big client-side play to begin with! -- portability of the 'legacy' desktop and web applications to mobile target platforms, and most especially the Android, is the only reason Chrome exists. Obviously, a smaller browser component and more capable (read: not hobbled) application environment is the wave the future -- we didn't need Google to tell us that. The VM and the Browser App has to be small enough to run on a cell phone battery-powered CPU, and that's really, really small in a world where IE8 is bigger, codewise, than Windows XP. The browser needs to stop being an entire platform, and become an application again. Users are *dying* for responsiveness on low-memory, lesser-CPU platforms. They want all that, and Ajax too.
Small means fast, and Chrome is damn fast, like any other light-weight browser component in its space. Yes, we will give up some CSS compliance to get it -- good call Google. But. But. But. Who the hell is going to buy the Android instead of an iPhone? It's another Java-based cell offering, dead from the get-go. You can quote me in January.
Google owns the server, but they don't own the client. Microsoft couldn't own the server -- but they owned the client for a long time. Victory -- even the absolute sort of grind-your-enemies-into-the-dust-and-sprinkle-them-on-your-breakfast-cereal-
the-next-morning victory, like Microsoft and Google have shown us, *in* their fields of competence, is not enough to conquer how the other half live. Google has flat out *lost* the client side. They don't get it. Not even close.
The problem with Google's play is that the desktop is a problem to be solved for them, not something they are willing to deign to like, and they have no solution for it but illusory standardisation -- that old developers' shibboleth. Google would *like* us all to write to the Chrome platform. But we won't -- because our users won't let us. Let's think a bit about users: they'll bitch about every little thing. No mouse gestures? Goodbye. Doesn't support my favourite plugin? Adios. But I *like* Firefox extension such and such. Why do you think 'quirks mode' exists? WTF does Google think all that CSS compliance about, and browser sniffing? Yahoo! at least understands that part, and gives us (http://developer.yahoo.com) the libraries to make it work -- even for Safari, Google. It's about the end user. They won't *let* us not support their whims, their quirks, and yes -- every damned bug that has ever been worked around, in a backwater website, somewhere in Backward Compatible Global Hypertext Creation. You don't get to ignore that. Even if you *are* Google.
Now you may think I've been critical of Google so far in this review -- but I haven't even gotten started. What I've been throwing so far are the soft balls, the things they might fix. Let's talk about the *real* problems. Let's start with what they didn't do.
Ouch. They missed an opportunity: what is their strategy again? Make everything JavaScript, and then run the easy performance gain, for native code. It reminds me of the Google Widget Toolkit (GWT) -- take JavaScript, call it a problem to be solved, and build a compiler to makes Java Swing into JavaScript. JS as assembler. JS as Intermediate Language (IL). Now we see the rest of the vision: JS as intermediate language is where Google is going, positioning JavaScript between Java (or whatever) and Assembler. This is just Dot-Net all over again, with all that implies for platform lock-in. OK -- so far so good.
But guess what -- JavaScript is ECMAScript, and Adobe is already there with the IL-on-a-VM shtick. They have ECMAScript too, only they call it ActionScript3 (Flex is free and Open Source, together with their proprietary extensions to show they have their thinking caps on for this one). They have a Java-like VM for it too -- called AIR. Remember that part about being a year ahead? Google is copycat again, only they just cobble together other peoples' tech and retread it, like Yahoo! with Hadoop. Again. Clear evidence they are clueless, and have lost. Right out of the gate.
But that's not the bad part: Google could have been innovative. They *could* (for billions of dollars and years of effort remember) given us something to separate Presentation from their intermediate language, or IL. They could have learned from such innovative Open Source projects as ZK or Echo2/3 (nextapp.com), what is becoming clearer to us now, that the server side generates *only presentation*. We need an intermediate language yes -- so we can interpret it, not at the client (like Chrome), but at the server.
I know Google understands Inversion of Control -- they build Guice after all -- but do they get this? This is basic MVC design. All that criticism from the user comes down to this: the user has to have a pluggable presentation, or some sort of interpreted intermediate code that caters to every presentation-side whim. Standardising on WebKit -- a non-compliant browser as far as CSS is concerned, which is a regression from even FireFox -- just won't cut it. There is no way to satisfy the user except to learn that we have to compile to a presentation-centric intermediate language. This is what Adobe taught us with PDF. You can make documents [read: presentation] portable, but the cost is you have to have the Distiller phase. The runtime works on every platform -- but every platform, every printer, has its quirks. Define the intermediate language, and let the presentation side presentation be built from the IL with drivers, with plugins.
Google could have given us a Distiller for the client side, and a nice assembler-based runtime, the equivalent of Distiller/Reader, with a defined format to write to (like compressed PostScript, which we call PDF). They could even use their compiled JavaScript as the IL if they wanted -- but they didn't. Not even close.
Google basically made the same mistake Sun did with its first, Java 1.0 AWT -- they gave us a cookie-cutter, one side fits all, client-side implementation, and asked us to embrace portability at the expense of all the quirky behaviour we, the users, demand. Guess what -- no one uses Applets today, and the AWT is dead. Chrome and WebKit will be too, unless we learn that.
So far, I've been negative. Google has indeed proven beyond a shadow of a doubt it is clueless on the client side. Now let's talk Server -- and the story is entirely different there, of course. There, Google is not clueless, but smart. Scary Smart. First, we have the multiprocess design -- this proves that Google thinks, effortlessly, about scalability. They just taught us all a lesson. The Desktop is dead -- and Microsoft is really, really dead. So listen up.
Let's think about what we just learned: browsers function better as a swarm of processes. We can launch one, and see it for ourselves now. We may have understood it in an abstract, theoretical way a week ago, but after Chrome, we know it in our bones. The computing world can never be the same. Chrome did that, and that is something. It is a lot more than nothing, this Google Chrome.
Imagine, if you will, your home network with say four computers on it, connected by a hodge-podge of wire and wireless connections, and hooked up to a dual WAN router with no less than two ISPs -- because you are the very model of the modern major telecommuter, and you cannot live if just one ISP goes South. Certainly, I can't.
So let's learn this lesson well: suppose you replace those computers with Linux running an 'Single System Image' (SSI) like OpenMosix, that is a grid or cluster -- this is what Google eats for lunch. They have about 500,000 at a guess. You have 4. Now, they just taught you your browser is a swarm of processes -- and they did that because they are farming out tasks, with Google Gears, to several processes -- one for your GUI, of course, but also worker processes to manage downloads, AJAX callbacks, indexing of webpages, background invasion of your privacy, whatever they want.
Did you get that? You could use *all four* of your computers simultaneously to browse. Is your wife and one child doing something else? Their computer is an idle resource. It has a network card. As an SSI, your process could run on their computer, and with a bit of tweaking use multiple network interface cards (NICs), and a bonded channel -- you have two ISPs after all -- to make your home network into a SuperBrowser that would be responsive beyond your wildest dreams. You can 'level the load' across your available resources, or even those of all your neighbours, to get a better experience for all of you. Wow.
What does this mean for the White Race? Google is the enemy of course -- one big corporation, a single point of failure, one place to control us all. But we have to learn their tech -- their way of thinking. They own the server.
On the server, we are all playing catchup. The string of techs is simply amazing: map-reduce, BigTable, sawzall, a distributed file system, task management. We see the fruit of that thinking in everything they release -- the APIs, Google Gears, the GWT. We see copy-cat wannabes like Hadoop (map-reduce), HyperTable, Yahoo! Pig Latin (sawzall).
The whole world is playing catch up. We are learning -- yet after all, even 500,000 nodes is a small fraction of 700 million CPUs. The Source is open, and we will learn because we have to. But one thing we don't have to bother with: Google doesn't get the client side. Thank God.