Javascript is the new assembly language -- why not the JS VM?
May 14, 2015 5:40 PM   Subscribe

There has been a rash of new languages (CoffeeScript, TypeScript, Dart) targeting JavaScript as their backend for running in a browser. My question is--why target JavaScript and not the JavaScript VM?

Are the various JavaScript VMs incompatible with each other? The existence of asm.js (a stripped down version of JavaScript specifically intended as a compilation target) makes this even more puzzling to me. By way of contrast, there are also a number of new languages targeting the (unrelated) Java VM (Clojure, Scala, Jython), but no one targets Java itself that I'm aware.
posted by zanni to Technology (19 answers total)
 
AFAIK, there is no JavaScript VM per se.
I heard a talk given by Jim Blandy, an old classmate of mine who works on SpiderMonkey. My understanding is that to the greatest extent possible, JavaScript the language, gets JIT compiled to the target machine. There is no intermediate VM. The VM is JavaScript itself and its hooks into the browser.

And I implemented a version of JavaScript for a VRML system in 1996 or so and while my code was interpretive, it was a very small step to take it to a JIT compiler.
posted by plinth at 5:47 PM on May 14, 2015


The difference is that there's a spec for the Java VM, and there always has been.
posted by stebulus at 5:49 PM on May 14, 2015


There is no specification for JavaScript bytecode. The spec defines the language, but each implementation can execute it any way it desires. To the extent that there is such a thing as bytecode for JavaScript, it is simply the intermediate products of interpretation, the details of which vary greatly between interpreters and are subject to change at any moment. Compare this to Java, where the JVM is rigorously defined in a backward-compatible spec that all implementations support.

Beyond that, the beauty of JavaScript is its compatibility. You can write CoffeeScript today and have it work in every browser. Dart targets more modern browsers, but it still works without any effort on the part of browser vendors, plugins, user intervention, etc... In short, these languages target JavaScript because JavaScript is what their target platforms understand.
posted by zachlipton at 5:52 PM on May 14, 2015 [1 favorite]


Yeah, as far as I know all of the current high-performance JavaScript engines (Chrome's V8, Mozilla's SpiderMonkey, and Safari's Nitro) are all basically just JIT compilers for JS. If there were a common VM standard, you bet that there would be an explosion of languages targeting it, but the fact that there isn't is why initiatives like PNaCl were ever launched. I suspect that the inability of the major players in the field to ever compromise on a standard for a browser-based VM, however, will keep JavaScript as the compilation target of choice for the foreseeable future.
posted by invitapriore at 6:04 PM on May 14, 2015


What would you have the VM consume other than ASM.js? At some point you have to have a language that the VM understands, and given ubiquitous handling of gzip compression there's no particular advantage to making that language a byte stream rather than a text stream.
posted by straw at 6:04 PM on May 14, 2015


asm.js is the closest thing we have to this. It's a subset of JavaScript that can be JIT- or ahead-of-time-compiled to machine code that is very close (in some cases identical) to the machine code that would be generated for equivalent C code.

Firefox has a special AOT compiler for asm.js called OdinMonkey. Chrome automatically feeds asm.js code into its TurboFan optimizing JIT. Microsoft's Chakra engine will soon have explicit optimizations for asm.js also.
posted by mbrubeck at 6:06 PM on May 14, 2015 [1 favorite]




When you ship java code, it's bytecode for the VM. When you ship javascript in the browser, it's javascript. There's no such VM as the javascript VM. Browser vendors are free to implement a VM-like approach to interpreting the language, but they are also free to...idk, transpile it to C++, compile that and run the resulting machine code in another process.

"Java" was a confusing thing to release under one name as a "programming language" because it's really at least three, maybe four different things:
- Java, the programming language. All the syntax and interpretation rules, etc. You could have released this along with a compiler and a runtime or an interpreter as a whole thing and been like, "Yeah, check it out. Java. It's a new thing we made." This is how every programming language in history more or less is released.
- Java VM and associated technology: a binary bytecode format, calling conventions, and a whole big VM spec. This would have made sense as a totally standalone product as well, but the idea of Java being "write once run anywhere" made this idea make more sense, since the idea was essentially that the VM was a giant compatibility shim for the compiler, sort of. You could have easily released this as its own thing, some sort of "hardware abstraction layer" and show how by targeting this bytecode format any number of languages could have been made WORA. This is more or less the approach taken by Microsoft when they released the Common Language Runtime as part of .NET. Right out of the gate, the day this whole mess was released, you could at least write "machine" code directly against the VM, and the earliest non-Java ways to target the VM were assemblers that produced bytecode.
- This huge, huge, huge standard library. Especially at the time, standard libraries were not expected to be nearly as large and rich as Java's was. C++, for instance, did not have a standardized set of *container classes* *at that time*, never mind when it shipped v1.0. Java had java.util.Vector, java.util.Hashtable, etc. right from launch. Even if Sun had just taken any off-the-shelf runtime or language or what have you and released a standard library that compiled on every architecture Java was targetting as "Java", that would have been a huge project and a major step forward.

This is not normal. People don't really do this. .NET was basically a similar project, except they released many languages targeting the CLR at the same time (with C# being the Java-like one), so the names weren't as confusing, except remember how no one still knows what ".NET" is or means?

The WORA idea ended up being kinda BS, surprising no one, but huge amounts of work were put into tuning and running the JVM at scale, and so that's why people still release languages that target it: they're confident that weird memory leaks, etc. have been fixed. The answers to questions like "What about monitoring? Logging? Deployment?" have all been asked and answered.

Similarly, there are not really other languages that target say, the Ruby VM. There is no Ruby VM. There's Matz's Ruby interpreter which...is a huge gnarly pile of code that interprets Ruby. There's no languages that target the classic Visual Basic VM, because classic visual basic is compiled and the resulting machine code is injected into the host process of a very special runtime.

When people say, "Javascript is the new assembly language" they just mean, "javascript is difficult for humans to write correctly, so maybe we should think of it as a compile-target for friendlier interfaces", not that it is anything remotely in any way like assembly language on a technical level.

You could, of course, build a VM *in* javascript, ship that and cache it everywhere, and then make your language ship a compact bytecode representation that targets that VM. In fact, many people have: this is exactly how browser hosted classic videogame emulators work: they download the rom into the browser and they loop over the instructions and do what they say.

IF you knew something SPECIAL about the behavior of a typical or common javascript interpreter, say that certain kinds of math were fastpathed and so xyz operations were actually quite fast despite the stereotypes about javascript (there has been so much investment in JS performance that certain JS code post-JIT and analysis actually runs insanely fast, much much faster than similar code in a language with a comparatively slow runtime that lacks sufficient runtime analytical powers to allow it to take certain shortcuts like Objective-C), there's no reason why you couldn't design a standard "javascript virtual machine" that you could compile code to that would run whatever language you want and probably pretty snappily, in certain cases.

Idk if that's the kind of crazy nonsense anyone would do other than for fun though.
posted by jeb at 6:21 PM on May 14, 2015 [14 favorites]


JavaScript doesn't compile to byte code, it is interpreted. There is no VM, it's all run directly by the engine (V8, Spidermonkey, Rhino/Nashorn, etc.). The compiled JavaScript languages are really just mapping one language to another (sometimes this is called "transpiling"). It's sort of like translating German to English. This is unlike a true compiled language where the compiler produces either a binary or byte code using a VM instruction set.

The JVM actually has its own assembly language so languages that compile to the JVM just produce .class files which consist of these instructions. Since JavaScript has no intermediary low-level language, there's nothing "below" it to target.

(Note to pedants: yes, this is a very simplified version of reality.)
posted by deathpanels at 6:47 PM on May 14, 2015 [1 favorite]


When people say, "Javascript is the new assembly language" they just mean, "javascript is difficult for humans to write correctly, so maybe we should think of it as a compile-target for friendlier interfaces", not that it is anything remotely in any way like assembly language on a technical level.
seconded
posted by j_curiouser at 7:17 PM on May 14, 2015 [2 favorites]


the ubiquitous AngularJs framework is a great example of that^^^^
posted by j_curiouser at 7:19 PM on May 14, 2015


so at least one major player (google) has bought into (for now) strong static typing and a type abstraction in addition to prototypes (interfaces).
posted by j_curiouser at 7:22 PM on May 14, 2015


When people say, "Javascript is the new assembly language" they just mean, "javascript is difficult for humans to write correctly, so maybe we should think of it as a compile-target for friendlier interfaces", not that it is anything remotely in any way like assembly language on a technical level.

This seems about right, except the part about it being difficult for people to write correctly. It's not; not for people who take the time to learn it as they would any other language. Things like "Coffeescript" are pre-processors that add little to no value; "Coffeescript" simply provides a Ruby-like syntax for Messianic Rails developers who lack the inclination to be serious enough about CS to learn another language. As things like Rails are killed off by Node.js, and JS becomes among the most common languages or both server and client, this becomes an even sillier concept.
posted by drjimmy11 at 10:57 PM on May 14, 2015 [2 favorites]


This seems about right, except the part about it being difficult for people to write correctly. It's not; not for people who take the time to learn it as they would any other language.

you have to consider that *people* != devs generally familiar with prototypes, closures, functions as first-class types, function expressions/lambdas, etc. *people* aren't 'learning languages'. they're copy-pasting code blocks under deadline.

*people* == some script kiddie trying to wire an event handler to a DOM element, or trying (failing) to block until that async call returns. Never used XMLHttpRequest without jQuery. Never built a floating window without extJs. Can't describe a reference type behavior. Outside of cross-browser compatibility, the proliferation of frameworks is a pretty good indicator that 'a lot of people trying to code for the browser can't do it very well with straight JavaScript.'

knowing node isn't like some magical supra-javascript-knowledge. the success of node isn't so much 'javascript winning' as much as it is 'non-blocking event pumps on the server side are really useful.' tbh, node could've been implemented to compile just about anything. and the cool part, libuv, is written in C.
posted by j_curiouser at 3:37 AM on May 15, 2015 [1 favorite]


In my observation, most "easy" languages are very difficult to write correctly, and most "difficult" language are very easy to write correctly. For example, Java's concurrency model is so complicated it takes years to master it, but Clojure's concurrency model is so simple and easy you can accidentally write a correct multithreaded program when you weren't even intending to.
posted by deathpanels at 5:45 AM on May 15, 2015 [1 favorite]


You answered your own question:
"There has been a rash of new languages (CoffeeScript, TypeScript, Dart) targeting JavaScript as their backend for running in a browser. "
JavaScript is the most ubiquitously available programming language to run programs in because web browsers are the most ubiquitous execution environment for programs.

At this point, approximately everyone has access to a web browser. Whether in your pocket right now or at your public library, browsers are incredibly available in a way no platform has ever been before.
posted by artlung at 10:02 AM on May 15, 2015


So another way to think about this is to ponder the notion that x86 is a high level language. Beyond the JVM, modern processors these days are doing JIT optimizations on internal data structures and actual program flow such that the byte codes are just an input language.
posted by straw at 10:23 AM on May 15, 2015


tbh, node could've been implemented to compile just about anything. and the cool part, libuv, is written in C.

Yeah, but it took off because of a very specific confluence of factors: having a good library for evented I/O already in existence, being the first popular dynamic language to have a very fast JIT compiler available, and having a bunch of devs already familiar with the single-threaded non-blocking asynchronous model since it's the only way to have your browser code not gum up the works of your rendering. I think if either of the latter two factors were not present we'd still just have a bunch of not-especially-popular evented I/O modules in various languages.
posted by invitapriore at 12:25 PM on May 15, 2015 [1 favorite]


Google, Microsoft, and Mozilla announced today that they are working together on WebAssembly, a new binary compilation target based on asm.js.
posted by mbrubeck at 10:42 AM on June 17, 2015 [1 favorite]


« Older Best TV options on PC   |   How do I deal with not having any sort of life... Newer »
This thread is closed to new comments.