Slashdot Mirror
The Future of Google Chrome
TRNick writes "Lars Bak, who heads up development of Google Chrome's cornerstone javascript engine, talks about why Google is so focused on in-browser javascript performance, the role Chrome has played in driving up javascript performance in other browsers, and why it's taking so long to introduce support for third-party extensions. 'The web is becoming an integral part of the computer and the basic distinction between the OS and the browser doesn't matter very much any more,' he says."
Being uninstalled?
is that its future per se doesn't matter.
What Google cares about is that there is a least one standards-compliant browser out there with fast javascript. Sure Google might have a slight preference for people using Chrome over another browser with fast javascript (like, say, Safari), but what really matters to them is that they are able to deliver web apps that are fast enough to be reasonable competitors to traditional desktop apps.
Chrome is a combination insurance policy/open-source soapbox whose purpose is to make sure that Google apps (and other web apps) will always have a browser to run on.
Expected time to finish is 1 hour and 60 minutes.
With compilers like GWT, Pyjamas, and HotRuby, I sometimes wonder if JavaScript is starting to emerge as a "portable assembly language" for dynamic languages, the way C is often used by higher-level language compilers. I mean, when it comes down to it JS is basically just hash tables and closures, some of the basic elements required for dynamic language execution.
Given a fast-as-C javascript engine, you could have a pretty decent VM to share between several dynamic languages, and due to JS's dynamic nature compiling these languages to JS is fairly trivial.
I mentioned this once on reddit and someone called it a 'braindead' approach. That may be true. I'm not sure. He also pointed out that many things you'd have to do to get languages like Ruby running in JS would require passing the context as a function argument, which he claimed would probably bypass any potential optimization by the JS compiler. Not sure about that either.
But I find it really interesting (and cool!) that JS's heavy web presence is giving it such attention in both the "compiler backend" and optimization departments simultaneously. Whether it's a braindead approach or not, it sure seems to be drawing a lot of interest lately.
incidentally, you may be unaware of the distinction made in the UK between pants and trousers, i.e. that pants are what one wears under trousers.
Rule of Slashdot #0: You and people like you are not representative of the larger population. - A.C.
Call me ignorant, or rash, or just living on the edge, but I actually use it on a daily basis for *almost everything. I haven't installed FF on this (brand new) machine and don't plan on it simply due to its bloat and slowness - things it didn't have when it was introduced.
Chrome introduced features which IE and FF either have since included as well or are planned for future releases. I am certainly aware that Chrome is quite limited in some areas, but in the end its speed, flexibility, small memory footprint, and physical layout (minimal intrusion into the web page display area) make it my first choice despite its drawbacks. Feel free to correct me where I may be ignorant (seriously, no sarcasm intended).
*Every now and then I find a web app that's just not well coded (mostly due to funky CSS that's poorly formed) that works or at least displays properly in IE but not Chrome. C'est la vie.
For conscience is the wound, and there's naught to staunch it
This is why Superman dresses as he does. He landed in America, and was told to wear his pants on the outside.
Too late. Google Docs is already here, a JavaScript word processor with real-time collaboration features.
http://pixelcort.com/