It's a little bit sad that Google pays people to have their entire job be to astroturf for Dart with blog posts like this one.
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.
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.
All I heard it from your post is a lot vitriol and hatred.
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.
That's not a strawman. It would be a strawman if the GP characterized the original comment as suggesting that, but it's not. It's saying that even this facetiously extreme example still would not disqualify the content of the post from being useful/interesting/whatever.
Well that's a plain "ad hominem" argument right there sir. I found the post interesting and useful, and the fact that the author works for Google or Apple or Microsoft or Walmart doesn't affect it in the slightest.
He presents the post as if he was learning something new, when he's really a seasoned Dart expert which has access to resources most of us don't have. Then there's the background that he could cherry pick his project to make the outcome look good, and doing so is in fact his job.
A misleading presentation potentially leading people to false conclusions is worth calling out.
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.
He's not saying that you have false conclusions. He's saying that you have false pretenses. It appears as though you are new to the language, porting over some javascript code.
The truth is, you are not new to Dart at all. I believe he feels duped by you.
My personal problems with your post is that you go far too deep into the guts of how Dart works. 90% of your blog post is the internals of Dart as if you are writing the first few chapters of a Dart book. I would personally prefer it if you focused more on the specifics of the library you were porting over. That's what feels illegitimate to me when I read this article.
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.
Honestly, I tried to work with Dart. I hit a few stumbling blocks during the tutorials. One difficulty was javascript interop. I also remember the drag and drop tutorials not working when I downloaded the code from github. It is really good that you covered those topics. Javascript interop in particular was a good choice. I can imagine a lot of developers may want to dip their feet in without migrating an entire project into Dart.
I think the post was a good writeup. I think that there is a void in Dart tutorials in general. It is incredibly easy to set up a standard Dart project. The idea of Futures are incredibly easy to follow. The code itself is very direct and easy to follow. The part that I always end up turning back on is when I try to integrate a real life project with Dart. I looked up the Angular port and found an incomplete tutorial. It gives me the feeling that others have not navigated that road before me, which in turn makes me wary to continue.
Perhaps a few blog posts that go heavy into the business logic of whatever app you decide to make would be more comforting. As a person who is on the fence, it would give me great comfort to see all the nuances of common CRUD apps blogged about. If you look at tutorials for Angular in javascript and are able to match those in Dart, I'll switch over.
Your definition of astroturfing doesn't seem to match mine. Seth states several times on his blog that he works on Dart developer relations at Google. Blogging about Dart is part of his job, and in no way is he being deceiving about that fact.
I on the other hand am simply an engineer on the Dart team, as I must disclaim in this context.
Where does he mention that other than the sidebar? I completely missed the fact that he works for Google while reading the article since it's never mentioned in the body of the article itself, and the article is written as if he's completely new to Dart and trying it out for fun. If he's not trying to present that image, then it's a really awful writing style.
Do you imply a conflict of interest? If you do, please state it explicitly. Your criticism as it stands doesn't add to the discussion and one could say that your writing style is really awful, too.
Sidebar is not an unusual place to place author bio and it is definitely enough for me.
Okay, I'll state it explicitly: I feel that the article is actively deceptive about the background of the author, which makes me distrust the content of the article as well. The sidebar with his background is not visible on the first page of the content, so I would have had to interrupt reading the article to read it.
I say that it is a bad writing style because I am assuming good faith. I assume that the positioning of his bio is merely unfortunate and not specifically chosen to reduce the number of people who read it, and that the article is not actually trying to deceive me about the author. I think it is obvious that coming across as astroturfing to some subset of your readers when that isn't what you're trying to do is a bad thing.
> I assume that the positioning of his bio is merely unfortunate and not specifically chosen to reduce the number of people who read it, and that the article is not actually trying to deceive me about the author
Oh please. Most blog authors barely manage to fill out an About page, let alone a sidebar and a big subheading at the top of the page that says who their employer is. If you're going to claim to be "assuming good faith", how about actually doing so?
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.
I agree. This is getting your panties in a twist because a writer hasn't spelt out his putative conflict of interest in a way that conforms to your norms, when it is certainly plain enough for many readers (I had no problem at all figuring it out and wasn't at all offended by it).
Please don't insult his writing style. That's an ad hominem attack and it is the only thing in this conversation that doesn't belong here. You don't have to agree with his concerns, but please cut that out.
What irks me is that the things he picks on have long since been solved. So the fact that he works at Google tells me that he knows better and is being intentionally deceitful. He picked a project that doesn't use any modern (by modern I mean in the last 5 years) practices like module loaders. It's fine to say that JavaScript doesn't have this by default, but that's not what he did here. He pretended to think that it's hard to know what the entry point file is.
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.
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.
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?
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.
Couldn't it also be the case that he's not doing it because he's paid to, but because he loves Dart? People at Google can move around between projects, and generally, if you're working on a particular project, it's not because you are disinterested in it and simply collecting a paycheck, but you're enthusiastic about it.
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.
I do not work at Google and yes, I love Dart. By following Seth's work for two years and a half, it is obvious to me that he loves Dart.
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've never minded harsh HN criticism b/c it's good at exposing design/develop weaknesses, but picking on presentation style while completely ignoring the technical aspects of the article is just bikeshedding. We all know he's a Dev Advocate. If you might have some great criticism on js/Dart, that would be very helpful. He could be wrong, so chime in.
I don't get your point. If a guy is going to advocate for anything presumably it is better if the guy has some practical experience and what is wrong with him sharing that experience? Do you honestly imagine that anyone reading this piece was in any way deceived or confused by his role at Google? It's not like he hid it.
I've been porting a larger application from JS to Dart, and I can repeat a lot of what Seth says in this article. The experience has been generally very good. While porting I also discovered a couple bugs that existed in the original code base for a very long time.
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.
I'm not sure what I can say about Dart adoption internal to Google, so I'll be conservative and say that it's going well in my opinion. I hope we can speak more about it at some point. Language adoption is a very gradual thing at first, so I'm not at all surprised that momentum isn't that apparent yet. The community is very active though (join the email lists or G+ if you're not already).
I somewhat skimmed the article, but it doesn't mention the fact the JavaScript is on the verge of getting modules. Unless you really love Dart, you can fix most of these problems by using something like the ES6 module transpiler: https://github.com/square/es6-module-transpiler. Even better, in then next few years JavaScript will start adapting these natively, solving many of the organizational issues laid out in this post.
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.
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?
While a lot of browsers are still lacking pretty much any ES6 support, you can get around this by using Traceur [1] to compile your ES6 javascript down to ES5, and then using the es6-shim [2] for new ES6 libraries (Promise, etc.)
Given that you'll need to compile dart down to JS for it to run on any browser (including chrome), and given that it seems unlikely Mozilla will ever include a dart VM, I'd say that starting to learn ES6 now is probably a better long-term bet than learning dart. Which isn't to say Dart isn't a nice language...
I don't see the different between using 1) Using Dart and 2) Using a framework that supports modules. The difference seems to be that Dart has a different syntax that some people might prefer. But the point is that everyone chooses to either use frameworks with JavaScript or chooses to using a compiled language (and probably use frameworks on top of that).
Like, when you build an API, (or other backend stuff) you're not concerned about browsers or the DOM - thats really just a delivery mechanism. So you can run --harmony within your own server and have it spit out JSON. Client doesn't know or care what your running, just the JSON.
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 really like Dart. I'm surprised its not getting traction faster. Its a language with few surprises, everything looks familiar and works as you'd expect without gotcha's. While it doesn't feel cutting edge like Haskell or retro on steroids like Clojure, it seems just right as a replacement for Javascript.
I really like Dart too and actually have worked on projects of multiple types (e.g. a game/simulation, parts of a web-app etc.). The just seems right thing that you mention actually resonates with me (in fact, resonated enough for me to teach students in an undergrad course that involved designing and building a web app).
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).
"I'm surprised its not getting traction faster" "replacement for Javascript" - doesn't work in other browsers without transpiling. Since it transpiles, it is not a true replacement. Replacing JS it is right direction nevertheless. Better idea would be integrating two major VMs into browsers: Mono and JVM, keeping them evergreen and just letting developers use any programming languages to have an actual open web instead of one we have now.
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.
One of the early issues raised about Dart was that it's compiled nature would make it hard to debug and was against the open source (easy to hack) nature of JS on the web.
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.
I'm concerned that, however good Dart may be, the fact that zero browsers intend on supporting it natively (and I understand they non-natively support it via js compilation), the popularity is likely to escalate.
Wasn't the idea of Dart to replace JavaScript as the "lingua franca"? And we still have to run Chromium to support it natively?
There is nothing preventing Google from release Dartium (Chrome with DartVM). In the meantime it compiles to js and is not the first thing to do so.
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.
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?".
So does Google Web Toolkit which is what AWS's admin console uses. Why would I use Dart over Google backed GWT?
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.
GWT is ideal for Java developers who prefer to write in Java, but have to deploy in JavaScript.
Pure JavaScript (or a JavaScript framework) are ideal if you either know JavaScript, or are ok learning the language. IMO, learning JavaScript is a good bet since it is the language of the web. Basically, your web apps will either be written in JS or compile to JS, so knowing the language is worth it.
Dart would be selected over GWT if you don't know Java, but like the lang features of Dart.
Of course, there are tons of options in the 'compile to' langs, with CoffeeScript being a popular on.
Learning to program in Javascript is like programming in assembler. That may be unavoidable when there are no high level languages, or when those languages and toolsets are immature. But there are serious experts (and people with a lot of experience with very large js programs) who don't see js as the solution.
"Goaded by Meijer as to whether it is possible to write big programs in JavaScript, Hejlsberg replied, Yes, you can, but you cant maintain them," much to the delight of the crowd that featured several prominent language and tools designers. I think there are some unmet needs there, Hejlsberg added.
Bracha immediately piped in saying, Thats part of why were doing Dart. You can write them [large programs in JavaScript]; its terribly hard and afterward youll be punished. - See more at: http://www.eweek.com/c/a/Application-Development/Is-it-Time-...
Well, i'd say it's more difficult but doable.(And i'm not a fan of javascript).
But tools are being created to help developpers maintain these "large apps".
Code analysis engines are the most important thing to work on in javascript land.I wish more people would work on that instead of framework MVC X or Y.
Something like TernJS ,while not perfect is actually doing interesting thing in term of understanding js code and auto completing it.
Now as I always say,dont like javascript? doesnt matter there are 100 languages you can use instead of it and still write for the web. The only thing that is important imho is wether that language can directly talk to the DOM or not,and invoke third party libraries.
that's why i'm not comfortable with Dart(but maybe it has changed).
I was trying alternative languages the other day and wrote this with one of them,the only thing i had to do to make it run in a browser is eval the transpiled version :
I really liked the direct comparisons in this article between the original javascript and the dart code. It makes me want to learn more about dart and about how I can use it in my personal (or work) projects.
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).
The article clearly shows that Dart doesn't stand too far from vanilla JS. Conceptually it's on the same level. Futures? Really? Functional reactive programming or communicating sequential processes solve the async problem a lot better than futures. FRP is available in vanilla JS (take a look at bacon.js) and CSP are part of ClojureScript which by the way exists because it's a good tool not because some megacorp throws it's money to push it to the masses.
Sure — I guess it's nice that Dart comes with a lot of useful things built in.
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.
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.
As a counterweight: I'm not a crazy smart developer, and I use those features. In production. Now.
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.
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?)
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.