7 ms·

I would much prefer having a sane new language replacing JavaScript instead of this hack to improve performance. A new language could provide the same performan

by danbruc 13y ago

I would much prefer having a sane new language replacing JavaScript instead of this hack to improve performance. A new language could provide the same performance advantage and make writing web applications much more pleasant. Admittedly it is harder to introduce a new language across all (major) browser but I think it would really be worth it.

callahad 13y ago
I don't understand this stuff well enough, but doesn't Emscripten effectively give you that? It converts LLVM bitcode into JavaScript, so if you can compile it with LLVM, you can use it on the web.
- axaxs 13y ago
  But that's like converting C into python. Why not begin a new/existing language that can be compiled and ran at native speeds?
  - mortehu 13y ago
    Three such languages are called AMD64, IA32 and ARM machine code, and are supported by Google Native Client (NaCl). I think they will be exceedingly hard to beat when it comes to speed and loading time.
    - Yoric 13y ago
      They are fast, indeed. But by targeting NaCl, you are producing code that: - will only run on Chrome; - will only run on the hardware platforms for which you have developed. This kind of kills all the fun in the web. By contrast, asm.js code will run just about everywhere, today. And will get blazingly fast in ~12 weeks for Firefox (a little later for Chrome and Opera).
      - ihnorton 13y ago
        > - will only run on the hardware platforms for which you have developed. What fast browser JITs are actively developed for platforms other than ARM, AMD64 and IA32? V8 does not support anything else, and while Firefox enables SpiderMonkey for MIPS and SPARC [1], "unsupported" is not a very hearty endorsement. https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#Platform_support https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#...
        bzbarsky 13y ago
        SpiderMonkey works on PPC, for what it's worth; the TenFourFox project is actively maintaining it there. They're usually a bit behind on porting the JITs, but they do actively port them. But the real issue with NaCl is this thought experiment. Assume NaCl were developed in 1998 and everyone had jumped on that bandwagon and the web in 2003 were full of NaCl blobs targeting the hardware architectures that mattered in 2000-2001. Then ask yourself the following questions: 1) Would this have affected the choice of hardware for phones and tablets and whatnot? 2) Would it be viable today to ship a web browser on an ARM system? 3) What makes us think that the currently-relevant set of hardware architectures will still be the set we want to be using in 10-15 years? In 30 years? The nice thing about asm.js or PNaCl compared to NaCl is that even if we ship it right now and only run it right now on ARM/AMD64/IA32, if someone comes up with a new hardware architecture they want to ship in consumer devices they can simply implement a JS JIT for it (in the case of asm.js) or an LLVM backend (for PNaCl), which is something they would need to do _anyway_ for that "consumer devices" bit. On the other hand, if they have to deal with legacy NaCl content they suddenly have to do hardware emulation or something insane.
  - tracker1 13y ago
    Google already has NaCl
- danbruc 13y ago
  That's correct, you can compile many things to JavaScript. But I think this is a suboptimal solution - besides paying the performance penalty because you have the hard-to-optimize JavaScript in the stack it makes development harder, for example debugging generated code in the browser is unnecessarily hard.
  - fafner 13y ago
    > besides paying the performance penalty because you have the hard-to-optimize JavaScript in the stack Well the article proofs you quite wrong.
- fhd2 13y ago
  I'm not entirely sure myself, but it seems to be a bit more involved than that. I recently came across a thread [1] discussing how to add support for Objective-C and it seems the approach is to compile the Obj-C to C++... I think only C and C++ are supported at this point. But I'd bet they eventually get there. The bigger problem however, is that most of the commonly used languages don't just compile to native executables. They include a runtime handling stuff like garbage collection and just-in-time compilation. Since these runtimes are usually written in C or C++, we'll get there if C compiled to asm.js gets fast enough. That's one of the goals of Emscripten :) There's a demo [2] showing off various language runtimes compiled to asm.js. I'm not sure how they perform in comparison with JS, but the REPLs work pretty well. [1] https://groups.google.com/forum/?fromgroups#!topic/emscripten-discuss/HY9yjH-EoqA https://groups.google.com/forum/?fromgroups#!topic/emscripte... [2] http://repl.it/languages http://repl.it/languages
fhd2 13y ago
I see two big issues here: 1. "Sane" is highly subjective. There is no single optimal language for all problems and audiences. 2. Pushing a new language to all major browsers is hard, like you said. Maybe even impossible, several huge corporations with complex politics are involved. Google is trying this approach with Dart, and I personally don't think it's the panacea, nor do I expect all major browsers to support it. So the only alternative I see is to have a very flexible VM that can run pretty much any language. asm.js proves that JS is actually quite good at that. I'd still prefer something like native client, but asm.js is highly promising: It's downwards compatible and has some potential for optimisation at the same time.
bad_user 13y ago
That's what asm.js is for, meant as bytecode for compilers. Take asm.js (e.g. an efficient subset of Javascript), in combination with source maps meant for debugging, and presto, you have everything needed to compile source-code from whatever language you want, including C/C++.
- discreteevent 13y ago
  "from whatever language you want" - in practice, not really. If you have a language that relies on gc or some kind of vm then you are also going to have to deliver all the asm.js code for the vm. That's potentially a lot of code to deliver to the browser, could you use threads efficiently in your implementation etc. There's no story yet for anything beyond a statically compiled language and even if there is a story you would probably have to wait a long time to see whether it would deliver anything in practice.
IanChiles 13y ago
I'd vote for LuaJIT as a new, sane, replacement for JavaScript.

by danbruc 13y ago

callahad 13y ago

I don't understand this stuff well enough, but doesn't Emscripten effectively give you that? It converts LLVM bitcode into JavaScript, so if you can compile it with LLVM, you can use it on the web.

axaxs 13y ago
But that's like converting C into python. Why not begin a new/existing language that can be compiled and ran at native speeds?
- mortehu 13y ago
  Three such languages are called AMD64, IA32 and ARM machine code, and are supported by Google Native Client (NaCl). I think they will be exceedingly hard to beat when it comes to speed and loading time.
  - Yoric 13y ago
    They are fast, indeed. But by targeting NaCl, you are producing code that: - will only run on Chrome; - will only run on the hardware platforms for which you have developed. This kind of kills all the fun in the web. By contrast, asm.js code will run just about everywhere, today. And will get blazingly fast in ~12 weeks for Firefox (a little later for Chrome and Opera).
    - ihnorton 13y ago
      > - will only run on the hardware platforms for which you have developed. What fast browser JITs are actively developed for platforms other than ARM, AMD64 and IA32? V8 does not support anything else, and while Firefox enables SpiderMonkey for MIPS and SPARC [1], "unsupported" is not a very hearty endorsement. https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#Platform_support https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#...
      - bzbarsky 13y ago
        SpiderMonkey works on PPC, for what it's worth; the TenFourFox project is actively maintaining it there. They're usually a bit behind on porting the JITs, but they do actively port them. But the real issue with NaCl is this thought experiment. Assume NaCl were developed in 1998 and everyone had jumped on that bandwagon and the web in 2003 were full of NaCl blobs targeting the hardware architectures that mattered in 2000-2001. Then ask yourself the following questions: 1) Would this have affected the choice of hardware for phones and tablets and whatnot? 2) Would it be viable today to ship a web browser on an ARM system? 3) What makes us think that the currently-relevant set of hardware architectures will still be the set we want to be using in 10-15 years? In 30 years? The nice thing about asm.js or PNaCl compared to NaCl is that even if we ship it right now and only run it right now on ARM/AMD64/IA32, if someone comes up with a new hardware architecture they want to ship in consumer devices they can simply implement a JS JIT for it (in the case of asm.js) or an LLVM backend (for PNaCl), which is something they would need to do _anyway_ for that "consumer devices" bit. On the other hand, if they have to deal with legacy NaCl content they suddenly have to do hardware emulation or something insane.
- tracker1 13y ago
  Google already has NaCl
danbruc 13y ago
That's correct, you can compile many things to JavaScript. But I think this is a suboptimal solution - besides paying the performance penalty because you have the hard-to-optimize JavaScript in the stack it makes development harder, for example debugging generated code in the browser is unnecessarily hard.
- fafner 13y ago
  > besides paying the performance penalty because you have the hard-to-optimize JavaScript in the stack Well the article proofs you quite wrong.
fhd2 13y ago
I'm not entirely sure myself, but it seems to be a bit more involved than that. I recently came across a thread [1] discussing how to add support for Objective-C and it seems the approach is to compile the Obj-C to C++... I think only C and C++ are supported at this point. But I'd bet they eventually get there. The bigger problem however, is that most of the commonly used languages don't just compile to native executables. They include a runtime handling stuff like garbage collection and just-in-time compilation. Since these runtimes are usually written in C or C++, we'll get there if C compiled to asm.js gets fast enough. That's one of the goals of Emscripten :) There's a demo [2] showing off various language runtimes compiled to asm.js. I'm not sure how they perform in comparison with JS, but the REPLs work pretty well. [1] https://groups.google.com/forum/?fromgroups#!topic/emscripten-discuss/HY9yjH-EoqA https://groups.google.com/forum/?fromgroups#!topic/emscripte... [2] http://repl.it/languages http://repl.it/languages

fhd2 13y ago

I see two big issues here: 1. "Sane" is highly subjective. There is no single optimal language for all problems and audiences. 2. Pushing a new language to all major browsers is hard, like you said. Maybe even impossible, several huge corporations with complex politics are involved. Google is trying this approach with Dart, and I personally don't think it's the panacea, nor do I expect all major browsers to support it. So the only alternative I see is to have a very flexible VM that can run pretty much any language. asm.js proves that JS is actually quite good at that. I'd still prefer something like native client, but asm.js is highly promising: It's downwards compatible and has some potential for optimisation at the same time.

bad_user 13y ago

That's what asm.js is for, meant as bytecode for compilers. Take asm.js (e.g. an efficient subset of Javascript), in combination with source maps meant for debugging, and presto, you have everything needed to compile source-code from whatever language you want, including C/C++.

discreteevent 13y ago
"from whatever language you want" - in practice, not really. If you have a language that relies on gc or some kind of vm then you are also going to have to deliver all the asm.js code for the vm. That's potentially a lot of code to deliver to the browser, could you use threads efficiently in your implementation etc. There's no story yet for anything beyond a statically compiled language and even if there is a story you would probably have to wait a long time to see whether it would deliver anything in practice.

IanChiles 13y ago

I'd vote for LuaJIT as a new, sane, replacement for JavaScript.