10 ms·

I ported a JavaScript app to Dart

76 points by zetalabs 12y ago

todd8 12y ago
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.
- k__ 12y ago
  It just doesn't play well with JS, because it was designed as a JS replacement, with an own Runtime, which kinda sucks...
  - spankalee 12y ago
    Care to be more specific? You can use JavaScript from Dart now, and we're working on improving interop support. Feedback is welcome.
    - k__ 12y ago
      Really? 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.
- CmonDev 12y ago
  "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.
- amartya916 12y ago
  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). 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=6092 https://code.google.com/p/googleappengine/issues/detail?id=6...
- bronbron 12y ago
  > I'm surprised its not getting traction faster. 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.
robmcm 12y ago
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. We already have ES6 down to ES5 http://addyosmani.com/blog/author-in-es6-transpile-to-es5-as-a-build-step-a-workflow-for-grunt/ http://addyosmani.com/blog/author-in-es6-transpile-to-es5-as...
- zevyoura 12y ago
  In addition to source maps, which have largely eased the pain of this issue, there's also the Dartium[0] build of Chrome, which has a proper Dart VM. [0] https://www.dartlang.org/tools/dartium/ https://www.dartlang.org/tools/dartium/
- grifpete 12y ago
  Why would the compiled nature of Dart make it hard to debug? Presumably you mean debug by someone other than the original developer?
  - robmcm 12y ago
    That and debugging the compiled JS assuming there was a bug in the compiler or a browser quirk the compiler hadn't worked around. This is me remembering the arguments not making it ;)
bla2 12y ago
I wonder how the size of the dart-generated js compares to the size of the original js.
- sethladd 12y ago
  Good question, I'll try to add that. Maybe more importantly, what is the startup time for the two versions?
  - Nemcue 12y ago
    Would also be interesting: Perform some operations, compare flame charts from Chrome developer tools.
    - sethladd 12y ago
      Also a good idea! Gah, I need more time.
tyleregeto 12y ago
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.
- spankalee 12y ago
  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). Rest assured, we're very committed to Dart.
deleted 12y ago
[deleted]
rockdoe 12y ago
"Here’s what I learned" This is a bit deceptive given that he's a Chrome Developer Advocate paid for pushing Dart. Surely he "knew" about that beforehand? I'll take his experience with a few bags of sand.
adamkochanowicz 12y ago
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?
- sethladd 12y ago
  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?".
  - arrty88 12y ago
    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.
    - akbar501 12y ago
      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.
      - grifpete 12y ago
        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-for-JavaScript-to-Step-Aside-for-the-Next-Big-Web-Thing-109707/#sthash.GI9zFsT3.dpuf" http://www.eweek.com/c/a/Application-Development/Is-it-Time-...
supporting 12y ago
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.
- tiziano88 12y ago
  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.
  - rockdoe 12y ago
    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.
    - sethladd 12y ago
      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?
jlongster 12y ago
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 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.
- sethladd 12y ago
  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.
  - Excavator 12y ago
    Thought you'd might want to know that Promise¹ is available in Firefox & Chrome since quite a while back and the spec for Modules can be found here: Spec: http://wiki.ecmascript.org/doku.php?id=harmony:modules http://wiki.ecmascript.org/doku.php?id=harmony:modules 1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    - sethladd 12y ago
      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?
      - jamesknelson 12y ago
Nilzor 12y ago
Tl;dr News flash: static typing is a good thing!
Nemcue 12y ago
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.
- sethladd 12y ago
  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?
  - Nemcue 12y ago
    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.
    - sethladd 12y ago
      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?)
x86_64Ubuntu 12y ago
Why can't I comment on the blog? Anyway, I was going to say. >Slowly but surely the JS worlds moves toward looking like the Flex/AS3 of years before.
- sethladd 12y ago
  Hm, the blog has G+ comments on it. Apologies if that's not working. You can leave comments here, too :)
dkarapetyan 12y ago
All that code and one bug? Either the original programmer is a genius or Dart isn't as great as it seems.
- sethladd 12y ago
  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.
ryanolsonx 12y ago
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).
Nekorosu 12y ago
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.

76 points by zetalabs 12y ago

todd8 12y ago

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.

k__ 12y ago
It just doesn't play well with JS, because it was designed as a JS replacement, with an own Runtime, which kinda sucks...
- spankalee 12y ago
  Care to be more specific? You can use JavaScript from Dart now, and we're working on improving interop support. Feedback is welcome.
  - k__ 12y ago
    Really? 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.
CmonDev 12y ago
"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.
amartya916 12y ago
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). 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=6092 https://code.google.com/p/googleappengine/issues/detail?id=6...
bronbron 12y ago
> I'm surprised its not getting traction faster. 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.

robmcm 12y ago

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. We already have ES6 down to ES5 http://addyosmani.com/blog/author-in-es6-transpile-to-es5-as-a-build-step-a-workflow-for-grunt/ http://addyosmani.com/blog/author-in-es6-transpile-to-es5-as...

zevyoura 12y ago
In addition to source maps, which have largely eased the pain of this issue, there's also the Dartium[0] build of Chrome, which has a proper Dart VM. [0] https://www.dartlang.org/tools/dartium/ https://www.dartlang.org/tools/dartium/
grifpete 12y ago
Why would the compiled nature of Dart make it hard to debug? Presumably you mean debug by someone other than the original developer?
- robmcm 12y ago
  That and debugging the compiled JS assuming there was a bug in the compiler or a browser quirk the compiler hadn't worked around. This is me remembering the arguments not making it ;)

bla2 12y ago

I wonder how the size of the dart-generated js compares to the size of the original js.

sethladd 12y ago
Good question, I'll try to add that. Maybe more importantly, what is the startup time for the two versions?
- Nemcue 12y ago
  Would also be interesting: Perform some operations, compare flame charts from Chrome developer tools.
  - sethladd 12y ago
    Also a good idea! Gah, I need more time.

tyleregeto 12y ago

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.

spankalee 12y ago
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). Rest assured, we're very committed to Dart.

deleted 12y ago

[deleted]

rockdoe 12y ago

"Here’s what I learned" This is a bit deceptive given that he's a Chrome Developer Advocate paid for pushing Dart. Surely he "knew" about that beforehand? I'll take his experience with a few bags of sand.

adamkochanowicz 12y ago

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?

sethladd 12y ago
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?".
- arrty88 12y ago
  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.
  - akbar501 12y ago
    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.
    - grifpete 12y ago
      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-for-JavaScript-to-Step-Aside-for-the-Next-Big-Web-Thing-109707/#sthash.GI9zFsT3.dpuf" http://www.eweek.com/c/a/Application-Development/Is-it-Time-...

supporting 12y ago

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.

tiziano88 12y ago
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.
- rockdoe 12y ago
  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.
  - sethladd 12y ago
    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?

jlongster 12y ago

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 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.

sethladd 12y ago
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.
- Excavator 12y ago
  Thought you'd might want to know that Promise¹ is available in Firefox & Chrome since quite a while back and the spec for Modules can be found here: Spec: http://wiki.ecmascript.org/doku.php?id=harmony:modules http://wiki.ecmascript.org/doku.php?id=harmony:modules 1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - sethladd 12y ago
    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?
    - jamesknelson 12y ago

Nilzor 12y ago

Tl;dr News flash: static typing is a good thing!

Nemcue 12y ago

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.

sethladd 12y ago
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?
- Nemcue 12y ago
  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.
  - sethladd 12y ago
    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?)

x86_64Ubuntu 12y ago

Why can't I comment on the blog? Anyway, I was going to say. >Slowly but surely the JS worlds moves toward looking like the Flex/AS3 of years before.

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

dkarapetyan 12y ago

All that code and one bug? Either the original programmer is a genius or Dart isn't as great as it seems.

sethladd 12y ago
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.

ryanolsonx 12y ago

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).

Nekorosu 12y ago

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.