En estos días, varios millones de entusiastas están probando Chrome, el browser de Google (me incluyo), en su primer lanzamiento público. Evidentemente, se ha lanzado una carga de profundidad en el mercado, que, como otros productos de su dueño, apenas comienza, y mucho más veremos.
Geoffrey Wiseman, en InfoQ, publica un breve pero abarcador artículo sobre estado y perspectivas, que es conveniente leer.
En cuanto al escenario en la industria, Wiseman estima:
En su resúmen técnico, Wiseman escribe:
Many people have heralded the launch as the renewal of the browser wars once fought between Microsoft and Netscape / Mozilla (those were the primary contenders, although every browser has its contigent willing to trumpet its strengths). Some are willing to count Chrome out already, while others are adopting a wait and see stance.
Many argue that Google doesn't wish to compete with other browsers, simply to advance the state of network-delivered applications to where they are indistinguishable from desktop applications and in so doing, push the operating system into the background.
In particular, people telling this story love to cast Microsoft in the opposing role, so that one can imagine the two titans clashing.
Por mi parte, no reemplazaré (por ahora) a Firefox, porque aún Chrome es incompleto para algunos de los usos que hoy mantengo en Firefox, pero sus ventajas por ahora son innegables, y en primer lugar, en performance. En Septiembre, la lucha ha comenzado.
The WebKit browser engine began its life as a fork of the KDE project's KHTML and KJS engines by Apple, becoming the basis of the Safari browser. WebKit was later re-adopted by KDE. Google already employs WebKit within their Android mobile phone platform, and it became the obvious solution for them. As the comic introduction to Chrome states:
It uses memory efficiently, was easily adapted to embedded devices, and it was easy for new browser developers to learn to make the code base work. Browsers are complex. One of the things done well with WebKit is that it's kept SIMPLE.
The version of WebKit used in the initial Windows beta seems to be WebKit 525.13, which is not the most recent version, and has some security vulnerabilities (see Security below). Some users have also noticed rendering differences from Safari's WebKit rendering to Chrome's, including antialiasing and shadows. This may be the result of the Skia graphics engine used under the hood.
Talking about the integration with WebKit, the Chromium FAQ says:
The Chromium source code includes a copy of the WebKit source. We frequently snapshot against the WebKit tip of tree or specific branches according to our release needs.
Our goal is to reduce the size and complexity of the differences between the copy we maintain in order to work more effectively as a participant in the WebKit community and also to make periodic updates occur more smoothly.
V8 claims a number of performance improvements and innovations, from fast property access using hidden classes, dynamic machine code generation and efficient garbage collection (stop-the-world, generational, accurate, compacting), small object hreaders, multi-threaded from the ground up. The team that created V8 was headed by Lars Bak, who, as Avi Bryant says, was "the technical lead for both Strongtalk and the HotSpot Java VM, and a huge contributor to the original Self VM" and has a number of VM-related patents to his name.
I think these properties will rapidly make V8 the dominant VM for dynamic languages. It ought to make a great platform for Smalltalk.
Google Gears has also moved into the Chromimum Project, as pointed out in the FAQ:
With Gears as a plug-in to Chromium we're carrying two copies of sqlite and two copies of V8. That's silly. We're integrating the code so Gears can run great in Chromium. We plan to continue to build Gears for other browsers out of the same code base.
Although Google Chrome supports plugins for content handling like Flash and PDF, it does not currently support browser extensions, although that is planned.