Hacker News Reader

Comment by hetman | Hacker News Reader

For some time now I've been wondering why the primary scripting format consumed by browsers is JavaScript (a language intended for humans) and not some sort of standard bytecode that would be executed in a browser's virtual machine.

What we need is the JSVM! In other words, something like the JVM but adapted for the browser. That probably means it would have a more dynamic typing focus since it makes sense for JavaScript to be the primary language targeted by the system (though there's no reason this couldn't evolve over time just like the JVM has).

All of a sudden you don't need to build in Python support, or Ruby support or LISP support or whatever else you fancy into the browser. The browser no longer cares what you compiled the script from, it just gets the standard bytecode and everyone's happy.

View on HN

Yes please. Just define a straightforward VM in the browser and be done with it. Let the coders handle the rest, and compile any of their favorite languages to it (they will!). Java was on the right track, too bad the implementation (and APIs) were so clunky instead of nicely integrated, otherwise we'd never have needed the JS, Flash, Silverlight, Java applets, HTML5 mess that we're in now.

Anyway, hindsight is 20/20, now we can just settle on JS as a target VM. Too bad it's implemented slightly different in every browser, making it inconvenient as intermediate format. Also, going through a dynamic language is an inefficient level of indirection if you want to program in a static language. You throw away information that could have been used to optimize.

Lots of essential Python features are not part of the language, but belong to its standard library. The thing that makes JavaScript so portable is that it basically has no such thing (except maybe Date and Math).

So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library. And you would have to do that for each language you want to support.

You also would not be able to minify it properly because of whitespace identation constraints. Or am I off on this?

Minifying is a compression hack. Just get the files served compressed with a proper algorithm. gzip compresses whitespace just fine.

You can compact a lot of whitespace out of python.

$ cat hello.py

    def helloooo():
        print "helloooo"
        print "SLAM!"
    
    helloooo()

$ cat hellomin.py

    def helloooo(): print "helloooo"; print "SLAM!"
    helloooo()

Or you could deliver your JSVM bytecode as binary files (which reveals a new set of drawbacks)

If we're compiling to bytecode there is no need to minify.

> So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library.

You would ship it once. Websites already do not download jquery etc. more than once. In fact websites can use those libraries from standard locations on the web so that multiple websites don't need multiple downloads of large libraries.

I'm sure we could have some sort of JSVM, we could even have some sort of bytecode for the HTML, but it would destroy part of what makes the web so great: it's openness. The ability to view the source of any webpage, and even make chances and enhance it locally.

There is also the fact that certain optimization can only be done by the browser if it has the actual source code rather than the compiled bytecode.

I think you're arguing a bit of a strawman when you mention viewing page sources: the discussion is about replacing JavaScript, not HTML. In any case, the fact that (non-web) applications are compiled into binaries hasn't stopped open source from flourishing.

Not really. HTML would remain HTML. We're talking about JavaScript, and that is already minified (and sometimes obfuscated) beyond recognisability for a human.

I'd be curious to hear what kind of optimisations become unavailable.

In both .net and java there exists excellent decompilation tools where you can easily decompile the bytecode back into java or C# or anyother language. It's not necessarily going to give you the original source code (especially missing comments) but it works incredibly well nonetheless. You could easily debug in it and edit it dynamically in browser tools as well. This is pretty much a solved problem. I wouldn't consider this a limitation worth talking about again.

Those optimizations can happen in the compiler that transforms the code into bytecode anyway.

You have already lost that. Go look at the source code for cuttherope.ie and tell me that you learned anything. It might as well have been binary.

We do have that VM. It just happens that this VM's "bytecode" looks like JavaScript.

Here is Python running in the browser:

http://syntensity.com/static/python.html

Yes. And it just happens that it's optimized for js and sucks compared to a lower level VM.

Not to mention the extra overhead, not having proper traces for exceptions, source-line equivalency on errors, etc.

Sorry, but this is not good enough. This argument is made all the time, but all you're really saying is that every other language should be a second-class citizen to JavaScript. Emscripten is a cool technical hack, but why the fuck is it 2012 and we have to compile C++ to JavaScript?

Browsers supporting JavaScript and some other bytecode format would bring web innovation to a crawl.

I think once browsers are able to debug in the originating languages people will stop complaining about this.

Arrogant people preemptively declaring failure and trying to enforce their baseless declarations on others is what brings innovation to a crawl.

Come on now, that's a bit harsh. There are really smart people who have been trying this exact thing for years without success. Microsoft tried harder than anyone to make "JScript" part of .NET but finally gave up and Windows 8 has 2 first-class VMs.

Without success because people like you have been fighting them every step of the way trying to hold back progress. It's hard to overcome inertia, and it's almost impossible when there is an organized resistance. It becomes absolutely insanity-inducing when said resistance uses its own success in warding off progress as ammunition for holding back progress.

I'd say I was exceedingly un-harsh, even downright polite, considering the long-term damage that has been inflicted.

It wasn't in the browser though. So it's a different story.

That's just shooting the messenger. The comment about 'enforcing ... on others' is completely unwarranted.

Can you provide some reasoning for why this is necessarily the case?

It's not good enough now, probably because JavaScript was designed as a lightweight scripting language to make web pages a little more interactive and not as a general "bytecode for the web".

However, it always amazes me when people in discussions like this take JavaScript as a done deal or a static target...this is a fatal flaw in this discussion.

JavaScript as a language and community has evolved a lot, and it continues to evolve. We've already seen improvements that make it a better target for compilation, and we'll be seeing more in the future...now that it's clear that that is what the web wants/needs and not just a little scripting language for forms.

My bet is it will be much easier/quicker to work JavaScript into a good target for compiling other languages to than to develop a general VM and convince all the browser vendors to adopt it.

That's not even taking into account which would be better overall, which I think is an interesting question without an entirely clear answer....but I'm a pragmatist and so I think it's not worth worrying about except intellectually.

> all you're really saying is that every other language should be a second-class citizen to JavaScript.

Every platform has a "native" form. On your x86 desktop, it's x86 assembly, which everything is a second-class citizen to in the sense it needs to be compiled into it. On the web, the native form is JavaScript.

It has to be something fairly high-level because the web is CPU and OS-agnostic, which JS is.

The only practical concern that can be here, is whether JS is good enough for this task - if languages compiled into it run efficiently enough. It can be, if browsers continue to improve JS and if we all improve compilers into JS. So far little work has been done on both of those, but there is starting to be effort there.

> Emscripten is a cool technical hack, but why the fuck is it 2012 and we have to compile C++ to JavaScript?

We need to compile into something platform-independent, memory-safe and standardized. There isn't currently a better option than JavaScript, because each other option has major downsides. So does JS, to be sure, but overall it's a wash, and JS is already there so it wins.

Source-level debugging please.

Agreed it's important. I believe several major browsers are working on that.

That bytecode is not good enough. It doesn't even have ints for christ sake.

Because that's how it was initially. And initially - before github and minifiers - that was very important as a way of helping people learn by being able to study the code of other websites.

Parrot in the browser! Don't really know a lot about it, to be honet, but it could work :)

"Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. Parrot is not about parrots, though we are rather fond of them for obvious reasons."

http://www.parrot.org/ http://duckduckgo.com/Parrot_virtual_machine

This is called NACL. And as great as it is, what we really need are on-the-fly compilers/interpreters.

The web needs to be open. As much as this would appease those who want privacy/drm for their code, we all know what road this leads to. Eventually we will be forced to execute certain binaries to browse certain portions of the web. The Urchin.exe forced to execute while we divulge our lives in our browsing habits.

Google/Facebook will track us, we'll know it, and we won't be able to function without it.

We do need a vm. But more than that, we need transparency in the future choices of web standards. Their are powers-that-be that are simply salivating at how quickly developers will evangelize this technology.

All I'm trying to say is the battle seems quite planned and half-done already, and I'm not sure anyone understands the long-term consequences. I sure don't.

Reply on news.ycombinator.com