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 ...
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...
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...