Live data from Hacker News

I ported a JavaScript app to Dart

blog.sethladd.com

51–60 of 83 posts

Re: I ported a JavaScript app to Dart

#51
post #45

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.

Thoughts?

Re: I ported a JavaScript app to Dart

#52

Earlier quoted context omitted.

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

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, €œYe…

> Yes, you can, but you can€™t maintain them

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 ($ "" {"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)))
FYI this is the classic todo list with jQuery

There is no shame into writing for the web and not using javascript.At the end of the day,only the product matters.

Re: I ported a JavaScript app to Dart

#53

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…

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.

No, it's not. It's not an argument of any sort, and doesn't make any claims about the quality of the article.

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.

Re: I ported a JavaScript app to Dart

#54
post #45

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

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.

Re: I ported a JavaScript app to Dart

#55

Earlier quoted context omitted.

+1, and also, safest place to use es6 right now is on the API side. No need to wait or use the transpiler.

Can you be more specific about what "API side" means?

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.

Re: I ported a JavaScript app to Dart

#57

Earlier quoted context omitted.

Can you be more specific about what "API side" means?

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.

Re: I ported a JavaScript app to Dart

#58

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

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.

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

Re: I ported a JavaScript app to Dart

#59
post #29

Earlier quoted context omitted.

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.

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…

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.

Re: I ported a JavaScript app to Dart

#60
post #54

Earlier quoted context omitted.

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

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 "Fut…

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

Post reply on HN