Dart is ready for the real world
arstechnica.com
arstechnica.com
The idea that code can be shared between client and server is the panacea touted by GWT, which (IMHO) failed to eventuate (eg some classes weren't "GWT compatible" and this included protocol buffers generated classes). Dart seems like the next throw of the dice. I am not optimistic about its successes.
Go on the other hand, seems to have an incredibly bright future (IMHO) and it has lots of things in it that I like.
The only issue with Go, as a low-level (C++ replacement) language at least, is that it is a GC language. I used to think that you could implement some kind of ARC (automatic reference counting) system a la Obj-C/iOS 5+ as a middle ground between manual memory management and GC but I now have doubts about this, largely due to reference counting being an issue with locking on highly concurrent systems (something not an issue on phones with Obj-C/iOS).
More to the point, I think Javascript is like the email of programming languages: its ubiquitous and a whole bunch of people are convinced it needs fixing but I'm not exactly sure why. More to the point, those fixes seem to be incredibly complicated to the point of being a questionable value proposition.
I've been using AngularJS of late and to me it's a bit like the Lisp of Javascript frameworks in the sense that it is actually incredibly expressive but can have a steep learning curve. There is a lot that's simple about Angular but once you start delving into custom directives that support ngModel and the like you start requiring a deeper understanding of what's actually happening.
Anyway, back to Dart: I wish them the best but the complexity of language cross-compilation I think diminishes most if not all of the benefits of client and server language-sharing.
Yes, this may look a bit weird, but it actually makes perfect sense. Those types are annotations. If you use them at the "API boundaries" (parameters and return values), you already get most of the benefits you may know from Java or C#.
Compare the doc comments you usually have to write with those baked-in type annotations:
/**
* Foos the bar.
* @param {int} x
* @param {int} y
* @returns {String}
*/
function foo (x, y) {
...
}
/// Foos the bar.
String foo (int x, int y) {
...
}
Additionally, adding those type annotations is useful right off the bat. The IDE will make use of them right away.
>Go on the other hand [...]
Well, Go is very different. It has a completely different focus. It's more like Rust, for example.
Try to add content to the documentation, as "what is expected to be x?", then you can't remove it so easily anymore
Both code snippets are equally documented. That triple slash thing is a doc comment and the type annotations will be also used by dart doc.
Furthermore, those type annotations will be used by the IDE right away. It will tell me if I pass something of the wrong type or if I do something silly with the return value. That type information will be also shown in call tips. I can also run my stuff in checked mode during development, which will make sure that everything is used correctly.
That's the advantage of having this kind of annotations baked into the language itself. It's a lot less annoying to write and, since it's standardized, every tool can use this information, too.
Since this stuff is optional, you can gradually add them as you go. You can quickly prototype something and if it worked as intended, you can add some types while you clean it up.
YUIDoc or JSDoc comments look pretty similar, for example. However, since this stuff isn't standardized, there are some differences between different flavors.
1: http://javascriptjabber.com/008-jsj-v8-and-dart-with-lars-ba...
2: http://javascriptjabber.com/008-1-v8-and-v8-and-dart-with-la...
Why are we bothering with developing new languages when what we should be doing is developing a web standard for a universal bytecode + VM? Hell, use the JVM or the CLR, just as long as it doesn't tie me to a specific language. Dart may be better than JavaScript (I would hope so) but that doesn't mean it's a silver bullet. If we create a standardized bytecode, it doesn't matter what language produced it.
I've been thinking about something like this for a long time. However, the question came up in an interview or presentation with either Brendan Eich or Douglas Crockford (I can't remember exactly where I read this) about why Javascript won out over a VM solution (supposedly this is what the JVM was made for). The most salient argument against a universal VM was that maintaining backwards compatibility between byte-code versions and the competing eco-system of languages would have been a nightmare. Instead the web targeted a single language (and all the trouble that has been along with it). I would rather like to see other languages on the web but I don't think a browser is good place to do it.
Instead what I'd rather see is http://www.cs.cornell.edu/home/ulfar/cuba/paper/ -- work could be done to improve that initial design, but the idea IMO is that the OS already handles processes and allocating memory well and the browser vendors are terrible at this task by comparison.
Either way, Dart is an interesting experiment and I'd give it a shot on some prototyping projects.
I personally believe that HTML is fantastic for what it was designed for: Structured Documents. But the world has gone more interactive and I believe the ad-hoc solution of Javascript, HTML and CSS is not "rich" enough to provide for the users demand.
I like the language independent VM idea as long as it doesn't turn out like bloated Java bytecode.
If the goal was to create a new language well Dart has done that.
If the goal was to give web dev some of tools of app dev (static typing, classical restricted OOP, better speed) I don't think Dart was the right answer specifically because I don't think it's got much chance of getting adopted by other browsers.
The practical solution IMO would be the CLR. Why? Because if Google had chosen the CLR they'd instantly have brought Microsoft and IE along with them at which point Mozilla would probably be pulled in if kicking and screaming.
That seems to me the most pragmatic solution but sadly Google is unwilling to do that for whatever reason.
http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-a...
- Every Javascript program is a valid typescript program so typescript doesn't fix JS semantics (like variable hoisting and the only numeric type being floats). I think typescript is a good fit when you already have some big JS project and you want to get some type errors by loading a predefined signature for jquery or whatever library you're using. You basically get a linter + code completion for free on a pre-existing project. But if I have the choice between Javascript and any other language with saner semantics to start a new project, then I will for sure not chose Javascript.
- I don't think that Dart aims to "replace the entire JacaScript runtime in all browsers", even though the Ars Technica article says so. It's an alternative to Javascript, exactly like Ruby is an alternative to Python. Of course there's a difference between Js vs Dart and Python vs Ruby: every browser runs Js and only Js. That's why the story with Dart is: develop with the VM and Dartium, so that you can reload you application with F5, use the debugger, etc. and then deploy by compiling to Javascript.
And then I completely lost interest when I started structuring my code well, and realised that I didn't need it as much as I thought.
Thanks to "tree shaking" (=dead code removal), you'll reach the break-even point fairly quickly though. You can use massive libraries, buy only those pieces you actually use get included in the final output.
For example, the last JS app I wrote is about 80kB (minified and compressed). jQuery alone took about 33kB of that. How much of jQuery do I actually use? I'd guess it's less than 20%.
So, even with that initial overhead, a Dart version would be probably a bit smaller.
I'd even bet that the ES standards committee will eventually give in on the "arrow" lambda style. ES5 has the "function(x) x * x" shorthand, but with C# and Java both settling on "(x) => x * x", I can see it happening in time.
Isolates: Message passing concurrency which takes away 80% of the problems with threads and locking. I find it intuitive in the way that Unix pipes are intuitive. A few other languages have this also but Dart is one of them and its a plus.
Optional Typing: Its a dynamic language so its very flexible. Some statically typed languages are also flexible but you can still run into some very complex cases with the type system. I want to focus on my application. By having optional types though I can get 80% of what static, strong typing gives me, namely documentation, the ability to quickly reverse engineer someone else's code and runtime type checks. You know all those unit tests that you write in a dynamically typed language just to check the type of some parameter? With Dart you just turn on a switch and those unit tests are built in (I don't think typescript gives you this as the type information is erased at runtime)
Native debugger: I want my apps to run everywhere which means generating javascript. I see the Dart VM as a native debugging environment. Google have built a special VM so that I can debug Dart natively. I don't think source maps will be able to give as rich a debugging experience.
Tree shaking: The size of javascript libraries is a big issue. Have you tried looking at some sites over a slow mobile connection? Tree shaking looks like it will make it possible to only pay for what you use. This is a major plus
A consistent core: How many javascript libraries are there? Which should I pick? I don't even want to pick anymore I just want to get on with the job.
A pretty good experience: Rob Pike had an article a while ago about people complaining about a language without using it. I tried Go and that's why I like it. I also tried Dart with the Dart editor. Its nice, the libraries are good, the language is fluent and concise enough. Everything seems to be in the right place.
I think I know what you mean, though. It's nice to be able to pick a narrow target that covers most of your customers and code for that.
Web development today with JS/CoffeeScript + jQuery + Underscore and other libs is not hard. Just accept that different users will use different browsers.
If you wanted to write an application that performed with native speed would you rather write it multiple times for Windows, Linux and OSX, iOS* and Android (and make sure it compiles on multiple architectures) AND force your users to install and update the application on their computer...
OR
Write it once as a mixed Dart/Native Client app targeting the LLVM bytecode and run it securely in the Chrome browser on multiple platforms? All the user needs to do is install Chrome and visit a URL. Updating the app becomes trivial.
I am not saying it is the clear winner, but to me it sounds like a damn interesting alternative with a lot of promise.
It is also possible that Chrome will "win" - either by gaining such majority user-base that targeting specific features of Chrome becomes worth while, or because Dart+Native Client becomes a de facto standard the other browsers adopt.
Also, if you are writing a "web app" to target a niche market that really want to use the application (hard-core gamers?), requiring Chrome really may not be a big deal for the user-base. After all, if people are willing to install native applications on their local system, why would they be unwilling to install Chrome and visit a URL?
* It is unclear if the Chrome browser on iOS will ever be able to download and run native code for both technical and policy reasons.
Link: http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-a...
You might say that this is the point, but I have to ask why they didn't just fully commit to GWT instead. If the point is to attract Java developers, that seems like the more logical way to go.
Less than 1/3 through I decided to started to zone out. I don't understand why you need a VM to compile something into Javascript. Also the optional typed language feature is just odd (okay I can see working in groups and wanting to empirically let other developers what type a variable is), but it's just not something I see myself wanting to learn to do what I already know.
I was also interested in the Angular talk, which was good, but it left me thinking Angular is to CakePHP in the MV* javascript world with all the built-in automagic.
Overall some pretty good talks at this.
Even if _you_ don't put type annotations in your code, the IDE infers types (locally) and gives you useful warnings and code completion.
The language and the vm are a distraction. The huge win with dart is what the IDE will do for your productivity.