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

The State of JavaScript - Brendan Eich

brendaneich.github.com

Post reply on HN
Print view View original

161–170 of 266 posts

Re: The State of JavaScript - Brendan Eich

#161

Post by esrauch »

bgarbiak wrote: post #72
mercurial wrote: post #63

Earlier quoted context omitted.

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.

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

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.

Re: The State of JavaScript - Brendan Eich

#162

Post by haberman »

BrendanEich wrote: post #149
haberman wrote: post #138

Earlier quoted context omitted.

There is a wide gap between fully embracing a technology and spreading misinformation about it. I respect Mozilla's decision not to integrate NaCl, to argue that it's premature to talk about doing so while it's underspecified and coupled to Chromium, and to set criteria that it must meet before it will be on the table for further discussion. I can understand concerns about cost and governance and an unwillingness to…

You are still being free with accusations of spreading misinformation and other evils. If you want to have a real exchange, cool it! Just try to imagine how a hardball from me casting aspersions on you for suspected bad or unfair (to Mozilla; "fair" to Google) motives might feel. Thanks for the PNaCl pointer. My comment was based on LLVM bitcode having machine word size dependencies. This was an issue a while ago. I…

If I sound argumentative and fired up, it's because I feel like Mozilla has been casting stones on this issue for years. Imagine how you would feel if Google executives were publicly criticizing Mozilla efforts like Persona, arguing that they would never support them and no one else will either, basing their criticisms on issues that you are actively fixing.

(For what it's worth, Persona looks promising to me personally, and I also like Rust very much, a lot more than Go. I say this to demonstrate that I'm not just a Google partisan and that I admire a lot of what comes from Mozilla).

I am much happier to discuss this dispassionately on a technical basis. I'm much happier if I don't have to argue against what to me are very unfair accusations, like being as proprietary as Silverlight.

> Here's a final clue: all browser vendors, definitely including Chrome, make the rule (not an argument) "no one gets to the machine except through our VM(s) and GC(s)"

I don't understand the argument you are making, (P)NaCl are specifically designed to allow execution of untrusted code without making it run on top of a VM or GC. And (P)NaCl executables are OS-independent. I don't understand what you're getting at here.

Re: The State of JavaScript - Brendan Eich

#163

Post by masklinn »

simanyay wrote: post #106
streptomycin wrote: post #87

Is there any estimate as to when this (mostly) awesome stuff will actually be implemented in browsers?

Firefox already ships with some (most?) of these features.

And according to [0], Chrome apparently has some (most?) of these features locked behind a big flag (seems to be "Enable Experimental JavaScript" in about:flags, no idea what's implemented though)

edit: http://kangax.github.com/es5-compat-table/es6/ considering the sea of red, it's rather clear that both Firefox and Chrome only implement some ES6 features (note: this crashes Chrome 22 after enabling "experimental javascript", which may explain the big flag, and the latest Firefox 16 improves quite a bit on the listed Firefox 13: adds const, default params, rest params, proxies and all the new Number functions)

[0] https://news.ycombinator.com/item?id=4633069

Re: The State of JavaScript - Brendan Eich

#164

Post by btilly »

pcwalton wrote: post #95
MatthewPhillips wrote: post #93

Earlier quoted context omitted.

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.

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 se…

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.

Re: The State of JavaScript - Brendan Eich

#165

Post by aplzrtve »

BrendanEich wrote: post #157
aplzrtve wrote: post #155

Earlier quoted context omitted.

These are shallow arguments: * pepper is "inspired" by nsapi, clarify your point. * PNaCl performance lagging isn't a solid argument, you know it'll get better, the solution might even be to cut LLVM out save for bitcode. * "nobody does this at the moment" so why does it belong in the OS?

In reverse order: * Why in the OS? I didn't say "belong", just "likelier". That is because plugins are native code compiled by OS-dependent toolchains, and OS vendors are few (three that matter) and lock up native code these days via SDK licenses, app store rules, and even kernel-level restrictions. In contrast, there are four or five competitive browsers, only one of which has Pepper and the rest do not -- and will…

Why differentiate plugins? What makes a VM with JIT not a plugin save the browser vendor shipping it with the browser?

Why wouldn't other browsers have Pepper?

Compilers are as good as what they've been tuned for. In my view PNaCl's shortcoming is startup time because it lacks a JIT and LLVM's back end is too slow for now. Speed up the backend or JIT code and you'll get close to GCC performance while being portable and somewhat language agnostic.

Yes I have seen pepper, and most of the interface relates to the GPU. How is sunk cost better, when a big part of the API can be backed by what canvas relies on?

You would consider adopting PNaCl and pepper in FF if there were games that targeted them? If the code were contributed to Mozilla?

What do you mean by "more native code"? Can't view source?

I appreciate the answers.

Re: The State of JavaScript - Brendan Eich

#166

Post by tikhonj »

MatthewPhillips wrote: post #93
cliffbean wrote: post #84

Earlier quoted context omitted.

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,…

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.

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.

Re: The State of JavaScript - Brendan Eich

#167

Post by goggles99 »

I am sure glad that a small committee of people can use their influence to dictate the standards of the web. We get so much more progress and innovation this way and at such a higher rate of speed don't we?

We don't need no stinking competition in the space. The standards people have a few people in high places here and there that the management in your company will blindly listen to to keep the standards alive.

Long live the dictatorial monarchy of the all powerful omniscient governing body of web standards.

Re: The State of JavaScript - Brendan Eich

#168

Post by dmorgan »

haberman wrote: post #162
BrendanEich wrote: post #149

Earlier quoted context omitted.

You are still being free with accusations of spreading misinformation and other evils. If you want to have a real exchange, cool it! Just try to imagine how a hardball from me casting aspersions on you for suspected bad or unfair (to Mozilla; "fair" to Google) motives might feel. Thanks for the PNaCl pointer. My comment was based on LLVM bitcode having machine word size dependencies. This was an issue a while ago. I…

If I sound argumentative and fired up, it's because I feel like Mozilla has been casting stones on this issue for years. Imagine how you would feel if Google executives were publicly criticizing Mozilla efforts like Persona, arguing that they would never support them and no one else will either, basing their criticisms on issues that you are actively fixing. (For what it's worth, Persona looks promising to me persona…

>(P)NaCl are specifically designed to allow execution of untrusted code without making it run on top of a VM or GC

And this is the argument he's making: that does not fly by browser vendors. They DON'T want to have code run OUTSIDE their VM/GC.

Re: The State of JavaScript - Brendan Eich

#170

Post by dmorgan »

aplzrtve wrote: post #165
BrendanEich wrote: post #157

Earlier quoted context omitted.

In reverse order: * Why in the OS? I didn't say "belong", just "likelier". That is because plugins are native code compiled by OS-dependent toolchains, and OS vendors are few (three that matter) and lock up native code these days via SDK licenses, app store rules, and even kernel-level restrictions. In contrast, there are four or five competitive browsers, only one of which has Pepper and the rest do not -- and will…

Why differentiate plugins? What makes a VM with JIT not a plugin save the browser vendor shipping it with the browser? Why wouldn't other browsers have Pepper? Compilers are as good as what they've been tuned for. In my view PNaCl's shortcoming is startup time because it lacks a JIT and LLVM's back end is too slow for now. Speed up the backend or JIT code and you'll get close to GCC performance while being portable a…

>Why differentiate plugins? What makes a VM with JIT not a plugin save the browser vendor shipping it with the browser?

I think you answered your own question with the "save" part.

The vendor shipping it with the browser means it controls it, it has responsibility for it, it secures it, and it allows it. End of story.

>Why wouldn't other browsers have Pepper?

JS is a necessity for a web browser/vendor, and is already present in it. Pepper is not, and there are NO signs it will be. Do you see any movement towards adoption as of now? I see the opposite, the abandonment of even old style plugins.

Post reply on HN