Good! This will quiet the noise, so that everyone can focus on advancing Dart and its ecosystem. Let's be honest: getting the Dart VM into non-Google browsers was always destined to be far, far away if not impossible, regardless of the team's excellent work or Dart's merits. Getting it into Chrome is just a decision, but one fraught with perils, namely that our community has an arguably healthy aversion to go-it-alone on the web, and untamed fear amongst the hoards that Google will shove it down our throats does not bode well for Dart.
And is it really worth it? As someone all in w/ Dart (I chose to build my product with it), dart2js serves me well, and the resulting JS is said to be more performant than raw JS. JS itself is improving (see ECMAScript 6 and TypeScript), which means Chrome's compiled JS will improve with it. Of course, having the Dart VM in a version of Chromium they call Dartium has been important, as it eliminates the need to compile until I care to test on other browsers. But there's exciting work ongoing on incremental compilation, so that in theory you'd just see your results in any old browser (http://goo.gl/EHJcK9) a la interactive programming. Bottom line: the Dart development cycle is already great and always getting better, no VM in Chrome needed.
As well, the Dart team can focus on more important priorities: the incremental compilation I mentioned, better JS interop (it's not bad now), improvements like async/await (coming in 1.9), even better concurrency primitives (see Fletch), Dart for native apps (again see Fletch) and more.
And remember, this decision can change later when the climate changes or other factors are in play. But for now, it makes a whole lot of sense to abandon any push, or notion thereof, to get the Dart VM into Chrome.
IMHO, Dart (I mean the language, libraries and tools combined) is hugely underappreciated. Folks will continue to focus on improving it and building awesome apps with it, and this news should quiet some of the noise.
Also curious as to what you think is missing. In my experience, server side Dart is full featured and awesome. There are also the Shelf libraries (https://pub.dartlang.org/search?q=shelf) – in time I plan to refactor to use them.
I don't think anyone's banking on Dart unseating JS, and it doesn't need to. It compiles to JS to work across modern web browsers while smoothing a fair deal for you in the way of optimizations and cross-browser issues. But that's saying nothing of the real reason folks choose Dart, or JS or any transcompiler or framework for that matter: the ways in which it may benefit you and your projects, relative to your other choices.
In Dart's case relative to JS, I think the language is more sane, debugging easier, the core libraries really powerful, the tooling more uniform, and the ecosystem more organized. I like the idea of one language on client and server, and yet the way it's done in JS-land with Node feels wilder and less approachable than I liked when I researched it some years back. That's just me, and admittedly I don't have all that much experience in the world of JS before I dove into Dart.
There are some tradeoffs of course, the biggest being that you sort of block yourself off from a world of JS libraries and even community to some extent. There's dart:js interop to wrap any JS library, and work being done to make that even easier with js:interop, but I think there'll always be some disconnect. Still, it's about costs versus benefits, and there are many benefits that I think ultimately outweigh the costs.
The point is there are a whole host of reasons to choose Dart, and I think it's foolish for any one of those reasons to be because you think it'll unseat JS. It won't, but there might be merit to it unseating JS in your own workflow.
I was a user, still have it embedded on my wedding site (though dead): http://dovandrebe.com/. Hadn't followed what came of it/you. Thanks for sharing your journey!
More specifically, Dart on App Engine via Managed VMs. (Dart was already runnable on Compute Engine instances.)
App Engine is a subset of Cloud Platform services and is a platform-as-a-service (PaaS) offering – auto scaling, a scalable datastore, logging and other managed services and guarantees that aim to substantially reduce your DevOps.
By contrast, Compute Engine (and its closest competitor AWS) is more an infrastructure-as-a-service (IaaS) offering – provision your instances and run anything you'd like on it, as well as choose from available resources like load balancers and firewalls to meet your needs.
Managed VMs attempt to offer the best of both worlds: the managed scalability of App Engine with the choice and flexibility of Compute Engine. Through a Docker-based container approach, App Engine scalability guarantees are still kept while allowing you to run your own language, like Dart or Node.js, and services.
My Dart app, http://woven.co, has been running on Compute Engine, and I plan to move it to App Engine.
I evaluated Node, intrigued by the idea of event-driven, non-blocking client and server side code written in one language, but I found it to be a wild ecosystem with dozens of frameworks and not enough support and guidance for them.
I found Dart with its promise to bring some structure and sanity to that approach, including building a language from the ground up to do away with JS's quirks, and it has delivered. I built http://woven.co with Dart and Polymer.
The biggest pain is when you'd like to use a JS lib that isn't wrapped for Dart yet. They're hard at work to make it much easier to interoperate. They're a kick ass team, great docs, first class support in WebStorm, and its future seems bright. There are issues with Polymer like SEO that are inherent in any SPA really, but there are experiments with React-like Virtual DOM diffing and others too.
On the server, the dart:io is powerful and Shelf looks like an awesome set of abstractions for http servers and more that I hope to play with soon.
Dart is treated with heavy skepticism I think often unduly, but judge it for yourself and I think you might be pleasantly surprised.
I'm not sure how HN does it specifically. In a version of our app, we had scoring which was initially modeled after Reddit's algorithm (http://amix.dk/blog/post/19588). A server task updated the scores for every item every hour. We could have limited how far back we went, but had no need in our case given that the amount we indexed was within reason. We'd add or subtract from the score based on a set of rules that considered a number of factors including posted date, number of votes and number of comments. We had an admin tool for assigning more or less weight to the various factors.
Way before 1.0 existed (and using an early version of Polymer called WebUI) we built a first version of our app, e.g. http://woven.co/miamitech, which is a fairly complex client and server side application. (The slowness is due to our poor pgsql data design.) I'm now building a more focused version with the latest SDK and Polymer, the beginnings of which are at http://mycommunity.org. For me it's simple: Google is arguably the greatest champion of the open web and probably does more to advance modern web development than most anyone else. V8 was a game changer, and enabled Node. The same folks behind V8 are building, in essence, a better Node. Modern web development with JavaScript is exciting, and there are so many great libraries and resources out there, but there is also much to be desired such as more structure, a saner language and a strong suite of core libraries that play well together. In my experience, Dart is what they say it is: a more structured approach to modern web app development.
Sorry folks, I thought and still maintain that our situation was relevant to other startups and hackers. I thought we'd get some critical feedback, and we did. And yes, we wanted to tell our own story with respect to Dart since we had been expecting to do something like that for some time as part of Google's announcement. The post is removed and we're moving on.
Psyched! See our HN post about our Dart app (Dart rocks) and our team's disappointment with not being included in the 1.0 announcement. https://news.ycombinator.com/item?id=6735044
And is it really worth it? As someone all in w/ Dart (I chose to build my product with it), dart2js serves me well, and the resulting JS is said to be more performant than raw JS. JS itself is improving (see ECMAScript 6 and TypeScript), which means Chrome's compiled JS will improve with it. Of course, having the Dart VM in a version of Chromium they call Dartium has been important, as it eliminates the need to compile until I care to test on other browsers. But there's exciting work ongoing on incremental compilation, so that in theory you'd just see your results in any old browser (http://goo.gl/EHJcK9) a la interactive programming. Bottom line: the Dart development cycle is already great and always getting better, no VM in Chrome needed.
As well, the Dart team can focus on more important priorities: the incremental compilation I mentioned, better JS interop (it's not bad now), improvements like async/await (coming in 1.9), even better concurrency primitives (see Fletch), Dart for native apps (again see Fletch) and more.
And remember, this decision can change later when the climate changes or other factors are in play. But for now, it makes a whole lot of sense to abandon any push, or notion thereof, to get the Dart VM into Chrome.
IMHO, Dart (I mean the language, libraries and tools combined) is hugely underappreciated. Folks will continue to focus on improving it and building awesome apps with it, and this news should quiet some of the noise.