Google chrome

Google releasing their own browser. This can be major news, with implications for various projects discussed here. There seems to be a boom in browser innovation recently.

They are apparently going to have their own Javascript VM (supposedly with JIT, and better GC). They implemented process isolation and sandboxing. This will clearly go in the direction of being a platform for application development (the relation to Android is intriguing). However, support for end-user client-side scripting (e.g., Greasemonkey) is not mentioned.

This is a developing story, as they say. I posted my thoughts about a google programming environment (and DSL) several times here. This may be a step in that direction.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

iPhone web apps

This sounds a project similar to what Apple did with the iPhone initially, posing the web browser as the application platform before the native SDK was released. There were some problems with that as I remember.

Maybe the same will happen with the Google platform, it will start out in the browser then the development target will end up on our desktop.

Is Javascript ready to take the world?

I'm waiting for Google to come up with...

..their own programming language.


I'm surprised they haven't attempted such a thing already--at least not publicly and on large scale. Given the nexus of intellectual and market prowess there, google could certainly pull off one that is both technically excellent, and gets lots of market penetration real quickly.

Getting back to the topic of this thread--this is an interesting development. For one thing--what will this mean for Mozilla and Firefox, especially if both browsers are open-source projects? How will it affect, if at all, future development of web-centric languages such as Javascript? And will Google at some point attempt to lay the proverbial smack on things like Flash, and other widespread but still-proprietary technologies?

Isn't python something like that...

... with GvR on board and all?

Not yet.

I haven't seen any attempt to expand Python outside of its server-side niche.

Now, if chrome were to provide native support for a client side scripting language besides JS--that might be indicative of something. But I suspect that an attempt by Google to abandon/hijack a well established standard for the web ecosystem would nowadays be met with the same disdain were MS to try it (again).

Do we need one?

The question is really do we need another scripting language? What does JS lack as a programming language? I'm not flamebaiting here, looking for a serious discussion.

JS' main problem has been poor performance and Google seems to be attacking that (and quite effectively). (X)HTML+CSS is also becoming closer and closer to being a very good UI layout language imho.

The attempt to use Python

The attempt to use Python (and Ruby) as a client-side scripting language in a browser is actually pretty well-known - it's Silverlight, specifically the upcoming version 2.0.

Actually, they are smart

Actually, they are smart enough not to enter this market directly. The closest you'll find is GWT (coming soon: chrome support). Comparing that with the Microsoft strategy is left as an exercise to the reader...

The MS strategy...

appears to be to continue to introduce dependencies on the Windows ecosystem. MS has some interesting and useful technology, including work done by SPJ and others (to keep this post kinda on topic), unfortunately, MS still insist in bundling it all up into a dreadnought operating system. Most of MS' products and technologies have equivalents in the free software ecosystem, as well as on the Macintosh platform--inertia seems to be paying the bills in Redmond these days.

Google's fundamental strategy appears to be to attract and retain eyeballs--their barrier to entry is the vast array of computational power, network bandwidth, and other resources; as well as a treasure trove of data they keep to themselves. There is no credible alternative to Google at the moment, at least not in the US (I can't speak of ASPs/search engines/advert servers located overseas, like Baidu in China). Yahoo tries, but hasn't "gotten it" for so long that it's probably too late for them.

Google has learned one important lesson from Microsoft in the latter's heyday--the care and feeding of developers is very important.

I do find it interesting though that despite the prominence of Peter Norvig (a longtime Lisp guru) in the Google technical hierarchy; so much server-side code is reportedly written in C++. *That* is kinda where I'd expect to see Google doing innovative work in programming languages--large scale distributed systems are one area not well served by any of the existing production languages--as opposed to an attempt to displace Javascript on the client.

previously on LtU

I'm waiting for Google to come up with...
..their own programming language.

Sawzall - a popular language at Google

I also recommend searching

I also recommend searching the archives for GWT.

the google chrome comic

From a didactic perspective, the google chrome comic is one of the coolest illustrated descriptions of a technical subject I've had the pleasure of reading.
Google chrome comic
I especially liked the panels with the javascript source code to internal representation transformation (little eye viewing the source code), and the browser memory allocation pictures.


It's really well done.

And here's a nice LtU angle: "...instead of multiple threads, what if we have multiple processes? Each having its own memory and its own copy of the global data structures."

After all these years, it's sort of disheartening that this is a revolutionary idea... And it's frustrating to see another layer of process isolation around the same old global data structures. My new motto: "Functional programming: process isolation all the way down."


What is disheartening is that even though Google took the trouble of having this comic to explain why they did their architecture this way, on quite technical forums there are some comments 'but why don't is use multithreading?'

*Argh*, some people won't ever understand that 'early optimisation is evil', and using multithreading instead of multiprocessing is a memory optimisation which has many serious consequence and should only be used when benchmarks show that the overheard of multiprocessing is unbearable (which it very unlikely to be the case here: I've tried Chrome on my 4year old PC, and it doesn't seem to use more memory than the competition).

Agreed but with reserve

Saying that multithreading instead of multiprocess is "just" a memory optimisation is only true if you look at native threads, with some implementations of user threads, you get such a difference of memory consumption (not speaking about synchronization primitives here, especially since I'm rather thinking of things like Strategies in GHC Haskell) that the kind of things you can do with threads become radically different of what you could do with process.

In the context of navigator tabs though, I agree that multiprocess makes much more sense than multithreads : the only sharing is of tools, not of data.

Can you imagine Erlang threads...

as kernel objects?

I can't either.

That said--Jedal is correct--users seldom have more than a dozen tabs open at once. Mapping each one to a different process makes a lot of sense.