Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

andrewducker.livejournal.com

Post reply on HN
Print view View original

171–180 of 187 posts

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

#171

Post by pyre »

SudarshanP wrote: post #168
pyre wrote: post #166

Earlier quoted context omitted.

It's probably less to do with a bytecode 'standard' vs. a set of standard libraries for doing things outside of the browser (file manipulations, etc). Then browsers could just not support those libraries, but JavaScript VM developers could. In this way, it would be possible to not have 'the future of JavaScript' tied down to a specific bytecode implementation. Then people could pick and choose the VM that they want t…

http://code.google.com/p/nativeclient/ may answer your need. Hopefully someday something like this will be available cross browser...

I'm not talking about pulling C libraries into the browser. I'm talking about expanding the use of the JavaScript language outside of the browser (beyond even something like Node.js).

Unless I'm completely misunderstanding NativeClient, that's not what it's about.

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

#172

Post by pedrocr »

user24 wrote: post #136
pedrocr wrote: post #4

I tried to make this point in this submission: http://news.ycombinator.com/item?id=1790311 The fact that it also ranted about Javascript shifted the discussion though

I remembered that post when I saw this headline. I think from a philosophical viewpoint it's a good idea - though I've no idea what the implementation difficulties might be (could google have created V8 if we had a bytecode system?). But from a practical stance, what's the benefit? What would it achieve?

>But from a practical stance, what's the benefit? What would it achieve?

The reasons I outlined in my post were things like having a single form validation codebase, deployed both server side and client side. More ambitiously you could have the same codebase used for the server-side online portions of something like gmail and also retarget that to use for offline gmail. Basically the big divide between your server-side and client-side codebases would start to disappear.

Seems like Google's native client system is a great step in this direction. Soon enough it may be possible to target say Lua to LLVM bytecode and deploy that to a browser in a bundle of javascript. If the browser supports NaCi you execute the LLVM bytecode with the built-in VM, if not you have a fallback bytecode interpreter in Javascript. That way you get full coverage of browsers with only degradation of performance when NaCi isn't available. I'm not sure however how fast you could make the Javascript fallback. If it is very slow it may not be workable.

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

#173

Post by silentbicycle »

InclinedPlane wrote: post #167
silentbicycle wrote: post #159

Earlier quoted context omitted.

Actually, I think you're right - Javascript was frozen very early and Unix had a while to develop, but the same forces (competing commercial implementations) locked in minor errors in Unix as well. I'd say Unix got more of its warts fixed than JS did, but that's only a difference of degree. Mainly: The whole "Worse is Better" thing works better when you don't get stuck maintaining reverse compatibility with your earl…

I'd say Unix and C have more warts, and more serious warts, than Javascript does. But we have come to accept those warts in Unix and C as "the way things are" whereas we generally perceive javascripts warts as such. Arguably the decision to use null-terminated strings in C in order to save one or two bytes of memory per string is an error of much greater than Y2K proportions that we are still paying for.

Agreed, though I think most of Unix's serious warts are actually C's. They're synergistic, though.

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

#174

Post by amix »

tptacek wrote: post #40
amix wrote: 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.

The point isn't that you can't decompile bytecode-languages, but that the decompiled bytecode is a lot harder to maintain than obfuscated JavaScript...

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

#175

Post by amix »

contextfree wrote: post #68
amix wrote: 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…

If anything I think e.g. .NET/CLR bytecode is easier to reverse engineer than obfuscated JavaScript, because of the type metadata.

With obfuscated JavaScript you get all the sematics and for the most time all the global functions and data structures names since they aren't obfuscated away. This is a lot more structure and information than you get in your average bytecode code (especially since bytecode tends to be much more low level than something like obfuscated JavaScript).

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

#176

Post by known »

pyre wrote: post #171
SudarshanP wrote: post #168

Earlier quoted context omitted.

http://code.google.com/p/nativeclient/ may answer your need. Hopefully someday something like this will be available cross browser...

I'm not talking about pulling C libraries into the browser. I'm talking about expanding the use of the JavaScript language outside of the browser (beyond even something like Node.js). Unless I'm completely misunderstanding NativeClient, that's not what it's about.

Doesn't both merge at some point?

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

#177

Post by contextfree »

amix wrote: post #175
contextfree wrote: post #68

Earlier quoted context omitted.

If anything I think e.g. .NET/CLR bytecode is easier to reverse engineer than obfuscated JavaScript, because of the type metadata.

With obfuscated JavaScript you get all the sematics and for the most time all the global functions and data structures names since they aren't obfuscated away. This is a lot more structure and information than you get in your average bytecode code (especially since bytecode tends to be much more low level than something like obfuscated JavaScript).

Have you ever looked at e.g. .NET assemblies in Reflector? It will decompile them into C# code that usually isn't even all that strange or hard to follow. There's plenty of structure and information there.

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

#178

Post by silentbicycle »

silentbicycle wrote: post #173
InclinedPlane wrote: post #167

Earlier quoted context omitted.

I'd say Unix and C have more warts, and more serious warts, than Javascript does. But we have come to accept those warts in Unix and C as "the way things are" whereas we generally perceive javascripts warts as such. Arguably the decision to use null-terminated strings in C in order to save one or two bytes of memory per string is an error of much greater than Y2K proportions that we are still paying for.

Agreed, though I think most of Unix's serious warts are actually C's. They're synergistic, though.

(Oops: I meant 'symbiotic'.)

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

#179

Post by sedachv »

jules wrote: post #145
sedachv wrote: post #144

Earlier quoted context omitted.

"- Scheme: this would have been a much better choice, because it supports integers and has a compact object representation instead of representing everything with hash tables. Bad point: all objects are boxed (like in JS). Good point: tail calls are handy when compiling all kinds of control structures." The boxing part is untrue. Even on 32-bit systems (that have word-aligned addressing, which all current 32-bit syst…

> The boxing part is untrue. You're right. Scheme implementations usually have unboxed fixnums and other types. However Scheme systems do not usually support user defined unboxed objects, like C#, C and ML do. > Tail calls are overrated, maybe you're thinking about continuations? Those would have been truly terrible I agree, I did mean tail calls. Tail calls may not be so good for programming with, but they are good…

"You're right. Scheme implementations usually have unboxed fixnums and other types. However Scheme systems do not usually support user defined unboxed objects, like C#, C and ML do."

That's because Scheme has to support type safety for arbitrary code loaded at run-time. Exactly like JavaScript has to do when the web browser GETs a script. Exactly what any of the other proposed ILs would have to do as well.

"I agree, I did mean tail calls. Tail calls may not be so good for programming with, but they are good for compiling to, because you can easily encode your control structures like while, for, until, state machines and more exotic forms of looping to them. You can also compile (parts of) code in continuation passing style without blowing the stack, which is hard to do efficiently if you don't have tail calls.

The reverse is not true, you cannot easily express tail calls on top of the usual control structures like while. This is why Scala and Clojure still don't have support for tail calls."

A better argument can be made for gotos than tail calls in this case. JavaScript already has gotos in the form of labels and break.

Tail call faking doesn't always have to have a trampoline overhead cost. Take a look at Scheme2JS for how they do it (http://www-sop.inria.fr/indes/scheme2js/)

"I'm not arguing that Java is better than Javascript for programming in. It's just a better target for compilers."

JavaScript provides run-time types and extensive reflection and introspection facilities. This makes it relatively straightforward to write something like Parenscript. OTOH trying to compile even a static subset of Common Lisp to C or Java is pretty complicated.

"Do you have any arguments to back up why ML would not be a better IL than JS?"

Your original statement was: "I challenge you to find a language that would have been a worse choice than Javascript." Given the state of ML implementations in 1995, I think it would have been a worse choice.

"It seems to me that you are arguing that these languages are not better than JS for programming in, but that is not what I claimed."

And you seriously think people would have first run out and built compilers from other languages to the "hypothetical better than JavaScript" language rather than use the latter directly? Because that's not what actually happened.

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

#180

Post by blasdel »

TNO wrote: post #157
silentbicycle wrote: post #103

Earlier quoted context omitted.

Tcl would have been worse, probably.

VBScript

Except that VBScript is implemented as a DOM scripting language in IE!

I've had several mid-end managed switches where the web configuration UI used it and was unusable outside of IE with no sign as to why unless you read the source.

Post reply on HN