Posts Tagged Chrome
Google Chrome OS – the browser is the OS?
Last week Google announced its upcoming OS, Chrome OS. More than the fact that Google is entering the OS market, which was expected, the most significant thing about this announcement is the OS name. Chrome is already the name of the web browser that Google launched 9 months ago.
Chrome is without a doubt the fastest browser in existence. It doesn’t really show in standard static HTML/CSS web pages, however bloated they may be, because I believe all browsers are close to the maximum speed that can be reached when displaying this kind of pages. Where Chrome crushes the competition is when running AJAX applications. The GWT application I’m working on is so much faster on Chrome than any other browser, that you easily forget it’s an AJAX app. Firefox is already much smoother than IE, but Chrome is way ahead in terms of executing JavaScript and giving the user instant feedback. There was a time we considered optimizing the server-side processing or the network usage because we thought that was where most time was lost. Good thing we didn’t, because after trying our application on Chrome, we now know that this would have been useless. The slow parts of or applications were only slow because of inefficient JavaScript execution on IE and (to a lesser extent) Firefox.
So, Chrome gives the best user experience for AJAX apps. But what about the overall computer user experience? Google figured that if you “live on the web”, the OS in you computer is probably getting in the way, because it’s designed to do too many things instead of just letting you get on the web. It’s slow to boot, it’s big, it has a lot of things you don’t need and will never use. So the idea of Google is to remove everything but the bare minimum: a kernel (Linux), a windowing system (no details on that, except it will be “new”) and of course a browser (Chrome). The name Chrome OS was then a logical choice, since the most visible part of this OS will be the Chrome browser.
I read a lot of articles saying that Google was now set to fight Microsoft on the OS field. Is this true? Yes and no. Yes, because it will probably take away a significant part of Microsoft’s business, that is computers that are designed for online access. That includes netbooks, but not only: a large and growing part of computer users “live on the web” and don’t use their computers for anything else. No, because there will still be some use cases where Chrome OS will not be an option: gaming, video editing, development, all CPU-demanding activities. And we’re only talking about desktop users of course.
So we have a OS with a minimal Linux kernel, and adopting web technologies as the main application building bricks… does that remind you of anything? If not, have a look there…
What’s RIA anyway ?
RIA or Rich Internet Applications have been a buzzword for a while now, but it’s hard to find two persons who agree on what it means. It appears the word was coined by Macromedia, now Adobe, when defining the requirements for the new version of their successful browser plug-in (Flash).
Let’s break it down:
- Application: a RIA is an Application, which doesn’t mean much except that it’s not system software. In short, it helps the user do something useful.
- Internet: a RIA uses the Internet. Actually, not necessarily the internet, but more generally speaking a network. What this really means is that the application’s responsibilities are distributed between the user interface and one ore more servers. Exactly what is distributed, how and when is all the difference between various kinds of RIAs. What we are talking about here is presentation, validation, business logic, persistence, etc.
- Rich: a RIA is Rich. This is probably in contrast with web 1.0 page-based applications where the interaction was limited to filling in a form and pressing submit. A RIA is Rich UI-wise, which means it has widgets that are similar to those found in desktop applications: formatted text fields, combo boxes, drop down-menus, tables with sorting and column re-ordering, to name a few.
To sum it up, a RIA is an application, with a near-desktop user interface, that requires a network to one (or more) servers for some (or all) of its functionality. This definition is voluntarily very vague, because many combinations of technology and architecture qualify as RIA.
Based on this definition however, we can refute some ideas that commonly surround RIA:
- RIA applications require a browser plugin: WRONG! It is true that some vendors (Adobe, Microsoft) have chosen to bypass the challenges of browser incompatibilities and poorness of native widgets by providing a plugin (Flash, Silverlight) that gives a uniform look on all (supported) platforms. But the current level of JavaScript implementation in major browsers makes it possible to implement a full-blown RIA in native JavaScript without the use of any plugin. This is even more true now that GWT is there, because GWT will take care of platform differences and let you concentrate on the programming itself. This will be even more true in the future with HTML5.
- RIA applications are necessarily JavaScript-based: WRONG! see above…
- A RIA application is an application that runs in a browser: WRONG! If most RIA applications run in a browser, be it in a plugin or as JavaScript, a Swing-based application launched through JNLP (WebStart) also qualifies as a RIA. And even applications that normally run in a browser can be packaged in such a way that they appear not to (see Prism for example)
- A RIA application only works online: WRONG! This might be true for most RIAs, but it is not a requirement. A RIA application can have an online mode where it communicates with a server, and an offline mode where you work locally, and your work is later synchronized with the server as soon as it becomes available. Google Gears is one of the ways this can be accomplished. And Google Docs is one of the examples of an online/offline RIA.
- A RIA application cannot be integrated into the OS like a native application: WRONG! Tools exist to make any web application (not even necessarily RIA) look like a native application to the user. For example, Prism from Mozilla will let you create an icon for any web page and launch it in its own window, without any browser decoration. Google Chrome will let you do the same right from the browser itself. Adobe Air goes further and provides all the missing “glue” between RIAs (Flex and JavaScript) and the OS, including creating a native shortcut, but also letting the application interact with the OS in ways usually reserved for native apps like drag&drop, access to local storage, etc.
- RIA applications are difficult to develop and debug: WRONG! plugin-based RIAs rely on vendor IDEs that let you develop just like you would develop a desktop app. For JavaScript-based RIAs, GWT lets you develop and debug your application in pure Java, and takes care of translating it to JavaScript for deployment.
All this points to a direction: the line between RIAs and classic desktop application is getting thinner every day. Technologies used for one can now be used for the other, thanks to frameworks such as Adobe Air or GWT. And as a consequence, the user eventually will not be able to tell one from the other. And probably he won’t even care.
