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

11–20 of 127 posts

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

#11

Post by StrawberryFrog »

thepumpkin1979 wrote: post #3
georgemcbay wrote: post #2

I feel for Brendan Eich, he is a bit of an unsung hero when you consider what he enabled with JavaScript and it is always stressful to learn someone is trying to kill your baby. Having said that, I really do hope it is killed. Well, not killed , but demoted to "one supported language of many". And the sooner this is started, the better, because it is a long, long process. I don't think JavaScript is bad , but I do st…

A standard VM/Runtime specification for all the browser would be awesome. We got plenty of them; CLR, DLR, JVM, Parrot, etc. Can you imagine? I can see those mime types already: application/csharp, application/perl, application/ruby, application/IL.

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.

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

#12

Post by danmaz74 »

I'm afraid it's already too late to make suggestions, but I would be really excited if Dart supported facilities to make unit testing an integral part of the language, taking into consideration the interaction with the DOM. This is something that would really help IMHO.

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

#13

Post by equark »

MatthewPhillips wrote: post #10
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…

Not all of Dart/Dash can compile to JS.

Given that it is also a server side language this is not surprising or worrying. It's no different than node.js specific code that doesn't work in the client. I think it's just inherent to heterogenous environments. If they can do better than gwt I think they'll be fine.

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

#14

Post by equark »

wavephorm wrote: post #8
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…

Google is clearly priming to do a Microsoft-style embrace-and-extend in a big way. Between Chrome, V8, NaCL, WebGL, Android, they have a wide range of technologies that they could begin steering away from standards.

Except that they have a monopoly position in none of those domains. Microsoft used their power to protect their monopoly. The Dart document itself says the number one reason for Dart is to protect Google's massive bet on the web platform. It's easy to see how Microsoft or Apple could seriously undermine Google by keeping the web platform second rate, which is certainly within their power given current browser marketshares.

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

#15

Post by wavephorm »

ender7 wrote: post #9
wavephorm wrote: post #8

Earlier quoted context omitted.

Google is clearly priming to do a Microsoft-style embrace-and-extend in a big way. Between Chrome, V8, NaCL, WebGL, Android, they have a wide range of technologies that they could begin steering away from standards.

But...why? Google makes money selling ads. It doesn't make money selling you support contracts for software that you've been locked into. From what I can tell, Android exists so that Google isn't at the whim of Apple. The big G's greatest fear is that iPhones become the defacto smartphone, and Apple has the power to cut them out of their platform (by banning Google's ad networks and by setting the default search engi…

Google's strategy may be different than Microsoft, but the motivation is the same: to trap developers, and make them dependent on you, and to differentiate their technology from their peers.

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

#16

Post by mbrubeck »

georgemcbay wrote: post #2

I feel for Brendan Eich, he is a bit of an unsung hero when you consider what he enabled with JavaScript and it is always stressful to learn someone is trying to kill your baby. Having said that, I really do hope it is killed. Well, not killed , but demoted to "one supported language of many". And the sooner this is started, the better, because it is a long, long process. I don't think JavaScript is bad , but I do st…

Brendan has previously talked about some obstacles to a bytecode/VM-level specification, and some advantages of specifying the browser language at the source level rather than at the bytecode level:

http://news.ycombinator.com/item?id=1893686 (see comments by BrendanEich and others)

http://www.aminutewithbrendan.com/pages/20101122

http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo...

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

#17

Post by petercooper »

ender7 wrote: post #9
wavephorm wrote: post #8

Earlier quoted context omitted.

Google is clearly priming to do a Microsoft-style embrace-and-extend in a big way. Between Chrome, V8, NaCL, WebGL, Android, they have a wide range of technologies that they could begin steering away from standards.

But...why? Google makes money selling ads. It doesn't make money selling you support contracts for software that you've been locked into. From what I can tell, Android exists so that Google isn't at the whim of Apple. The big G's greatest fear is that iPhones become the defacto smartphone, and Apple has the power to cut them out of their platform (by banning Google's ad networks and by setting the default search engi…

Don't forget SPDY. If you use Chrome, you're probably using SPDY when accessing services like GMail and Google Search. What does this get you? A snappier experience. This could dissuade you from using other services even in just the 'feel'.

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

#18

Post by chromatic »

LeafStorm wrote: post #5
georgemcbay wrote: post #2

I feel for Brendan Eich, he is a bit of an unsung hero when you consider what he enabled with JavaScript and it is always stressful to learn someone is trying to kill your baby. Having said that, I really do hope it is killed. Well, not killed , but demoted to "one supported language of many". And the sooner this is started, the better, because it is a long, long process. I don't think JavaScript is bad , but I do st…

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.

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

#19

Post by enneff »

ender7 wrote: post #9
wavephorm wrote: post #8

Earlier quoted context omitted.

Google is clearly priming to do a Microsoft-style embrace-and-extend in a big way. Between Chrome, V8, NaCL, WebGL, Android, they have a wide range of technologies that they could begin steering away from standards.

But...why? Google makes money selling ads. It doesn't make money selling you support contracts for software that you've been locked into. From what I can tell, Android exists so that Google isn't at the whim of Apple. The big G's greatest fear is that iPhones become the defacto smartphone, and Apple has the power to cut them out of their platform (by banning Google's ad networks and by setting the default search engi…

When making these analyses people tend to forget that Google is a company of thousands of engineers. If we can devote a bit of engineering time to building better environments, the benefits across the entire company are multiplicative. Would you expect anything less from an engineering-driven company?

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

#20

Post by BrendanEich »

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 nonsense, a thin rationale for going it alone rather than cooperating fully.

The big issue I have with Dart, which you seem to consider inconsequential, is whether Google forks the web developer community, not just its own paid developers, with Dart, and thereby fragments web content.

A Dart to JS compiler will never be "decent" compared to having the Dart VM in the browser. Yet I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM.

So "Works best in Chrome" and even "Works only in Chrome" are new norms promulgated intentionally by Google. We see more of this fragmentation every day. As a user of Chrome and Firefox (and Safari), I find it painful to experience, never mind the political bad taste.

Ok, counter-arguments. What's wrong with playing hardball to advance the web, you say? As my blog tries to explain, the standards process requires good social relations and philosophical balance among the participating competitors.

Google's approach with Dart is thus pretty much all wrong and doomed to leave Dart in excellent yet non-standardized and non-interoperable implementation status. Dart is GBScript to NaCl/Pepper's ActiveG.

Could Google, unlike Microsoft ten or so years ago, prevail? Only by becoming the new monopoly power on the web. We know how that story ends.

Post reply on HN