4 ms·

The "no view source" argument is pretty weak. Most major websites nowadays serve you unreadable compressed JS soup already. Personally, I'd love to have a cross

The "no view source" argument is pretty weak. Most major websites nowadays serve you unreadable compressed JS soup already. Personally, I'd love to have a cross-browser bytecode alternative to Javascript, preferably running in a VM accessible outside of a web browser.

bgarbiak 14y ago
It's rather easy to make minimized JavaScript readable again though. For example, Chrome's Web Developer Tools have such feature built-in.
- esrauch 14y ago
  Readable is a bit of a stretch when the js is thousands of lines of files concatenation together with variable renaming. Google Closure compiler also does function inlining among other optimizations; it's not like you can do view source in Gmail and expect to get anywhere without a lot of reverse engineering effort.
cliffbean 14y ago
A lot of people say they want a bytecode for the web. The problem is, bytecode vs text is just an encoding issue, and it's practically insignificant. It's a platform either way, and the real issues are what services the platform will provide. For example, NaCl doesn't provide Garbage Collection (GC) last I checked. Applications can link in GC libraries for themselves, however that's more code for clients to download, and it may mean that the GC can't do all the low-level things that modern GCs do to get good performance. Is this an acceptable tradeoff for the web? I believe questions like this one are the important ones.
- MatthewPhillips 14y ago
  People who want bytecode has nothing to do with bytecode being better; they want bytecode because they want their language of choice to be a first class citizen and JavaScript-as-assembly means their language will always be second class.
  - pcwalton 14y ago
    I've never seen a bytecode that wasn't just a straightforward source-to-source translation of some language. JVM bytecode is pretty much just another way to encode Java (invokedynamic notwithstanding). .NET bytecode is pretty much just another way to write C#. Bytecode really is nothing more than just a compressed source encoding of some language. It doesn't magically result in a VM that can efficiently encode all semantics of all programming languages, and I don't believe such a VM can exist anyway.
    - MatthewPhillips 14y ago
      Not sure about the JVM, but .NET compiles to an intermediate language called CIL before creating the bytecode. I agree with you, but to bytecode advocates, this is an emotional issue. They do not want JavaScript to be the first-class language and their pet language to be "held back" by it.
    - btilly 14y ago
      Bytecode really is nothing more than just a compressed source encoding of some language. I was with you until you said "compressed". There are plenty of examples where the bytecode representation is bigger than the original source files.
    - mercurial 14y ago
      What about LLVM? It seems able to deal with a fairly large number of languages with fairly different paradigms (including Rust :) )
      - cygx 14y ago
        That's similar to saying that x86 asm is able to deal with a large number of paradigms. LLVM IR might be a a viable target to avoid writing your own native code generators, but that does not a universal bytecode VM for dynamic languages make. It sure would have been nice if Parrot had succeeded there...
  - tikhonj 14y ago

bgarbiak 14y ago

It's rather easy to make minimized JavaScript readable again though. For example, Chrome's Web Developer Tools have such feature built-in.

esrauch 14y ago
Readable is a bit of a stretch when the js is thousands of lines of files concatenation together with variable renaming. Google Closure compiler also does function inlining among other optimizations; it's not like you can do view source in Gmail and expect to get anywhere without a lot of reverse engineering effort.

cliffbean 14y ago

A lot of people say they want a bytecode for the web. The problem is, bytecode vs text is just an encoding issue, and it's practically insignificant. It's a platform either way, and the real issues are what services the platform will provide. For example, NaCl doesn't provide Garbage Collection (GC) last I checked. Applications can link in GC libraries for themselves, however that's more code for clients to download, and it may mean that the GC can't do all the low-level things that modern GCs do to get good performance. Is this an acceptable tradeoff for the web? I believe questions like this one are the important ones.

MatthewPhillips 14y ago
People who want bytecode has nothing to do with bytecode being better; they want bytecode because they want their language of choice to be a first class citizen and JavaScript-as-assembly means their language will always be second class.
- pcwalton 14y ago
  I've never seen a bytecode that wasn't just a straightforward source-to-source translation of some language. JVM bytecode is pretty much just another way to encode Java (invokedynamic notwithstanding). .NET bytecode is pretty much just another way to write C#. Bytecode really is nothing more than just a compressed source encoding of some language. It doesn't magically result in a VM that can efficiently encode all semantics of all programming languages, and I don't believe such a VM can exist anyway.
  - MatthewPhillips 14y ago
    Not sure about the JVM, but .NET compiles to an intermediate language called CIL before creating the bytecode. I agree with you, but to bytecode advocates, this is an emotional issue. They do not want JavaScript to be the first-class language and their pet language to be "held back" by it.
  - btilly 14y ago
    Bytecode really is nothing more than just a compressed source encoding of some language. I was with you until you said "compressed". There are plenty of examples where the bytecode representation is bigger than the original source files.
  - mercurial 14y ago
    What about LLVM? It seems able to deal with a fairly large number of languages with fairly different paradigms (including Rust :) )
    - cygx 14y ago
      That's similar to saying that x86 asm is able to deal with a large number of paradigms. LLVM IR might be a a viable target to avoid writing your own native code generators, but that does not a universal bytecode VM for dynamic languages make. It sure would have been nice if Parrot had succeeded there...
- tikhonj 14y ago