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

61–70 of 127 posts

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

#61

Post by nu23 »

nu23 wrote: post #57
BrendanEich wrote: post #38

Earlier quoted context omitted.

You have me wrong: NaCl is great, perhaps as near to ideal as it can be (it's still nowhere near "done"; it's experimental where it isn't in DLL hell, libc hell, "portable" LLVM bitcode hell, etc.). The quality of the NaCl work is not the problem. The problem is that none of the other browser vendors can or will afford to get on Google's treadmill, trust Google as much as they would have to, then try to implement Pep…

I agree with what you are saying in the beginning - We definitely need a proper standard and not a single company having design control. I am not so much defending the way Google is going about it, but rather the value of something which plays the essentially same role. Ideally, I would like the web developer to have as much freedom as a developer for a native application - the freedom to choose a programming languag…

OK, Thanks for clarifying. Again, my purpose is not defending NaCl and if this can be done by making JS a better target or by a translator from another VM, that's great, and I hope these projects succeed. And these are worth trying even when the OSes have incompatible workalikes, precisely because they are incompatible. Thanks again for all your work on JS and the open web.

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

#62

Post by nu23 »

samth wrote: post #44
nu23 wrote: post #33

Earlier quoted context omitted.

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…

I guess I was wrong when I said every browser innovation. I also, more or less, agree with your other points - my goal wasn't to bash HTMLWG but to point out that the standardization of a lower level api will help us skip some of the other parts of the standards process by allowing us to do things like compile an sql library directly. Design is indeed hard, but with people free to implement different alternatives, it can happen in a distributed way with more possibilities explored even in production systems. Of course, something as basic as a module system should definitely have a standard. Which would also lead me to agree with your comment on scheme standardization while noting that some of the experiments with first class environments and f-expressions seem to be a genuine exploration a new part of the design space and not a gratuitous incompatibility, but maybe the standardization process should ignore them for the time being.

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

#63

Post by BrendanEich »

nu23 wrote: post #61
nu23 wrote: post #57

Earlier quoted context omitted.

I agree with what you are saying in the beginning - We definitely need a proper standard and not a single company having design control. I am not so much defending the way Google is going about it, but rather the value of something which plays the essentially same role. Ideally, I would like the web developer to have as much freedom as a developer for a native application - the freedom to choose a programming languag…

OK, Thanks for clarifying. Again, my purpose is not defending NaCl and if this can be done by making JS a better target or by a translator from another VM, that's great, and I hope these projects succeed. And these are worth trying even when the OSes have incompatible workalikes, precisely because they are incompatible. Thanks again for all your work on JS and the open web.

In the very long run, could OS-specific CFI enforcement toolchains and runtimes merge into a single standard, usable on the web?

Maybe, but that is beyond my prediction horizon. Either OS vendors or browser vendors (if there's a difference) would have to standardize a butt-load of APIs.

Since the '60s, researchers have dreamed of universal object files (ANDF, e.g.). It would be too funny if far-future JS merges into this single standard too!

("too funny" in my experience means this will definitely happen...)

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

#64

Post by BrendanEich »

nu23 wrote: post #62
samth wrote: post #44

Earlier quoted context omitted.

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…

I guess I was wrong when I said every browser innovation. I also, more or less, agree with your other points - my goal wasn't to bash HTMLWG but to point out that the standardization of a lower level api will help us skip some of the other parts of the standards process by allowing us to do things like compile an sql library directly. Design is indeed hard, but with people free to implement different alternatives, it…

Quick comment: lower-level APIs can be harder to standardize than higher-level ones, depending on the diameter of the API-set and the implementation dependencies. Running native binaries requires a new compiler and a bunch of runtime API support (Pepper).

OTOH adding typed arrays or binary data to JS is narrowly targeted and pays off for higher-level API builders. And the typed arrays and binary data specs are being standardized.

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

#65

Post by BrendanEich »

BrendanEich wrote: post #37
asynchrony wrote: post #32

Earlier quoted context omitted.

I'm having a hard time understanding these objections. Suppose Dart is a new open-source language from Google for front-end web developers. Surely this wouldn't offend anyone. Now suppose they include a Dart->Javascript compiler with the language. Well, he have GWT and coffeescript and all the others. Surely this wouldn't be offensive. Pragmatic, even. Then, being in the unique position to do so, they include special…

You set up a series of straw men based on nothing I wrote. I wrote "Then Dart could come to Ecma as a proposed spec with a single open source implementation." Nowhere did I say a single word trying to corral Google into a non-evil, artificially held back (you imply) posture of offering only compile-to-JS, with no Dart VM in Chrome. Chrome ships all kinds of non-standard or proto-standard stuff. Chrome can certainly s…

A bit more detail about ActiveX. What really brought pressure on non-IE browsers targeting Windows was not just ActiveX's support for scripting the plugin from the page's JS -- again that was missing from the NPAPI.

The big pressure started when Microsoft dropped NPAPI altogether. See http://web.archive.org/web/20071016233843/http://www.meer.ne... (September 4, 2001).

Fast forward to today. I'm told that the next Android release, Ice Cream Sandwich, will drop NPAPI support -- this time in favor of Pepper. ActiveX, ActiveG.

Vertical lock-in from plugin to browser to OS to hardware. The 90s -- if not the 80s pre-commodity-PC -- are back.

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

#66

Post by chromatic »

adgar wrote: post #46
chromatic wrote: post #18

Earlier quoted context omitted.

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.

You're right about LuaJIT, but there's no reason the VM can't also optimize code paths related to high-level string operations.

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

#67

Post by bzbarsky »

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 the security issues ActiveX had. If ActiveX were required for use of gmail today, how would you feel about it? How would you have felt about it in 2002?

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

#68

Post by bzbarsky »

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 wants to lock you into their advertising channels (gmail, google docs, google search).

As long as your mail app is a source of revenue for someone (whether from support contracts or ads), they benefit from you being locked in, at least locally. Globally they may suffer because of the loss of goodwill, of course.

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

#69

Post by bzbarsky »

danmaz74 wrote: post #12

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.

> I'm afraid it's already too late to make suggestions,

Which was precisely the point of developing things this way. They don't want anyone's suggestions; they want to force the thing that benefits _them_ the most on everyone else.

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

#70

Post by SwellJoe »

BrendanEich wrote: post #53
SwellJoe wrote: post #51

Earlier quoted context omitted.

"Whose intent was that?" I have no idea. But, the script tag in HTML, for example, allows specification of language (i.e. " , historically). It was my understanding that this was intended to permit other languages to be included in the browser, or as plugins. It was used by Microsoft for vbscript, and others along the way. I thought that was the intent of that flexibility built into HTML. And, I noted that it was not…

I'm the guy that created -- big dummy me first used language="JavaScript", not type= -- type came in HTML4 (where Dave Raggett invented "text/javascript", never registered; see RFC 4329). Yes, I added language= at the start, but the default was JS and I had no particular intention to support other languages using one or more VMs. I see what you mean now, though -- thanks. Hope this history helps. It's less meaningful…

"More like blind future-proofing."

To me, through my own skewed historical lens, it looks like an admirable level of humility. So, good job.

While that flexibility was mostly used for evil, rather than good (vbscript, for instance), I think it probably helped build a stronger web ecosystem having competitors to the throne even if none ever really got a foothold against JavaScript.

Post reply on HN