The Future of Google Chrome 294
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."
<script type="text/python"> (Score:5, Interesting)
I would rather have the browser guys work on getting something OTHER than javascript into the browsers. Javascript is getting better, but you only polish a turd so much.
JavaScript assembly language (Score:5, Interesting)
With compilers like GWT [google.com], Pyjamas [pyjs.org], and HotRuby [accelart.jp], 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.
Re:As we've seen. (Score:5, Interesting)
Re:The whole point of Chrome (Score:5, Interesting)
I think it's more important that it's a challenge to the rest of the 'market' to catch up on Javascript performance. I don't think they -really- expect their browser to be the best or even have a decent market share... They just need something to point to and say 'See, it's possible. Why haven't you done it yet?'
Re: (Score:2, Interesting)
If all JRE's (browsers) are alike in syntax, semantics, security and libraries then the faster one will become the shell of choice to run these cloudy, ajaxy apps. And we'll partying like it's 1980 with browser-and-cloud architectures replacing greenscreen-and-mainframe.
It's a shame that, like you said, javascript is superficially pretty but deeply broken (namespaces? proper, native OO? etc.)
Re:The whole point of Chrome (Score:5, Interesting)
It is interesting the while javascript is being more and more heavily used, it is in a way like development tools have been reset 10 years.
Maybe I have been blind, but I have yet to come across a decent IDE for javascript development. All the nice features like code completion and even syntax checking are now no longer a given.
Even some decent syntax checking would be nice. I would like to know how much time is lost now on developers looking for typos in their js code. The only way you discover them is to run the code. And even then, the errors generated are not always helpful.
And debugging is getting more complicated. Stuff like venkman and firebug work for basic standard linked javascript, but the newer libraries use so many shortcuts in declaring objects that no debuggers just can't seem to keep up.
A lot of this is with any script that is weakly typed. So many libraries and scripts take advantage and abuse this.
Now these same libraries are abstracting so much of what is hard browser differences and the like out. So that is good. But with this only really being at the start of being heavily used. I can see some real ugly legacy applications around in five years time.
And this type of scripting is popping up everywhere, I see servers now that have javascript running on the server, and other devices using them for UI.
Re:annoyed (Score:3, Interesting)
I like how the Japanese do it: year/month/day.
Re:As we've seen. (Score:2, Interesting)
This "the browser is the OS" rubbish is really starting to annoy me. It's just not the case.
This really doesn't signal a change in paradigm in computing. Rather, it signals that many users who don't understand the distinction between local and remote applications have become the majority, and those who understand the distinction are now the minority. Buzzwords like "cloud computing" and "online OS" don't change the fact that this is not a paradigm shift so much as a widespread misperception.
The so-called "browser is the OS" paradigm is simply a use case where the majority of a user's tasks are performed in a browser. Cloud computing really just describes people who use a PC for Facebook more than they use the PC for productive work with a word processor.
I know what you're thinking. Yes, you, thinking "it's just a matter of time until word processors get implemented in JavaScript". Please, I beg you, go and get a vasectomy. For the sake of mankind.
Re:JavaScript assembly language (Score:2, Interesting)
I don't know, Lua [lua.org] would fit that role a whole lot better. It's semantically similar to Javascript but is much cleaner. Javascript is a disgusting hack of a language with bizarre bit and pieces shoehorned into it over the years.
The fastest Javascript engines will never be as fast as the fastest Lua engines. Javascript is too tied down by cruft. LuaJIT already beats every other Javascript engine out there in all tests except a few and it's not even using tracing yet (the fastest JS engines are using tracing). LuaJIT 2 with tracing is supposed to be out at some point here and that will probably blow the doors off everything else.
How about something OTHER than javascript... (Score:4, Interesting)
It seems to me that the browser will not be able to replace the desktop ... or even claim to be an "OS" in anything but the most attenuated sense... until we have the ability to use something other than javascript in a reasonably cross-platform way. Imagine for a second that Windows could only be programmed in Visual Basic, or Linux could only be programmed in C. We'd absolutely hate it, and we'd be right to hate it.
Now, granted, any given development platform generally displays a preference for a given programming language. If you're going to develop Gnome applications, you're probably going to use C, if Cocoa, then Objective C, etc. But right now the situation in the web space is one of total locking to Javascript, which isn't even all that good of a language.
What I really want to see is a reasonable degree of cross-platform support for the use of a reasonable variety of object-oriented scripting languages embedded in the browser, as plugins. So I can develop web pages in HTML + Ruby, or HTML + Python, or HTML + Javascript, as is best suited for my application. The hooks are there in the HTML specs to do this, but browser implementations don't seem to have caught up.
Single platform, then multi, equals fail (Score:3, Interesting)
it's faster to develop for a single platform than to use a shotgun approach.
Yeah, but telling your developers that they can develop for windows only and then porting the application is likely to be a lot slower than writing things portably from day 1.
An argument to back this assertion up: the sooner you fix a bug, the cheaper it is to fix [this is widely believed]. Every dependence on a particular platform that's not put into a platform abstraction layer is a bug. If you develop for every platform all the time, you'll find and fix those bugs immediately, paying the lowest possible price for portability. If you develop for $PLATFORM first and then port, you'll pay the largest possible price for portability.
Re:I know the future... (Score:5, Interesting)
I think it is important to add that Google Chrome already supports add-ons (well, user scripts)... the types that block ads... customize sites... etc... I use these user scripts all the time, and these weren't ones I wrote myself... these are ones written by others.
What Chrome does not yet have is the ability for non-techies to easily find and install these user scripts. That is definitely coming, but everyone just needs to be patient. Also what is coming is the ability for such add-ons to modify and tweak the UI.
Re:How Many People Even Use Chrome? (Score:3, Interesting)
I use it as my primary browser in Windows. The only time I use anything else is when I need to go to the Windows Update site.
You mention the minimal intrusion of menus and taskbars and such. I wish all software was that good at getting the administrative debris out of my way.
When I go back to Safari in OSX I immediately notice the difference between it and Chrome's UI, Chrome is light years better. They've uncomplicated and uncluttered the modern address bar design while keeping it (making it?) actually useful. First letter, tab, search phrase is brilliant. I'm not sure I care one way or the other yet about the screenshot start page but it is growing on me. I like how settings and history and such open as browser tabs rather than dialogs. That pretty much avoids the overextended 'stack of tabs' convention.
I am probably less feature demanding than most Slashdot users. It seems like the first 10 comments in any Chrome story are about the lack of extensions. When I used FF I think I had AdBlock, maybe Forecast Fox, a skin or two. I can see how Chrome wouldn't work if I really really needed the /b/ Toolbar, but since I don't the UI improvements alone sell it.
Comment removed (Score:3, Interesting)