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

71–80 of 127 posts

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

#71

Post by othermaciej »

BrendanEich wrote: post #23
magicalist wrote: post #21

Earlier quoted context omitted.

> We see more of this fragmentation every day I'd be curious to see this backed up. Certainly with a long enough timeline we are not at a maximum of "works only in x", and -- ignoring those beleaguered Opera users still subjected to crappy UA sniffing -- I can't think of the last time I came across a site that blocked me for whatever my choice of browser (I'm a Chrome and Firefox user as well). If, on the other hand,…

I was explicit about the problem, which is not new features that come to some browsers first, advertised in a browser-agnostic way. That is ok, provided the features are on a standards track. What I cited is fragmentation due to capital-C Chrome as a requirement. Google is doing deals and marketing web apps and add-ons as "Chrome". This is showing up all over the place, most recently in my experience on the Starbucks…

I agree with many of the points you have made in this thread, it is indeed a worrying trend.

Howver, I am not sure it is fair to tar WebSQL with the same brush as these other technologies. WebSQL was on the standards track, and in fact started there. The main reason it isn't any more is that Mozilla representatives insisted on kicking it off the standards track instead of fleshing out the spec to be truly independently implementable.

The most common use of SQL you see is in iOS/Android-targeted Web apps, because WebSQL has been around there fore a few years while IndexedDB is new and isn't shipping in production quality anywhere.

Google is actually pretty sanguine about replacing WebSQL with IndexedDB.

Better examples of this trend would be:

SPDY as a replacement for HTTP, actually used in production by Chrome talking to Google servers, not a hint of it on any standards track.

VP8, where Google's single-source implementation is more authoritative than their spec, and no hint of it on any standards track. No apparent interest in putting it there.

(I realize Mozilla is on board with VP8 due to the patent licensing issues with MPEG, but consider the risk of giving Google total unilateral control of video codec design. I would have hoped that Mozilla insisted on taking VP8 through a real standards process before signing on wholeheartedly.)

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

#72

Post by BrendanEich »

othermaciej wrote: post #71
BrendanEich wrote: post #23

Earlier quoted context omitted.

I was explicit about the problem, which is not new features that come to some browsers first, advertised in a browser-agnostic way. That is ok, provided the features are on a standards track. What I cited is fragmentation due to capital-C Chrome as a requirement. Google is doing deals and marketing web apps and add-ons as "Chrome". This is showing up all over the place, most recently in my experience on the Starbucks…

I agree with many of the points you have made in this thread, it is indeed a worrying trend. Howver, I am not sure it is fair to tar WebSQL with the same brush as these other technologies. WebSQL was on the standards track, and in fact started there. The main reason it isn't any more is that Mozilla representatives insisted on kicking it off the standards track instead of fleshing out the spec to be truly independent…

Maciej, why do you write as if Mozilla doesn't ask for (not "insist" on) things with Google and fail to prevail? We do that all the time. Some in Mozilla are still waiting for the good thing to happen.

In VP8's case, what alternative do we have that isn't OS-dependent? We can't afford the gangster fee.

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

#73

Post by othermaciej »

BrendanEich wrote: post #72
othermaciej wrote: post #71

Earlier quoted context omitted.

I agree with many of the points you have made in this thread, it is indeed a worrying trend. Howver, I am not sure it is fair to tar WebSQL with the same brush as these other technologies. WebSQL was on the standards track, and in fact started there. The main reason it isn't any more is that Mozilla representatives insisted on kicking it off the standards track instead of fleshing out the spec to be truly independent…

Maciej, why do you write as if Mozilla doesn't ask for (not "insist" on) things with Google and fail to prevail? We do that all the time. Some in Mozilla are still waiting for the good thing to happen. In VP8's case, what alternative do we have that isn't OS-dependent? We can't afford the gangster fee.

I am wholeheartedly convinced that you asked privately. It might have made a difference if Mozilla had publicly asked for an open standards commitment. As things stand, Google got PR cover for a power grab. I also think it was a reasonable choice for Mozilla to sign onto VP8 anyway, given the lack of better alternatives for you. However, I think VP8 is still a better example of the phenomenon of Google's increasing promotion of purely Google-controlled technologies than WebSQL is.

The video codec situation is really quite sad. There is no technology option that is all of an open standard, RF licensed and sufficient quality. Vendors all have to make their choices out of the imperfect options we have.

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

#74

Post by _sh »

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 reason you won't see a bytecode VM replace Javascript is because bytecode is either interpreted (slow) or JIT-compiled (complicated but faster). If you go for speed and JIT-compile bytecode, why not just compile your source and dispense with bytecodes altogether (as V8 has done)? This gives other runtime implementers the freedom to choose whether to create an interpreter, compiler, or some other execution mechanism, and the programmers the freedom to code at a high-level.

Bytecode, as distinct from object code, is on the way out. Consider Javascript a portable high-level object code and move on. If you want other languages, compile them to Javascript. Semantic affinity between source language and execution environment (e.g. is "0" false, as mentioned elsewhere) is an issue you'll need to address regardless of whether you're using bytecode.

Also, don't underestimate the power 'view source' had in making Javascript perhaps one of the most widely-adopted programming languages in the world.

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

#75

Post by gruseom »

bzbarsky wrote: post #67
gruseom wrote: post #58

I'll pipe up with one thing nobody seems to be emphasizing. A lot depends on how good Dart turns out to be. Suppose it turns out so good that we get all four of the following: 1. No worse a user experience in any browser; 2. A much better user experience in Chrome; 3. A much better developer experience; 4. A much better server-side platform than V8. If we get all that, standards or not, I will be jumping for joy. If…

#2 is bad for users unless Chrome is shipping on all hardware and operating systems users use. In fact, that's the same reason any sort of web-related monopoly is bad. Where's Chrome for PPC processors? Chrome for ARM (being worked on, but no there yet)? Chrome for whatever architecture or OS users might want tomorrow? The right comparison here in your success scenario may not be VBScript but ActiveX, except without…

If ActiveX had been insanely great, not only would I feel fine about it, it would be ubiquitous by now.

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

#76

Post by BrendanEich »

gruseom wrote: post #75
bzbarsky wrote: post #67

Earlier quoted context omitted.

#2 is bad for users unless Chrome is shipping on all hardware and operating systems users use. In fact, that's the same reason any sort of web-related monopoly is bad. Where's Chrome for PPC processors? Chrome for ARM (being worked on, but no there yet)? Chrome for whatever architecture or OS users might want tomorrow? The right comparison here in your success scenario may not be VBScript but ActiveX, except without…

If ActiveX had been insanely great, not only would I feel fine about it, it would be ubiquitous by now.

Isn't "insanely great" a Steve Jobs phrase?

I like Apple's hardware (modulo the fans running all the time on my latest dual-core i7 MBP), and some of its software (but WTF happened to Mail.app on Lion?).

Still, "insanely great" didn't make Apple-only web tech ubiquitous. That took hard, open-standards spec-work in the CSS WG. And that, to the extent it happened with help from Apple, is the opposite of the Dart plan in the leaked memo.

Stop worshipping i.g. It's never that great. Native apps on iOS use Objective-C, for crying out loud. Everyone's sh*t stinks.

I.g. is no excuse for monopoly behavior. The greatness goes away, leaving only insanity.

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

#77

Post by m-k-s »

BrendanEich wrote: post #76
gruseom wrote: post #75

Earlier quoted context omitted.

If ActiveX had been insanely great, not only would I feel fine about it, it would be ubiquitous by now.

Isn't "insanely great" a Steve Jobs phrase? I like Apple's hardware (modulo the fans running all the time on my latest dual-core i7 MBP), and some of its software (but WTF happened to Mail.app on Lion?). Still, "insanely great" didn't make Apple-only web tech ubiquitous. That took hard, open-standards spec-work in the CSS WG. And that, to the extent it happened with help from Apple, is the opposite of the Dart plan i…

Well said Brendan!

Like I said in a tweet this morning, I know those Googlers know way more about JS than I do, but if they think as per the leaked mail) that devs are choosing iOS over browsers because of JS, they have their heads in the sand.

Those choices are happening due to iOS as a platform not because devs are somehow so much more happier learning/using objective-C! The best thing that Google could do is to KEEP working hard on improving the browser platform like you guys are doing with B2G and they started to do with ChromeOS.

For example, I'd love to hear from the ChromeOS team exactly what in JS is blocking them delivering all the kinds of APIs that B2G is promising to deliver.

And on the server-side, some one should tell the hordes flocking to Nodejs that they are all wrong! As you pointed out, serverside everyone can choose to use whatever they want and given that choice, just look at everyone jumping on the Nodejs bandwagon. I'd love to see all those thousands of module that dev around the world have written in Go recently! (npmjs.org)

maks.

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

#78

Post by espadrine »

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…

I don't think Dart will beg other browsers to comply to their will of adding a VM. On the other hand, I find it more likely that, in a whole year's time, the people behind Dart thought about NPAPI. They may very well produce a plugin that everyone will download.

That would make Dart the new Flash, but that's the price to pay for a serious cross-browser Dart.

Of course, that would also make Dart second-class citizen in the web platform, and I guess Dart people don't want that. However, I find it hard to believe that they hoped all browser vendors would bow before the new programming language overlord.

Now, making browsers speak Dart will be the easy part, I think. The Enterprise will have a hard time accepting a brand-new language blindly when they have just learned that C# is slowly losing Microsoft backing.

Programming languages all make mistakes, and Dart will be no exception; they had a full year and bright engineers, but that rule is sacred. No matter how hard they advocate the niceties of the language (which I assume will be closures (again!), the full funarg, yet another garbage collector, optional typing, type inference, bignums, modules, event-oriented programming, maybe lazy evaluation) but I know many programmers that won't bother learning any programming language that falls too far from the C-like tree, especially if it has odd features, especially if there are mistakes in the way those features work together.

I have seen many bright programming languages that never found any serious adoption. Scheme would have been very interesting in real work environments; Perl6 has many interesting features, but is too late and slow; Haskell still has potential, but I don't see it suddenly go past Objective-C, C# or Java in popularity.

I would love Dart to find success. But this is not a dream world. The platform it seeks to conquer, the competition it must overcome, the tender age it has: Dart is so very late for such a challenge.

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

#79

Post by bzbarsky »

gruseom wrote: post #75
bzbarsky wrote: post #67

Earlier quoted context omitted.

#2 is bad for users unless Chrome is shipping on all hardware and operating systems users use. In fact, that's the same reason any sort of web-related monopoly is bad. Where's Chrome for PPC processors? Chrome for ARM (being worked on, but no there yet)? Chrome for whatever architecture or OS users might want tomorrow? The right comparison here in your success scenario may not be VBScript but ActiveX, except without…

If ActiveX had been insanely great, not only would I feel fine about it, it would be ubiquitous by now.

So you would be OK with requiring everyone to use Windows as their operating system, in perpetuity?

I think we have some fundamental philosophical differences about how the world should work. ;)

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

#80

Post by gruseom »

bzbarsky wrote: post #79
gruseom wrote: post #75

Earlier quoted context omitted.

If ActiveX had been insanely great, not only would I feel fine about it, it would be ubiquitous by now.

So you would be OK with requiring everyone to use Windows as their operating system, in perpetuity? I think we have some fundamental philosophical differences about how the world should work. ;)

"So you would be OK with requiring everyone to use Windows as their operating system, in perpetuity?"

Of course I don't think that. I meant by "ubiquitous" to imply the opposite. I fear we're talking past each other.

The risks of Google behaving like a Microsoft-style monopolist here are low because (a) they have no monopoly in browsers, VMs, or OSes to abuse, (b) their culture is the most hacker-driven of any large company, (c) their interests are aligned with what is good for the web, and (d) the industry has changed since the bad old days.

Given this, and because the potential value of this project is so high, I'm willing to give them a chance.

Since making my original post, I've read a bit more about Bracha and Newspeak. Assume for the time being that Dart is an evolution of this work. We're talking about a fast, small, even-more-dynamic Smalltalk augmented with ideas from Self and E, designed for the web and multicore. That's mind-blowing. Now throw in the implementation prowess of a Bak and the institutional support of a Google, and we're talking about something potentially game-changing. To judge by their track records (e.g. the Resilient embedded Smalltalk that Bak worked on), these guys are out to correct not only the mistakes of Javascript but of Java as well. Historic stuff, which they have as good a shot at pulling off as anybody ever has.

I admit the odds are against it turning out so well. But this is the rare case where at least some optimism is well-grounded. If what they release does turn out to be an attempt at the above, it will be exciting.

Post reply on HN