Being a "developer advocate" is one thing, writing official documentation, answering questions on forums, whatever — but "I ported a JavaScript app to Dart. Here's what I learned." Seriously? More like "I'm on the Dart Team. I ported a JavaScript app to Dart because it's my job."
Open source shouldn't need to be juiced with paid posts. If you scroll down to the "Lessons learned" section at the end, it really strikes to the core of what being disingenuous is all about.
This particular project was done on my own time, a little bit while at work, and a lot at nights and weekends.
I don't know who Seth Ladd is. I looked at the page and it skipped over his title and went straight to the text.
I don't care if Google paid him, or if the works for Google, or if he wrote because he was forced to at gunpoint by Colombian mafia. It doesn't matter. It is a good article and I enjoyed reading it. It is very well done, it shows how the IDE works, explains some concepts about Dart.
I can see maybe if you had direct proof that he was forced to do this against his will by Google, ok we could maybe discuss the implications of it. That still wouldn't make that a bad article.
strawman alert.
I on the other hand am simply an engineer on the Dart team, as I must disclaim in this context.
A misleading presentation potentially leading people to false conclusions is worth calling out.
edit: so "ad hominem" is just going to mean "disapproval" from now on, and not implying that someone's argument is incorrect because of who they are?
This was an simple assertion about clear disclosure, not a logical fallacy.
This is especially true of developer advocates. No one's whining about all the HTML5 advocacy that Google does on sites like html5rocks.com, do you think the developers that write those articles merely do so because orders came down from above, or because they chose things they thought were exciting or that they were enthusiastic about.
Why do I love Dart? As a developer and a university professor, for the first time in my long career, I can do the following with Dart:
I can use Dart both on the client and on the server; with Dart, I can apply both object-oriented and functional way of programming.
I can develop in Dart and deploy applications in JavaScript.
I can be a productive developer with many Dart tools and libraries, and get a very good performance in either Dart applications or their JavaScript versions.
I can start developing a prototype without data types and introduce them when I need to convert the prototype to a deployable application.
I can use Dart for both synchronous and asynchronous programming.
I can use many publicly available packages and reuse their libraries.
I can be a web engineer on the client-side and a software engineer on the server-side, with the same language and many reusable libraries.
I don't care who writes the article, all that matters is whether the content of the article is interesting.
For this particular article, I think the answer is "Very", so thanks to the author.
I do keep flip-flopping on whether I'm going to seriously commit to it though. I really like Dart, my code is safer, cleaner, and more maintainable. But it just doesn't feel like it has much momentum yet.
Rest assured, we're very committed to Dart.
Spec: http://wiki.ecmascript.org/doku.php?id=harmony:modules
1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
That being said, traction for any new programming language is hard. A programmer's learning time is limited and most programmers would treat it as an investment. In Dart's case, the investment will make more sense if the Dart team could get the VM onto Chrome's release channel (not Dartium/Chromium as it currently stands). I bet that's going to be a hard fought battle, but I believe this would incentivize developers to code in Dart and serve Dart2Js generated js files to other browsers (FF, IE etc.); especially because the coding/debugging experience is so much better than vanilla javascript (I am now prepared for coffeescript advocates to join the fray).
As an aside there might be some App Engine integration that can help the cause. "Specifically, we are working on server-side Dart support for Managed VM" https://code.google.com/p/googleappengine/issues/detail?id=6...
There are so many novel, cool "JS replacements" that it's easy to feel some paralysis about the whole matter. Do you go with Dart? TypeScript? Clojure? Or do you stick with regular JS and start learning a new framework (e.g. Angular)?
They're not necessarily mutually exclusive, but I think a good majority of web developers are waiting to see what unfolds before committing one way or the other.
These days JS is more or less compiled, at least the file you get in your browser is very different that what the developer saw.
This seems to improve the case of Dart and I wouldn't be surprised if we saw more languages that compile down to JS in the near future.
We already have ES6 down to ES5 http://addyosmani.com/blog/author-in-es6-transpile-to-es5-as...
This is me remembering the arguments not making it ;)
Wasn't the idea of Dart to replace JavaScript as the "lingua franca"? And we still have to run Chromium to support it natively?
In fact I think Google should release Google Chrome with Dart VM and then accelerate a few of their apps (oh look much better Google maps!), before you know it, Opera will get it as well.
I'm also torn between using a pure javascript framework like Google Angular or a hybrid such as GWT or Dart. There are seriously too many options and no one has a clue what the long term support for any of these will be.
It's doubtful that JavaScript will be widely replaced as the language of the web. I can see a day where most web developers don't write JavaScript anymore and languages that compile to JavaScript (like dart) will be widely adopted.
It's almost like the evolution of programming languages. If you take, for example, the C programming language, people could write a lot of modern applications using it but C++ and .NET has made things easier and more maintainable. I think a similar thing could be said in the future about dart (representing C++ or .NET) and JavaScript (representing C).
Outside of Dart we already have pretty good solutions for Promises (with Promise A+ compatible libs; Q, RSVP etc) and modules (ES6 modules, Require etc), which /kind of/ makes those points moot.
Which leaves type checking and autocompletion as the big benefit. Which are nice, I guess.
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?
I'm not going to argue against your point though, because I think you are right. One needs to have some grasp of the JS ecosystem to know what libraries to use. And as I said, it's nice that Dart has made that choice for you.
But that said, poking around a bit in the Dart documentation I think it's interesting that "Futures" are seemingly /not/ entirely interoperable with the de facto standard of Promises (A+) in JS.
>Slowly but surely the JS worlds moves toward looking like the Flex/AS3 of years before.
