13 ms·
Never rely on Google for anything - always have alternatives. In the case of Dart, the alternative is that it is open source, which means if (read: when) Googl
by RyanZAG 13y ago
Never rely on Google for anything - always have alternatives. In the case of Dart, the alternative is that it is open source, which means if (read: when) Google drops Dart, other developers can continue to support it.
However, Dart is a 'full stack' solution. This means that any developer taking over Dart would have to support the IDE, the VM, the javascript transcoder, the language, integration with new browser features, cross browser compatibility, etc. This is practically impossible for hobbyists to do properly.
Why would Google drop Dart? Google is almost guaranteed to drop any project that does not have high traction and/or high income within a few years of release. Dart has neither income nor traction. If Google does not drop it, I will be very surprised and impressed.
I highly recommend avoiding Dart, but obviously the choice is yours. You've been warned.
EDIT: Just to add, Google can artificially increase traction of Dart by putting the Dart runtime inside Chrome and using that as a weapon to increase Chrome adoption, similar to Microsoft's ActiveX strategy. If Google does this it would be a pretty evil thing to do and go against the spirit of the web.
If your ethics are a bit lacking, you may want to try betting on this effect which would create a demand for Dart dev houses in the future, and could make you some cash.
- _greim_ 13y agoGoogle will drop Dart because they will inevitably realize what the rest of us already know: Dart won't displace JS, even a little, as the lingua franca of the web. Anybody with even half a brain can see this. It's an exercise in futility, like trying to build a whole new web browser and expecting it to dominate within five years' time. Including Internet Explorer. Worldwide. Such fantasies are ridiculous and a waste of everybody's time. Get back to the drudgery of your actual lives, folks.
- Peaker 13y agoYou must be a reasonable man. The world does change, even dramatically, sometimes. (Not that I believe Dart is interesting or useful enough to drive dramatic change, I find your approach overly pessimistic).
- danmaz74 13y agoDoes Google use Dart internally, like they do with Go? I would check about that to understand how serious they are about it.
- kyrra 13y agoI was talking a Dart guy about this recently. They have no projects they can talk about, but there are a few teams within Google using Dart right now. I'm guessing we'll hear about these eventually, but for now they are keeping them quiet.
- bradleyjg 13y agoGWT was used internally, by AdWords even. That didn't stop it from getting dropped on the floor when the new shiny came along.
- kyrra 13y agoGoogle still has a team of 10 people working on GWT (they have no developer advocate anymore, so no one really advertises it). GWT is considered "infrastructure" by Google now. AdSense/AdWords both use GWT I believe (and that won't be changing anytime soon, so Google will continue to support GWT. There are also other small tools from Google written in GWT (Flights, their jobs site, and others I'm sure). GWT doesn't have nearly the team it used to have, but its still being supported by Google. EDIT: to add, GWT has recently transitioned to a non-Google site[1], run by the GWT committee. As well, a GWT focused conference is being organized by Vaadin[2]. [1] http://www.gwtproject.org/ http://www.gwtproject.org/ [2] http://gwtcreate.com/ http://gwtcreate.com/
- bradleyjg 13y agoYes, I know they have people working on it. Among other things this work consists of closing 90% of existing bugs as assumed stale. I'm sure that if you have code that works today it will continue to work if you change nothing (although there is talk of dropping support for IE8) but there are a lot of rough edges that will now never be improved. That's not optimal for people who bought the story that google was selling to developers just two years ago at IO -- that this was the wave of the future and well worth devoting effort to learning and pitching to clients.
- RobAtticus 13y agoThis seems overly negative, and for rather simplistic reasons. If Dart is successful internally, I'm sure they'll keep working on it. Making their developers' lives easier, and making their web properties faster/better is easily worth it for them. Also, your edit doesn't strike me as evil. It's only evil if they prevent other vendors from putting in a Dart VM. The language is opensource, and so is Chromium where their VM implementation would be, so that seems unlikely. They'd have to put in quirks that make it "work best" on Chrome that they somehow hide from the competition. I mean, was SPDY an evil move? It was originally baked into Chrome but the spec and implementation were open. It just took Firefox and others longer to decide to add support.
- pcwalton 13y agoThe DOM memory model that all browsers use is incompatible with Dart (or any "second language" for the Web). That includes Chrome, by the way: that's why they need the Oilpan project which completely rewrites DOM memory management from scratch. In practice this is going to be a blocker for other engines to "just adopt" the Dart VM. (These concerns were raised, and ignored, on webkit-dev when Google first proposed Dart support.)
- magicalist 13y agoThis seems like a weirdly combative comment. This certainly isn't the primary technical (or emotional) argument against Dart. To translate for others: browsers tied the DOM memory model tightly to the single Javascript VM because it was a lot easier that way, and expanding support to multiple VMs will take a lot of work. This is one reason why you don't see many browser forks running with the "let's just add python to browsers" idea that so many have had. It's also why we still have no canvas or WebGL in web workers: no one has a DOM that sufficiently supports multi-threaded access. I have no idea what "ignored" means in this context, since Dart bindings obviously weren't added to webkit, and Oilpan is replacing the GC model for the DOM in blink. That might make it easier to support Dart (that's still only something I've read here on HN, but I don't follow Dart lists), but it's a performance improvement that has long been needed. Try tracing garbage collection in Chrome sometime in an app that manipulates the DOM; the typical pause will spend most of its time trying to collect memory on the DOM side, not the Javascript side, even for some of the simplest DOM manipulations. My understanding is that (somewhat humorously, in the context of the above) this is because of the more inefficient bindings created to allow V8 to work with Webkit, where it used to be that only JavaScriptCore bindings were needed.
- ericssmith 13y ago"Google can artificially increase traction of Dart by putting the Dart runtime inside Chrome and using that as a weapon to increase Chrome adoption" Chrome itself gained in traction because V8 was faster for a while. Putting Dart VM in Chrome and getting another competitive leap seems like a no-brainer. Not sure how that is evil or going against the spirit of the web. It's a one-liner to have it use the Javascript version, making it available in other browsers. It's not like ActiveX, as far as I can see. In practice, Dart is a decent enough compile-to-Javascript alternative with a low barrier to entry. And it works as advertised. Easy to learn, use, and debug. And the claims about structure are true. As far as I can tell, the lack of conviction is as much about seeing where developers are headed as anything. Why spend a lot if there won't be adoption. It's a tough call for Google in a pretty crowded and evolving space (ie, compiling to Javascript). I should add tha NaCl and LLVM complicate the vision of the future for web technologies as well. Hard to place a bet at the moment.
- kevingadd 13y agoGiven the presence of modern technology like Emscripten, it would be a 'one-liner' to load a compiled-to-JS equivalent of any native ActiveX plugin (assuming it does only things the browser can do; same goes for Dart - Dart2JS is not going to be able to implement SIMD or threads or anything else that the native Dart runtime adds). It's against the spirit of the web because: 1. Dart is controlled by a single player 2. Dart was implemented by a single player 3. Dart was designed for the needs of a single player 4. Dart was designed in secret before being released to the world Those four factors combined make it seem evil even if it's not, and definitely contributed to the negative reaction it got from WebKit. If using Dart means relying on Dart2JS (which it does, because Google completely failed to get any other browser vendors to consider adopting it so far), then Dart is now just another competitor to things like GWT, Emscripten, TypeScript, etc. Dart2JS at least delivers reasonable performance thus far but it's hardly a compelling option compared to actually writing the language that runs in the browser, especially given that it has an entirely new home-grown set of libraries that aren't mature yet. If Dart is still alive 5 years from now, however, a lot of these factors could change. If it manages to prove itself somehow, maybe a Dart VM would get into WebKit or Gecko (seems unlikely due to implementation hurdles though), and the libraries will absolutely be mature by then.
- lucisferre 13y ago> Just to add, Google can artificially increase traction of Dart by putting the Dart runtime inside Chrome and using that as a weapon to increase Chrome adoption, similar to Microsoft's ActiveX strategy. If Google does this it would be a pretty evil thing to do and go against the spirit of the web. This is entirely hyperbolic. ActiveX was an entirely closed source system including the browser it ran on. Not true for Dart or Chrome. In fact you can already get Dartium (http://www.dartlang.org/docs/dart-up-and-running/contents/ch04-tools-dartium.html http://www.dartlang.org/docs/dart-up-and-running/contents/ch...). These scenarios are not even remotely similar.
- kevingadd 13y agoSo far the response to the suggestion of adding a native Dart runtime to anything other than Chromium proper has been extremely negative. WebKit didn't want it, Mozilla doesn't seem to want it. Maybe Opera will include it since they're using Blink? It may not be a Microsoft feature but it's basically being treated the same as one. Native Client is getting similar treatment.
- spankalee 13y agoThe point is that Dart will run on all browsers. ActiveX only ran on IE. Dart's also friendly with the web. It has a full DOM API and JS-interop. It's not a plugin.
- kevingadd 13y agoDart2JS will run on all browsers. Dart currently will only run in Chrome. This is an important distinction.
- mythz 13y agoDart currently only runs in Dartium, There is no DartVM in Chrome which just runs the Dart2JS version live every other browser. Also I don't think it's clear whether or not Opera will include a DartVM by virtue of Blink.
- gwern 13y ago> Why would Google drop Dart? Google is almost guaranteed to drop any project that does not have high traction and/or high income within a few years of release. Dart has neither income nor traction. If Google does not drop it, I will be very surprised and impressed. Likewise. As it happens, my model's* 5-year survival prediction (=Dart being supported by Google in ~March 2018) is just 21%. I can't say I really disagree. * http://www.gwern.net/Google%20shutdowns http://www.gwern.net/Google%20shutdowns
- mythz 13y agoDart is a solution for building and maintaining complex web apps. Googles JS web apps has 100's of engineers working on it spanning millions LOC. Google doesn't think it's possible to develop at this scale with vanilla JS which is why they've invested a ton of effort in developing the Closure Compiler/Library and GWT (i.e. what their big JS Web Apps use). The problems with the previous strategies is that they add boilerplate, artefacts and complexity on top of JS that slows down their build times to the point where some devs have to wait 24mins to see a live/edit reload cycle. Dart was built from the ground-up to manage complexity and to provide a consistent development experience with the goal of providing the fastest edit/reload dev cycles possible. As it's also built with the input of the VM engineers who helped create StrongTalk, Hotspot JVM, V8 VMs they are able to add features that enable a high-performance VM implementation and enable features like 'Snapshots' to provide instant start up times. Google will never drop support for their 2 crown jewels, Chrome or Android. When Dart gets into Chrome and some of their big internet properties start to depend on it, you can pretty much guarantee that they'll never drop support for it. One of the mandates Google has is to improve the web, make it faster and make it possible for everyone to build richer more interactive web experiences so more people use and spend more time on the Internet. More time on the Internet means more time on Google, so developing and investing in technologies like Dart indirectly benefits them. It's also why any investments on improving the Internet remain supported, free and Open Source e.g WebP/M, SPDY, Chromium/Blink, V8, Closure Library, GWT, mod_pagespeed, Polymer and now Dart. People like to confuse Google's dropping of support for their products where everything they create is fair game and can be dropped at anytime, what's not looked at, is how the product to relates to their entire ecosystem, whether it adds value and is in a growing technology/market.
- spankalee 13y agoStandard disclaimer, I work on Dart. And normally I'd avoid engaging a borderline troll, but this is such a terrible comment, in so many ways, that I have to speak up. > Never rely on Google for anything First, you're expectation that Google will drop Dart is based on what exactly? A few SaaS product cancelations? The "never rely on Google" meme is getting so old, mainly because it's overly applied to Google when all SaaS providers have this issue, and it's been a known downside for years: when product support ends for an installed app, you still have the old installed app to use, when support is ended for SaaS users have a problem. I hope this can be mitigated one day, but that's a whole other topic. The differences with Google is that we have a ton of users even for our "small" products, and there's a single name to attach attention to, rather than the numerous shutdowns that have happened in other companies, or the startups that have bee bought and killed. The important bit for the discussion at hand is that Dart is not even _anything_ as a service. It's a set of installed, open source compilers and libraries. They will continue to work in the (unlikely, IMO) event that Google drops support. > This means that any developer taking over Dart would have to support the IDE, the VM, the javascript transcoder, the language, integration with new browser features, cross browser compatibility, etc. Dart's more of a collection of independent pieces. If Google ever did completely drop Dart I'm pretty sure that the parts could be maintained by the community (assuming the community hits critical mass). The dart2js compiler is the most important part and it's well structured, easy to understand code. The IDE could be abandoned in favor of plugins for WebStorm (already maintained by IDEA), Sublime, vim, etc. > Dart has neither income nor traction. Dart will never have income, that's not its purpose. Dart's purpose is to make web development easier, more productive and more scalable, and web apps themselves faster. This goal is both for internal development, for which we badly need something like Dart, and for everyone else because we want to see more and better web apps. As for traction, if Dart doesn't get any traction (after it's actually released, and had a good chance to succeed of course!), inside Google or outside, then it probably _should_ be abandoned, right? In that case, who exactly is there to care that it's not developed anymore? I've heard some people point to GWT as an example of what might happen to Dart. I don't agree, but for the sake of argument, let's look at where GWT is: 1) There's an official community maintaining GWT, 2) Google still has a team working on GWT, and large projects using it. 3) GWT will still get better as Java gets better. There are other factors that apply to GWT and it's language that don't apply to Dart. If Dart's fate was ever the same as GWT, I'd say it'd be a pretty soft landing for everyone. > Just to add, Google can artificially increase traction of Dart by putting the Dart runtime inside Chrome and using that as a weapon to increase Chrome adoption, similar to Microsoft's ActiveX strategy. This is still a ridiculous comparison. ActiveX was a plug-in architecture. Dart compiles to JavaScript. We support all "modern" browsers, IE9 and up. Look, we've made no bones about wanting to get the VM into browsers some day. And obviously, being part of the Chrome team, we'd like to see it in Chrome. Lars pointed out at Google I/O that there's work already being done to pave the way for this on the memory management side. The Dart VM does enable faster and quicker to startup applications, no doubt. But we all understand that Dart will be distributed as JavaScript for the foreseeable future, and we do considerable work to ensure that programs behave the same in dart2js and the VM, and that the JS output is very fast. The Dart and Chrome teams firmly believe that the adoption of Dart will entirely depend on it's success as a compile-to-JS language. How Dart helps developers will be its main draw, and hopefully there's organic demand for the VM as an accelerator for apps that already work well across the web. This will not be "evil" in anyway, but one of many ways that the browser vendors have pushed the web forward. There are so many examples of a vendor pushing something that's initially totally or somewhat proprietary but end up being a great thing for the web, that only comparing Dart to ActiveX is just juvenile and annoying. Consider JavaScript itself, XHR, <canvas>, CSS, SVG, WebGL, setImmediate() and so many other DOM APIs, CSS extensions like rounded corners, shadows, transforms, etc. Some of these have actually been much more backwards-incompatible than Dart which primarily _compiles_to_JS_. The FUD around Dart is just incredible. No matter though. We see the benefit every day that we luckily get to code in Dart, and so does our community. Those who wish to reap the benefits Dart can opt-in and those who don't can ignore it.
- jrockway 13y agoEDIT: Just to add, Google can artificially increase traction of Dart by putting the Dart runtime inside Chrome and using that as a weapon to increase Chrome adoption, similar to Microsoft's ActiveX strategy. If Google does this it would be a pretty evil thing to do and go against the spirit of the web. Couldn't Microsoft put Dart in IE today? This argument boils down to: "nobody should ever work on any programming language, because any company could add support for it to a web browser." It's technically true.
- coldtea 13y ago>Never rely on Google for anything - always have alternatives. In the case of Dart, the alternative is that it is open source, which means if (read: when) Google drops Dart, other developers can continue to support it. Well, if we're being pragmatic and cautious ("never rely on Google for anything"), then expecting Dart to get support post Google because "it's open source" is an even more dangerous idea. For one, all of Dart's core developers are Google employees. If Google kills it, I seriously doubt others will take their place. We have many precedents of abandoned open source projects where the community consistent 90% of some companies paid employees. And it's not like Dart has gained any traction from programers using it to get stuff done either.