I really hoped for something like python/ruby/coffeescript in the browser, and I got something that looks like Java. And yes, I admit it, I did stop to check Dart when i saw the curly braces. But others have probably better reasons ...
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)
What are you talking about? Javascript is a full-fledged programming language. You can argue that certain languages are more or less difficult to sandbox, but then I'd be interested in knowing why this is. I think what actually happened is that they gave up on the idea of Java applets, and that led to it becoming a security hazard, not any fundamental property of the difficulty of sandboxing it.
You think wrong. The inability to reliably restrict access to a rich API library full of dangerous stuff is a fundamental property of sandboxing as an in-language mechanism, or at least Java's sandboxing model.
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.
I'm not convinced there is such an inability, or why Javascript would be particularly better. Simply don't offer the dangerous libraries as part of the runtime. It's the runtime which has to be secured, not the language.
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.
This is a straw-man argument. You are not understanding the fundamentals of web safety and the design decisions behind ECMAScript and derivatives. Put the fanboyism down (i love python just as much as the next guy).
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.
There is a simple strategy to make a sandboxed Python runtime. 1) remove anything from the standard library that affects files or system stuff. 2) disallow anything but Pure python libraries.
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.
No, Javascript by design can't do certain things, such as write directly to your disk, read arbitrary data from the disk, control threading at the cpu level, etc.
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.
The number of sites that use Javascript is many orders of magnitude greater than those that use Java applets. This means that much more attention is going to keeping the Javascript runtime safe. If the same attention would go into making, say, a Python runtime for browsers, it would be just as safe (and removing the file writing and system call abilities would be the trivial part). Note that in HTML5, Javascript can read files (see e.g. http://www.html5rocks.com/en/tutorials/file/dndfiles/ ), so the point is not to exclude such functions from the language, but to adequately control when they can be used.
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.
> not a good idea. any fullfledged programming language that can operate in the browser becomes a significant security risk.
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.
Wrong. Vanilla javascript does not have access to system calls, nor is it sandboxed in the same sense as a java applet.
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)
> Vanilla javascript does not have access to system calls, nor is it sandboxed in the same sense as a java applet.
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.
Witness Node.js - Javascript that does have access to system calls and whatnot.
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...
The difference is that vanilla Javascript does not HAVE facilities for system calls, filesystem access, etc. Node ADDS those, immediately making Javascript-on-Node as dangerous as anything. Java tried the opposite via sandboxing, at it failed.
"* Node ADDS those, immediately making Javascript-on-Node as dangerous as anything. "
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 do the same thing with python except "REMOVE those"*.
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 keep repeating stuff along the lines of "language is capable of system level calls". Define what you mean, otherwise it's hockus pockus argumentation that no one can rebut. It's like arguing with Peter Joseph.
> > You could do the same thing with python except "REMOVE those".
> 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.
Node.js IS vanilla JS, as much as V8 in Chrome is...
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...
I've had similar experiences, not just with myself but with a number of the other front-end developers I've worked with.
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.
I also was hoping for syntax more similar to python (my background mainly is in python & ruby and I wrote my fair share of coffeescript).
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
* …
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.
That explains why it's not used in production. What I don't understand is why the idea of replacing Javascript with something better hasn't been embraced. Maybe Dart isn't actually better but I don't see anyone arguing that and that is the interesting substantial question.
I really wish there way a way of coding for the web that didn't require [backend language] + [front end language] + Javascript (might be the same as previous two) + HTML + CSS. If I want to write a website in Python, I still need to know Javascript, HTML, and CSS, so why bother with Python?
Don't use Python then. Prefer a language that has compilers targeting Javascript instead. Candidates that I have tried: Clojure & Scala. And I'm sure there are others. People don't talk that much about it because Javascript being used as a compilation target is a fairly new trend.
> If I want to write a website in Python, I still need to know Javascript, HTML, and CSS, so why bother with Python?
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.
Sorry, I should have mentioned the "why bother with python" was rhetorical. I know the answer, I was just expressing frustration at the barrier to entry that doesn't need to exist.
No particular reason. It was the first example language that popped into my head when I was thinking of "what language do I think really doesn't belong in a client browser". i.e. my personal opinion.
I'm sure it's a perfectly valid option to put in the browser, though.
I agree with you that you should use the right tool for the job. No CSS on the server :) There are a couple of projects (ghcjs, fay, purescript, haste) that make it possible to write Haskell for the browser. After maintaining JS libraries with a team over the past three years I've come to wish for Haskell's type system and compiler. It would make my job much easier. :)
> # For a competitor to become popular it’d have to persuade every browser manufacturer to implement it
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).
I don't think Dart is better. It is better in some ways, but it's not enough. You're not seeing arguments because currently people don't care.
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.
Dart does have a new VM (that's what Dartium uses after all), and it would probably make for a better compile target than JS since it has strong typing, better number types, etc.
More recent benchmarks[1] show 85-91%. IME developer productivity has been far more important than raw performance.
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.
Worth noting there's no compile step or debugging with source maps when you're developing using Dartium, which runs the Dart code directly; you'd only need to compile for deployment.
My developer experience with Dart was not a good one. The most succinct way that I read from other developer experiences on the internet was, "It's the worst parts of Java brought into Javascript". Not intended as a trolling statement, but like other folks have posted, it didn't strike me as having provided interesting value/productivity gain.
I had the exact opposite experience. I was vastly more productive in Dart then in JavaScript. The code result was also more clear and understandable. I would say "readable", but often pretty looking code is as understandable as the Brain Fuck language.
The main problem with CoffeeScript is that you're still talking about the exactly same type system and mostly the same problems, minus some superficial fixes and plus some syntactic sugar.
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.
Yes, I wrote coffeescript daily for a few months. It is also much more productive then JavaScript is, and I do enjoy it more then JavaScript, but I still find it lacking compared to Dart. Dart gives you the option of static typing. Static typing speeds up development because the compiler itself gives you a bunch of free debugging effort. I also find it much easier to manage includes and layout of the code. There is no need for tools like require.js, browserify, or bower.
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.
Since starting with Dart, everytime I am back in JavaScript-land I cringe when I run into 'undefined' errors and other trucking-along road bumps (DateTimes are mutable in JavaScript, srsly?).
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.
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/
Dart runs in every modern browser (you can compile it to JavaScript). You can use it for real world projects. We use it in production at https://www.blossom.io
It a threat to their control of the web. Javascript is currently the only real option for client-side software, and Mozilla owns Javascript. Why would they do anything to help Google take that away from them?
Adding support for Dart would be a huge maintenance expense over the years, for a language that's basically a minor improvement over Javascript.
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.
I think that's a disingenuous argument. Mozilla has been happy to support extremely marginal standards in the past - speech, the whole microformats mess, webfonts. Dart had (and has) more momentum behind it, more developers wanting to use it, than those.
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.
I dunno, as far as a compile to JS, statically typed language I prefer Haxe. But JS is a great language - super flexible and powerful. How some people choose to use it is questionable at times, but there's no doubt that it's powerful.
I would love to learn Haxe, but anything I can find about it assumes you've been a professional Flash developer for 20 years or the example code doesn't compile (and the errors are quite cryptic to me). I need a Learn Haxe the Hard Way.
Dunno, I never used flash but Haxe is pretty easy to follow. Try the newer OpenFL examples... It helps to learn using OpenFL since it sets up a project that compiles for you, then you can mess around with the syntax and language features.
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...
Dart is good at large applications, like 50,000+ lines of code. After 50,000 lines of JavaScript, you really start to miss static typing and hate the type system that JavaScript uses.
Dart has the restriction of "must be compilable to Javascript".
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.
> I guess the majority of existing mainstream languages
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.
Simply because there is no incentive for some of the main players to make the browser significantly better. Actually the opposite is true - think of what has Microsoft and Apple to gain (or lose) if the browser becomes de facto replacement for native OS and their walled gardens? (in case of MS the wall is rather made of consumers inflexibility)
I'd say that Javascript is currently living a renaissanse, with people creating libraries that make it operate on completely different (and incompatible) paradigms.
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 like Dart quite a bit. The tools are pretty nice and it has some good features. It's biggest problem from my perspective was the largely unfinished documentation. Many of the methods in the API reference list only signatures. I'd use it for some projects if they ever fix that.
Most of those methods are in dart:html where the library is generated from web IDL. We should be pulling in more documentation from MDN, so I'm not sure what's happening there.
I've been increasingly sceptical of things from Google, because of their track record. That includes the usual losing interest, as well as general people avoidance. Quite simply they are not a safe bet.
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.
The web doesn't need another language. It needs a sandboxable VM which has the DOM as a first class citizen. Dart didn't address that need...it merely provided another language and tried to strongarm its way into becoming a standard.
DOM as a first class citizen is a non-feature. Dart didn't address that feature because they went out of their way to distance the language from the DOM, and instead provide a clean API on top of the DOM.
The term "first class citizen" usually means there is a language syntax built-in for the feature that would be "first class." Dart has no such built-in syntax to deal with DOM elements. You have to use the API to manipulate the DOM.
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.
I'm not saying another language is bad, just that it is not a deficiency of the web. We already have hundreds of them...all of which are hacked onto a language that was never created with the intent of acting as a VM. A web-native VM would actually enable much better selection of programming languages than Javascript currently does. Dart is nothing more than a new soda selection in a broken vending machine. It hasn't gone anywhere because it isn't in any better of a position than the rest of the sodas in the vending machine.
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.
Remind me again why it's so hard to come up with a better alternative to the current HTML+CSS+JS mess?
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).
My impression is that it's mostly a matter of inertia. On the technical side I don't think any individual part is unsolved or even hard but technologies and their applications keep changing (e.g., mobile) so it's not possible to create one unified, elegant framework without it being obsolete immediately; the alternative is that we incrementally evolve the existing mess ... Furthermore, perhaps there's also an element of companies making their competitors' lives more difficult by not embracing standards introduced by others.
> There was a lot of hype for Dart a couple of months/1 year ago and now it seems it faded away. What happened?
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.
The platform itself is also maturing quickly. Some notable recent things from the top of my head:
* 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/
Building and releasing non-trivial projects takes some time so there is always a bit of an incubation period re visibility of adoption and like I said from my own perception even though it is just a personal anecdote Dart is getting picked up.
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:
Last year I was very enthusiastic about Dart, and before that Clojurescript.
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.
I wasn't interested in the first place, because I don't want to replace JS with a different new browser-centric language; I want to replace it with an existing good general-purpose language that just happens to run in a browser.
To me Dart is really a great alternative to JS. The less I have to code in JS the better. Dart gives me the Java/c++ kind of language, has a lot of nice features out of the box, IntelliJ has a nice Dart-plugin - I can use strong typeded vars... Sure Dart has its kickups and it's traps but it i
envolves and becomes more mature every day.
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.
I also think that the Dart Team expected more uptake from JavaScript people (I also thought that) similar to how the Go people expected the most uptake from C/C++ people.
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 …
111 comments
[ 2.1 ms ] story [ 246 ms ] threadEveryone 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...
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.
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...
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.
In my book Dart looks pretty attractive once you take a closer look: https://www.dartlang.org/articles/idiomatic-dart/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.
=
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.
There's plenty of other javascript compilers for plenty of languages.
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.
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.
# 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).
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.
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.
[1] https://www.dartlang.org/performance/
[2] http://www.google.com/trends/explore#q=dartlang
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.
But if someone produces something interesting with it, all can change...as soon as tomorrow.
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.
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.
If 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.
Google already has a better JS implementation that Firefox,so how would less javascript usage be a good thing for Google?
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.
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...
> 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.
JavaScript has many flaws, and there are plenty of languages available that have similar properties as JavaScript that do not exhibit these flaws.
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.
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.
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.
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.
http://en.wikipedia.org/wiki/Google_Native_Client
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).
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.
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:
The platform itself is also maturing quickly. Some notable recent things from the top of my head: Building and releasing non-trivial projects takes some time so there is always a bit of an incubation period re visibility of adoption and like I said from my own perception even though it is just a personal anecdote Dart is getting picked up.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...
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.
You can use Dart to write server-side or command line applications:
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 …