sethladd

Thanks for the helpful feedback! The latest version of Polymer.dart removes the need for reflection at compile time, and our output is much smaller today. Curious when you last tried compiling a Polymer Dart app?

[disclaimer: I work for the Dart team.]

Also a good idea! Gah, I need more time.

The original developer is really good. Also, the original app is small-ish, so I really wouldn't expect too many (or any) bugs in the original app.

Hm, the blog has G+ comments on it. Apologies if that's not working. You can leave comments here, too :)

This makes me curious... what's the adoption of module loader, bower, etc, today for new small-ish apps. That is, what is the archetype JS project look like? Is there such a thing?

So perhaps the question is, why didn't the original app use bower.json, module loader, etc. Was it that the startup cost is too high? Or was the app too "small" to worry about that?

What do we need to do to help all web devs to use all the awesome that does exist "out there"? It's all "built in" with Dart, what can we do for our JS devs?

I don't know enough of the intimate details of Promises to know if Future == Promise. I hope I didn't make it sound like Future == Promise, but I do think they are quite similar in intention.

Can you expand on why you think Futures aren't entirely interoperable with Promises? Also, which specific implementation of promises? (what's the link to the promises that you're talking about?)

I hope I didn't "pick on" anything. My attempt was to do a before/after and then list out what I, personally, learned. I thought I did say "JavaScript doesn't have some of these features like modules or promises by default" at the bottom of the article.

I picked a project that was written this year, and because it used Web Audio API and looked pretty. I was inspired by the original app, and I wanted to see what a Dart version would look like.

To be clear, I did find it hard to know where the entry point was. I literally opened each file, in order, to see where the program started. I find it hard to believe that other seasoned developers could look at the file names and instantly know exactly, to which line, where the app started.

Ah, you mean "server side". Gotcha. Yes, building for the server is easier because you have a single runtime to target. In the case of Node, it's V8. In the case of Dart, it's Dart VM on the server.

I've clarified at the bottom of the post that JavaScript is probably going to get some of these features in the future. One of the points I was trying to make was Dart has these features now (and because Dart compiles to JS, it means I can deploy these features now).

The other question we should ask is, why didn't the original author use those new shiny JS features in his app? He's a crazy smart developer. My hypothesis: because the out-of-the-box dev experience doesn't include modules, promises, etc, there's a higher barrier to using the new shiny JS features because the developer needs to first A) know about them B) find the right polyfill.

Thoughts?

The header of the layout says "Dart DevRel @ Google,", as you mention the sidebar has a bio (which I will move up), and I just added a note to the beginning of the article. Thank you for the feedback, and thanks for reading.

Thank you for calm and reasoned explanation. It's easy to address. Aaaaand, done, I added a little note at the top.

re: your personal feedback, thanks very much. The Music DNA app is pretty simple, there's not a lot of specific business logic there. It is a good example of Web Audio API, async, code organization, drag and drop. Are you saying you'd like a more detailed explanation of those APIs? I guess I assumed that web developers would read the post.

Open to ideas.

The header on the blog says "Dart DevRel @ Google", and the sidebar says "Seth is a web engineer and Chrome Developer Advocate". I apologize it wasn't obvious enough. I agree, it should be obvious that I work at Google.

This particular project was done on my own time, a little bit while at work, and a lot at nights and weekends.

Can you be more specific about what "API side" means?

Yup, thanks! What's the story for modern browsers that don't yet support those features? Do they both have polyfills?

As I mentioned in the article, libraries and futures aren't exclusive to Dart. It's just that they are here now for Dart and are compiled to JavaScript for all modern browsers.

I think it's telling that the original author didn't use Promises or Modules. Of course he could have, but we should ask, why didn't he?

I picked the Music DNA app not because it makes Dart look good, but because I never really used Web Audio API before and the app looked good. If I really wanted to cherry pick, I wouldn't have picked an app that uses a third-party JS lib. The JS interop in Dart is sufficient, and it works, but obviously is not as seamless as it is in JavaScript. JS interop in JS is better than it is in Dart, and I didn't hide that.

I welcome anyone to pick a random JavaScript app, port it to Dart, and write up their experience. I'm sure the community would love to learn more about that experience, especially me.

I don't have access to anything you don't. Dart is open source. Heck, in my job, I don't even write Dart code every day. :)

I even reported issues about the original Music DNA app (bugs, code quality) to the original author. I helped make the original Music DNA app better.

Can you help me identify the false conclusions?

Luckily, Dart compiles to JavaScript, so we don't need to wait for browser adoption of the VM. The questions that I see as important are: "Do my Dart apps, when compiled to JavaScript, work across the modern web?" and "Am I more productive building web apps with Dart?".

Good question, I'll try to add that. Maybe more importantly, what is the startup time for the two versions?

Thanks for the feedback. I did point out, in the end of the article, that some of the techniques (e.g. libraries, futures) aren't impossible in JavaScript. And I'm really happy to hear they might be coming to a future version of JavaScript (everyone should have modules and promises!). Part of the point of the article is that Dart has these features now.

I think the web was a big success on desktop (modulo some pretty big apps like Photoshop, and we should ask ourselves why apps like Photoshop never landed in the browser, and then fix those issues).

As for mobile, it's clear a lot of companies have no problem building their app twice (for both iOS and Android).

Have you tried to use source maps to help debugging? Plenty of compile-to-JavaScript languages support source maps, and even some CSS frameworks. Building complex/large apps without a compiler and tools is really difficult. GWT, Closure, TypeScript, Dart are all efforts to help developers build more interesting apps that scale. Building/compiling is just a natural step in the process, and source maps are a natural output of that process.

Why would a site want to target only Chrome? If your site has a URL, I think it's of the site's best interest to target many modern browsers and provide a graceful upgrade/download experience.

Good question, I'd have to run some queries. dart.googlecode.com and github.com/dart-lang are the two main locations. We receive more patches for the libraries and docs than we do for the VM. But we have received patches for dart2js (a fairly complicated bit of code).

Browsers should compete on performance. As long as dart2js outputs efficient JavaScript (current benchmarks: https://www.dartlang.org/performance) so that Dart code runs well on browsers without the VM, I think it's fine if some browsers run Dart more efficiently than others. Consider Dart VM as an accelerated way to run Dart code which otherwise runs fine in other browsers.

To be very clear, Dart runs across the modern web when you compile it to JavaScript, so it's not a language that works only in one browser.

I find Dart much easier to learn than Java. Check out http://programming.oreilly.com/2013/05/dart-is-not-the-langu... for many differences between Java and Dart.

If the web community doesn't continue to work on innovative new platform features, and deliver fantastic experiences for mobile users, then native mobile (ios, android) will become the de facto way to deliver apps to users. That day is more likely and closer than some may want to believe. So double check before you say something like your comment. :)

Dart compiles to JavaScript, is open source, and is now in ECMA. The project has mostly Google engineers committing, but we also have plenty of open-source contributions.

asm.js is a compile target that takes C/C++ code and outputs lots of typed arrays, and a custom engine to interpret the asm.js "hints". It's an interesting way to get C code onto the web, but developers don't write asm.js code by hand. In contrast, Dart is designed to be written by developers. The similarity is that both asm.js and Dart want to enable faster experiences for users, but they take very different approaches.

Better for users also (and yes, better for Google because Google makes money when people see and click ads on the web).

When the web has more interesting content being produced by more motivated developers, users win. When the web starts up faster, users and vendors win. When pages and apps run much quickly on the web, users and vendors win.

Why wait for the VM when you can compile to JavaScript today?

Do you have a source for the above quote? I ask because it appears he liked using it: https://twitter.com/notch/status/412290357892636673

"I really like it." - notch

I wrote up why I think Dart is not the language you think it is here: http://programming.oreilly.com/2013/05/dart-is-not-the-langu...

[disclaimer: I work on the Dart team]