Having said that, I wish they would stop working on advancing Dart and ship a 1.0 version. It's been 1.5 years since it was announced. Make the advancements in the 1.1 or 2.0 and give the tool developers a solid target to optimize for in 1.0. Let us not have to sell clients on a beta development system, even though that's what I'm doing and it's working, despite some panic when Dart developers break things with breaking changes (which is often.)
Looking at Dart's API, I don't see anything like it; queryAll() returns a List<Element>. In order to act on a collection of elements, you have to use iteration mechanisms such as for loops.
The whole concept behind jQuery's $() is that it's a DSL.
Historically, the hardest part of interacting with the DOM has been the inconsistencies (and missing functionality) amongst ancient browser versions. We've had standardized methods for a long time now that make DOM interactions relatively trivial if you have the luxury of working with browsers that support them.
Even newer browsers have a surprising amount of DOM inconsistencies, especially for newer HTML5 APIs that are still evolving. While this is an ongoing job, the Dart DOM API tries hard to polyfill that so that you get a single API that works across most browsers.
Sounds like 1.0 might be a Google I/O announcement.
However, we are making very few breaking language changes right now. Most of the fast-paced evolution is in the core library. Unfortunately, the corelib was essentially stagnant for close to a year, so now that people are working on it, they are feverishly playing catch-up to get it to a good place before 1.0.
YMMV of course but it definitely makes sense to look into your target audience. For some people Firefox 3 and IE6 might still be user bases that are worth supporting, we are glad to have a product for web and mobile developers :)
I wouldn't be surprised if this decision also makes sense for a lot of other target audiences, especially when you consider that you are in it for the long term.
Dart is really cool. Awesome, in fact. I want this project to do well.
But there's just no way I am going to base my business on it when not even Google uses it for their own stuff. It's just way too early.
A lot of people like to say GWT is dead, but Google AdWords still uses it. And as a users of GWT still, their dev team actually seems to be more on-top of putting out new developer plugins (for each Firefox update). Sure releases of GWT have slowed down, but it is still being maintained and used within Google.
It's neither primarily internal nor external. My understanding is that the higher-ups feel Dart must succeed both inside and outside of Google to be successful. Which one must happen first is an open question, but I think the end goal is wide use both inside and outside the company.
Yes, I think everyone understands today that languages don't directly generate revenue.
> They probably have a compelling internal reason for doing this.
Off the top of my head:
* If Dart succeeds externally, that's more third-party code that Google can then use for its own projects, so that directly saves us money.
* If Dart makes other web developers more productive, that makes the web bigger. A bigger web means more people spending time on it and more people doing web searches, which ultimately goes right back to Google. Google is happy when the web gets bigger.
* Autocompletion (intellisense)
* Quick turn around time in the "change code, set breakpoint, run code, stop at break point" cycle.
* Calling native JS code is painless. Libraries that are currently not available as Dart, such as three.js can still be used.
* Project organization is fairly automatic.
* Code analyzer - this one is my favorite. The analyzer will tell me if my change causes a problem in another file. It runs in the background, like C# does.
Seems that the story is they are moving towards a more opinionated language/framework. That it is Dart isn't the story here; they don't even mention the Dart VM as a benefit for the switch. It just as easily could be ClojureScript, which provides all of the same benefits.
As mraleph already mentioned the Dart VM is very useful for the instant-feedback development experience that you get from working with Dart.
It would be awesome to see it in Chrome or other platforms going forward but having it from the start is a big plus for day to day development and for the people building infrastructure on top of Dart.
There are also people who do exciting stuff with the VM in node-like scenarios.
I personally can't comment on that because we haven't looked into that use-case yet (our backend is in Python and App Engine does not support Dart yet) I'm very interested in the VM and I guess we'll see some interesting things in this area going forward.
Server side is were people are looking for nicer solutions that what's available, even moving away from RoR towards more one-page-app friendly stacks.
It's also an area were IE compatibility doesn't matter (because we're server side), whereas raw speed, good tooling, type checks and such matter a lot, so it plays to Dart's strengths, especially if it could provide both a freaking fast raw server performance (the way V8 is already 10x faster to PHP and Python) AND a good async story with futures, that for Node.js are bolted-on.
Inspiration comes from Express for Node, but it is similar to what you can achieve with flask.
Give it a look, and file feature/bug requests if you want to see something or something breaks.
I know of 1 person that implemented a Google Oauth endpoint with it, so it does work well.
Also, IANAL but I'm pretty sure you don't have to include a disclaimer to post on the internet. No one is going to rush out and buy Google stock based on your comments so there is no conflict of interest to what you wrote.
[regarding the disclaimer: I add it for two reasons. First, I have seen people accusing others of hiding their bias, so I prefer to state my affiliation explicitly. Second, if anybody wants to ask any Dart VM related questions and get response they know where to ask :-)]
Now, if we are talking about the DartVM, asm.js could be used as an argument not to include the DartVM in other browsers. But asm.js is still very much in it's infancy, so we really need to wait and see how it's adopted and how it progresses.
It would be very interesting to see a benchmark of emscripten/SomethingMonkey/asm.js vs emscripten/DartVM.
(Could also add emscripten/dart2js/V8 for giggles)
> That it is Dart isn't the story here; they don't even mention the Dart VM as a benefit for the switch.
Which I think is equating Dart with the VM? Then you say:
> They are switching because they like the language/ecosystem better.
That sounds to me like Dart is the story then. The language/ecosystem is Dart, isn't it? Can that be separated somehow?
Finally, Dart, with its "boring" C-like syntax, is familiar to pretty much anyone.
How about coming back in a year and telling us how it turned out instead? Actual case-studies and analysis are interesting, fashion statements are not.
1. It lets developers familiar/interested in the tech to know that you use it and that they should apply there.
2. You've done the work to research it and make the decision to switch - it doesn't hurt share that. Who knows someone may point out some flaws you didn't expect.
3. It increases the inertia of the technology. There are strong network effects in technology and if everyone sees that something is growing they'll make the jump too. One new library created per X developers is a big win and makes it better.
We'll definitely keep you posted on our journey with Dart. I don't have specific announcements yet but we're looking forward to share code examples and open source a few web components going forward.
So far Dart really has been a pleasure to work with and we'll definitely blog more about it in the future and hopefully also go a bit more into detail.
The main motivation behind this blog post came from people asking us about how it was to work with Dart and why we chose to adopt it.
I can see how this might come across as a fashion statement but I just wanted to share my thoughts and have a url to point people to :)
Every time I see such posts here, I think what is the business value of such changes.
There are great projects like Underscore, Sugar,
Prototype, jQuery, CoffeeScript and many many more that
Unfortunately they don’t mix and match very well. Also,
which map() or forEach() implementation should I use if I
have multiple available?
* working with collections
* working with objects
* extending 'things'
* iterating over 'things'
* working with async
Are you perhaps thinking of the baroque and once-very-inconsistently-implemented DOM API?
Regarding your other points, JS is an extremely object-oriented language. I really don't think you need more "working with obejcts" things out-of-the-box. Iteration is very straightforward in all cases, unless you find hasOwnProperty confusing. The Node.js project has demonstrated well how easily Async maps to JS outside of the browser model (where Async has always reigned).
JS is a strange beast in certain ways, but it is a featureful language.
It's the same for iteration, the hasOwnProperty is mostly omitted because it works most of the time without it and specifying it adds un-necessary boiler plate.
Same with async, there's a zillion async libraries that try to manage async in different ways and they aren't interchangable either. By standardizing on Futures/Streams it means all libraries can build on consistent and composable foundations and build higher-level functionality.
How would you switch communities without switching languages? As far as I can tell, it's actually much easier to switch tech than it is to convince a million existing users to change their culture to something different.
I feel that Dart having a solid foundation make it hard to bike-shed over simple things that just should work out of the box. This is where I see Dart helps, where CoffeeScript didn't (because it was not its design goal).
Scroll down to the "Module Loaders" section at http://todomvc.com/ I don't see any of the products listed you mentioned.
Notice that require.js works with Backbone.js, Ember.js, Knockout, AngularJS, Ember.js, Knockout, AngularJS, CanJS.
TroopJS uses require.js. The only major competition it has is Thorax + Lumbar or Twitter's Flight.
jQuery 1.7, Dojo 1.7, EmbedJS, Ender-associated modules like bonzo, qwery, bean and domready, Firebug 1.8+, and the BBC all use it or work with it.
What I am interested in: Why did you go for Dart? What was the trigger? When I look at Google Trends Dart seems to have a very hard time compared to other current technologies regarding search popularity.
And what's your backend based on? Could I go for Dart with Node?
Anyhow, since the front-end only communicates with the back-end via standardized protocols (say, HTTP or WebSockets), it doesn't matter what's used on the server-side. These two parts are completely decoupled.
I worked on some big js projects, and together with a good module-system and jslint with strictmode on it works out all quite well.
I think OOP is nice but you can do without much of it by focussing on composition instead of inheritance.
Which is not a bad thing.
1. How do you test your Dart code?
3. Do you use Dart Web UI?
1) We have unit tests and mocks built-in. Check out https://www.dartlang.org/articles/dart-unit-tests/
2) We have JS-interop. Check out http://www.dartlang.org/articles/js-dart-interop/
3) We have tutorials for Web UI. Check out http://www.dartlang.org/docs/tutorials/
Hope that helps!
1.) We have an acceptance test suite for the existing app (pre-Dart) using web driver and written in Python). This is currently quite useful since we can continue to use the same test suite when we've migrated a certain widget to Dart.
Additionally to that we use the testing infrastructure that comes with dart: https://www.dartlang.org/articles/dart-unit-tests/
For the migration we are rewriting widget by widget (Backbone view by view). That's fairly straight forward since our existing Backbone.js codebase already was structured in a way where widgets are encapsulating behaviour, dom and style.
3.) Yes we do use Web UI. It's awesome. A bit like Angular.js but on top of a solid language foundation. We'll also look into open sourcing some of our web components going forward :)
DartVM seems to outperform V8 anyway from the benchmarks on the Dart site.
edit: ok I forgot http://www.socketstream.org/ but regardless, the realtime single page app sector really is dominated by those four products. everything else is already obsolete.