We are Switching to Dart

http://www.ramen.io/post/46936028144/we-are-switching-to-dart-why

by MartinMond • 13 years ago

105 94 13 years ago

tosh8• 13 years ago

BTW this is not an April fools joke :)

MartinMond2• 13 years ago

I hope Google gets (even more) serious with Dart. Web App Development with JavaScript is a joke. Just remember the recent callbacks vs promise debate. It's like JS devs know nothing about software engineering.

leeoniya• 13 years ago

debate?

MartinMond2• 13 years ago

I'm talking about https://news.ycombinator.com/item?id=5466872

_jmar7777• 13 years ago

Where to start, where to start...

arkitaip• 13 years ago

It seems very risky to base your core business on a language that's only been around for two years. Sometimes web development seems to be more volatile than the fashion industry.

lmm• 13 years ago

With the state of javascript at the moment you would certainly be using library code that's less than two years old to build core parts of your app. The line between language and library can get pretty blurry, particularly when we're talking about a language that compiles to JS.

rictic• 13 years ago

To be fair, there's a difference between a library and a language here. Replacing or taking on the maintenance for a library is a much more feasible option for many than jumping to a new language or taking on the maintenance for an entire language (as it's not just the compiler, it's also custom tooling, debugging, plus Dart really needs its own libraries, etc.)

at-fates-hands• 13 years ago

I thought the same thing and wondered if they have a backup plan if/when Google suddenly decides to stop supporting it.

pjmlp• 13 years ago

Quite true.

Every time I see such posts here, I think what is the business value of such changes.

desireco422• 13 years ago

This sure sounds like April 1 joke, but, I get that developer(s) wanted something even more innovative then brunch and coffeescript. Like arkitaip said, it is a very risky move.

michaelwww15• 13 years ago

Riskier than using the latest perpetual beta JavaScript library? I don't think so.

desireco422• 13 years ago

Which one ?! JQuery? What are you angry about?

peroo• 13 years ago

Why does so many startups feel the need to brag about the fact that they're switching to <hot new technology>? To me it just comes off as an attempt to convince themselves it's a great idea.

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.

dantheman• 13 years ago

I think it does at least 3 things well:

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.

tosh8• 13 years ago

Thanks a lot for your comment.

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 :)

michaelwww15• 13 years ago

The idea that this is fashion statement is laughable because Dart has been quite unfashionable until recently (like 2 weeks ago.)

trimbo2• 13 years ago

Assuming this is not April 1 con'd.

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.

michaelwww15• 13 years ago

I don't know if Google does not use it for their own stuff and you don't supply references. That's not the same as saying Google will not use it for their own stuff. That would be quite surprising. In fact, I'm assuming they are developing it primarily as an internal tool, hence the disregard for a reasonable time line for shipment of 1.0

munificent7• 13 years ago

> I'm assuming they are developing it primarily as an internal tool

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.

trimbo2• 13 years ago

I have no information except what Google says publicly. In the absence of any information about whether Google is using it, I have to assume they are not when making a decision on that basis.

kyrra2• 13 years ago

The Dart team has said that internal teams are already using Dart, but nothing they are allowed to talk about publicly yet. I'd imagine as part of the 1.0 launch they will start talking about it.

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.

MatthewPhillips5• 13 years ago

The title is inaccurate, they weren't using JavaScript before, they were using CoffeeScript.

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.

michaelwww15• 13 years ago

CoffeeScript is JavaScript with syntactic sugar so the title is accurate.

MatthewPhillips5• 13 years ago

But the title makes it sound like they are changing languages when what the post is actually about is switching ecosystems.

mraleph3• 13 years ago

[disclaimer: I work on Dart VM]

Even though Dart VM is not a deployment target for the client side code right now it is still an integral part of the development experience. It runs all your code while you develop (no need to compile to JavaScript just edit&refresh) and backs things like dart2js, dwc, pub which are all written in Dart itself.

MatthewPhillips5• 13 years ago

Right, but the author here doesn't mention the Dart VM as a reason for the switch; they are not switching to get better performance in Chrome. They are switching because they like the language/ecosystem better.

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.

coldtea• 13 years ago

Guys, if you can get somebody to write a decent (say, Flask level) server side Dart framework, Dart could gain a lot of ground there.

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.

ahoge2• 13 years ago

> ClojureScript [...] provides all of the same benefits.

That doesn't seem to be the case. Dart provides great tooling and you can also step-debug your code from within the IDE. The workflow with Dartium (Chromium with embedded Dart VM) is pretty neat. The performance of the generated JavaScript is pretty good, too. There are also Dart Web Components which give you custom tags (with shadow DOM) and two-way data-binding.

Finally, Dart, with its "boring" C-like syntax, is familiar to pretty much anyone.

MatthewPhillips5• 13 years ago

Sure, but those aren't the arguments the post made. The post focused primarily on the ecosystem and package management aspects, which Clojure/script certainly has.

tosh8• 13 years ago

I only mention the virtual machine very briefly in a list of things that come with Dart (batteries included rock) as I didn't want to loose/confuse the reader since there are no browsers that come with a Dart VM yet (except Dartium which is awesome for development).

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.

michaelwww15• 13 years ago

I think a few points are worth emphasizing. Dart produces JavaScript that is closer to being correct https://news.ycombinator.com/item?id=5424680

Dart can produce JavaScript that is faster http://news.dartlang.org/2013/03/why-dart2js-produces-faster...

The JavaScript output of Dart2js works across all modern browsers (IE9 and above, among others.) No browser hacks required.

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.)

trungonnews• 13 years ago

IE9+. I hope people don't miss this keyword.

michaelwww15• 13 years ago

That satisfies all mobile development as far as I know. The loss is on Windows XP desktop for those stuck on IE8 and below. So far, I'm doing ok telling people to run Chrome or FireFox on XP as most of them are anyway.

tosh8• 13 years ago

To give some perspective: we were lucky to have less than 2% of traffic coming from IE, most of those visits via IE9+. This made the decision to switch easy in terms for browser support in our case.

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.

_jmar7777• 13 years ago

If your browser requirements are IE9+, then there's little need for things like underscore (and, arguably, even jQuery) since you can count on x-browser support for things like document.querySelectorAll() and other niceties that jQuery typically levels the playing field for.

For example, why would there have been confusing over _.each vs. $.each when you have perfectly consistent native support for [].forEach? Nothing against Dart... it's cool and all, but I'm not sure the JavaScript "fragmentation" rationale is all that strong when you have the luxury of only dealing with such modern implementations.

michaelwww15• 13 years ago

My understanding is that people continue to use jQuery because it makes DOM manipulation that much easier. The Dart authors kept this in mind and said jokingly on http://www.dartlang.org/articles/improving-the-dom/ One area where the DOM has a bunch of baggage is finding elements. Today’s DOM has a pile of methods for finding stuff. All of this piled up before jQuery appeared on a mountaintop to give us the revelation that Thou Shalt Find Nodes By Using CSS Selectors. With the One True Way in hand, we’ve stripped it down to just two (!) methods: query() and queryAll().

melling• 13 years ago

I think the language is done. After listening to this FLOSS episode, I think they're just finishing off the libraries.

http://blog.sethladd.com/2013/03/dart-on-floss-weekly-from-t...

Sounds like 1.0 might be a Google I/O announcement.

munificent7• 13 years ago

There's still a small amount of language evolution going on. We recently added mixins, for example, and there's a couple of minor things still being batted around.

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.

apunic• 13 years ago

I like your post since it's a refreshing take on today's language and framework decisions. Usually people go for Coffee, Node, Go, Clojure or ClojureScript nowadays (I mixed FE and BE tech deliberately).

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?

ahoge2• 13 years ago

You could write the back-end in Dart, too. The Dart VM can do IO out-of-the-box. Just like the Node executable, it can be used to run command line scripts, web servers, or anything else you can think of.

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.

vor_• 13 years ago

I would be too afraid to base a business on a language that's only two years old. It's not even a guarantee that the language will remain supported by Google in the long term, given their periodic house-cleaning.

tjholowaychuk4• 13 years ago

Why go through so much pain to avoid JavaScript, coffeescript now Dart? JavaScript is not the problem, it's how terrible our community is at sharing/creating modular things. Classes and shitty syntax wont help you there

munificent7• 13 years ago

> JavaScript is not the problem, it's how terrible our community is at sharing/creating modular things. Classes and shitty syntax wont help you there

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.

tjholowaychuk4• 13 years ago

Not really just stop using/promoting bad design like jQuery plugins, eventually people catch on.

michaelwww15• 13 years ago

I think you're wrong. JavaScript has a great community with tons of talent. JavaScript is the problem. You don't see nearly the same level of problems in the Python community for example.

_jmar7777• 13 years ago

The problem here is browsers, not JavaScript. Python has evolved much since the '90s, just like JavaScript has. The problem unique to JavaScript is browsers, and end users running browser versions with a decade span in between them. This is also why the "IE9+" requirement is so relevant to this conversation, because developing with that luxury is entirely different than developing for IE7+ (or, for some poor souls still out there, IE6+).

oinksoft2• 13 years ago

You touch on a good point, but I'm not sure it has to do with this particular piece. Rather, the author seems really confused:

  There are great projects like Underscore, Sugar,
  Prototype, jQuery, CoffeeScript and many many more that
  help to work around JavaScript’s language quirks.
  Unfortunately they don’t mix and match very well. Also,
  which map() or forEach() implementation should I use if I
  have multiple available?

That's like comparing barricuda, rubberbands, and bolts. Only one of the projects he mentions has anything to do with "JavaScript’s language quirks," and that's CoffeeScript. Just another person who did not know JavaScript/frontend development, expected it to be like any other programming environment, and bailed rather than stepping back and reconsidering his original assumptions.

tosh8• 13 years ago

I understand what you're saying but I'm humbly disagreeing.

I do believe that all the mentioned frameworks (while positioned differently) do offer solutions to work with/around JavaScript language quirks. e.g. simple things like

    * working with collections
    * working with objects
    * extending 'things'
    * iterating over 'things'
    * working with async

That's one of the main things that I (and probably more) people find confusing about the JavaScript ecosystem even while I'm not new to it.

tosh8• 13 years ago

Hey TJ, thanks for your work on component.io, Stylus (we use Stylus) and in the node community. I applaud every effort to improve the JavaScript ecosystem.

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).

basch4• 13 years ago

Isn't that the point of http://requirejs.org/ and the AMD API - http://requirejs.org/docs/whyamd.html ? Why is there not more of a push for frameworks and libraries to be AMD compatible? The Dojo Toolkit is, and thus lets you load just what you need.

munificent7• 13 years ago

Don't forget npm, and bower, and jam, and component, and ender, and volo, and...

Really, it's only a matter of time before someone creates a JavaScript package manager manager so you can manage your package managers.

SeanDav• 13 years ago

How well does Dart work with node.js? Should I even consider Dart if using node.js?

michaelwww15• 13 years ago

It works transparently on the client to a node server of course. I haven't seen a lot of examples Dart interop with Node on the server. There are two choices, Use the Dart VM on the server and interop with Node through the js-interop lib, or use Dart2Js to convert Dart to JavaScript and operate with the node packages that way. There's still a lot of uncharted territory with Dart, which I think provides me with a lot of interest and opportunity.

Daegalus2• 13 years ago

I think if you are using it in the server-side to just use the DartVM. its the direct analogy to Node.js. It runs server code and everything else. and I am not sure why you would even try to run it on Node.js except for some library that you really need.

DartVM seems to outperform V8 anyway from the benchmarks on the Dart site.

33a• 13 years ago

April fools?

tosh8• 13 years ago

It's not, we're serious about Dart :)

basch4• 13 years ago

Why Dart over http://meteor.com/ https://github.com/yahoo/mojito or http://derbyjs.com/ ?

michaelwww15• 13 years ago

My April fools joke should have been that I've modified the CoffeeScript transpiler to emit Dart code - CoffeeDart!

stephanos2k• 13 years ago

Interesting post! I'm wondering:

1. How do you test your Dart code?

2. How do you integrate Dart with your existing Javascript?

3. Do you use Dart Web UI?

sethladd• 13 years ago

[disclaimer: I work on the Dart team]

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!

tosh8• 13 years ago

Great questions. Seth already hinted on some answers but I'll try to go more into detail.

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/

2.) We use js interop http://www.dartlang.org/articles/js-dart-interop/ to communicate between Dart and JavaScript.

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 :)

eliben2• 13 years ago

This makes sense. Every time I side-peek at JS, I get terrified by the huge amount of libraries that one is supposed to be used to just get it running. It must be a liberating feeling to be able to just use one language with one standard library, for all your stuff. The "batteries included" philosophy worked well for Python.

michaelwww15• 13 years ago

I wonder if we could go so far as to say Dart is to JavaScript what Python is to PHP? My whole reason for using Dart on a project was out of desperation because I was handed a JavaScript/PHP mess and I didn't want the nightmares to start again. I've been sleeping really well lately. Since Guido von Rossum did a stint at Google, all they need him to do is ask him to bless Dart and we're good, or find a suitable rock star replacement to promote "The Dart Way" ;-)

xiaoma• 13 years ago

Many libraries, including Underscore, default to the native browser methods when they're available. It's not really much of an issue deciding which map() to use.

TeeWEE• 13 years ago

While I think dart is a nice language, I do not think JavaScript is bad enough to justify switching to a completely different language.

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. http://en.wikipedia.org/wiki/Composition_over_inheritance

Dart has a big focus on OOS and looks a lot like "JavaScript for Java Programmers". Which is not a bad thing.

smrtinsert• 13 years ago

5k large? 10k large? 500k large?

the real test of a language is when it has all the millions of bug fixes built in over the years. At that point, do you feel comfortable refactoring/rearchitecting it to remove development inefficiencies? I argue that with Javascript there is no way you do once it grows beyond a small team size.

We are Switching to Dart

Related Stories