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

Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

brendaneich.com

Post reply on HN
Print view View original

41–50 of 127 posts

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#41

Post by haberman »

BrendanEich wrote: post #20
equark wrote: post #6

From what is known, it seems as if Google plans to move all their Javascript app building efforts to Dart. Given that GWT/Closure are already pretty successful in large organizations and internally, that seems like a big bet on Dart's future. Whether the Dart VM gets adopted by other browsers seems relatively inconsequential provided they have a decent cross-compilation story. Assume Dart is objectively better except…

"Even Brendan Eich admitted...". As if I would not expect, nay demand , that Gilad and Lars would do better -- much better -- than JS! For the record, I'm not worried about JS being replaced by a better language. I am working to do that within Ecma TC39, by evolving JS aggressively. The leaked Google doc's assertion that this is impossible and that a "clean break" is required to make significant improvements is nonse…

So somehow Google is going to become a monopoly because Apple and Microsoft will voluntarily decline to support a new technology that Google will presumably license freely (as with NaCl)?

I don't even know if I like Dash or not, but how is this move predatory? Did you approach a standards committee or consider the philosophical balance of your competitors before creating JavaScript and shipping it in Netscape? You don't get new good ideas from committees -- just look at the disaster of the last 10 years of the W3C.

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#42

Post by BrendanEich »

haberman wrote: post #41
BrendanEich wrote: post #20

Earlier quoted context omitted.

"Even Brendan Eich admitted...". As if I would not expect, nay demand , that Gilad and Lars would do better -- much better -- than JS! For the record, I'm not worried about JS being replaced by a better language. I am working to do that within Ecma TC39, by evolving JS aggressively. The leaked Google doc's assertion that this is impossible and that a "clean break" is required to make significant improvements is nonse…

So somehow Google is going to become a monopoly because Apple and Microsoft will voluntarily decline to support a new technology that Google will presumably license freely (as with NaCl)? I don't even know if I like Dash or not, but how is this move predatory? Did you approach a standards committee or consider the philosophical balance of your competitors before creating JavaScript and shipping it in Netscape? You do…

Who said anything about Google being "predatory"? I said "not standard."

Google is a search monopoly in some locales, but what I wrote is more about their acting like a browser monopoly.

In a more balanced market, the "defect" choice in the Prisoner's Dilemma is to crank out proprietary stuff and leave your fellow prisoners twisting on the reverse-engineering treadmill (update: don't try open-washing me: NaCl being licensed freely is meaningless when Google controls this very complex pile of code that depends on a deep/wide Pepper API into only one browser; Dart may be simpler but open-source != open or "free"; some vendors such as Opera cannot use any open source).

The "cooperate" choice is to bring prototypes and proposals to standards bodies and gain buy-in and interop.

Yeah, Netscape did a bunch of stuff without standardizing it with w3c or any other body, definitely including JS. We made Microsoft reverse engineer JS as JScript (poor them!). We took JS to ECMA in the second year and only under some pressure from MS and non-sock-puppet web devs. Nothing I can brag about there. That was then, and everyone paid a price.

Now, are you suggesting that Google is the better Netscape, the "good" monopoly? I don't think so.

Again, I'm not moralizing. I'm not the dry drunk lecturing the kids to avoid having the "fun" I had. Google will do what it thinks best. My objection is that we have a non-monopoly browser market, not even a duopoly, with pretty good open-standards innovation. Dart goes the other way and puts the open web at risk. It is fragmenting.

On JS evolution in Ecma TC39, no one wants design by committee. I spoke about how we strive to avoid that in TC39 at TXJS. Give my blogged video a listen if you can.

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#43

Post by karussell »

equark wrote: post #6

From what is known, it seems as if Google plans to move all their Javascript app building efforts to Dart. Given that GWT/Closure are already pretty successful in large organizations and internally, that seems like a big bet on Dart's future. Whether the Dart VM gets adopted by other browsers seems relatively inconsequential provided they have a decent cross-compilation story. Assume Dart is objectively better except…

Just one image for reference :) http://3.bp.blogspot.com/-GBSGBbc9UtA/TmexwLaJN9I/AAAAAAAAAK...

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#44

Post by samth »

nu23 wrote: post #33
BrendanEich wrote: post #29

Earlier quoted context omitted.

Yes, standards must keep up, whatever the proprietary challenger does -- this was true when Flash could do many tricks that browsers generally could not. Without further nuance, saying "standards must keep up, deal with it" is a bit too consequentialist for me, a Mozilla founder, or for anyone working sincerely in the open web standards bodies. Korean and Chinese banks still require ActiveX PKI plugins or else deny s…

Responding to your comment about NaCl, I just wanted to point out something, not contradicting what you said, but emphasizing the motivation for the other side. We are right now in a situation where every significant browser innovation has to move through a very slow process on a timescale of years. And these are the succesful features not blocked by vendor politics. Also, features which are not of widespread interes…

First, jashkenas isn't held up by standards committees -- he's able to experiment with cool new client-side web tech on whatever schedule he wants. And building on this, even more new stuff is happening, like Tim Disney's contracts.coffee [1].

Second, your ability to ship the coolest new client-side technology isn't being held up by TC39, or by the HTMLWG -- nothing we or they could do would make MS ship IE 9 for XP (or make people upgrade from Debian Stable :).

Third, the reason that design takes a while is because it's hard. I'm really glad that Dave Herman and I haven't iterated the ES6 module design in shipping versions of a browser -- that's not the right thing for anyone.

Finally, you mention Scheme. If you want to see a truly disastrous example of language progress held up by politics, check out the last 5 years of Scheme standardization.

[1] http://disnetdev.com/contracts.coffee/

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#45

Post by adgar »

I hate to say it, because Brendan Eich is no blogspammer, but I feel like he name-dropped Google Dart (Dash) as well-intentioned linkbait. It's mentioned in one sentence and offers no new details or interesting discussion.

I agree with georgemcbay that he has reason to be disturbed by Dart's appearance and the backing of Google/Chrome, but with no actual details, he's just taking a quick shot at it while he can here.

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#46

Post by adgar »

chromatic wrote: post #18
LeafStorm wrote: post #5

Earlier quoted context omitted.

The main problem with common VMs for multiple existing languages is that often the semantics of the language are heavily coded into the VM. For example, Parrot's core opcodes mimic Perl's behavior of "Type coercion for everyone, the string "0" is false!" There are a lot of other issues as well, and while they are certainly solvable, the resulting VM would be very heavyweight. If you want to design a VM that runs mult…

Parrot's core opcodes mimic Perl's behavior of "Type coercion for everyone, the string "0" is false!" That's true only for the intrinsic STRING type. Language-specific strings supply their own boolean semantics.

But then if the VM optimizes code paths related to STRING operations, languages can't take advantage of them as easily.

There's a reason why the fastest VMs are deeply tied to the semantics of the language they support, LuaJIT being the best example.

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#48

Post by StrawberryFrog »

thepumpkin1979 wrote: post #31
StrawberryFrog wrote: post #11

Earlier quoted context omitted.

To be pedantic, it wouldn't be "application/csharp". By the time it's compiled to MSIL bytecode it doesn't matter if it was C#, VB, F# or whatever. "application/MSIL" is what I'd say. I can imagine it, and I guess my browsers already have three VM/Runtimes in them (JavaScript, Flash, Silverlight) but it feels so inelegantly top-heavy to have lots more.

Right, call me silly but I'm honoring the "Right-click->View Source" spirit here, I don't know about you but I feel more confortable knowing that my browser is downloading source code and compiling or interpreting than downloading some kind of binary to execute, even if you call it "intermediate code", "byte code" "almost-there-machine-code" or whatever, it's still binary stuff. I get your point though.

I agree, source is better.

But. Flash isn't served as source, is it? And JS is often minified/obfuscated. Sure you can run that through a tool to get back the source (sans comments and long variable names) but you can do just that with MSIL bytecode too.

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#49

Post by juandopazo »

BrendanEich wrote: post #36
ootachi wrote: post #34

Earlier quoted context omitted.

How should we deal with the mandatory dependency on a particular major/minor/patchlevel version of SQLite? That seems bad to standardize on. I personally think there's definitely room for a SQL database API built into the browser, but Mozilla did have a point. It should be something a little bit better specified than that. Also, it's not singlehanded -- IE refused to support Web SQL as well IIRC, and they aren't goin…

Thanks, that's worth reiterating: IE wasn't buying. Alas they didn't get IndexedDB done for IE9. And, just because WebSQL wouldn't fly does not make IndexedDB the one and only winner. We need to revisit this whole messy area.

MongoDB for everyone!

Re: Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

#50

Post by chintan »

karussell wrote: post #43
equark wrote: post #6

From what is known, it seems as if Google plans to move all their Javascript app building efforts to Dart. Given that GWT/Closure are already pretty successful in large organizations and internally, that seems like a big bet on Dart's future. Whether the Dart VM gets adopted by other browsers seems relatively inconsequential provided they have a decent cross-compilation story. Assume Dart is objectively better except…

Just one image for reference :) http://3.bp.blogspot.com/-GBSGBbc9UtA/TmexwLaJN9I/AAAAAAAAAK...

Wow. Just wow!

Goes to show how "Open" the corporations are. Don't blame them, but just wow!

Post reply on HN