Live data from Hacker News

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

andrewducker.livejournal.com

41–50 of 187 posts

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

#41
post #28
post #26

Earlier quoted context omitted.

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.

Not the same on all platforms is a wholly legitimate complaint. It's frickin' annoying that browsers don't all implement the same language. But bytecode won't solve that. IE will still refuse to implement subset-X, WebKit will still prefix their CSS with -webkit, etc. Until everything settles down and decides on one implementation, in which case I'd still prefer to be able to read what the web is sending to me.

minified js isn't much more readable than bytecode

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

#42
post #26

Earlier quoted context omitted.

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.

I'd add that it has functions as first-class citizens and closures. Javascript has for sure some crappy parts, but there is also a lot of good in it.

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

#44

Earlier quoted context omitted.

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.

I'd add that it has functions as first-class citizens and closures. Javascript has for sure some crappy parts, but there is also a lot of good in it.

I find Javascript depressing. If it had a few more years to develop, it could have been a really great language. I understand why it wound up that way, but, sigh.

If you want to see a much better language with the same general design, look at Lua. It's made for scripting C programs rather than web pages, and it has had over a decade longer to mature.

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

#45
post #43

Am I missing something, or did we all have a browser bytecode standard that everyone hopped on board with, and it turned out nobody really liked feeding browsers compiled programs after all?

It was the core, defining feature of the most used language in the business world... and everyone with any sense is trying to forget it every happened.

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

#46
post #43

Am I missing something, or did we all have a browser bytecode standard that everyone hopped on board with, and it turned out nobody really liked feeding browsers compiled programs after all?

It was never integrated into the DOM, though, was it? I am only aware of it being used in a separate, sandboxed area on the page, unable to interact with anything else except in a very limited way.

(Never mind the slow loading time etc)

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

#47
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 struc…

The same holds true with bytecodes. e.g. TCO on the JVM: http://stackoverflow.com/questions/105834/does-the-jvm-preve...

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

#48

Earlier quoted context omitted.

I'd add that it has functions as first-class citizens and closures. Javascript has for sure some crappy parts, but there is also a lot of good in it.

I find Javascript depressing. If it had a few more years to develop, it could have been a really great language. I understand why it wound up that way, but, sigh. If you want to see a much better language with the same general design, look at Lua. It's made for scripting C programs rather than web pages, and it has had over a decade longer to mature.

Why do you find it depressing?

I'm not saying that there aren't better programming languages than Javascript. I'm just saying that there is a subset of Javascript which is really expressive and elegant.

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

#49

Earlier quoted context omitted.

I'd add that it has functions as first-class citizens and closures. Javascript has for sure some crappy parts, but there is also a lot of good in it.

I find Javascript depressing. If it had a few more years to develop, it could have been a really great language. I understand why it wound up that way, but, sigh. If you want to see a much better language with the same general design, look at Lua. It's made for scripting C programs rather than web pages, and it has had over a decade longer to mature.

JavaScript was released in 1995 as part of Netscape Navigator 2.0. Lua was released in 1993. I don't know about a decade.

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

#50
post #16

Earlier quoted context omitted.

I believe some work went on to produce a Java-running chip at one point. It proved better to compile down to whatever suited the chip best.

In that sense, Intel is just making CPUs on top of x86 bytecode that runs natively. I wonder if a little extra firmware can eliminate the need for an OS altogether.

If by "a little extra firmware", you mean "calling the OS firmware, and burning it into the CPU", then yes.
Post reply on HN