[mercurial]

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.

[cliffbean]

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]

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]

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.

[btilly]

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.

[MatthewPhillips]

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.

[mercurial]

What about LLVM? It seems able to deal with a fairly large number of languages with fairly different paradigms (including Rust :) )

[cygx]

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]

Languages targeting bytcode platforms are just as liable to be second-class citizens as ones targeting JavaScript.

Scala and Clojure don't support proper tail calls. Why? Because the JVM is the Java Virtual Machine! I believe there were similar issue for dynamic languages on the JVM for the longest time as well.

And now just imagine implementing a Haskell->JVM compiler. I wouldn't be surprised if that's actually more difficult than implementing a Haskell->JavaScript compiler.

So yes: with JavaScript as the target, other languages are second-class citizens. But with some bytecode, that won't probably won't change much. Knowing how these things get designed, the end result could easily be that every language including JavaScript becomes a second-class citizen.

[bgarbiak]

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

[esrauch]

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.