Proper OOP and type checking. Fighting to finally make the web open. Open to new languages, technologies and innovation. All we have now is legacy stuff like JS and HTML. I hope NaCl will also start dominating at some point. Freedom of choice of tools is important.
If Google had done this right with the other vendors, it would have been the second coming of Smalltalk in a way. As the developer experience is somehow similar.
As it is, it is just another language that transpiles to JavaScript.
And now I have to support (and debug) two languages only because on a single browser one can perform slightly better, while the rest of the resources and frameworks for web clients are all written in javascript. No thanks
Why would you be supporting two languages? You can choose to write your app in JavaScript (that's not going away and that's one language) or you can choose to write your app in Dart (also just one language) which will run as Dart on the Dart VM and compiled-you-don't-touch-it JavaScript everywhere else. Sounds like FUD to me.
Because if I choose dart I have still to deal with the derived javascript code implementation I must use to run in other browser that are not chrome and, as described by the post close to this, often that js is so broken it cause big bugs on firefox for example, and to understand and repair those you have to know js.
I would take what kevingadd says with a grain of salt. He's the author of a .NET -> JS compiler (arguably a competitor to Dart) and the experience he cites below is pretty different from what I've had and my colleagues have had. I don't mean that as character assassination - he's obviously a very talented developer - but rather as a point of contrast.
Frankly, you would not want to be touching the compiled JavaScript from Dart - it's not meant to be changed. I agree that if it's that broken, then you should certainly not use the platform. So you should just be writing in JavaScript or just be writing in Dart.
Dart is presently broken by design for web browsers in general, because they have to ship a set of type mapping tables that contains names & information specific to individual browser versions. In the past, new releases of Firefox have broken it and those errors had to be pointed out to the dev team for a later fix.
Ideally in the future the Dart team will be more on top of things, but you will still have to recompile your Dart applications every time a new browser comes out. Many developers will probably not remember to do this - if they're maintaining their apps at all.
Dart2js is also an afterthought (in general) compared to the mainline dart vm, so it will be possible (if not common) for dart applications to end up only being compatible with Chrome's implementation. One of the main issues I'm aware of in this area is that integers larger than 53-bit will silently fail to work correctly, while native Dart will handle them.
There's not just one killer feature. Here's a few strong features that add up:
- optional static type annotations
- advanced object-oriented features (mixins, advanced constructors, etc)
- rich built-in libraries
- pub package manager
- 2X V8 performance w/ the Dart VM
- integrated tooling
- exceptions
- generics
- operator overloading...
I could go on, but basically I'm not sure what language you were looking at because Dart has a lot that plain vanilla JavaScript does not (although can have with extensions). It also doesn't inherit all of those flaws JavaScript got from being designed in a time crunch (10 days is really not enough time to design a language).
If I had to pick one though, it would probably be the fact that Dart is a platform (rich language, libraries, tools, and package manager) rather than hodge podge of frameworks on top of a lightweight language.
If it compiles down to javascript then it does have the same flaws as javascript. 2x performance of v8 is bullshit, and "rich built-in libraries" and "integrated tooling" are just marketing drabble. If you understand what they actually mean please explain or gtfo.
Performance - Dart has its own VM which runs independently (on the server, or in special builds of Chrome, but soon to be mainline Chrome). So it's not just a language that trans-compiles to JavaScript, it's also a language with its own independent high performance VM that you can use on the server today and the browser tomorrow (hopefully). By the way the Dart VM was written by the same guys that created V8 - generally considered to be one of the highest performance JavaScript VMs - so I think we can believe them when they say it's higher performing.
Rich Built-in Libraries - Just take a look here: https://api.dartlang.org/
There's everything from a reflections API to a WebGL library. There's JavaScript interop libraries, concurrency libraries, and the equivalent of jQuery built-in. That's just scratching the surface.
Integrated Tooling - Dart has its own package manager (pub) which is quite nice as well as its own IDE (Dart Editor) which comes with a debugger, profiler, and all the niceties you'd expect (code completion, deployment help, etc).
It's also a new language (less than a year since 1.0) backed by a big company so these things are only going to continue to improve.
The wider adoption of Dart is a pipe dream, and the fact that it will remain confined to Chrome is a very good thing. The web community should reject this, or we'll soon have only one browser and one true master of the internet.
- No other browser can practically implement or support Dart. If they do their implementation will be slower than Google's, and will get classified as inferior. Google has in abundance the time and money to build and fix bugs, which Mozilla and Opera may not have in the near future.
- Google's engineering could have gotten JS much farther along, but from what I have read on Twitter the V8 team has been shuffled around and the focus of innovation on Chrome is Dart.
There is no other way this would be played out, and the plan from the outset must have been to push Dart forcefully using Google's distribution capability on the web and on devices. I am waiting for Servo to launch to become a full-time Mozilla cheerleader again, once again after Internet Explorer's heydays.
I'm not sure exactly what I said that you're replying to (or if you're just replying to my Dart boosterism more generally) but what you seem to be addressing are political issues (who controls the Web, where resources are allocated) and not technical issues. Considering that Dart is open source, standardized by the same international body as JavaScript (ECMA), and compiles to JavaScript I think the argument against it would be weightier if it was made on technical merits.
But I agree that it would be dangerous for one company to control the web - but like you said it's a pipe dream that Dart will gain wider adoption - so why worry yourself by writing all that about it? You can't say it will never gain wider adoption and then also be worried about it gaining wider adoption at the same time. So either it has merit and will gain adoption and we should be worried about it, or it doesn't have merit and there's nothing to worry about.
This is an incorrect. Dart2JS is an implementation of the Dart specification that transpiles to JS and is supported by every modern browser. Dart also has great support for Source Maps letting you debug (JS Transpiled) Dart code in other browsers via source maps.
The Dart team expect Dart2JS will be the primary way of running Dart which is why they've designed the language so that it transpiles well to JavaScript as a primary objective - i.e. they've often rejected language features which can't be implemented efficiently in JS (e.g. non-local returns).
It's also not clear if Opera (by virtue of Blink) will adopt Dart once it lands into Chromium/Blink.
> Google can push Dart the same way MS did with ActiveX
ActiveX is a proprietary binary blob that has nothing in common with Dart. Dart is entirely Open Source, runs on all modern browsers and integrates cleanly with the DOM (i.e. like JS).
> C# is an ECMA standard too; how well did Mono fare in the early days and even now after more than ten years?
Only the language is a standard which Mono's compiler and runtime has excellent support for. The biggest problem Mono faces is that they've had to re-implement the massive .NET Framework class libraries themselves. This is not an issue with Dart because they entire platform (VM, Class Libraries, Tools, Analyzer, etc) is Open Source, so the same implementation can be used everywhere as-is.
This is exactly where it becomes an issue. You get to a situation where apps running on Chrome are faster, and the other browsers are slower. Why would anyone run a slower JS implementation of an app, when Chrome gives them wings?
> Google can push Dart the same way MS did with ActiveX
A large body of source code isn't as adoptable as you imagine. You need the people who are embedded in the evolution of the platform, or you are always going to lag.
> Only the language is a standard which Mono's compiler and runtime has excellent support for.
Not true. As an example, for a long time Mono's GC was much slower than .Net's.
The lessons from the 90s and early 2000's were very clear. We need to learn from them.
> This is exactly where it becomes an issue. You get to a situation where apps running on Chrome are faster, and the other browsers are slower.
So? JavaScript apps already run faster with in Browsers with faster JS VMs or for different users on faster hardware and different devices e.g. Smart Phones vs iPads vs TVs vs Desktops. Safari in iOS had a much faster JS implementation than Android or even the WebView in iOS apps, this doesn't make slower devices useless or stop users from viewing websites in different apps than Safari or even stop other browser vendors from developing alternative browsers for iOS.
Having a faster implementation doesn't make every other device or browser useless.
> Why would anyone run a slower JS implementation of an app, when Chrome gives them wings?
Why should the web be shackled to the limitations of JavaScript? This same reasoning could apply when V8 was first released which was 100x faster than other JS engines at the time. This just made every browser vendor care deeply and invest more in JavaScript performance. This is the same as impl-driven defacto standards like Canvas and WebGL, new experiences open up more categories and encourage other vendors to follow suit - A rising tide lifts all boats.
The core Dart Team is driven by trying to improve the web as best they can, just as they've done with V8 they want all their work to be freely used and used to encourage new innovations on the web.
> A large body of source code isn't as adoptable as you imagine. You need the people who are embedded in the evolution of the platform, or you are always going to lag.
Not true. A valid implementation of a language spec precisely means that source code in that language can be run on any implementation, just like existing Java code could run on Android's Dalvik and ART VMs. When a language has a specification it makes it easier to create different implementations (http://en.wikipedia.org/wiki/List_of_Java_virtual_machines). It's also possible when a language doesn't have a specification as seen with Ruby VMs (https://github.com/cogitator/ruby-implementations/wiki/List-...) but it's much easier to implement when there's an unambiguous spec to follow.
Also because Dart (like V8_ is both open source and embeddable, no-one needs to reimplement it, they can embed it as-is or port it.
> You need the people who are embedded in the evolution of the platform, or you are always going to lag.
The developers of Node, didn't have to work on V8 team to embed V8, neither does anything else that embeds, compiles or ports V8.
> Not true. As an example, for a long time Mono's GC was much slower than .Net's.
You're contradicting yourself and disproving your own point. A GC is not in the language specification, it's an implementation detail which the Mono team had to re-implement themselves precisely because it wasn't Open Source.
None of this applies with the Dart platform or team whom are developing a truly open platform and embeddable VM who are actively encouraging other users and vendors to adopt.
> The lessons from the 90s and early 2000's were very clear. We need to learn from them.
It seems at least they're not as clear to you - none of your comparisons are valid, nor have you cited the ones that were.
Stop making up stuff. I never said GC is in the language specification; instead was responding _specifically_ to your own statement about C# being supported well by the Mono runtime. I assumed it was fairly obvious what I stated: for C# to work you need the runtime (with the GC) and the Mono implementation while being good enough, lagged Microsoft's for a long time. Still does probably by a bit.
In short, I don't believe we need a single Dart VM any more than we need a single HTML rendering engine. I don't believe Mozilla (and others) have to depend on Google engineers for anything in their product, even if it is Open Source. I don't believe a single company should go about extending the web by leveraging market dominance; like Google is doing right now.
Our positions are very clear here, and we disagree. That's fine.
> Stop making up stuff. I never said GC is in the language specification; instead was responding _specifically_ to your own statement about C# being supported well by the Mono runtime.
Sorry you've got it backwards, you're the one who introduced the .NET Framework vs Mono and their differing GC implementations as a valid comparisons for Dart (which they're not):
> C# is an ECMA standard too; how well did Mono fare in the early days and even now after more than ten years?
I've just corrected you in both cases that the Mono compiler has excellent support for the (C#) language specification which it does, valid C# both compiles with the Mono C# compiler and runs on the Mono VM fine. The language specification was what made this possible. The issues that you cite in the early days have no basis for comparison with Dart, which are instead side-effects from re-implementing a closed implementation like ActiveX (another incorrect comparison) should anyone else had chosen to re-implement it.
The fact is the Dart platform couldn't be any more open than it is already: it's completely open source, has a language specification, has multiple compliant open source implementations (Dart VM + Dart2JS), has open patent grants, develops in the open, accepts external contributions, features are prioritized and driven by user feedback, encourages re-use and adoption.
The Mono team were instead forced to create the VM and compiler from scratch and had to re-implement and reverse-engineer .NET's vast class libraries and API's (which don't have specs), precisely because they're not able to re-use the existing implementation. The Mono team are actually very happy whenever Microsoft releases some of their .NET libraries as Open source which they've been able to re-use as-is. Thus none of the issues you've brought up applies to Dart which is entirely Open Source that both supports and encourages embedding and re-use.
Instead of Mono and ActiveX, the JVM and open source OpenJDK implementation or examples of embedding V8 like node would've been better comparisons.
> Our positions are very clear here, and we disagree. That's fine.
Whilst I disagree with your invalid comparisons, I'm ok with the rest of your comments in which you're only stating your opinions and beliefs. In contrast, I believe innovations like Dart are going to help move the web forward and enable richer experiences and already improves the development of large web apps .
This bug has bitten users of modern browsers more than once. They were probably too modern and Dart uses the Blink codebase for its interface to JavaScript.
So in reality even dart2js can only safely be used together with Google Chrome.
> No other browser can practically implement or support Dart.
They don't have to, they can use the Open Source DartVM as-is, in-fact this is what Google encourages, just like how node was able to use V8 JavaScript engine - which they've said is an example of new use cases that's possible when you create a high-performance VM.
> Google's engineering could have gotten JS much farther along
Lars Bak and Kasper Lund on the Dart VM are the same guys on the V8 team, who were also on the world-leading JVM Hotspot compiler that was derived from the Strongtalk VM (the fastest implementation of Smalltalk) that they created. They believe performance of JavaScript is reaching its peak and is unlikely to see another 2x improvement, JS VM's are also extremely complex as JavaScript is extremely hard to optimize.
By contrast Dart is a much simpler and predictable language designed for both productivity and performance and because it was designed in-hand with the VM engineers, language features are designed in a way that performs well.
Based on that description, Dart sounds like Google's version of Adobe Flex.
I suspect that experience has shied people away from the idea of relying on a single-vendor platform for web apps. We tried "rich Internet applications" and they weren't a lasting solution; both Adobe and Microsoft gave up on their efforts.
Google's solution has a plain-JS fallback which Flex and Silverlight couldn't do, but otherwise the Dart world view seems similar: one vendor, one monolithic platform, one preferred runtime.
That seems the general skeptic's analysis - and it has some validity - but let me point out a few things that make Dart seem a bit more open:
- It compiles to JS (you mentioned this)
- It is standardized by ECMA
- The entire platform (VM, compiler, libraries, IDE, etc) is open source
I guess how you feel about Dart may depend on how you feel about Google and big corporations more generally. Just because a big company that has a lot of mindshare/marketshare creates a great platform, does that necessarily mean we should be afraid of it? Maybe, but if you're frustrated by JavaScript, it's certainly worth a look.
Except for the JS transpiler, Microsoft Silverlight could make similar claims: the CLI runtime is standardized by ECMA, and the entire source code for the .NET Framework is available. (Granted, not the Visual Studio IDE.)
For these kinds of platforms, post facto standardization efforts and code releases are part of marketing, IMHO. Dart remains a Google-lead project tied to Google's goals rather than an actual open platform.
> Dart remains a Google-lead project tied to Google's goals rather than an actual open platform.
Right, I agree with you. I guess you didn't read my whole post. To quote myself from just above: "I guess how you feel about Dart may depend on how you feel about Google and big corporations more generally. Just because a big company that has a lot of mindshare/marketshare creates a great platform, does that necessarily mean we should be afraid of it? Maybe, but if you're frustrated by JavaScript, it's certainly worth a look."
> the entire source code for the .NET Framework is available.
Which means nothing as no-one else is legally allowed to use it. It's only "Source Open" (not "Open Source") so no-one is legally allowed to adopt, adapt, enhance, etc as can be done with true Open Source projects.
It's tool support and unsurprising semantics. Few other web frontend languages have that.
TypeScript comes close with the tool support, but it doesn't have the unsurprising semantics, and all in all it's a lot more limited, because it's designed to be a near-superset of JavaScript.
I'd be using Dart already if it was simpler to integrate with existing JS libraries. That's the part TypeScript got way better.
Tool support must be one of the most underrated language features these days. The enormity of blog posts about desiging your ruby code for "greppability" is just scary - I just want my tool to generate a call hierarchy for me, thank you. Dart has this covered.
Semantically, Dart is pretty much Smalltalk, so it's actually a useful, reasonably well-thought-out language with sane semantics. A bit of a shame about the syntax...
It even has doesNotUnderstand:, so it's quite extensible.
The optional typing is neat: you can have a type error and the program won't just compile, it will continue to run! There's a video of Gilad demonstrating this in a live coding environment: he changes the type of a variable that's a number to String and apart from the compiler now complaining, nothing changes.
The isolates concept also seems well-thought out, with separate heaps and the only interaction via messaging. Nothing breathtakingly new, but I think they picked up the right thing and implemented it well.
The fact that the semantics are sane means the compiler can create faster code than JS with fewer heroics (if it isn't compiled via JS).
I evaluated it. Didn't work in Firefox 31 Beta. Reported the bug. Was fixed in Dart around the time when Firefox 32 RC got released.
Please remember to recompile all your apps you deployed with Dart < 1.6. There are still some Firefox users out there. (Majority in Germany uses Firefox.)
Way before 1.0 existed (and using an early version of Polymer called WebUI) we built a first version of our app, e.g. http://woven.co/miamitech, which is a fairly complex client and server side application. (The slowness is due to our poor pgsql data design.) I'm now building a more focused version with the latest SDK and Polymer, the beginnings of which are at http://mycommunity.org. For me it's simple: Google is arguably the greatest champion of the open web and probably does more to advance modern web development than most anyone else. V8 was a game changer, and enabled Node. The same folks behind V8 are building, in essence, a better Node. Modern web development with JavaScript is exciting, and there are so many great libraries and resources out there, but there is also much to be desired such as more structure, a saner language and a strong suite of core libraries that play well together. In my experience, Dart is what they say it is: a more structured approach to modern web app development.
this talk didn't talk about server-side dart. does this mean the project is refocusing on client code ?
also another question : does anyone here using angulardart can talk about how much static type anotation helps ? i'm thinking of future<t> instead of $q and directive writing ( which i always found a bit confusing, so maybe types help).
In regards to your question about server-side Dart, it seems that the space is just beginning to mature. A couple frameworks have solidified a fan base such as:
I am mostly a Java developer. I guess I could write syntactically correct JavaScript but it's a bit alien to me. As is the whole tooling landscape of JavaScript (Grunt, Node, Angular, Backbone, etc.).
I'd like to do a few personal projects with server-side scripting and I need to learn a new language and ecosystem for it. From what I've seen I'd rather learn Dart because it is more familiar to me. What's been stopping me from doing that is missing integration and/or documentation in asset compilation toolchains for example in Play (i.e. no sbt-web plugin).
Dart is often found to be very familiar by Java developers. In fact, on the mailing list, it is sometimes criticized for being too Java like. Java developers who feel disaffected by JavaScript are certainly a large niche that Dart appeals to.
You might try Adobe's editor, Brackets. It does a very good job at psudeo-intellisense, can even infer argument types, and has lots of nice plugins for working with JavaScript - including features that let you see the body of a function under the cursor, or the JSDoc (the equiv of JavaDoc). There is a JSHint plugin (linting is the closest JS gets to compilation). And of course the Theseus debugger, which is quite good. I think its neat that the editor is built on browser tech (Github's Atom is built like that, too).
Client side development is, ironically, somewhat more complex because of the lack of module standard. You'll almost certainly want to use require() in the browser, but that won't work without taking extra, confusing steps. 'Browserify' pre-processes your JavaScript, generating a single large bundle, but that introduces complexity both at build- and run-time. And that doesn't even address the ongoing saga of the lack of a module standard for the browser.
By contrast, writing simple programs or servers in Node is vastly more enjoyable than in Java.
I wish they'd invest in Go for the frontend. If a project like GopherJS can get as far [1] as it is now with just 1 person working on it for a few months, imagine if it had more support. And then you could use a language as nice as Go for both frontend and backend.
Yes, I totally echo this sentiment - Javascript has the traction and the stability to be a good transpiler target. That Google is actively trying to push both Dart and Go simply makes no sense for me, especially since Dart is supposedly (as far as I can tell with half a degree in googling) aimed at frontend work more-so than Go but at the same time seems to come with even more complex language structure than Go..
I actually see the Google-backed web technologies as a net negative. The general pattern is that 1) the community starts to develop good tools that work well in all browsers 2) Google comes along with a technologically inferior solution that they developed in-house. They present it as being ostensibly completely free and open source, but it is designed in a way that means it will be faster in Chrome and hard for other browsers to support as well due to different architectural decisions. 3) Google markets the solution well through its large and well connected employee and fan base, and so the Google technology gets much more adoption than the earlier and technically better alternative. Presumably they do all this in an attempt to make the web unusable through any browser except Chrome, so they can over the long term replace the open web with the 'Google web' that they control.
For example, compare Ember and Angular; Ember's architecture records the dependencies between values, and only updates what needs to be updated when an upstream dependency changes, while Angular has to recompute everything on every 'digest' cycle. When it comes to writing directives in a complex Angular application, you often to set a numerical priority field to the just the right number to get things to happen in proper order - leading to spaghetti code that is hard to reason about and fragile to extend.
I think Dart is even worse when compared to better emerging options like ghcjs (which compiles Haskell to JavaScript) and Elm; these alternatives have more powerful type systems that make common patterns like reactive programming and generic programming much easier and safer. Control structures that are built into Dart (e.g. the 'async' feature) can be treated as just one instance of a general type class (e.g. Monad) with ghcjs.
I think everything considered, these highly promoted and usually highly adopted but technically inferior Google front-end technologies are actually a net negative for the web.
I agree that ember is better than angular but there is no reason why angular should run faster in chrome so it is not really relevant to your first point. In fact apart from Dart I can't think of any web technology that Google is promoting to developers that will be faster in chrome.
This to me feels a lot like GWT: making it easier for Java developers to write client side code.
It was marketed as faster, however in reality it's slower on everything except a special build of Chrome.
It supposed to make us more productive, however all it does is that it makes churning out code easier at the expense of debugging. Sourcemaps are here to solve these issues, however since Dart is not a purely transpiled language, I don't really see that working out.
In my opinion Dart is an excellent research project, but it ultimately fails at fixing anything that makes client side web development hard.
60 comments
[ 4.2 ms ] story [ 116 ms ] threadAs it is, it is just another language that transpiles to JavaScript.
The advantage is that (1) on Chrome, you get better performance, and (2) you get a nicer language that Javascript.
Frankly, you would not want to be touching the compiled JavaScript from Dart - it's not meant to be changed. I agree that if it's that broken, then you should certainly not use the platform. So you should just be writing in JavaScript or just be writing in Dart.
Ideally in the future the Dart team will be more on top of things, but you will still have to recompile your Dart applications every time a new browser comes out. Many developers will probably not remember to do this - if they're maintaining their apps at all.
Dart2js is also an afterthought (in general) compared to the mainline dart vm, so it will be possible (if not common) for dart applications to end up only being compatible with Chrome's implementation. One of the main issues I'm aware of in this area is that integers larger than 53-bit will silently fail to work correctly, while native Dart will handle them.
- optional static type annotations
- advanced object-oriented features (mixins, advanced constructors, etc)
- rich built-in libraries
- pub package manager
- 2X V8 performance w/ the Dart VM
- integrated tooling
- exceptions
- generics
- operator overloading...
I could go on, but basically I'm not sure what language you were looking at because Dart has a lot that plain vanilla JavaScript does not (although can have with extensions). It also doesn't inherit all of those flaws JavaScript got from being designed in a time crunch (10 days is really not enough time to design a language).
If I had to pick one though, it would probably be the fact that Dart is a platform (rich language, libraries, tools, and package manager) rather than hodge podge of frameworks on top of a lightweight language.
Performance - Dart has its own VM which runs independently (on the server, or in special builds of Chrome, but soon to be mainline Chrome). So it's not just a language that trans-compiles to JavaScript, it's also a language with its own independent high performance VM that you can use on the server today and the browser tomorrow (hopefully). By the way the Dart VM was written by the same guys that created V8 - generally considered to be one of the highest performance JavaScript VMs - so I think we can believe them when they say it's higher performing.
Rich Built-in Libraries - Just take a look here: https://api.dartlang.org/ There's everything from a reflections API to a WebGL library. There's JavaScript interop libraries, concurrency libraries, and the equivalent of jQuery built-in. That's just scratching the surface.
Integrated Tooling - Dart has its own package manager (pub) which is quite nice as well as its own IDE (Dart Editor) which comes with a debugger, profiler, and all the niceties you'd expect (code completion, deployment help, etc).
It's also a new language (less than a year since 1.0) backed by a big company so these things are only going to continue to improve.
- No other browser can practically implement or support Dart. If they do their implementation will be slower than Google's, and will get classified as inferior. Google has in abundance the time and money to build and fix bugs, which Mozilla and Opera may not have in the near future.
- Google's engineering could have gotten JS much farther along, but from what I have read on Twitter the V8 team has been shuffled around and the focus of innovation on Chrome is Dart.
- See how Chrome trails Firefox in ES6 here: http://kangax.github.io/compat-table/es6/ (Thankfully, arrow functions are landing soon).
There is no other way this would be played out, and the plan from the outset must have been to push Dart forcefully using Google's distribution capability on the web and on devices. I am waiting for Servo to launch to become a full-time Mozilla cheerleader again, once again after Internet Explorer's heydays.
But I agree that it would be dangerous for one company to control the web - but like you said it's a pipe dream that Dart will gain wider adoption - so why worry yourself by writing all that about it? You can't say it will never gain wider adoption and then also be worried about it gaining wider adoption at the same time. So either it has merit and will gain adoption and we should be worried about it, or it doesn't have merit and there's nothing to worry about.
- Google can push Dart the same way MS did with ActiveX
- C# is an ECMA standard too; how well did Mono fare in the early days and even now after more than ten years?
- The relegation of JS innovation to second place behind Dart is a cause of concern. HTML and JS are the basic foundations of our web.
This is an incorrect. Dart2JS is an implementation of the Dart specification that transpiles to JS and is supported by every modern browser. Dart also has great support for Source Maps letting you debug (JS Transpiled) Dart code in other browsers via source maps.
The Dart team expect Dart2JS will be the primary way of running Dart which is why they've designed the language so that it transpiles well to JavaScript as a primary objective - i.e. they've often rejected language features which can't be implemented efficiently in JS (e.g. non-local returns).
It's also not clear if Opera (by virtue of Blink) will adopt Dart once it lands into Chromium/Blink.
> Google can push Dart the same way MS did with ActiveX
ActiveX is a proprietary binary blob that has nothing in common with Dart. Dart is entirely Open Source, runs on all modern browsers and integrates cleanly with the DOM (i.e. like JS).
> C# is an ECMA standard too; how well did Mono fare in the early days and even now after more than ten years?
Only the language is a standard which Mono's compiler and runtime has excellent support for. The biggest problem Mono faces is that they've had to re-implement the massive .NET Framework class libraries themselves. This is not an issue with Dart because they entire platform (VM, Class Libraries, Tools, Analyzer, etc) is Open Source, so the same implementation can be used everywhere as-is.
This is exactly where it becomes an issue. You get to a situation where apps running on Chrome are faster, and the other browsers are slower. Why would anyone run a slower JS implementation of an app, when Chrome gives them wings?
> Google can push Dart the same way MS did with ActiveX
A large body of source code isn't as adoptable as you imagine. You need the people who are embedded in the evolution of the platform, or you are always going to lag.
> Only the language is a standard which Mono's compiler and runtime has excellent support for.
Not true. As an example, for a long time Mono's GC was much slower than .Net's.
The lessons from the 90s and early 2000's were very clear. We need to learn from them.
So? JavaScript apps already run faster with in Browsers with faster JS VMs or for different users on faster hardware and different devices e.g. Smart Phones vs iPads vs TVs vs Desktops. Safari in iOS had a much faster JS implementation than Android or even the WebView in iOS apps, this doesn't make slower devices useless or stop users from viewing websites in different apps than Safari or even stop other browser vendors from developing alternative browsers for iOS.
Having a faster implementation doesn't make every other device or browser useless.
> Why would anyone run a slower JS implementation of an app, when Chrome gives them wings?
Why should the web be shackled to the limitations of JavaScript? This same reasoning could apply when V8 was first released which was 100x faster than other JS engines at the time. This just made every browser vendor care deeply and invest more in JavaScript performance. This is the same as impl-driven defacto standards like Canvas and WebGL, new experiences open up more categories and encourage other vendors to follow suit - A rising tide lifts all boats.
The core Dart Team is driven by trying to improve the web as best they can, just as they've done with V8 they want all their work to be freely used and used to encourage new innovations on the web.
> A large body of source code isn't as adoptable as you imagine. You need the people who are embedded in the evolution of the platform, or you are always going to lag.
Not true. A valid implementation of a language spec precisely means that source code in that language can be run on any implementation, just like existing Java code could run on Android's Dalvik and ART VMs. When a language has a specification it makes it easier to create different implementations (http://en.wikipedia.org/wiki/List_of_Java_virtual_machines). It's also possible when a language doesn't have a specification as seen with Ruby VMs (https://github.com/cogitator/ruby-implementations/wiki/List-...) but it's much easier to implement when there's an unambiguous spec to follow.
Also because Dart (like V8_ is both open source and embeddable, no-one needs to reimplement it, they can embed it as-is or port it.
> You need the people who are embedded in the evolution of the platform, or you are always going to lag.
The developers of Node, didn't have to work on V8 team to embed V8, neither does anything else that embeds, compiles or ports V8.
> Not true. As an example, for a long time Mono's GC was much slower than .Net's.
You're contradicting yourself and disproving your own point. A GC is not in the language specification, it's an implementation detail which the Mono team had to re-implement themselves precisely because it wasn't Open Source.
None of this applies with the Dart platform or team whom are developing a truly open platform and embeddable VM who are actively encouraging other users and vendors to adopt.
> The lessons from the 90s and early 2000's were very clear. We need to learn from them.
It seems at least they're not as clear to you - none of your comparisons are valid, nor have you cited the ones that were.
In short, I don't believe we need a single Dart VM any more than we need a single HTML rendering engine. I don't believe Mozilla (and others) have to depend on Google engineers for anything in their product, even if it is Open Source. I don't believe a single company should go about extending the web by leveraging market dominance; like Google is doing right now.
Our positions are very clear here, and we disagree. That's fine.
Sorry you've got it backwards, you're the one who introduced the .NET Framework vs Mono and their differing GC implementations as a valid comparisons for Dart (which they're not):
> C# is an ECMA standard too; how well did Mono fare in the early days and even now after more than ten years?
I've just corrected you in both cases that the Mono compiler has excellent support for the (C#) language specification which it does, valid C# both compiles with the Mono C# compiler and runs on the Mono VM fine. The language specification was what made this possible. The issues that you cite in the early days have no basis for comparison with Dart, which are instead side-effects from re-implementing a closed implementation like ActiveX (another incorrect comparison) should anyone else had chosen to re-implement it.
The fact is the Dart platform couldn't be any more open than it is already: it's completely open source, has a language specification, has multiple compliant open source implementations (Dart VM + Dart2JS), has open patent grants, develops in the open, accepts external contributions, features are prioritized and driven by user feedback, encourages re-use and adoption.
The Mono team were instead forced to create the VM and compiler from scratch and had to re-implement and reverse-engineer .NET's vast class libraries and API's (which don't have specs), precisely because they're not able to re-use the existing implementation. The Mono team are actually very happy whenever Microsoft releases some of their .NET libraries as Open source which they've been able to re-use as-is. Thus none of the issues you've brought up applies to Dart which is entirely Open Source that both supports and encourages embedding and re-use.
Instead of Mono and ActiveX, the JVM and open source OpenJDK implementation or examples of embedding V8 like node would've been better comparisons.
> Our positions are very clear here, and we disagree. That's fine.
Whilst I disagree with your invalid comparisons, I'm ok with the rest of your comments in which you're only stating your opinions and beliefs. In contrast, I believe innovations like Dart are going to help move the web forward and enable richer experiences and already improves the development of large web apps .
This bug has bitten users of modern browsers more than once. They were probably too modern and Dart uses the Blink codebase for its interface to JavaScript.
So in reality even dart2js can only safely be used together with Google Chrome.
They don't have to, they can use the Open Source DartVM as-is, in-fact this is what Google encourages, just like how node was able to use V8 JavaScript engine - which they've said is an example of new use cases that's possible when you create a high-performance VM.
> Google's engineering could have gotten JS much farther along
Lars Bak and Kasper Lund on the Dart VM are the same guys on the V8 team, who were also on the world-leading JVM Hotspot compiler that was derived from the Strongtalk VM (the fastest implementation of Smalltalk) that they created. They believe performance of JavaScript is reaching its peak and is unlikely to see another 2x improvement, JS VM's are also extremely complex as JavaScript is extremely hard to optimize.
By contrast Dart is a much simpler and predictable language designed for both productivity and performance and because it was designed in-hand with the VM engineers, language features are designed in a way that performs well.
That makes no sense whatsoever. As evidence, I submit that Haskell can be compiled to C (and to javascript these days).
I suspect that experience has shied people away from the idea of relying on a single-vendor platform for web apps. We tried "rich Internet applications" and they weren't a lasting solution; both Adobe and Microsoft gave up on their efforts.
Google's solution has a plain-JS fallback which Flex and Silverlight couldn't do, but otherwise the Dart world view seems similar: one vendor, one monolithic platform, one preferred runtime.
- It compiles to JS (you mentioned this)
- It is standardized by ECMA
- The entire platform (VM, compiler, libraries, IDE, etc) is open source
I guess how you feel about Dart may depend on how you feel about Google and big corporations more generally. Just because a big company that has a lot of mindshare/marketshare creates a great platform, does that necessarily mean we should be afraid of it? Maybe, but if you're frustrated by JavaScript, it's certainly worth a look.
For these kinds of platforms, post facto standardization efforts and code releases are part of marketing, IMHO. Dart remains a Google-lead project tied to Google's goals rather than an actual open platform.
Right, I agree with you. I guess you didn't read my whole post. To quote myself from just above: "I guess how you feel about Dart may depend on how you feel about Google and big corporations more generally. Just because a big company that has a lot of mindshare/marketshare creates a great platform, does that necessarily mean we should be afraid of it? Maybe, but if you're frustrated by JavaScript, it's certainly worth a look."
Which means nothing as no-one else is legally allowed to use it. It's only "Source Open" (not "Open Source") so no-one is legally allowed to adopt, adapt, enhance, etc as can be done with true Open Source projects.
And also not the actual Silverlight part: http://davidburela.wordpress.com/2013/11/22/is-it-time-to-op...
TypeScript comes close with the tool support, but it doesn't have the unsurprising semantics, and all in all it's a lot more limited, because it's designed to be a near-superset of JavaScript.
I'd be using Dart already if it was simpler to integrate with existing JS libraries. That's the part TypeScript got way better.
Tool support must be one of the most underrated language features these days. The enormity of blog posts about desiging your ruby code for "greppability" is just scary - I just want my tool to generate a call hierarchy for me, thank you. Dart has this covered.
It even has doesNotUnderstand:, so it's quite extensible.
The optional typing is neat: you can have a type error and the program won't just compile, it will continue to run! There's a video of Gilad demonstrating this in a live coding environment: he changes the type of a variable that's a number to String and apart from the compiler now complaining, nothing changes.
The isolates concept also seems well-thought out, with separate heaps and the only interaction via messaging. Nothing breathtakingly new, but I think they picked up the right thing and implemented it well.
The fact that the semantics are sane means the compiler can create faster code than JS with fewer heroics (if it isn't compiled via JS).
Please remember to recompile all your apps you deployed with Dart < 1.6. There are still some Firefox users out there. (Majority in Germany uses Firefox.)
also another question : does anyone here using angulardart can talk about how much static type anotation helps ? i'm thinking of future<t> instead of $q and directive writing ( which i always found a bit confusing, so maybe types help).
http://redstonedart.org
https://github.com/lvivski/start
There's also a Dart specific hosting service that's in beta: http://www.dartvoid.com
And there's been some success running Dart on Google Compute Engine through App Engine Managed VM (not sure if this is out of beta).
I'd like to do a few personal projects with server-side scripting and I need to learn a new language and ecosystem for it. From what I've seen I'd rather learn Dart because it is more familiar to me. What's been stopping me from doing that is missing integration and/or documentation in asset compilation toolchains for example in Play (i.e. no sbt-web plugin).
Client side development is, ironically, somewhat more complex because of the lack of module standard. You'll almost certainly want to use require() in the browser, but that won't work without taking extra, confusing steps. 'Browserify' pre-processes your JavaScript, generating a single large bundle, but that introduces complexity both at build- and run-time. And that doesn't even address the ongoing saga of the lack of a module standard for the browser.
By contrast, writing simple programs or servers in Node is vastly more enjoyable than in Java.
[1] https://github.com/gopherjs/gopherjs#what-is-supported
For example, compare Ember and Angular; Ember's architecture records the dependencies between values, and only updates what needs to be updated when an upstream dependency changes, while Angular has to recompute everything on every 'digest' cycle. When it comes to writing directives in a complex Angular application, you often to set a numerical priority field to the just the right number to get things to happen in proper order - leading to spaghetti code that is hard to reason about and fragile to extend.
I think Dart is even worse when compared to better emerging options like ghcjs (which compiles Haskell to JavaScript) and Elm; these alternatives have more powerful type systems that make common patterns like reactive programming and generic programming much easier and safer. Control structures that are built into Dart (e.g. the 'async' feature) can be treated as just one instance of a general type class (e.g. Monad) with ghcjs.
I think everything considered, these highly promoted and usually highly adopted but technically inferior Google front-end technologies are actually a net negative for the web.
It was marketed as faster, however in reality it's slower on everything except a special build of Chrome.
It supposed to make us more productive, however all it does is that it makes churning out code easier at the expense of debugging. Sourcemaps are here to solve these issues, however since Dart is not a purely transpiled language, I don't really see that working out.
In my opinion Dart is an excellent research project, but it ultimately fails at fixing anything that makes client side web development hard.