Live data from Hacker News

Why are we limited to JS in browsers - would a bytecode standard help?

andrewducker.livejournal.com

31–40 of 187 posts

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#31
post #26
post #23

In all honesty... what's the difference? Turing complete language ≈ Turing complete language. Just make something to compile your language of choice into JavaScript, or make a new one (CoffeeScript). Bytecode is just a little more dense, little faster executing, far harder to investigate language than JavaScript, which the browser can compile for added speed anyway. I prefer my language-of-the-web to be readable, tha…

The difference is that Javascript is a crappy language and I resent having to write in it. In addition, it lacks types and is therefore slower and does not execute the same way on all platforms.

Crappy is subjective. I actually like JavaScript.

JavaScript, although dynamic and loosely typed, does have types: string, number, object (including array, function and date), null and undefined are all JavaScript types.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#32
Before speculating too much about "a bytecode standard", etc., it would probably be helpful to understand virtual machines and instruction sets.

I know web programmers generally aren't big on assembly or writing virtual machines, but an instruction set (group of bytecodes) design and implementation predisposes a processor/VM to certain operations. A VM for an OO language is going to have bytecodes (and other infrastructure) for doing fast method lookup, because it will really hurt performance otherwise. A functional or logic language VM will probably have tail-call optimization, perhaps opcodes specific to pattern matching / unification, and a different style of garbage collector.

Compare the JVM to the Lua or Erlang virtual machines; think about the issues people run into when trying to port languages that aren't like Java to the JVM. Unless people are very deliberate about making a really general instruction set, a "bytecode standard" informed by Javascript could be similarly awkward for languages that aren't just incremental improvements on Javascript. Besides, you can't optimize for everything.

There are a LOT of details I'm glossing over (e.g. sandboxing/security concerns, RISC vs. CISC, the DOM), but I've been meaning to point this out since I read someone saying, "Why do people keep writing more VMs? Why don't we just use the JVM for everything and move on?" It's not that easy.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#34
Having a standard bytecode would make it much harder to steal code which is much needed as web and mobile applications shift towards using lots of JavaScript.

Currently it's way too easy to steal everything since the whole source is exposed. You can obfuscate JavaScript and CSS, but the main semantics will still be there and someone that's interested will still steal your code (this has happend twice to us, even if all of our JS is obfuscated using Google Closure...) The same thing could happen with bytecode, but their takeout would not be maintainable. Obfuscated JavaScript is still maintainable, since the structure and semantics are largely there.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#35
post #23

In all honesty... what's the difference? Turing complete language ≈ Turing complete language. Just make something to compile your language of choice into JavaScript, or make a new one (CoffeeScript). Bytecode is just a little more dense, little faster executing, far harder to investigate language than JavaScript, which the browser can compile for added speed anyway. I prefer my language-of-the-web to be readable, tha…

Well, you would be developing with plain javascript or symbols just like when writing native code. And besides, minified javascript might be more readable than bytecode but just barely.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#36
post #26
post #23

In all honesty... what's the difference? Turing complete language ≈ Turing complete language. Just make something to compile your language of choice into JavaScript, or make a new one (CoffeeScript). Bytecode is just a little more dense, little faster executing, far harder to investigate language than JavaScript, which the browser can compile for added speed anyway. I prefer my language-of-the-web to be readable, tha…

The difference is that Javascript is a crappy language and I resent having to write in it. In addition, it lacks types and is therefore slower and does not execute the same way on all platforms.

Then why don't you treat your JavaScript as object code, and compile a language you like better to it?

It does not lack types (it just lacks static type checking); it is not significantly slower (JavaScript JIT is very advanced, and you're not compute-bound in JavaScript). And "it does not execute the same way on all platforms" is true for pretty much all languages on all platforms, so I don't know what you're getting at.

If you'd like a better language I can suggest CoffeeScript and ghcjs.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#38
post #34

Having a standard bytecode would make it much harder to steal code which is much needed as web and mobile applications shift towards using lots of JavaScript. Currently it's way too easy to steal everything since the whole source is exposed. You can obfuscate JavaScript and CSS, but the main semantics will still be there and someone that's interested will still steal your code (this has happend twice to us, even if a…

I'd counter that that ability to easily copy what the browser sees and dissect it is what leads to rapid growth and innovation on the web front.... obfuscating everything will act counter to that, and leave the web not nearly as nice a place as we'd like it to be.

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#39
post #23

In all honesty... what's the difference? Turing complete language ≈ Turing complete language. Just make something to compile your language of choice into JavaScript, or make a new one (CoffeeScript). Bytecode is just a little more dense, little faster executing, far harder to investigate language than JavaScript, which the browser can compile for added speed anyway. I prefer my language-of-the-web to be readable, tha…

One difference is in compiler optimizations. For a given language, compilers can often make inferences based on the code and the semantics of the language, allowing for very targeted optimizations. If you go from LanguageFoo -> Javascript -> bytecode, then you may be limiting the range of optimizations possible (because Javascript may not be able to infer the same things about the code, be it because of program structure, language semantics, etc.)

Re: Why are we limited to JS in browsers - would a bytecode standard help?

#40
post #34

Having a standard bytecode would make it much harder to steal code which is much needed as web and mobile applications shift towards using lots of JavaScript. Currently it's way too easy to steal everything since the whole source is exposed. You can obfuscate JavaScript and CSS, but the main semantics will still be there and someone that's interested will still steal your code (this has happend twice to us, even if a…

Bytecode-compiled languages are dreadfully easy to decompile.
Post reply on HN