6 ms·

Emscripten (LLVM-to-JavaScript compiler) 1.0

122 points by carussell 16y ago

jimmyjazz14 16y ago
In my opinion this is probably the most exciting thing being done with Javascript currently; I can't wait to see where this goes.
thasmin 16y ago
Can someone give an example of what this would be used for?
- Jebdm 16y ago
  It looks like you can use it as essentially an LLVM backend, meaning that any compiler/interpreter that uses LLVM can compile into Javascript (for use in the browser).
- vessenes 16y ago
  He mentions he'd like to use it to get windowing environments compiled over to JS for use in the browser. I scoffed until playing around with his real live python 2.7 running on javascript in Chrome. YOW! That's just super cool.
- irfn 16y ago
  imagine a hugely useful c library being compiled into javascript for use in a browser env and even nodejs.
  - skrebbel 16y ago
    on the latter example: you could also just compile that hugely useful c library as a nodejs plugin directly.
Smerity 16y ago
Emscripten, given the recent advancements in Javascript interpreters, holds immense promise. There is a problem however: the size of the Javascript "executables". As the size of their executables are already competitive with their C/C++ counterparts this is not easily fixed. CPython's "Javscript" runtime is 2.8 megabytes whilst CPython's C runtime is 2.2 megabytes, less than a 30% increase. With compression the JS size decreases, but not by enough. A 2 megabyte JS file is likely prohibitively large. Even if common JS "executables" were hosted by Google, as is currently done for jQuery and other libraries, the problem is only mildly alleviated. Emscripten is an amazing technical feat but I fear due to this it will see little usage. Their main focus currently is improving performance, but is anyone looking into decreasing the size or improving the handling of these "executables"?
- wahnfrieden 16y ago
  Fair criticism, but this still has plenty of potential use for projects that are only one step away from llvm rather than two (i.e something written in C) which don't have runtimes.
  - wahnfrieden 16y ago
    It ocurred to me that this will be useful for things like Chrome extensions too, where the code is downloaded once and stored locally, and the user doesn't mind a longer download in this case.
- Ruudjah 16y ago
  Maybe include generic libs into browsers.
  - wladimir 16y ago
    Your idea has the drawback that browser updates might be few and far between (for some users), so when embedding them in the browser you can never rely on a certain version of a certain library to be available. A more general caching system would be better. For example, "Cache by digital signature", as some people above mention.
- Nate75Sanders 16y ago
  Do you not think that as time goes on (bandwidth increases) a 2MB download is something that we won't even notice?
- tlrobinson 16y ago
  "A 2 megabyte JS file is likely prohibitively large." Tell that to Gmail. They load at least 2MB of code. New Twitter loads 1MB. Facebook used to load that much, but it appears they've cut it down a lot recently. It's certainly prohibitive for webpages and lightweight page-oriented web applications, but not single-page web apps. I would expect this to be used more for the latter.
mckoss 16y ago
Amazing. Tried to run the current CPython port on iPad and the browser crashes. :-(
snotrockets 16y ago
Quote Brendan Eich (if I'm not mistaken): “JavaScript is x86 for the web”
nitrogen 16y ago
This looks very useful for now, but shouldn't we be trying to get LLVM-based native client standardized for the long term?
- lautis 16y ago
  If we wanted to have LLVM-based native clients, Emscripten would definitely be needed. Distributing binaries isn't feasible as they aren't portable. Chrome would like to address this by distributing LLVM bitcode[1] and then compile this to native binary using LLVM. Portable Native Clients were introduced as an idea one year ago, but AFAIK there hasn't been much development, mostly because LLVM itself isn't very portable. If native clients would be the path for future web apps, we can't reasonably expect the whole world to switch to LLVM in one night. There would have to be some fallback. As both Portable Native Clients and Emscripten work on LLVM bitcode, Emscripten would be the natural choice. [1] LLVM's name for their intermediate language, low-level bytecode
  - ieefransi 16y ago
    How are they not portable when translated to javascript ? Granted, this will probably never run Quake in the browser, but if you want a SHA256 hash translated to javascript ... I seriously doubt there's a better tool. All the difficult C stuff instantly useable from javascript, from GWT, from ... That's got to be a boon, right ?
- bzbarsky 16y ago
  One problem is that last I checked LLVM is not really all that portable across different hardware architectures (e.g. you can't use the same LLVM bitcode for both x86 and AMD64 code generation; you can't use the same LLVM bitcode for both little-endian and big-endian hardware, etc, etc).

122 points by carussell 16y ago

In my opinion this is probably the most exciting thing being done with Javascript currently; I can't wait to see where this goes.

thasmin 16y ago

Can someone give an example of what this would be used for?

Jebdm 16y ago
It looks like you can use it as essentially an LLVM backend, meaning that any compiler/interpreter that uses LLVM can compile into Javascript (for use in the browser).
vessenes 16y ago
He mentions he'd like to use it to get windowing environments compiled over to JS for use in the browser. I scoffed until playing around with his real live python 2.7 running on javascript in Chrome. YOW! That's just super cool.
irfn 16y ago
imagine a hugely useful c library being compiled into javascript for use in a browser env and even nodejs.
- skrebbel 16y ago
  on the latter example: you could also just compile that hugely useful c library as a nodejs plugin directly.

Smerity 16y ago

Emscripten, given the recent advancements in Javascript interpreters, holds immense promise. There is a problem however: the size of the Javascript "executables". As the size of their executables are already competitive with their C/C++ counterparts this is not easily fixed. CPython's "Javscript" runtime is 2.8 megabytes whilst CPython's C runtime is 2.2 megabytes, less than a 30% increase. With compression the JS size decreases, but not by enough. A 2 megabyte JS file is likely prohibitively large. Even if common JS "executables" were hosted by Google, as is currently done for jQuery and other libraries, the problem is only mildly alleviated. Emscripten is an amazing technical feat but I fear due to this it will see little usage. Their main focus currently is improving performance, but is anyone looking into decreasing the size or improving the handling of these "executables"?

wahnfrieden 16y ago
Fair criticism, but this still has plenty of potential use for projects that are only one step away from llvm rather than two (i.e something written in C) which don't have runtimes.
- wahnfrieden 16y ago
  It ocurred to me that this will be useful for things like Chrome extensions too, where the code is downloaded once and stored locally, and the user doesn't mind a longer download in this case.
Ruudjah 16y ago
Maybe include generic libs into browsers.
- wladimir 16y ago
  Your idea has the drawback that browser updates might be few and far between (for some users), so when embedding them in the browser you can never rely on a certain version of a certain library to be available. A more general caching system would be better. For example, "Cache by digital signature", as some people above mention.
Nate75Sanders 16y ago
Do you not think that as time goes on (bandwidth increases) a 2MB download is something that we won't even notice?
tlrobinson 16y ago
"A 2 megabyte JS file is likely prohibitively large." Tell that to Gmail. They load at least 2MB of code. New Twitter loads 1MB. Facebook used to load that much, but it appears they've cut it down a lot recently. It's certainly prohibitive for webpages and lightweight page-oriented web applications, but not single-page web apps. I would expect this to be used more for the latter.

mckoss 16y ago

Amazing. Tried to run the current CPython port on iPad and the browser crashes. :-(

snotrockets 16y ago

Quote Brendan Eich (if I'm not mistaken): “JavaScript is x86 for the web”

nitrogen 16y ago

This looks very useful for now, but shouldn't we be trying to get LLVM-based native client standardized for the long term?

lautis 16y ago
If we wanted to have LLVM-based native clients, Emscripten would definitely be needed. Distributing binaries isn't feasible as they aren't portable. Chrome would like to address this by distributing LLVM bitcode[1] and then compile this to native binary using LLVM. Portable Native Clients were introduced as an idea one year ago, but AFAIK there hasn't been much development, mostly because LLVM itself isn't very portable. If native clients would be the path for future web apps, we can't reasonably expect the whole world to switch to LLVM in one night. There would have to be some fallback. As both Portable Native Clients and Emscripten work on LLVM bitcode, Emscripten would be the natural choice. [1] LLVM's name for their intermediate language, low-level bytecode
- ieefransi 16y ago
  How are they not portable when translated to javascript ? Granted, this will probably never run Quake in the browser, but if you want a SHA256 hash translated to javascript ... I seriously doubt there's a better tool. All the difficult C stuff instantly useable from javascript, from GWT, from ... That's got to be a boon, right ?
bzbarsky 16y ago
One problem is that last I checked LLVM is not really all that portable across different hardware architectures (e.g. you can't use the same LLVM bitcode for both x86 and AMD64 code generation; you can't use the same LLVM bitcode for both little-endian and big-endian hardware, etc, etc).