We have a ton of JavaScript/CoffeeScript code and I really wish we could use something like Dart. JavaScript is great for smaller projects, but once you get a ton of code it really becomes a unmanageable mess.
I think tho' it would be amazing if Dart could run on the server side as well. This way you could just have one language on both the client and the server.
If you are looking for a structured language (for front end dev), Typescript is a better alternative imho. Javascript devs can still read it and it's compatible with any JS library out there.
Dart not so much since the semantics are different.You can still interact with JS libs but it's not as straight foward as TS.
I tested a number of options (GWT,Haxe,CS,Dart,Opal,Jsx,...),while i'm not a Microsoft fan(by a long shot),Typescript is the solution that allows the best integration with legacy code and pure JS libraries,while making easy to port old java/C#/as3 code to JS.
I've done a project in Dart and another in TypeScript and like them both a lot more than doing straight JavaScript. I appreciate the optional type checking in both and the IDE support that each enables. TypeScript is appropriate if your project is more quickly completed with existing libraries like jQuery UI and needs to run on older browsers. Dart is appropriate if you don't need to use older established JS libs and IE9 and above are your target requirements. I like having them both in the toolbox, but I prefer Dart slightly more than TypeScript for various reasons.
That's very different from Javascript (and from the untyped-language mainstream) but is it really "horrible"?
The type-checker will give a very clear warning if it catches you putting a non-bool in a conditional context. And make no mistake: the type checker is an important part of the Dart development process.
(One downside of this is that it does push you to working in the -- Eclipse-derived -- DartEditor, which isn't always a wonderful experience. However, the type checker is exposed and available, and there's nothing to prevent it being tightly integrated into other editors or IDEs.)
That's not a horrible semantic. There is one canonical truth value and everything else is false. It's the inverse of the Lisp semantic, where there is one canonical false value and everything else is true. I think it's better than the ad-hoc semantics of other scripting languages,[1] and more appropriate for a dynamic language than throwing an exception if a non-boolean is used as a predicate.
[1] And as a practical matter generates faster code, because it can be implemented with a comparison against a single constant.
Dart does run on the server. The VM runs standalone for scripts and long-running apps, and the dart:io library provides very node.js like file, network and HTTP APIs, with the addition of Isolates for actor-like concurrency.
In fairness to JavaScript, it is absolutely possible to write very large apps and keep them organized and maintainable.
I think the issue is that JS doesn't have strong conventions for how to do that, so you actually need to make good choices that work well with your app.
I have no doubt that Dart makes that stuff easier, but there's nothing inherent to JavaScript that makes it unsuitable for larger applications. It just forces you to make decisions.
> In fairness to JavaScript, it is absolutely possible to write very large apps and keep them organized and maintainable.
I see it a bit like when Dijkstra wrote "Go To Statement Considered Harmful". I have no doubt a lot of developers at the time objected to it and said "that is wrong, it is possible to write good code using GOTO". Because they probably wrote code using GOTOs and some of that code was probably decent quality.
In C it is almost customary to use `goto` as poor man's exception handler: you do `goto cleanup` from inside of nested ifs and loops if a fatal error happens and all you need is to clean up what needs cleaning and return an error code.
The problem is that `goto` is easy to abuse, and, worse, easy to abuse inadvertently, e.g. you might produce a `goto` into a loop or something like that during refactoring.
It's important to remember that the "goto" Dijkstra is talking about is very different from the "goto" that C programmers use. He's talk about unstructured goto: jumping from the middle of one function to another, or across scopes.
"Goto" as another local flow control construct is relatively innocuous.
How do you mean "Knuth won"? Can you paraphrase the paper? I couldn't find a one phrase or proof of this "winning".
Here is what Dijkstra said:
> "The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program.
"
How does Knuth win that?
In any case, I think there is a popular understanding of that phrase. It entered folklore to mean something else and regardless if that something else is different, it does make sense.
Excessive GOTOs complicate code and create a spaghetti mess. Today we don't need scientific papers on it. That is how I understand it.
The general idea is that there are better construct and better paradigms out there. Not all programming construct are strictly equal in practice. Yes all languages that are Turing complete can do the same kind of things. We know the theory. But it turns out some paradigms are better than others. OO programming, despite it being hated and derided today, was a better idea that writing lots of GOTOs. Functional programming with immutable data-structures does make sense in a distributed and concurrent environment. STMs compose better than locks and mutexes and so on.
Javascript comes from a school that most people simply didn't attend. But it's actually ahead of the curve by about 10 years, as evidenced by the emergence of Scala and co.
People have found success in managing large Javascript codebases through good design choices like module systems (AMD/CommonJS), using the SRP to keep modules tight, and testing. It's tough (nigh impossible?) to retrofit those design choices onto an existing codebase.
Dart and TypeScript seem to offer a more familiar path to people who are used to Java/.NET/etc and who have been burned by messy JS codebases.
Why don't you choose JSX or TypeScript? The latter is a superset of JavaScript, so migration should be a breeze.
If you'd like the same language for client and server side, try Kotlin or HaXe.
For now, Dart doesn't have a crossbrowser VM yet (except for Dartium), so it doesn't give you any performance boost over JavaScript. Maybe one day there will be a cross-browser Dart VM as a PNaCl or asm.js module?
Dart definitely runs on the server side. We had plain Dart and two of its initial web frameworks, Start and Stream, in Round 7 of our benchmarks project [1]. It performs modestly well, and I suspect there room to optimize further.
I'm curious - what stops you from using dart2js today? Isn't it kinda like CoffeeScript? If you already have the latter, you already have workflow for "something that compiles to JS" as part of your app.
We have a ton of JavaScript/CoffeeScript code and I really wish we could use something like Dart. JavaScript is great for smaller projects, but once you get a ton of code it really becomes a unmanageable mess.
I think tho' it would be amazing if Dart could run on the server side as well. This way you could just have one language on both the client and the server.