My observations: Installing dependencies was easy. Types help a lot. The IDE is good but sometimes can not show the correct type or just shows dynamic, the autocomplete is usable if you write `this.` . Usable for a modify-refresh cycle but the attached chromium seems to be a little buggy (on xubuntu the window is not correctly drawn). In-browser exceptions are a little cryptic to read. Very similar syntax to java/c#. Good stdlib (I tried async/browser/math). Little cumbersome calling JS but it works. Bult-in factory pattern, setters/getters.
I think they could let users create multiline functions with the => operator (currently only one line). :)
I tried to pub my code, but it did not work for some reasons. I haven't tried since then so I don't know what kind of js it generates.
In my line of work (web analytics), I have to use third-party JavaScript libraries in order to integrate tools onto my page, like Adobe Analytics (formerly Omniture SiteCatalyst) or IBM CoreMetrics or WebTrends. Fully instrumenting a page generally involves wiring up other JavaScript on the page with event handlers for web analytics functions (e.g. video play/pause/progress, with video name & length as parameters).
Most analytics tools are also moving towards asychronously-loaded script-injection techniques, like Adobe DTM or Ensighten. These usually include the ability to selectively load relevant libraries, like only having video tracking on video pages.
What's Dart's story for interacting with tools like that?
I'm not the best person to ask about JS interop, but I know it's something that other people on the team put a lot of effort into.
> I know that the Dart compiler is a whole-program optimizer, and I get the impression that Dart wants to own all the code on the page.
dart2js likes to have access to all of the Dart code while it's compiling, so it can do global optimization, but as far as I know, that doesn't affect JS interop. Talking to JS is all dynamically dispatched at runtime, so the compiler doesn't really care about it.
(We can also do deferred loading of Dart code now too, though I don't know the details.)
> What's Dart's story for interacting with tools like that?
Beyond the general JS interop story, I don't know if we've done anything specific there. I believe you should be able to talk to JS code even if it's loaded much later.
Great question. Generally dart:js will let you do interop: https://www.dartlang.org/articles/js-dart-interop/. It's designed to interact pretty well with the dart2js compiler. However it feels a lot like you're using a foreign function interface. For example, calling a the global method Object.keys is: js.context['Object'].callMethod('keys', [obj]);
For Custom Elements (one of the new web components specs) we did something better: you can register the Dart wrapper type associated with that element. Then whenever you get one of those elements, it automatically looks like the Dart type. We used this heavily in the new core_elements and paper_elements packages. Here's an example of defining a type like that: https://github.com/dart-lang/core-elements/blob/master/lib/c...
Ultimately we'd like to make something similar for all JavaScript objects and expose it from dart:js. That would make interop almost seamless (especially if we could generate the types from DefinitelyTyped's APIs).
1) Properly package and add "batteries" for a server side version of Dart. Pay some team to write a proper and complete Rails/Django or at least Flask level framework -- and document it.
2) Make a Google version of node.js using Dart instead of v8.
3) Even better, merge (1) and (2) for a serve side framework with both good syncrhonous (e.g Django like) and async (e.g Node like) story.
4) Support Dart as a first tier development language for Android.
1) Dart VM runs on the command line and server. You can access files, directories, sockets, HTTP, Web sockets, SSL, and more. So the core functionality is all there, out of the box.
2) When people say "node.js", they usually mean at least two different things. Forgive me if I'm assuming too much, but I'll try to answer. Node.js is "javascript + v8 + server", and the equivalent for Dart is "dart + dart vm + server". So we've delivered that. Sometimes, when people say "node.js", they mean "express + v8", and Dart has "shelf + dart vm". You can check out the shelf package here: https://pub.dartlang.org/packages/shelf
3) There are a few emerging server-side frameworks out there (I mentioned shelf above). Dart VM is asynchronous, so you'll get a Node-esque experience. There aren't plans to make a fully sync server API.
4) That would be cool!
I really like Dart. Google is pretty much the only company trying to break the tyranny of JS in browsers.
(e.g. Microsoft clearly said that they are betting on C# and .NET as their main offering for everything - would be nice if Google was capable of this sort of direct messages)
My experience with their TypeScript initiative has been really smooth, feels like they're trying to improve JS instead of inventing something new (by sticking as close as possible to the ES.next specs). The generated JS is very close to the original, both in size as readability.
Dart on Android?
Will the Dart IDE look correctly on Windows 8 high-dpi devices? (I know that's partially an Eclipse problem)
In fact, what is the future of Dart? Is it just a complement to browser-based JavaScript?
We're working on it! Having two language virtual machines with objects that can contain references to each other is quite technically challenging. There's a bunch of work to be done to address that[1]. Along the way, we're working with the larger Chrome team to address any other requirements they have.
> Dart on Android?
The Dart VM does run on Android right now [2]. My understanding is that the performance is impressive relative to Dalvik/ART, though don't quote me on that.
[1]: https://groups.google.com/a/chromium.org/forum/#!topic/blink... [2]: https://code.google.com/p/dart/wiki/Android
> Will the Dart IDE look correctly on Windows 8 high-dpi devices?
Aside from the splash screen, it looks nice and sharp on my retina Mac.
> In fact, what is the future of Dart? Is it just a complement to browser-based JavaScript?
We're working to make it a comprehensive web language, both client and server-side.
[1] More than https://code.google.com/p/dart/wiki/Android
> We are working out a proposal that is somewhat similar to async-await in C#. Again, we hope to finalize that in time for the next rev of the standard. Details as soon as coherent articles explaining it all can be put together.
I really want to use AngularDart for the front end of an application I am using and I would like to use Rails for the back end as well as some static content. I can't seem to find an easy way to make that happen. In addition, how does Dart interact with existing JavaScript libraries?
IMO integration is as straight-forward as it gets, basically just use a HTTP Client to call JSON services. Here's an AngularDart example for calling a REST backend: http://japhr.blogspot.com/2013/10/http-requests-in-angularda...
I've also created a JsonClient that provides a terse API for calling JSON services: https://github.com/dartist/json_client
Dart comes with a rich functional and Stream API's on collections so most of the time you wont need to extend it (same LINQ examples in Dart: https://github.com/dartist/101LinqSamples), but unfortunately you can't extend built-in (or external) types which means you need to use top-level methods which can break-up the flow of your beautiful expression flows. Extensions is also important for minimizing unnecessary abstraction and maximizing re-usability since you can extend without being forced to create foreign wrapper API's.
IMO Extensions are one of the most important traits for keeping a minimal friction-free language, something I see Go and Swift benefiting a lot from.
Dart does have powerful mixins (https://www.dartlang.org/articles/mixins/) but you can only mixin into classes you define (i.e. not built-in or external types).
But otherwise I find Dart's optional-typing a tonne more productive than Swift's strict type inference / generic enforcement, Dart also has a rich consistent library, integrated package manager, static analyzer and overall better development experience.
Although there's little overlap as Swift is mainly for creating iOS/OSX desktop apps and Dart is focused on rich Web Apps. Basically the only times when you'd be able to choose one or the other is in command-line scripts, I'd still prefer to use Dart for.
I'd like to Dart to happen. What worries my is that Dart has Java EE mentality. Hipster programmers won't touch it and lack of traction may kill the project. What's the solution? Performance may be a great USP. Rewrite Gmail in Dart, so tools like Streak, Rapportive and other extensions won't kill the performance.
We aren't planning it, we've already done it. Dart comes with a command-line VM with a full-featured (IO, networking, etc.) set of libraries[1].
The performance is quite good and getting better[2], from what I understand.
[1]: https://api.dartlang.org/apidocs/channels/stable/dartdoc-vie... [2]: https://www.dartlang.org/performance/io/
[disclaimer: I work on the Dart team.]
I/O performance increased drastically with 1.3. The performance is tracked over here:
https://www.dartlang.org/performance/io/
1.4 added experimental support for ServerSocket references, which allow you to share a socket across isolates (~"workers"):
https://groups.google.com/a/dartlang.org/forum/#!topic/misc/...
Redstone is becoming increasingly popular: http://luizmineo.github.io/redstone.dart/
Whilst I've built a simple Express-like API: https://github.com/dartist/express
Which also includes a complete port of node's popular jade view engine: https://github.com/dartist/jaded
I don't know many details here, though. The committee is still pretty new and the communication channels are still being set up.
1. One big issue with JavaScript applications is that they are single threaded. Does Dart/Web Component platform provide any solution to this?
2. Will we see another UI rendering layer other than DOM for Dart?
Because Dart compiles to JavaScript, we're limited in some ways in what we can do here. We do, of course, support Web Workers, but those have a bunch of constraints that make them difficult to use in practice.
We have tried to make single-threaded async programming more pleasant. In particular, Dart comes with built-in, very rich Future and Stream types. Even better, those are deeply integrated into the code libraries, including the DOM.
Every asynchronous DOM operation in Dart returns a future, which is much more pleasant to deal with than raw callbacks. Likewise, things like events are exposed as streams, so you can map and transform them like any other stream of data.
I gave a talk on Dart at Strange Loop last year[1] that talks a bit about this. Skip to around 38 minutes.
> 2. Will we see another UI rendering layer other than DOM for Dart?
Good question! There are a few different frameworks that people have built for Dart that expose their own ways of expressing UI. I think they all ultimately fall back to the DOM because that's the primitive the browser gives you, but what you as a programmer deal with may be fairly removed from that.
These days, I mostly do command-line Dart stuff, so I don't have a good lay of the land here.
If I'm using GWT, should I be thinking about using Dart instead?
Yes. We on the team, of course, use Dart heavily. My day job is working on pub, the package manager for Dart, and a slew of other libraries, all written in Dart. Our API[1] doc site is written in Dart.
Likewise, we have an increasing number of internal customers who give us the kind of feedback you only get from someone who isn't obligated to see your project succeed. :)
Obviously, a bunch of customers we can't talk about, but I can say that Google Elections and Google Fiber use Dart. Google has an internal sales tool also written using Dart and Angular.dart.
I'm biased, being on the Dart team, but I think Dart is a much nicer language that Java, so I would choose Dart for a new project. GWT might still be a good choice though if you have a large existing investment in Java that you can repurpose in the client. Many enterprises have hundreds of thousands or millions of lines of Java code that aren't going anywhere anytime soon.
So, should you think about Dart? I guess that depends on how ready or willing you are to migrate your code away form Java. If you were thinking about rewriting in JavaScript, then I'd definitely say consider Dart. If you're happy with Java and GWT, then you can keep going that direction.
The code-labs provide pretty good, practical walk-thru's: http://io2014codelabs.appspot.com/static/codelabs/dart-start...
Thank you.
I don't know the details, but I believe sanitize uses of innerHTML to avoid some common security vulnerabilities. More details here: https://groups.google.com/a/dartlang.org/forum/#!topic/misc/...
1.- It is better than JavaScript, is like using C# with a litle mix of Java.
2.- It comes with its own libraries, no more underscore.js or other patch libraries that JS needs, it is already in the toolkit.
3.- It comes with the Dart Editor, where you can debug your code easily, for scalable projects I find this to be invaluable.
4.- It will run in all your browsers, because it will export your code to JavaScript, but not only export it, it will optimize it and will run really fast.
5.- The pub library, go to pub.dartlang.org and you will find lots of packages that you can install and use, like a bootjack, a bootstrap port in Dart.
There are prolly many more, but these are the ones that come to my head right now.
But it also has its own problems like:
1.- No Dart support for Chrome yet and we don't know if there will ever be at this point.
2.- The generated JavaScript will be huge, and I mean huge, mine is like 460k per file and I'm not using polymer, when I used polymer the generated JavaScript was over one megabyte, just insane in the cloud.
3.- Get use to regressions, with every point update I've have issues, I upgraded from 1.4 to 1.5 two days ago, now my code is broken It runs, but it will for example run futures twice, So I went back to 1.4 for now, I had some other issues with UTF when migrating from 1.3 to 1.4 so, get use to.
4.- They are slow fixing bugs, looks like polymer and speed are their priorities, but when you need something trivial that other languajes have had for years and you report a bug it will get ignored, I've waited for 18 months and my open bugs are not fixed yet.
I would say that Dart is nice and you should give it a chance.
If you include all of your 'standard' libraries in a JS app, it can be pretty big. I basically pull everything together for an Ember app I work on, and all-told it's ~3MB prior to minification. Minification takes it down to ~1.5MB, and Gzip-compression on the server takes it sub-1MB (can't recall the number off-hand). It's not that far off from what you might have in a JS-heavy app.
[disclaimer: I work for the Dart team.]
[1] https://www.blossom.io/ [2] http://www.ramen.io/post/46936028144/we-are-switching-to-dar...
We're super happy with Dart & really excited about polymer. Love the language & platform in general.
We'll put out some essays, code snippets & lessons learned in the next few days :)
Stay tuned.
And how are you finding Dart to be verbose? In my experience it can be more concise than JS because of short lambdas, no function keyword, method cascades, real classes, the fluent Iterable and Stream interfaces.
On the other hand, I see some Dart programmers use a lot of classes and type all their variables. I'm curious what ended up being verbose for you.
Oilpan project: https://docs.google.com/presentation/d/1YtfurcyKFS0hxPOnC3U6...
You can track Darts's performance here: https://www.dartlang.org/performance/
That was never going to change. The idea, as far as I understand it, is for Dart to be executed natively where there is a Dart VM. Where there isn't, the dart2js output would be executed. The DOM itself would be unchanged. I think that's reasonable. In fact, more than reasonable, that's just a good idea.
And now they're putting Android inside ChromeOS, too, just because they don't want to admit Android itself would work better on notebooks (given the right interface) than ChromeOS.
But it will apply to those using Chrome (their performance benchmarks show consistent improvement, sometimes up to 2x) and it will be using a better language for all the other ones.
It will be still about as fast as regular JavaScript.
Personally, I wouldn't worry too much about JavaScript frameworks evolving rapidly, just go with anything the supports Web Components. In JavaScript that would be Polymer, X-Tags or Bosonic. In Dart that's Polymer. Or, in either you can write directly to the platform APIs without a library.
In my mind there is BWC and AWC: Before Web Components and After Web Components. The world or web apps is undergoing a paradigm shift on par with AJAX right now, and I wouldn't use any framework that doesn't support Web Components.
Dart is Google's me-too attempt at creating something which compiles to JavaScript. It borrows heavily from java and generates equally bloated code.
OK, so maybe last sentence is a bit over the top critical, but last I checked, hello world in dart rendered in at 100kb [1] of js and dependencies.
[1] http://lostechies.com/jimmybogard/2011/10/12/the-dart-hello-...
Dart 1.5.1 produces nowhere near that much for the same input, producing just 14KB (see [1]). Yes, arguably still too verbose, but note that much of the overhead is essentially a Dart-compatibility support library, so remains constant as the amount of Dart increases.
I decided to try such an experiment with GWT recently, since the same kind of unfair microbenchmark has been used against it.
I detail how I reduced the hello world from 2205 bytes to 710 bytes here: Th3e Hello World Challenge https://plus.google.com/+RayCromwell/posts/VK8URgZiLbS
What how did I do it? By not registering any global exception handlers, or any async tasks, and arranging for the compiler to be able to optimize away the unused runtime stuff.
But how likely is it that no one wants to catch exceptions and print pretty stack traces? Or to schedule microtasks to run at the end of the event loop?
It's not a realistic test.
I don't mind Java, but I don't see how a) being compared to Java is a negative given the alternative is JavaScript (which as a language is terrible) and b) how Dart borrows heavily from Java.
Re b), there are enough differences between the two (e.g. dart has optional static typing, mixins and js-type closures, and is single-threaded and interpreted) that the similarities are completely superficial.
[disclaimer: I work for the Dart team, and I'm a coauthor of that book.]
CoffeeScript says that the main problems with JS are the inelegant C-style syntax and a few semantic trip wires. It addresses those while still keeping the underlying semantics, APIs and ecosystem.
If what drives you up the wall about JS is stuff like the DOM, or JS's object model, CoffeeScript won't help you much. If you are OK with how JS behaves and like the very large JS ecosystem, CoffeeScript can be a nice fit.
Dart takes a much larger semantic step away from JS. Syntactically, it's more similar to JS than CoffeeScript is. It sticks with braces and statements, and the whole C kit and kaboodle.
However, semantically, it's much different. It has a full-featured class system with inheritance, mixins, getters, setters, operator overloading, etc. It has a static type system so you get the nice tooling experience you expect from a language like Java or C#. It also completely revamps the DOM APIs to (hopefully) be more rational, modern and consistent.
The cost, though, is that interacting with the existing JavaScript world is a little more difficult. You can interop, of course, but it isn't as seamless as CoffeeScript.
Plus, they seem to want to use web tech to build native desktop tools all the time and little things like "keyboard acceleration" don't seem to matter to them because there are no standards for that in web-world.
Even the #1 feature for VS.NET is to continue developing very popular XNA framework: http://visualstudio.uservoice.com/forums/121579-visual-studi...
Likewise on the server side there's been history of deprecated frameworks a lot of developers have invested a lot of energy into learning, e.g: .asmx, CSF, WCF, WCF/REST, WSE, WCF DataServices, RIA
Whilst VisualStudio is a great IDE, I find it a subpar experience without R#. The major advantages Dart has over C# is that it still provides an enjoyable experience to develop even without an IDE which also includes support for the most popular text editors: https://www.dartlang.org/tools/ If you like IDE and tooling support, the DartEditor offers a good experience with built-in analyzer, debugging and refactoring support you can expect from a well engineered language.
By contrast, C#'s configuration model, msbuild project format, heavy frameworks and tooling makes it unfeasible to develop without an IDE.
The other major advantage Dart has is that it compiles down to JS where even the compiler is completely self-hosting and runs inside a browser without plugins: http://try.dartlang.org/ Being able to share the same code on client and server and having a single integrated development full-stack experience is a huge win in re-usability and utility.
Another killer feature is that the language and tooling is cross-platform which supports Windows, OSX and Linux. Something .NET devs often miss out on is the value and utility of being able to host apps on cost-effective Linux servers.
Google continues to invest a tonne of resources in Dart and Polymer which are massive undertakings that are providing a much simplified and consistent experience for developing large, complex web apps. Nothing like Dart or Polymer exists. Dart is a platform that transpiles to JS, includes a native Dart VM, an entire toolchain including IDE, analyzer and debugger both in Dart Editor as well as in Chrome, in both the Dart VM as well as debugging with Source maps.
The worlds best VM engineers work on the Dart VM, i.e. the same pedigree responsible for the StrongTalk VM that was later acquired by Sun to form the basis of the world-class Java Hotspot VM that later went on to develop V8, are now leading the development on the Dart VM.
The excellence shows itself in the consistency and minimalism goals in the language, providing a productive, iterative dynamic language experience for fast prototyping with the benefit of static analysis with optional typing when scaling up to a maintainable, well-documented code-base (best of both worlds).
Not only is Dart a productive dynamic language, it also has excellent performance, the best performance of all languages I benchmarked with a port of Peter Norvig's Sudoku solver: https://github.com/dartist/sudoku_solver#benchmarks
> Not sure what you mean: MS has a history of abandoning its developer platforms and frameworks that thier developers have invested in, so much so that there's no longer a clear UI story for building native desktop windows apps, i.e. VB6, Silverlight, WinForms and WPF are all effectively deprecated.
WPF is still chugging a long strongly even if there aren't so many new features. Visual Studio was recently rewritten in it, and its a very good design with lots of room for encoding desktop apps in the future. I use it daily and cringe at the thought of ever doing something for the web without it.
> Whilst VisualStudio is a great IDE, I find it a subpar experience without R#.
I use visual studio just fine without R#. I see no point these days writing code without an IDE, I'm addicted to code completion. Not to mention amazing things are being done with Roslyn.
> By contrast, C#'s configuration model, msbuild project format, heavy frameworks and tooling makes it unfeasible to develop without an IDE.
C# is totally usable from the command line, most developers just refer the IDE.
> he worlds best VM engineers work on the Dart VM, i.e. the same pedigree responsible for the StrongTalk VM that was later acquired by Sun to form the basis of the world-class Java Hotspot VM that later went on to develop V8, are now leading the development on the Dart VM.
The CLR is one of the best VMs ever (read: very fast), worked on by some of the brightest who are very comparable to the Animorphic crowd. The DLR feature (ability to generate/compile expression trees at run-time) is also very cool and missing from the JVM. If you are into building language run-times, it is an awesome base for a dynamic language.
True: it is only available on Windows, but Mono has made progress as well (most features available sans WPF). I've been thinking about porting my language work [1] over to mono.cairo to see if I can achieve cross platform without going to Java or the web.
[1] http://research.microsoft.com/en-us/people/smcdirm/liveprogr...
"Deprecated" is just a word that means absolutely nothing here since all of those kits are still fully functional on current versions of Windows (including XNA and the server side stuff that you mentioned). And VB6 is 20 years old! You wanna make a bet that your Android, Dart or Go code will run in 20 years? Android code from 2008 won't even run today mate :) Also, when Google deprecates something - it's usually hooked to a service, so there's no hope to keep using it when it's no longer fashionable (like some are doing with VB6, Foxpro and other really old kits).
> Whilst VisualStudio is a great IDE, I find it a subpar experience without R#.
And I find the lack of a single IDE built and maintained by Google to be sub-subpar. Visual Studio is superb without R#, but even if you don't think so - at least Microsoft is making life easy by offering an IDE that is tuned specifically for the task at hand instead of using some open source pile of junk that tries to do everything. There's nothing to decide when I need to do .NET - I know what tools to use. Meanwhile Google has no comprehensive strategy here and you're forced to cobble together your own toolkit. Blech.
> Another killer feature is that the language and tooling is cross-platform which supports Windows, OSX and Linux.
That's a weakness because "cross-platform" means a crappy non-native Java UI or some half-functional impostor built with HTML - and those tools suck on every platform. No thanks, I like things that are native to my platform please. Besides that, I can certainly do all of my coding on Windows and build and run it on Linux without any problem thanks (because I have been).
I don't really want to spend my time responding to another wall of text or the rest of this one so I'm going to end it here. I will say that Google does some cool stuff in the browser and with Android, but my main point here is that they don't put forth a very comprehensive strategy at all. Most of their developer stuff seems to be created by 20 percenters in their spare time instead of making a concerted effort like Microsoft does.
