Google's Dart Becomes ECMA's Dart 190
mikejuk writes "Google's Dart just reached version 1.0, but now it seems that it has aspirations to being an international standard. The question is will this make any difference to the language's future? Given that Google effectively owns Dart, what advantage does standardization bring? The answer to what Google thinks it brings is indicated in the Chromium blog: 'The new standardization process is an important step towards a future where Dart runs natively in web browsers.' and this seems reasonable. A standard is something that would be required before other browser makers decided to fall in line and support native Dart. It is probably a necessary but far from sufficient condition, however, with Microsoft, Apple and Mozilla having other interests to further. Last but not least, having the backing of a standard might just encourage possible users to believe that the language won't sink if Google gets distracted with other projects and decides that Dart is dispensable. However, a strong open source development community capable of supporting Dart without Google's input would be a better reassurance. If you want to help, Google would like you to join the committee. After all, it still doesn't have a Vice Chair. So can we expect to see ECMA CoffeeScript or TypeScript in the near future? Probably not."
Does it replace the DOM? (Score:3, Interesting)
People keep coming up with alternatives to javascript. Everything from whole languages that compile down to javascript, to building new languages into the browser, to javascript supersets, to plugins that makes your browser run compiled code. Not a single one of these caught on. The REAL problem is the DOM, the CSS and how they interact with each other. Javascript is a bad language, but it's not awful. What makes web development awful is the DOM and CSS with all its crazy and cross-browser incompatibilities. Why no one tries to replace THAT? I'm almost implementing myself a new api that runs on top of a 100% width/height canvas tag for christ sake.
I'm not familiar with the Qt but QML ( http://en.wikipedia.org/wiki/QML [wikipedia.org] ) looks pretty good to me. Why can't browsers just implement that? Oh right, because it was not developed by google/m$/apple/mozilla so they can't guide it to the directions they want. Noooo, you have to have a completely new language that no one knows.
If they want to replace javascript so much why don't they just take the python or ruby runtime, bundle it to the browser, sandbox it and add DOM mappings?
Re:Not to rain anybody's party, but.... (Score:5, Interesting)
Every one of your points is partially correct, but just wrong enough to make it misleading, and the combined effect is very misleading.
They created their own replacement for NPAPI plugins, and got Adobe to prefer it over NPAPI. Now they're not going to support NPAPI anymore in a year. As a result, Linux Flash is now only going to work on their browser, and it hasn't really improved the situation in Chrome enough to justify the switch.
Google's PPAPI fixes numerous problems with NPAPI, particularly around security, because NPAPI plugins run in the same process as the browser making them a perfect vector for compromising the security of the browser, and indeed many of the major NPAPI plugins are so riddled with security problems that Google blacklisted them some time ago. And it is those same security concerns that are driving Google's decision to deprecate NPAPI completely. This is a good thing and it will make the web safer. In addition, NPAPI standardizes the API and should make it possible for a single plugin to work with multiple browsers. The end result will be not only safer for users, but should actually encourage the creation of plugins, since they'll be more widely usable.
With respect to Flash, Google didn't twist Adobe's arm. Adobe made its decisions for its own reasons; most likely because PPAPI is so much better to work with.
They didn't like other people's image formats, so they invented WebP, and got a lot of nickel-and-diming image hosters to start pressuring other browser vendors to support the format as if it's a proven tech... even though it's a "standard" that has shifted so much it's turned into such a kitchen sink of a format that everyone will basically have to use their implementation.
Again "didn't like" is misleading. The available image formats had serious deficiencies. Only GIF supported multi-frame animations, but did it in about the most inefficient way possible (storing each full frame, and compressing them individually with run-length encoding). JPEG works great for still images, but is far less efficient at compression than modern approaches, and also doesn't support layering, animations or transparency, and is limited to 24-bit color. JPEG2000 provided much more efficient compression, but lacked most everything else. PNG was pretty good at lossless stuff, but nothing else.
And once again, Google didn't twist anyone's arms. It created a better image format, started supporting and using it, and then put it through the standardization process. Your implication that it's somehow "unproved tech" is rather laughable. It's not like there's any new technology there at all, just a better repackaging of what we already knew. And it's not a "kitchen" sink format at all. It supports both lossy and lossless modes, with variable bit depths and includes animation (because it's actually based on VP8, a video format, this was very easy). It's very flexible which means it's somewhat complex, but it's actually simpler than the raft of standards it's positioned to replace.
They decided that Media Source Extensions were good enough that they could flip the switch on Youtube before other browsers were ready for it, thus rendering Firefox unable to play hi-def videos in HTML5 on Youtube.. though it was completely unnecessary to do so.
I don't actually know anything about that situation. However, I suspect that your description is no more accurate than the others.
They didn't like how long it was taking to make HTML2 so they invented SPDY. They then enabled it on the products that they popularized by using other people's standards, like Google Documents, thus forcing other browser vendors to support it or feel comparitively sluggish, even though HTML2 was coming along at the time anyway.
And that's just the tip of the iceberg.
In late 2012 the IETF HTTP committee solicited proposals from the industry, in competition
Re:OK, I'll bite (Score:3, Interesting)
Javascript is a fine language. Javascript mostly gets a bad rap from the in browser DOM API (or lack of (thanks web standard politics)); and the fact that developer's only really learn VERY basic Javascript and spend all of their time manipulating the shitty browser DOM. I mean no one would like python, C, Java, etc if all you ever did with it was basic XML manipulation.
Go checkout Nodejs or some other non-browser implementation of Javascript. It's a really remarkable language.
P.S. saying it's the way it handles object generation is not sane is very wrong; in a fully interpreted language doing the object generation from a prototype allows flexability that traditional class definitions just won't allow, and is really the only sane way you can do it. And you can do things that blow Java/C++ developers' minds.