5 ms·
Brendan Eich cried foul about Dart because other browser manufacturers, and web developers themselves, said they didn't want it, and Google did it anyway.
by ootachi 15y ago
Brendan Eich cried foul about Dart because other browser manufacturers, and web developers themselves, said they didn't want it, and Google did it anyway.
- haberman 15y agoI was unaware that a poll had been taken of all web developers asking whether they wanted Dart. If developers really don't want it, they'll vote with their feet, so what's the big issue? Also: > 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." --Brendan Eich, http://news.ycombinator.com/item?id=2982949 http://news.ycombinator.com/item?id=2982949 Basically he's arguing that the browser vendors of today (not developers/users) are the gatekeepers of what new technologies can be tried. It's like making browser innovation a UN Security Council where every member has a veto over doing anything. If you value progress and innovation, I do not see how you can support such a position. If Google introduces something like Dart or NaCl, is willing to support standardization of it and even release a free implementation, but other browser vendors don't want to integrate it because they don't like it, that's their problem, not Google's. If that means popular apps become "Works best in Chrome," that is a self-inflicted wound.
- mbrubeck 15y ago"Basically he's arguing that the browser vendors of today (not developers/users) are the gatekeepers of what new technologies can be tried." Anyone's free to try things. But those things will never become a part of the web platform if other vendors don't think they will benefit from implementing them. The people who make the browsers are gatekeepers of what ends up in the browsers. That's not a statement about how things should or shouldn't be; it's just a tautology. The job of anyone who wants to create a web standard is to accept that fact, not ignore it. Ignoring it leads to single-browser "standards", which may get adopted by developers but will not become part of the open, interoperable web platform.
- tptacek 15y agoWhat are the things Webkit has "proposed" by releasing builds that you don't think should be part of the web platform? And, what are the things Webkit has built that were "overridden" by the standards process? Where did Webkit actually get things wrong? Just what comes to your mind.
- mbrubeck 15y agoFirst of all, I don't want to come off as argumentative. I think we agree on the fundamentals: Implementation should come before standardization. Vendors should feel free to experiment. The W3C should focus more on quickly standardizing things that are already working in the field. Today, experimental and prefixed features used in the wild are creating real problems for interoperability and competition. But I don't think there's a villain here, and I'm not blaming WebKit. Both the browser vendors and the W3C are using processes that were designed to certain solve problems. Now those processes are creating new problems and might need to change in response. But, to answer your direct question (although I think this is getting on a tangent from the original post): > "What are the things Webkit has "proposed" by releasing builds that you don't think should be part of the web platform?" Dart is an example of something that Google has proposed (not "WebKit" as a group) that I and many others - even others like Oliver Hunt within the WebKit community - do not think benefits the web platform. Some people would put Web SQL Database in this category; I don't have an informed opinion about that one. (Though I do know it's the reasons some versions of Gmail wouldn't even load in mobile Firefox.) > "Where did Webkit actually get things wrong?" Apple's "meta viewport" tag is something that they released in Safari and evangelized to developers without specifying it or getting community feedback. I had the pleasure of reverse-engineering it for Gecko. Among other things, it's not even implemented in a layer where it makes sense. (It should be part of style, not markup.) Apple never proposed it as a standard; other people eventually did and are trying to fix some of the problems. Unfortunately, the basic design is locked in by legacy content (and has been since soon after Apple shipped this feature in the first release of mobile Safari). But frankly, I don't care so much whether they get things "right" or "wrong." As bad as meta-viewport is, at least Firefox and Opera and Android and IE can implement support for it without controversy, and be compatible with sites that use it. The way that prefixed CSS properties are (a) released to market by browser vendors, (b) evangelized to web developers, and (c) deployed on production web sites is creating a situation where new browsers are either locked out of existing sites or have to implement each others' prefixes. This is not a stable equilibrium.
- SoftwareMaven 15y agoI think this is a valid concern. It is very similar to ActiveX with Internet Explorer, and, with the browser share Chrome is gathering, it isn't unreasonable to see people focusing on that. --BUT-- With ActiveX, there was no other way to accomplish the same task. With Dart versus JavaScript, I can't accomplish anything in Dart that I can't in JavaScript. And, even if I decided to use Dart for some reason, it would be idiotic of me not to provide a JS version for non-Chrome browsers. What would be really nice (heck, even something a standards body should have done) is coming up with a standard byte-code for browsers, so I can use any language I want. JavaScript isn't good enough, because I want my sites to load faster, and parsing the code shouldn't have to happen every time somebody visits a page.
- haberman 15y ago> What would be really nice [...] is coming up with a standard byte-code for browsers I used to think that too, until I read convincing arguments against it like this: http://www.2ality.com/2012/01/bytecode-myth.html http://www.2ality.com/2012/01/bytecode-myth.html
- cromwellian 15y agoHowever, Javascript as the intermediate language does not follow. It may be true that a source-level intermediate representation has benefits, but the idea that the best intermediate representation is JS doesn't follow. For example, late-binding, boxing/heap-numbers, etc all serve to make it extremely difficult to maximize startup performance, or heap overhead. It also makes the VMs much more complex to deal with optimizing such languages. TypedArrays don't really fix the problem, they just introduce others. For example, by forcing your to implement your own manual memory management everywhere. This is somewhat problematic if you're compiling a language with GC into TypedArray heavy code, since there's no finalizers in JS or Reference queues, you can't really do automatic release if a regular heap object holds into pseudo-objects in manually allocated memory. The problem is particularly acute on mobile devices which are very resource constrained.
- nailer 15y ago> I was unaware that a poll had been taken of all web developers asking whether they wanted Dart. A few hours ago at JQuery UK someone asked Paul Irish what he thought of Dart. Then the whole room laughed. PI mentioned 'its complicated' and then that 'Dart has a place' and then everyone laughed again.
- batista 15y agoA few hours ago at JQuery UK someone asked Paul Irish what he thought of Dart. Then the whole room laughed. PI mentioned 'its complicated' and then that 'Dart has a place' and then everyone laughed again. So a knee jerk unintelligent response by some random group of Javascript programmers, given without context, is supposed to mean something?
- ootachi 15y agoIt wasn't "any member having a veto over doing anything". Don't attack a straw man. It was every other browser manufacturer unanimously saying Dart is a bad idea, and specifically outlining reasons for doing so. The only possible position you could have in support of Google here is that Google should be able to push whatever it wants, on account of Chrome being open source. In other words, monopolistic behavior is fine as long as it's open source. I don't agree with that. Also "Works best in Chrome" is hardly a self-inflicted wound. With the might of Google, that's actually a recipe for browser monopoly. This is the reason why Google pushed ahead with Dart despite the opposition.
- cromwellian 15y agoHow would your opinion change if Dart was just a cross-compiler to JS like GWT or CoffeeScript? And if you have no problem with that, then why is there a problem with a Dart VM in Chrome? All it means is that potentially, Chrome apps will startup faster or run a little faster. However, this is not really much difference than V8 vs other JS VMs. There was a time when V8 was way way faster than other JS VMs, so the same speed differential existed anyway. There's a difference between "doesn't run" and "runs, but faster"
- azakai 15y ago> If Google introduces something like Dart or NaCl, is willing to support standardization of it and even release a free implementation, but other browser vendors don't want to integrate it because they don't like it, that's their problem, not Google's. If that means popular apps become "Works best in Chrome," that is a self-inflicted wound. I completely disagree. First, if a technology is really bad for the web, are you saying other browsers should still implement it, just to not suffer the situation where popular apps work best in Chrome? That's bad enough as it is, but those popular apps are likely going to be Google properties - google.com, gmail. That means Google can basically force other browsers to adopt technologies as it sees fit, even if they are bad for the web. Second, the WebKit situation on mobile exactly shows why this is wrong. If one popular browser adds special features and leaves them there indefinitely, in release versions of the browser - as WebKit does with its special CSS properties, and like Chrome does with NaCl and perhaps soon Dart - then people will develop for those features. If that browser then becomes dominant, those features will become a de-facto standard. Given Chrome's incredibly rapid rise, we should not assume it will not become dominant on the desktop, so this should concern us all.
- tomjen3 15y agoYes they may be forced to develop these things and to include them (if by being forced to we mean they would otherwise not having enough users) but I don't see that the browsers should have any say in what is good or not for the web. Browsers should focus on making the best browsers possible.
- batista 15y agoI am a web developer and I very much want it. I don't want Javascript to be the only game in town for front end programming. But this is beside the point: Eich never asked if web developers want it or not.