[sethladd]

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.

[Touche]

The problem is that you picked a project that doesn't reflect current (again, defining current as in the past 5 years at least) development practices. Any decent JS project these days is using a modular loader and has a bower.json that has a 'main' property telling you the entry point.

I'm sure someone could look at early Dart projects and find things unpleasant about them compared to today.

[sethladd]

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?

[Touche]

The startup costs to using a module loader are the same startup costs to using Dart. That's the point I'm making, Dart is an alternative to JS tools, but it's still a choice that has to be explicitly made. You don't get Dart for free in any browser but Dartium.