Ask HN: Why hasn't Dart become mainstream?
There was a lot of hype for Dart a couple of months/1 year ago and now it seems it faded away. What happened?
=
A special version of Chromium (the open-source browser at the core of Google Chrome) comes with the Dart virtual machine, allowing it to run Dart programs.[19] As of May 2013, Microsoft Internet Explorer, Mozilla Firefox, Opera Software's Opera browser, and Apple Safari have no plan to embed a separate Dart VM.[citation needed]
Dart source code can be compiled to JavaScript, allowing applications written in Dart to run in all modern web browsers. In the M1 version, released in October 2012, the generated JavaScript reached about 78% of the performance of hand-written JavaScript while native Dart code ran about 21% faster than similar code in V8.[6]
=
So for me : No browser except a special version of chromium, and slower than javascript whend compiled in it. So NO ...
We have a lot of problem to have some standards on the web (css anyone ? ) , we fight with ie6, so taking such a non standard is nope.
Not sure where the fading away perception is coming from; looks like it's still trending up, or at least staying afloat. [2]
Some barriers to entry:
* still have to interface with old javascript libraries for anything not ported to Dart
* compilation step + debugging. I know there's probably a sourcemap, but that's still more friction than straight javascript.
* learning curve
* pioneers get arrows in their back. Everything new has gotchas people haven't found yet. Javascript has some really shitty corners, but we know all about them.
Dart's pros have to outweigh these. I've only toyed with it, and from a strictly language-vs-language I like it better than javascript. If it gains traction, it'll start with toy projects -> company intranets -> the occasional startup -> small company, etc.
Thing is, Javascript works as a target for other languages. For example ClojureScript and Scala.js are examples of compilers targeting Javascript, amongst many others. So people that want an alternative to Javascript already have options.
From a technical point of view, I think Google made a mistake in designing a new language, instead of a new VM that could be used as a more efficient target for multiple languages, because even though Google tried copying the good parts of Javascript's story, you can't beat the incumbents at their own game. And from a social perspective, Dart is seen as an attempt to fragment the web, so Google's handling of the situation was poor.
# JS has shown surprising legs when it comes to performance improvements
# For a competitor to become popular it’d have to persuade every browser manufacturer to implement it
# Once implemented it’d have to wait for multiple years for devices in the market to implement it
# Older devices are slower devices, so having a compiles-to-JS version that lags in performance for older devices isn’t tenable either.
Basically, it makes more sense to increase the local maximum than any other path.
IMHO this is a misconception. Dart compiles to JavaScript with decent performance of the generated code. In some cases even faster than comparable hand-written JavaScript (see: http://dartlang.org/performance).
JavaScript engines getting faster also means that Dart code compiled to JavaScript is getting faster. It is a win-win scenario.
Even if other browser vendors won't ship a Dart VM tomorrow the situations is pretty awesome performance wise.
Once Chrome ships a Dart VM a huge user base gets even better and more predictable performance characteristics than would be possible in JavaScript which is incredible but I don't see the browser vendor support/performance angle as a real show-stopper for Dart.
You don't give anything up when you use Dart, you can still call JavaScript libs if you need to (e.g. we do use PubNub.js at https://www.blossom.io and we use it from Dart without any problems).
There's plenty of other javascript compilers for plenty of languages.
Libraries. Backend code can be quite different than frontend depending on your requisites.
E.g., there's no SQLAlchemy for Node.
HTML and CSS are quite different things, you can't escape that.
Right tool for the right job. That's why I don't think you should use css on the server! Or haskell on the client's browser!
I'm sure it's a perfectly valid option to put in the browser, though.
Because you don't want to write your backend in Javascript and you prefer a different language. You don't have to know well only one language in your lifetime.
I see more and more people I know who've been on the fence earlier to actually start to play around with Dart recently (last few weeks).
Why?
Improved Dart support for IDEs apart from the Eclipse based Dart Editor:
* IntelliJ Webstorm/IDEA: https://www.dartlang.org/tools/webstorm/ & http://plugins.jetbrains.com/plugin/6351
* Sublime: https://github.com/dart-lang/dart-sublime-bundle
* Chrome Dev Editor: https://github.com/dart-lang/chromedeveditor
* Soon: Dart on App Engine: https://www.dartlang.org/cloud/
* Polymer.dart (replacement for Web UI, interop w/ Polymer.js)
* Angular.dart (now 6 times faster! http://blog.angulardart.org/)
* Dart became an official ECMA Standard (http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-408.pdf)
* More and more incredible packages to use on pub http://pub.dartlang.org/packages?page=1
* Dart 1.6 soon to be released which supports installing pub packages globally (similar to npm)
* People start to learn about functional reactive programming and Dart as great native support for its concepts: https://www.dartlang.org/docs/tutorials/streams/
Shameless plug: I've also started a series of posts on why I fell in love with Dart. If you're interested to learn more check it out:
https://medium.com/why-dart/why-i-fell-in-love-with-dart-1f8...
Dart let's me focus on the app I'm writing, the data structures, the business logic & the overall architecture as well as value is I'm providing to my customers without getting held up with heisen-bugs.
This has a lot to do with getting into the zone/flow. I personally don't want to run into things like language insanities while I code, I also don't want to accumulate a huge repository of patterns or workarounds to avoid the bad parts/minefields of a language.
I wonder where the "It's the worst parts of Java brought into Javascript" FUD is coming from.
As I see it Dart avoids the worst parts of Java (http://www.javapuzzlers.com/) and JavaScript (https://www.destroyallsoftware.com/talks/wat) and mixes it up with great parts borrowed from various languages and platforms (mixins, streams, async/await, …).
Dart is a dynamic language at heart, yet provides great performance (even faster than JavaScript which by now has pretty fast implementations in the wild compared to ruby/python): https://www.dartlang.org/performance/
If you are used to tooling support (autocompletion, warnings/hints, code navigation like in Java/Scala/C#) on a level which traditionally only statically typed platforms offered you also get it with Dart (see support for IntelliJ/Webstorm: https://www.dartlang.org/tools/webstorm/ & Sublime: https://github.com/dart-lang/dart-sublime-bundle).
So I don't really understand where the "worst parts of Java brought into JavaScript" sentiment comes from. I'd like some concrete examples.
I'm not a javascript fan by itself, but I do like coffeescript. I was probably making a comparison in my mind of coffeescript vs dart?
I prefer more heavy-weight approaches that use Javascript as a compilation target. Clojure and Scala can both compile to Javascript, but you're talking about different communities, libraries and tools, so very much like Dart, but focused on targeting just Javascript VMs.
JavaScript => CoffeeScript => Dart.
I think once you've took the red pill of "There has to be something which is better than JavaScript" it is hard to go back.
Once you've written some CoffeeScript you will start to long for even more semantic improvements beyond classes, preventing you from polluting the global namespace and being able to bind `this` using the fat arrow.
That all said it takes time for things to become mainstream. See the Joel article: "Good Software Takes Ten Years" http://www.joelonsoftware.com/articles/fog0000000017.html
Go dates from 2007, and is currently 8 years old, and is heading into the mainstream. Dart is about 3 years old - it will take more time plus a non-typical Google track record to get there, if it ever does.
I'd say the major problem is inertia: why switch when Javascript is working "well enough?" Dart does offer some degree of type safety, however it doesn't really have any killer features that make it a huge sell to the existing Javascript community. Contrast this with Coffeescript which provides a complete overhaul of Javascript's syntax to appeal to many web developers, especially those coming from a Python or Ruby background. It leaves the semantics the same with only a few syntactic sugars like classes and the fat arrow. To the fans of Coffeescript, both of these are the killer features that make them want to use it.
Perhaps Dart isn't aimed at the Javascript community. They're happy with JS.
It's more aimed at those who dislike JS, perhaps coming from traditional OO or static languages.
Dart's killer features to me?
- Tree shaking. You can add a large library, and dart2js will only spit out the code you actually use.
- Classes, type safety, and generic lists.
That said, in the day to day syntax (while important) is just a part of the equation. The main thing is that it does not get in your way (I struggled with JavaScript objects getting silently reduced to the first attribute in coffeescript because of syntax errors on my side).
When evaluating a platform I look at syntax (the first thing you see) but then I try to look under the cover to see the whole.
* What are the basic building blocks of the language
* How is the standard lib
* How is the 3rd party lib story (dependency mgmt, modularity, package mgmt, …)
* How is tooling support
* How is performance
* How is working together with others
* How is reading code I've written months ago
* …
Everyone I know that used it then have repented, it was apparently horrible..
not a good idea. any fullfledged programming language that can operate in the browser becomes a significant security risk. even with sand-boxing, if you can break out of the sandbox, then you have access to a full-fledged language with all of it's power. This is the reason Java has got a bad rap; it's due to the use of Applets in the browser from which people have repeatedly broken out of the sandboxing and then can execute arbitrary code on your system (without your knowledge).
The only safe and secure way to have a language run in the browser, is if it just simply does not have the capabilities that could harm your system (ie. write directly to the disk, execute other local code, etc). If the language just can't do it, then there's no sandbox to break out of and due harm with. One of the (many) reasons Javascript has been successful. (I'm a Java developer)
There's been a steady stream of critical security bugfixes for the Java browser plugin coming out of Oracle for years, and it's never been enough.
Vanilla javascript simply does not have the API's to make system calls. Java does, as does Python, etc. Removing from the runtime (like in a java browser plugin) is fine, until someone can break out of that sandbox and hook into the runtime installed on the system, or inject a runtime, etc.
The thing that makes javascript a "safer" web language is it just simply cannot make system calls, period. This was by design, as javascript was intended for solely residing in the browser. All other languages have had "web" bolted-on after the fact, and all have failed to be secure in the same way Javascript has been.
Node.js and derivatives have explicitly added this functionality, which is what we would then call a "general purpose programming language", aka. full-fledged language.
There's no debate here. ECMA Script's designers were very public about their logic in the design process, and the reasons stated here are exactly why they made the choices they did.
Will some of it leak through? Possibly. Does that mean we should do it or try? Of course not.
if it can be removed (features, api's, etc), then it can be added back in (maliciously or not) or hooked into via a system runtime or a program installed on the system. If it's just not there at all (the api's nor the facility for the api's), then it can't be added. that is really the boiled down version.
every other language that has tried to be a web language without being explicitly designed as a web language has failed. why do you think python would be any different? because python is just so awesome?
and to rebut your point in the other thread, i have stated explicitly the things that make javascript "safer" -- you have just chosen to ignore them or brush it off. I'll say it again -- javascript does not have the api's nor capabilities to make direct system calls. system calls are filesystem actions, threading actions, process manipulation, executing arbitrary code, writing to different outputs, manipulating memory, etc. these are all considered highly dangerous to run from a browser.
Arbitrary system calls can only come from either the standard library or an extension module in C, and these are ruled out by step 1 and 2. Your argument about adding things back in or hooking into other runtimes is unsubstantiated; ruling out such things is the very goal of making a sandbox.
This was part of the design process in order to make Javascript a "web browser safe" language. Other languages have been modified and browser support "bolted on" after the fact, which leads to the sandboxing, which means if one can escape the sandbox, they have a full language and all of it's features at their disposal. This is dangerous, and can lead, and has led to severe security issues.
Applets are very actively maintained by the OpenJDK and Oracle projects. They are used still today for a lot of things, especially in the banking sector.
Critical security flaws can come from any C code, be it a Javascript runtime, a PNG library or a PDF viewer. There is nothing inherent in those things to make them unsafe (as opposed to say, running arbitrary executables), except maybe that they are written in C.
JavaScript is as much of a full-fledged programming language as Python or Ruby. What makes the browser implementation of JS more limited than typical "native" Python or Ruby is exposed APIs, not language features. There's no reason a Dart/Ruby/Python in-browser environment would need to expose any more of the underlying system than the same browser's JS implementation.
The problem comes down to the API's either being there or not.
In a java environment, the browser plugin does not allow calls to the system such as arbitrary writes to the disk, reading, etc. However, if one can break out of the sandbox, then they can make those system calls. The same would go for any desktop/server general purpose language that has been modified and/or sandboxed to run in a browser.
With vanilla javascript -- there is no ability to make the system calls even if one were to "break out of the sandbox".
That is the difference, and what I mean by a "full-fledged language".
(node.js is heavily modified javascript with the explicit intention of being (mostly) server-side and have sys call capabilities)
Access to system calls is an API, not language issue. There is no reason python or ruby in the browser would have any more access to system calls than JS-in-the-browser does. (Nor is there any reason, for that matter, that Java in the browser should -- the particular way that applets were implemented isn't fundamental to the language, its just an implementation decision tied to a much earlier time.)
> The same would go for any desktop/server general purpose language that has been modified and/or sandboxed to run in a browser.
No, the same would go to any desktop/server general purpose VM that used a Java-style applet sandboxing approach and Java-style plug-in interface to run outside of, but interact with, a browser the way Java applets do.
A browser-specific implementation of a language that simply doesn't include the system-call features of the general purpose VM would have essentially the same security considerations as in-browser JS implementations (in fact, it could share the same in-browser VM with a different compiler in front of it.)
> That is the difference, and what I mean by a "full-fledged language".
The thing is, the difference you are pointing to has nothing to do with the language, but instead has to do with the implementation/runtime/VM used and how the language is exposed to the browser. The features of the applet model that are problmatic are particular to the applet model, and have nothing to do with Java-as-a-language.
> node.js is heavily modified javascript
No, its not. There's no language-level modifications at all (well, other than the ones that are made in the underlying V8 system, which is also used in browsers.)
There are additional APIs implemented in node that aren't implemented in in-browser V8, but you can do the same thing the reverse direction with Ruby or Python to get ruby or python in the browser with no greater security concerns than are posed by JS in the browser.
Javascript is a full programming language, a pretty powerful one at that. The only thing that makes it safe in the browser is the browser implementations themselves, sandboxing, etc...
What you're describing is an implementation of a language, not the language itself. No language inherently has access to the system unless it's part of the specific implementation...
You could do the same thing with python except "REMOVE those"*.
This discussion is a complete non-issue. No one is suggesting to put a full-fledged python interpreter into the browser and allow remote websites to execute arbitrary code on it. Of course it will be "sandboxed" and gimped to prevent malicious code from executing on the client machine.
You could -- as the java plugin does, but the problem is someone can inject a runtime, part of a runtime, or hook into a system runtime, or into another installed application's runtime, etc.
That is the core of the issue. If the language is capable in any sense of system level calls -- then it's dangerous to run in the browser -- someone can escape browser sandboxing, or language sanboxing and make direct system calls.
Any language that is not designed from the ground-up to be a web language is inherently going to be insecure. It's a lot like trying to bolt on threading into a language that was not designed to be threaded (look at php's struggles). It becomes almost impossible to make it work as intended.
Javascript was designed from the very beginning to be a web language -- it was designed from the very beginning to not be capable of certain things a web browser should not be capable of doing.
There's no debate here. ECMA Script's designers were very public about their logic in the design process, and the reasons stated here are exactly why they made the choices they did.
> You could -- as the java plugin does
But the Java plugin doesn't. It uses the same platform for browser Java as local Java, which is why it is possible to break out and do things you shouldn't be able to do.
So, no, a browser-specific, limited-API version of Ruby or Python is nothing like running on a full Java VM but trying to constrain what web code can do via the Applet security model. Its exactly like (from a security perspective) in browser JS.
Here is what Dart really is: Node.js without the JavaScript baggage — I like Node.js because of the principles on which it was built: run things asynchronously whenever possible, use data streams whenever you can get away with it, and tie it all together with futures and callbacks. The problem with Node.js is that it’s JavaScript. There’s no distinction between types of numbers, working with arrays is always janky, NaN-infused wat moments abound, and so on.
But Dart gives you everything that’s great about Node.js without the baggage of JavaScript clinging to the project like a nagging, alcoholic in-law. Dart has an incredibly robust stream API and top-notch futures support baked into the core dart:async library, plus a bunch of other stuff that you get for free, like WebSockets, SSL support, a decent math library (complete with ints, nums, and doubles out of the box), as well as the foundations for an Erlang-flavored actor system in the dart:isolate library.
Basically, server-side Dart is trying to solve the same problems that Node.js was built to solve, i.e. problems around asynchronous, non-blocking I/O, but is doing so on a better VM and with a more robust and less flaky language. Another bit of good news is that Dart in practice is highly reminiscent of JavaScript, from the basic syntax to callback functions as first-class citizens, which means that the bridge from Node.js to Dart isn’t a terribly precarious one.
Because choice is bad, right?
On a technical level, I would also have preferred something like a "bytecode" type VM. However, I believe that would have severely hindered the uptake since all browsers would have to support it before I'd even think about using it.
Dart's "VM" is already supported on all modern browsers.
edit: This was already tried with Java Applets, however I guess Microsoft's implementation had put people off it. Plus it was before it's time, IMO.
For example, the C language does not have OOP as a first class citizen. However, you can do OOP in C. GTK+ and GObject, for example, accomplish it.
What the Dart Team got wrong was that at first there target were all the JS-Devs out there. I think, a wrong decision. If you like JS, if you are used to the whole toolstack, you probably stay with JS. But if you like a statically typed, modern, language then Dart is a greate alternative.
Turns out that people who already are happy with an alternative solution are less likely to switch than people who are already unhappy with the alternative because they are not yet used to it/invested and judge it with fresh eyes (like people from other camps like Python, Ruby, Scala, C#, Haskell, Clojure, …).
I personally find it sad that there is such an aggressive backlash against Dart from people who did not really take a close look at Dart or dislike Google for some reason (see Paul Graham's essay on how to disagree http://www.paulgraham.com/disagree.html).
If you look at decent JavaScript coders who are fluent with many programming languages they tend to see Dart in a different light, take it for what it is and judge it on its own merit.
Maybe focusing on getting the JavaScript community excited was a bit too optimistic. I don't know, you gotta try right?
That said, Dart seems to have an easier time with people who come from languages other than JavaScript or with people who only briefly learned JavaScript to do some stuff and wonder why they have to avoid 90% of the language and every library out there uses a slightly different not completely compatible set of conventions to emulate classes, promises, packages …
1.- There isn't native support in any browser, not even Chrome.
2.- Still has plenty of bugs.
But there are cases where Dart is used, so, the reasons my vary.
What put me off both languages was an experiment I did: I coded up the same non-trivial web app in Clojurescript and Meteor. I wrote the Meteor app in about half the time and it had more features. I didn't do the experiment with Dart, but I have written enough server and client experiments in Dart that I believe that Dart is not as agile as Meteor using plain JavaScript.
That said, Dart is nice, and for some combined client/server projects it makes sense. I don't understand the complaints about it being a Google project though. I used GWT a while back on personal projects and for customer work, and Google did a good job of open sourcing it so betting a company on GWT seemed safe enough. I have the same opinion about Dart - it could have a life without Google support.
JavaScript has many flaws, and there are plenty of languages available that have similar properties as JavaScript that do not exhibit these flaws.
You can use Dart to write server-side or command line applications:
* Soon: Dart support for App Engine http://dartlang.org/cloud
* Documentation: Dart command-line/server: https://www.dartlang.org/docs/serverguide.htmlIf we could use it in mainline Chrome/Chromium then maybe it could start to take off but currently the install base is way smaller than even Chromes.
I personnaly dont use Dart because IMHO there are better options right now for people who dont like writing raw javascript.
Coffeescript gives the declarative style i want for quick dev.
Typescript gives me the "type safety" that allows managing large codebases.
Clojurescript for other stuff.
The only reason I would use Dart is if Dart was part of the Android dev stack,or Chrome for the public.
I see little reason to use Dart right now,though Dart has some very good libraries,for game development,angular dart ,etc ... So maybe in the future perhaps.
I think Microsoft strategy (Typescript) is a better one.
TypeScript in particular, brings something like ES6 to today's browsers.
They are both languages that "compile" into Javascript, just like Dart is able to.
As trivial as that sounds, that is part of what has hindered its adoption. I seem to remember reading about the Dart team learning that many early adopters were not c++/java people but Pythonista's. You'd think they would have adapted to that.
Untill we have one (or few) winning paradigm, there is no point in replacing Javascript. Whatever we create will become obsolet before it gets adopted.
I also highly recommend using the 'Vaxe' VIM plugin with YouCompleteMe as well - it will recognize your OpenFL project, and give you context aware auto-complete, easy compilation of projects, etc..., making things much easier.
While Haxe without any framework can be confusing at first, it's really not that bad...
If they're going to support a new language, how about something with widespread usage, such as Python?
How about something that offers significantly different capabilities, such as R?
How about something that supports a huge number of languages and/or significant speed improvements, such as the LLVM IR?
If they're going to open such a huge can of worms, they're going to want to see substantial benefits rather than small incremental improvements.
They obviously can't support everything, so to pick a language it has to be demonstrated that the language is a better choice than (pretty much) any other choice. Dart has not done that.
By all means, bring on Python, R, or LLVM IR. I'd support any and all of those (though including one doesn't have to mean excluding Dart). Any of those would be a huge improvement over Javascript. But Mozilla seems to see ensuring as much code as possible gets written in that abominable language as part of its mission.
Google already has a better JS implementation that Firefox,so how would less javascript usage be a good thing for Google?
But if someone produces something interesting with it, all can change...as soon as tomorrow.
> I suspect there are currently always better alternatives.
In my experience, this is true. There is no need for Dart, because there are languages which are better.
So when people decide to replace JavaScript with something better, why would they choose "slightly better" over "significantly better"?
I guess the majority of existing mainstream languages have aspects that would make meeting this requirement difficult, without breaking the language.
It's also about control. Once they implemented say, Python, there isn't then much room for improvement/change without it becoming a different language anyway.
Given the wealth of languages out there, this still gives us a large amount of languages to pick from.
> It's also about control. Once they implemented say, Python, there isn't then much room for improvement/change without it becoming a different language anyway.
That's why they should have just standardized some IL format instead, and let real language designers target that IL.
Is the only problem the fact that we need a language that can be easily sandboxed? Isn't Lua like that?
Supposing we solve the sandboxing problem, what's the next problem? Offering a decent drawing API? Why not just offer an OpenGL viewport or something like SVG but with interactivity?
I really need to be educated on what is the hard part about this (besides widespread adoption - so I guess I'm wondering what's the technical obstacle).