7 ms·

LLJS : Low-Level JavaScript

72 points by vmorgulis 11y ago

halosghost 11y ago
This appears to be about a language that compiles to js (asm.js it seems?), not wasm (WebAssembly) which is mean to be more like an IR (think of llvm ir) but for the web. Am I misunderstanding something?
- girvo 11y ago
  > more like an IR Actually, it's more like a compressed abstract syntax tree. Subtle difference, but there's no stack machine you're targeting in wasm, which I think is quite interesting!
  - halosghost 11y ago
    I suppose, but my point is that what the OP posted appears to be completely unrelated to wasm…
bobajeff 11y ago
They actually made a version that generated asm.js. Unfortunately that was before asm.js was stable and they haven't updated it since so it no longer generates valid code. The language and generator were simple enough to use in a browser-only environment so it's a shame there was never more interest in it. It would've been nice to be able to fool around with asm.js without having to set up a dev environment, which isn't possible in some circumstances.
girvo 11y ago
The idea of LLJS is quite interesting, similar in ways to asm.js (in fact there was a fork that can compile to it!) but easily human readable and writable. It seems to be a dead project however; I came across it a few weeks ago and it seems abandoned, unfortunately. With wasm, hopefully we'll see more and more languages like this one; I'm imagining a low-level C-like language solely for doing WebGL in a fullscreen canvas.
- halosghost 11y ago
  I don't know; honestly, I think the nicest part about wasm is that it might allow us to stop making more dialects of JS, get rid of JS altogether and compile to the web whatever language we like (I'm looking at you Haskell).
  - woah 11y ago
    I never really have understood this kind of sentiment. There are a huge number of people who like js, to the point that it is used in a bunch of places that are not the browser. In terms of dynamic scripting languages, it's a fast, easy, and flexible option.
    - iopq 11y ago
      Some people want a statically-typed language for larger apps. Tooling support can be made a lot better for statically-typed languages because it's easier to analyze.
    - halosghost 11y ago
      Disclaimer: the below text is just my opinion meant to answer the Parent's questions about my preferences. Please do not take it to be an attempt at starting a flamewar (or, for that matter, an invitation to do so). I have never enjoyed dynamic typing; it has always seemed like TheWrongSolution™ to me. And Haskell really drives that home for me (i.e., it is possible to have a static type system with all the benefits that gives you without any of the headaches). Additionally, I really dislike the trend of JS moving out of the web browser; it is incredibly easy to write impenetrable JS (particularly with the compile-to-js languages) which makes it much harder for me to understand what is running on my system, how to contribute to it and how to debug it. Furthermore, JS is fast in comparison to other interpreted dynamic languages, but is quite slow compared to most native code (like the kind you would get with Haskell). I am not trying to be one of the JS naysayers that gets into religious wars, but I will say that I am generally not a fan of the language, and the possibility of removing it from my life does seem like a net-positive. But again, my intention is not to start a flamewar, simply answer your questions about my preferences.
bluejekyll 11y ago
Can we get over all this native JavaScript junk and finally move to either platform independent llvm bytecode (wasm as I understand it) or just use the damn jvm? There's no need other than faster Dev times (which can be handled in other ways) to keep the code in a non compiled format anymore. It's nuts and super inefficient. Let's move on already.
- rinon 11y ago
  I think the problem is cross-browser backwards compatibility. Until we solve this (maybe wasm will), we can't really deploy on the web in anything but JS.
- vmorgulis 11y ago
  If wasm is effectively adopted, the browser could become the cocoon of most of end-user applications. It will be like a VM plus an OS API: -DOM replace GUI frameworks (like Qt) -Canvas replace framebuffer (or GDI) -JS File API replace fopen() (or with emscripten virtual FS) - ... Like in 90s, we could see rewamping of applications but for the web this time (instead of Windows). We can see JS as a higher level shell and the Web API as a cross-OS POSIX.
  - teacup50 11y ago
    The DOM is going to be the first thing to go if WebAssembly actually takes off. It's simply not a suitable performant model for a GUI event/render tree.
    - the8472 11y ago
      The DOM might not be quite as bad if you can do all your actual work on other threads and only submit changes to the UI thread asynchronously. If some non-renderable DOM tree could be cloned and transferred across threads you could basically operate in a clone-modify-splice cycle across threads. I think it's salvageable. But before you can even think about concurrent APIs you first need threads/parallel task executors. And Web Workers aren't going to cut it because they dictate what you're allowed to send (structured clone) instead of being extensible.
empyrical 11y ago
I wonder if LLJS could become something like Cython for JavaScript. Imagine writing Node or Emscripten bindings to a C library with JS!
logicallee 11y ago
I asked Carmack and others, he hated my idea and said it was silly.† I still think it's the right way to go. I think we should physically have CPU's that you can hand a binary you don't trust, off of the Internet, to and nothing bad can happen. Read that again. CPU's should be able to be given a binary blob, and nothing bad can happen. It should be native speed because it's running on the actual metal. Like a hardware CPU, for the web. A multigigaherz processor cannot render an 8-bit (that is 0-255 here) processor running at 1.79 MHz with a whopping 2 kB of RAM that is orders of magnitude slower: https://news.ycombinator.com/item?id=9624483 https://news.ycombinator.com/item?id=9624483 This is insanity. It's time for new hardware, that you can say "go wild" to by typing in an http address. 90% of the reason for enduring this slowness is security. (It's okay to interpret javascript - what's the worst that will happen. It's not okay to agree to run any binary regardless of what will be in it.) It's time for Intel to make chips that you can hand to a website and say, "go wild". I think reinventing C in Javascript at 10% of performance (generously), is what is silly. Running Mario at a bit too slow to be called "perfect" is what is silly. It's 2015. Light travels 10 centimeters between clock cycles, with cores at 3 GHz. Do we really have to spend three billion cycles every second, on interpreting javascript? † "Dedicated hardware would be silly – the current hardware can do secure sandboxing just fine. Cross platform compatibility is an issue with a lot of possible solutions; dedicated hardware would be a far worse case."
- cactusface 11y ago
  NaCl?
  - lucd 11y ago
    https://developer.chrome.com/native-client https://developer.chrome.com/native-client Native Client is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.
    - cactusface 11y ago
      Oh, it was a suggestion to the guy, but thanks for elaborating.

72 points by vmorgulis 11y ago

This appears to be about a language that compiles to js (asm.js it seems?), not wasm (WebAssembly) which is mean to be more like an IR (think of llvm ir) but for the web. Am I misunderstanding something?

girvo 11y ago
> more like an IR Actually, it's more like a compressed abstract syntax tree. Subtle difference, but there's no stack machine you're targeting in wasm, which I think is quite interesting!
- halosghost 11y ago
  I suppose, but my point is that what the OP posted appears to be completely unrelated to wasm…

bobajeff 11y ago

They actually made a version that generated asm.js. Unfortunately that was before asm.js was stable and they haven't updated it since so it no longer generates valid code. The language and generator were simple enough to use in a browser-only environment so it's a shame there was never more interest in it. It would've been nice to be able to fool around with asm.js without having to set up a dev environment, which isn't possible in some circumstances.

girvo 11y ago

The idea of LLJS is quite interesting, similar in ways to asm.js (in fact there was a fork that can compile to it!) but easily human readable and writable. It seems to be a dead project however; I came across it a few weeks ago and it seems abandoned, unfortunately. With wasm, hopefully we'll see more and more languages like this one; I'm imagining a low-level C-like language solely for doing WebGL in a fullscreen canvas.

halosghost 11y ago
I don't know; honestly, I think the nicest part about wasm is that it might allow us to stop making more dialects of JS, get rid of JS altogether and compile to the web whatever language we like (I'm looking at you Haskell).
- woah 11y ago
  I never really have understood this kind of sentiment. There are a huge number of people who like js, to the point that it is used in a bunch of places that are not the browser. In terms of dynamic scripting languages, it's a fast, easy, and flexible option.
  - iopq 11y ago
    Some people want a statically-typed language for larger apps. Tooling support can be made a lot better for statically-typed languages because it's easier to analyze.
  - halosghost 11y ago
    Disclaimer: the below text is just my opinion meant to answer the Parent's questions about my preferences. Please do not take it to be an attempt at starting a flamewar (or, for that matter, an invitation to do so). I have never enjoyed dynamic typing; it has always seemed like TheWrongSolution™ to me. And Haskell really drives that home for me (i.e., it is possible to have a static type system with all the benefits that gives you without any of the headaches). Additionally, I really dislike the trend of JS moving out of the web browser; it is incredibly easy to write impenetrable JS (particularly with the compile-to-js languages) which makes it much harder for me to understand what is running on my system, how to contribute to it and how to debug it. Furthermore, JS is fast in comparison to other interpreted dynamic languages, but is quite slow compared to most native code (like the kind you would get with Haskell). I am not trying to be one of the JS naysayers that gets into religious wars, but I will say that I am generally not a fan of the language, and the possibility of removing it from my life does seem like a net-positive. But again, my intention is not to start a flamewar, simply answer your questions about my preferences.

bluejekyll 11y ago

Can we get over all this native JavaScript junk and finally move to either platform independent llvm bytecode (wasm as I understand it) or just use the damn jvm? There's no need other than faster Dev times (which can be handled in other ways) to keep the code in a non compiled format anymore. It's nuts and super inefficient. Let's move on already.

rinon 11y ago
I think the problem is cross-browser backwards compatibility. Until we solve this (maybe wasm will), we can't really deploy on the web in anything but JS.
vmorgulis 11y ago
If wasm is effectively adopted, the browser could become the cocoon of most of end-user applications. It will be like a VM plus an OS API: -DOM replace GUI frameworks (like Qt) -Canvas replace framebuffer (or GDI) -JS File API replace fopen() (or with emscripten virtual FS) - ... Like in 90s, we could see rewamping of applications but for the web this time (instead of Windows). We can see JS as a higher level shell and the Web API as a cross-OS POSIX.
- teacup50 11y ago
  The DOM is going to be the first thing to go if WebAssembly actually takes off. It's simply not a suitable performant model for a GUI event/render tree.
  - the8472 11y ago
    The DOM might not be quite as bad if you can do all your actual work on other threads and only submit changes to the UI thread asynchronously. If some non-renderable DOM tree could be cloned and transferred across threads you could basically operate in a clone-modify-splice cycle across threads. I think it's salvageable. But before you can even think about concurrent APIs you first need threads/parallel task executors. And Web Workers aren't going to cut it because they dictate what you're allowed to send (structured clone) instead of being extensible.

empyrical 11y ago

I wonder if LLJS could become something like Cython for JavaScript. Imagine writing Node or Emscripten bindings to a C library with JS!

logicallee 11y ago

I asked Carmack and others, he hated my idea and said it was silly.† I still think it's the right way to go. I think we should physically have CPU's that you can hand a binary you don't trust, off of the Internet, to and nothing bad can happen. Read that again. CPU's should be able to be given a binary blob, and nothing bad can happen. It should be native speed because it's running on the actual metal. Like a hardware CPU, for the web. A multigigaherz processor cannot render an 8-bit (that is 0-255 here) processor running at 1.79 MHz with a whopping 2 kB of RAM that is orders of magnitude slower: https://news.ycombinator.com/item?id=9624483 https://news.ycombinator.com/item?id=9624483 This is insanity. It's time for new hardware, that you can say "go wild" to by typing in an http address. 90% of the reason for enduring this slowness is security. (It's okay to interpret javascript - what's the worst that will happen. It's not okay to agree to run any binary regardless of what will be in it.) It's time for Intel to make chips that you can hand to a website and say, "go wild". I think reinventing C in Javascript at 10% of performance (generously), is what is silly. Running Mario at a bit too slow to be called "perfect" is what is silly. It's 2015. Light travels 10 centimeters between clock cycles, with cores at 3 GHz. Do we really have to spend three billion cycles every second, on interpreting javascript? † "Dedicated hardware would be silly – the current hardware can do secure sandboxing just fine. Cross platform compatibility is an issue with a lot of possible solutions; dedicated hardware would be a far worse case."

cactusface 11y ago
NaCl?
- lucd 11y ago
  https://developer.chrome.com/native-client https://developer.chrome.com/native-client Native Client is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system.
  - cactusface 11y ago
    Oh, it was a suggestion to the guy, but thanks for elaborating.