Live data from Hacker News

I ported a JavaScript app to Dart

blog.sethladd.com

71–80 of 83 posts

Re: I ported a JavaScript app to Dart

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

Re: I ported a JavaScript app to Dart

#72
post #66

Earlier quoted context omitted.

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 Dar…

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?

Re: I ported a JavaScript app to Dart

#75
post #68

Earlier quoted context omitted.

Good question, I'll try to add that. Maybe more importantly, what is the startup time for the two versions?

Would also be interesting: Perform some operations, compare flame charts from Chrome developer tools.

Also a good idea! Gah, I need more time.

Re: I ported a JavaScript app to Dart

#76
post #66

Earlier quoted context omitted.

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…

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.

Re: I ported a JavaScript app to Dart

#77
post #36

Earlier quoted context omitted.

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 writin…

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 tha…

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.

Re: I ported a JavaScript app to Dart

#78

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 i…

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.

Re: I ported a JavaScript app to Dart

#79
post #4

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…

Why would the compiled nature of Dart make it hard to debug? Presumably you mean debug by someone other than the original developer?

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

Re: I ported a JavaScript app to Dart

#80
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.
Post reply on HN