Future of the Web

Nick Carr gives us an insight into the future of the Web from the perspecive of Google's business model. No doubt the Chrome "omnibar" is revolutionary in th esimple way it leverages Google search and index services to extend web surfers experience. Truly great stuff tha tNick ties back into the basic business model of Google. What Nick doesn't cover is how Chorme is desinged to bridge that gap between Web surfing and next generation Web Applications (RiA). Microsoft is in position to dominate this next generation, while Chrome represents Google's first step into the fray. Sure, Google dominates consumer applets and services, but RiA represents a model for enterprise and corporate business systems moving their core to the Web. It's a big shift. And Google has some serious catching up to do.

It's this natural drive to reduce the cost of complements that, more than anything else, explains Google's strategy. Nearly everything the company does, including building big data centers, buying optical fiber, promoting free Wi-Fi access, fighting copyright restrictions, supporting open source software, launching browsers and satellites, and giving away all sorts of Web services and data, is aimed at reducing the cost and expanding the scope of Internet use. Google wants information to be free because as the cost of information falls it makes more money.

The Web spreads its tentacles to yet more new turf.

Matt Assay has posted an interesting article arguing the point of view that Google Chrome will have a difficult time catching up Microsoft SharePoint. While everyone is moving to the Web, many will be surprised ot find that Microsoft is already there. Very surprised.

Good article from Matt Assay

The consensus of the developers who are using WebKit is clear: it's an outstanding rendering engine that lends itself to an extremely diverse assortment of practical uses. It is everywhere, and it is gaining traction at a very impressive rate. That traction is causing some developers to question whether Mozilla's Gecko rendering engine is still relevant.

Historical walkthrough comparing two great rendering engines (layout); Mozilla Gecko and WebKit.

Great insight into Adobe AiR and the transition from browser based surfing to web application building.

Building the Dojo Toolbox allowed us to dive into Adobe® AIR™, and to create a blended toolchain of JavaScript, PHP, Python and Rhino (JavaScript on the Java Virtual Machine) for developing an amazing desktop application using open web technologies. One of the most noticeable things you'll see when moving from typical browser-based development to AIR is that you only have one browser to worry about. Dojo does a great job of masking browser JavaScript API differences, but there are still enough differences in CSS and other aspects of application development that it is somewhat refreshing to only have one platform to develop again. Also, since AIR includes WebKit, it has one of the fastest JavaScript implementations around and offers numerous useful experimental CSS properties that you can use in the AIR context. Apple has invested a lot in WebKit development, and AIR will naturally inherit those benefits when they next upgrade the included WebKit.

There's a change in Google's business model indicated by that last paragraph, sharing Google ad revenues with publishers. Publishers have been suing Google in Europe and the U.S. for indexing their web site news content. Is sharing Google Ad-Sense revenue with publishers the compromise that will bring the world an explosion of information previously unavailable online in easily searchable form? Most newspapers' archives are not available online and with far too many that are, subscriptions are required to search a single newspaper's archives; e.g., the New York Times. Sounds like Google may have its sights set on eroding the information subscription business model that the news business -- along with advertising -- has been built around for centuries. This announcement might mark a paradigm shift.

There were three must see demonstrations at Office 2.0; Adobe Genesis, Joblogs and GE. Genesis and Joblogs are stunning examples of what RiA will mean int he future. GE offered a rather extraordinary example of how collaborative computing changes everything in the workplace. GE' Suk made an interesting statement, "Collaboration is simply a digital version of how a workgroup "works" a business process." Done right, collaboration becomes the business process.

RiA is making the leap from web design to web application by first reinventing the end users "workspace-workgroup" experience. "... The winds of change are blowing through collaborative software, and they're blowing pretty hard. Here at the Office 2.0 conference, Adobe Systems and Joblogs previewed their approaches, which are strikingly similar. They both offer real time collaboration. Both use mash-ups and provide ease of use well beyond today's collaborative systems, which Joblogs founder Steve Ireland described as "workspace 1.0." Both are aimed at the enterprise and seek to provide context around the user's workspace, doing mash-ups (define) of contact databases, e-mail, calendars, photos, and task lists, although Joblogs' application also offers blogs.

Good analysis by Stephen Vaughan-Nichols. He gets it right. Sort of. Stephen believes that Chrome is desinged to kill MSOffice. Maybe, but i think it's way too late for that. IMHO, Chrome is designed to keep Google and the Open Web in the game. A game that Microsoft is likely to run away with. Microsoft has built an easy to use transiton bridge form MSOffice desktop centric "client/server" computing model to a Web centirc but proprietary RiA-WebStack-Cloud model. In short, there is an on going great transtion of traditional client/server apps to an emerging model we might call client/ WebStack-Cloud-RiA /server computing model. As the world shifts from a Web document model to one driven by Web Applications, there is i believe a complimentary shift towards the advantage Micorsoft holds via the desktop "client/server" monopoly. For Microsoft, this is just a transtion. Painful from a monopolist profitability view point - but unavoidably necessary. The transition is no doubt helped by the OOXML <> XAML "Fixed/flow" Silverlight ready conversion component. MS also has a WebStack-Cloud (Mesh) story that has become an unstoppable juggernaut (Exchange/SharePoint/SQL Server as the WebSTack). WebKit based RiA challengers like Adobe Apollo, Google Chrome, and Apple SproutCore-Cocoa have to figure out how to crack into the great transition. MS has succeeded in protecting their MSOffice monopoly until such time as they had all the transtion pieces in place. They have a decided advantage here. It's also painfully obvious that the while the WebKit guys have incredible innovation on their side, they are still years behind the complete desktop to WebStack-RiA-Cloud to device to legacy servers application story Microsoft is now selling into the marketplace. They also are seriously lacking in developer tools. Still, the future of the Open Web hangs in the balance. Rather than trying to kill MSOffice, i would think a better approach would be that of trying to

There are five reasons why Google is doing this, and, if you read the comic book closely - yes, I'm serious - and you know technology you can see the reasons for yourself. These, in turn, lead to what I think is Google's real goal for Chrome.

I'm still keeping the door open on a suspicion that Microsoft may have planned to end the life of MS Office after the new fortress on the server side is ready. The code base is simply too brittle to have a competitive future in the feature wars. I can't get past my belief that if Microsoft saw any future in the traditional client-side office suite, it would have been building a new one a decade ago. Too many serious bugs too deeply buried in spaghetti code to fix; it's far easier to rebuild from the ground up. Word dates to 1984, Excel to 1985, Powerpoint to 1987, All were developed for the Mac, ported years later to Windows. At least Word is still running a deeply flawed 16-bit page layout engine. E.g., page breaks across subdocuments have been broken since Word 1.0. Technology designed to replace yet still largely defined by its predecessor, the IBM Correcting Selectric electro-mechanical typewriter. Mid-80s stand-alone, non-networked computer technology in the World Wide Web era? Where's the future in software architecture developed two decades ago, before the Connected World? I suspect Office's end is near. Microsoft's problem is migrating their locked-in customers to the new fortress on the server side. The bridge is OOXML. In other words, Google doesn't have to kill Office; Microsoft will do that itself. Giving the old cash cow a face lift and fresh coat of lipstick? That's the surest sign that the old cow's owner is keeping a close eye on prices in the commodity hamburger market while squeezing out the last few buckets of milk.

"The Sun Labs Lively Kernel is a new web programming environment developed at Sun Microsystems Laboratories. The Lively Kernel supports desktop-style applications with rich graphics and direct manipulation capabilities, but without the installation or upgrade hassles that conventional desktop applications have. The system is written entirely in the JavaScript programming language, a language supported by all the web browsers, with the intent that the system can run in commercial web browsers without installation or any plug-in components. The system leverages the dynamic characteristics of the JavaScript language to make it possible to create, modify and deploy applications on the fly, using tools built into the system itself. In addition to its application execution capabilities, the Lively Kernel can also function as an integrated development environment (IDE), making the whole system self-sufficient and able to improve and extend itself dynamically....." Too little too late? Interestingly, Lively Kernel is 100% JavaScript. Check out this "motivation" rational: "...The main goal of the Lively Kernel is to bring the same kind of simplicity, generality and flexibility to web programming that we have known in desktop programming for thirty years, but without the installation and upgrade hassles than conventional desktop applications have. The Lively Kernel places a special emphasis on treating web applications as real applications, as opposed to the document-oriented nature of most web applications today. In general, we want to put programming into web development, as opposed to the current weaving of HTML, XML and CSS documents that is also sometimes referred to as programming. ...." I agree with the Web document <> Web Application statement. I think the shift though is one where the RiA frames web documents in a new envirnement, blending in massive amounts of data, streaming media and graphics. The WebKit docuemnt model was designed for this p

ZOHO Speaks about Chrome: "The biggest losers in Google's announcement are not really competing browsers, but competing rich client engines like Flash and Silverlight. As Javascript advances rapidly, it inevitably encroaches on the territory currently held by Flash. Native browser video is likely the last nail in the coffin - and Google needs native browser based video for its own YouTube, so we can be confident Google Chrome and Firefox will both have native video support, with Javascript-accessible VOM (video object model) APIs for web applications to manipuate video. As for Silverlight, let me just say that if Silverlight is the future of web computing, companies like us might as well find another line of work - and I suspect Google and Yahoo probably see it the same way too. More speculatively, I believe we will witness the emergence of Javascript as the dominant language of computing, as it sweeps the client side and starts encroaching on the server. The server landscape today is split between "enterprise" platforms like Java and .NET on the one side (we ourselves are in the Java camp on the server side), and "scripting" languages like PHP, Python, Ruby on the other, with Javascript firmly entrenched on the client. Languages like Ruby promise tremendous dynamism and flexibility to the developer, but their relatively weak execution environments have held them back. It is telling that both Java and .NET come with state of the art just-in-time compilers, while none of the major scripting languages do......" Interestingly, ZOHO already has a prototype running on Chrome! Solves tons of performance problems for them, as well as givign them an on-line / off-line story (Gears). The success of Chrome depends on Chrome "killer apps"; Not browser surfing features! And we already have a number of killer apps that will immediately take advantage of Chrome: gMail, gReader, gMaps and Google Docs! ZOHO will no doubt use Chrome to put themselves squarely i

"What's good for the Internet is good for Google, and the company says its strategic proposition for the newly introduced Chrome browser is: a better platform is needed to deliver a new generation of online applications......." This is one of the best explanations of why Google had to do Chrome i've seen thus far. Kontra also provided some excellent coverage concerning the Future of the Web in a two part article previously published. Here he nails the RiA space, comparing Google Chrome, Apollo (Adobe AiR/Flex/Flash) and Microsoft Silverlight. Chrome is clearly an Open Web play. Apollo and Sivlerlight are proprietary bound in some way. Although it must be said that Apollo implements the SAME WebKit layout engine / WebKit docuemtn model as Google Chrome, Apple Safari-iPhone, Nokia, RiM and the Iris "Smart Phone" browser. The WebKit model is based on advanced HTML, CSS, SVG and JavaScript. Where Adobe goes proprietary is in replacing SVG with the proprietary SWF. The differences between JavaScript and ActionScript are inconsequential to me, especially given the problems at Ecma. One other point not covered by Kontra is the fact that Apollo and Silverlight can run as either browser plugins or standalone runtimes. Wha tthey can't do though is run as sufing browsers. They are clearly for Web Applications. Chome on the other hand re-invents the browser to handle both surfing mode AND RiA. Plus, a Chrome RiA can also run as a plugin in other browsers (Opera and FireFox). Very cool. The last point is that i wouldn't totally discount Apple RiA. They too use WebKit. The differnece is tha tApple uses the SquirrelFish JavaScript JiT with the SproutCore-Cocoa developers framework. This approach is designed to bridge the gap between the OSX desktop/server Cocoa API, and the WebKit-SproutCore API. Chrome uses the V8 JiT. And Adobe uses Tamarin to compile JavaScript-ActionScript. Tamarin was donated to the Mozilla community. If there is anythin that will s

Google released its second web browser yesterday afternoon, adding additional headroom for web applications stretching the limits of what it's possible to accomplish within a web browser. The Google Chrome team assembled domain experts in various fields over the past six years, both through direct hires and acquisitions, to create a new browser and its critical components from scratch. GMail and Google Maps pushed the Web to its limits, taking advantage of browser technologies invented in Redmond but left dormant for far too long. Contributing to Firefox's core, writing browser extensions, and championing HTML could only take the $150 billion company so far: they needed to own the full browser to push their Web efforts forward at full speed.

I've installed and played with Chrome but I'll spare you my review of it. What's more interesting to me and of concern to you is where the Internet is heading as specific client- and server-side technologies (as well as the entities in between) become deeply aligned with one another at the expense of openness. Or should I say Internets?

One new feature I'm particularly excited about is process affinity. The online comic describes each tab as a separate running process. Why is this important? The short answer is robustness. A web application running in your browser, is a lot like an application running on your operating system, with one important distinction: Modern operating systems[1] run applications in their own separate process space, while modern browsers[2] run web applications in the same process space. By running applications in separate processes, the OS can terminate a malicious (or poorly written) application without affecting the rest of the OS. The browser, on the other hand, can't do this. Consequently a single rogue application can suck up mountains of memory and eventually crash your entire browser session, along with every other web application you were using at the time.

Good discussion on why Chrome is a great web application foundation

Yet another wrapper around OpenOffice.org, this time the 3.0 version still in beta. $99.90 per seat for 10 users, Lots of Javascript to give a web collaboration capability. Perhaps most notable so far: [i] a sniff that there's a fair amount of money behind this one; and [ii] an article by Eric Lai says they approached the OOo Project but were rebuffed because they compete with desktop OOo. Support for different browsers planned. an XULRunner plug-in the works. Several mashups mentioned. Claims 80 percent of OOo features available, which is another way of saying that 20 per cent of the features are not supported. Claim that oSays code will be released under GPL. Apparently that's just their custom stuff because OOo 3.0 beta is LGPL. Building a business atop a code base controlled by a malevolent branch of Sun Microsystems seems less than wise. More at zooos.com. Preliminary impression: Like OOo itself, dead end technology that sucks mind and market share from software that supports truly open standards. The world needs to figure out that the OpenDocument format is roughly as open as OOXML. Open standards are fully specified so anyone can implement them.

"The AIR "robot" application connects to a Java backend that controls the robot through Mindstorm's public Java api, and Java and AIR are then glued together through an open source technology called Merapi. Merapi is an open-source project for connecting AIR and Java run by Adam Flater, and is sure to have an exciting future." This is an excellent example of how many applications are using Adobe AiR. Java is used on the backend with the sophisticated Flash GUI on the front

"The biggest rival for Microsoft's next-generation Silverlight web technology will be JavaScript, not Adobe's ubiquitous Flash, according to experts speaking at Microsoft's TechEd conference in Sydney on Friday. " Good article capturing Microsoft's early response to Google Chrome. Not surprisingly they try to pit Chrome against Adobe AiR, and argue that Chrome is a bigger threat to Microsot's XAML-Silverlight RiA than Adobe Flash (AiR). I posted a comment to this article, Divide and Conquer".

Response to two ZDNet articles about Google Chrome. The first article, "Who Wins with Google Chrome" is very positive, but for mostly all the wrong reasons. The second article, "Five reasons why Chrome will crash and burn" is very critical; again for all the wrong reasons. Clearly much of the world doesn't get RiA. Not do they have a clue as to why it's so important to the future of the Open Web.

"We realized that the Web had evolved from mainly simple text pages to rich, interactive applications, and that we needed to completely rethink the browser. What we really needed was not just a browser but also a modern platform for Web pages and applications, and that's what we set out to build," writes Sudar Pichai, Google's vice president for product management on the official Google blog. Beautifully done Google!