I ported a JavaScript app to Dart
blog.sethladd.com
blog.sethladd.com
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.
A misleading presentation potentially leading people to false conclusions is worth calling out.
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?
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.
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.
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.
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.
I on the other hand am simply an engineer on the Dart team, as I must disclaim in this context.
Sidebar is not an unusual place to place author bio and it is definitely enough for me.
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.
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?
Seth Ladd's Blog
Dart DevRel @ Google, web engineer, author, conference organizer.
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.
I'm sure someone could look at early Dart projects and find things unpleasant about them compared to today.
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?
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 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 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.
This particular project was done on my own time, a little bit while at work, and a lot at nights and weekends.
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...
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?
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...
When I last looked into it, there had to be some strange stuff to be done, to call JS from Dart and Dart from JS.
It just didn't felt as naturally as in TypeScript or LiveScript.
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?
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.
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.
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 :
(define $taskList ($ "#tasks"))
(define $input ($ "input"))
(define $form ($ "form"))
;; add task
(define (addTask task)
(let ((t ($ "<li>" {"class" "task link"} )))
(t.on "click" (lambda (event)
(t.toggleClass "stroke")))
(t.text task)))
;;on submit
($form.on "submit" (lambda (event)
($taskList.append (addTask ($input.val)))
($input.val "")
(event.preventDefault)))
There is no shame into writing for the web and not using javascript.At the end of the day,only the product matters.
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.
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.
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?)
>Slowly but surely the JS worlds moves toward looking like the Flex/AS3 of years before.