Hacker News Reader

Comment by billybob | Hacker News Reader

There seems to be agreement that Javascript is a messy language which is popular by default: it was included in Netscape, then other browsers picked it up. Now we're stuck with it.

I realize this would be very difficult and introduce horrible compatibility issues for a while, but sometimes I think, "what if we could start over?" What if Chrome and Firefox started supporting Python or Ruby or a custom, well-designed language for web scripting? Could it gain enough momentum to replace Javascript?

Actually, the easiest candidate would be for browsers to start natively supporting Coffeescript. But imagine a "dream team" designing a language just for the web, from scratch: Douglas Crockford, John Resig, Guido van Rossum, Yukihiro Matsumoto...

Is this a "it's crazy but it just might work" scenario, or is it just crazy?

View on HN

If we started over, we should pick a VM, not a language.

Some kind of flexible bytecode implemented across browsers would be fantastic, and you could always implement a fallback interpreter in javascript (or if feeling fancy, a decompiler).

Isn't Javascript a flexible bytecode?

Well, yes, but it comes with all the overhead of being a (partly) flawed language. Having a bytecode that allows, for instance, optional static and dynamic types would be much more direct than relying on type inference or separate native APIs (as are being introduced). Of course we have javascript now, so pragmatically languages should be compiled to it if we want them, but if there were to be an additional web bytecode, there would be many areas for improvement in terms of performance and safety.

JavaScript is a programming language that compiles to bytecode. It can be treated as object code, but it is a very different and higher-level thing than the term "bytecode" generally denotes.

Calling JavaScript "flexible bytecode" is like saying that all Turing-complete programming languages are the same, or that all objects capable of driving a nail into a piece of wood are equivalent. It's true in a very facile way. JavaScript can be treated kind of like bytecode, and all Turing-complete languages can be treated as a simulation of a Turing machine, but the details that these rough descriptions miss are more numerous and more significant than the details that actually went into forming the generalization.

JavaScript is a programming language that compiles to bytecode. It can be treated as object code, but it is very different and higher-level thing than the term "bytecode" generally denotes.

Yes a VM would be nice. Or LLVM + native client, "portable native client", Google is (was?) working on this in Chromium.

LLVM code with access to the DOM would be fine by me. Security would probably take a while to audit.

"The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable for fast loading by a Just-In-Time compiler), and as a human readable assembly language representation. This allows LLVM to provide a powerful intermediate representation for efficient compiler transformations and analysis, while providing a natural means to debug and visualize the transformations. The three different forms of LLVM are all equivalent. This document describes the human readable representation and notation." http://llvm.org/docs/LangRef.html#abstract

Producing a truly language-neutral VM would be an interesting goal, one that no-one's really got that close to achieving. (I think Microsoft's got closest.) Making it a compact wire format to boot would be... challenging.

Ultimately, a VM is just another language with lousy readability.

I see your point, but I think a VM spec comes with an implicit promise that it is OK to develop languages as opposed to the "why don't you just program in what we give you?" mantra.

I agree its a very hard problem. If I was starting from scratch I would probably look a lot more on vector operations than someone would have 10 years ago. Plus the manner of parallelism a person choses would seriously influence language implementors.

I would not consider that a dream team considering the languages/libraries they have produced.

You think jQuery, Ruby and Python are subpar?

Why, and who would you pick?

Not crazy at all, especially if is a VM that can host multiple languages. Hm... What would be even more interesting is a VM that can be configured form the server.

1. User opens a page with scripts in LanguageX. The page links to some kind of VM configuration file. 2. Browser loads that file, which enables it to parse LanguageX. Browser caches that file. 3. From now on, the browser can execute scripts in LanguageX.

Although, this particular idea might be the case when too much flexibility would lead to issues in the long run.

Chrome's ative code plugin NaCl lets you do this - there is a Tcl implementation using it so far, but no reason why there should not be others.

But NaCl in its current state is limited to a specific platforms, which is a big problem for a web app. Do you know if portable NaCl ever got anywhere?

Actually haven't seen anything for a bit. You are right we do need this too...

Reply on news.ycombinator.com