[proussea]

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

[robbrit]

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.

[jenscow]

> make it a huge sell to the existing Javascript community

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.

[tosh]

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
    * …

In my book Dart looks pretty attractive once you take a closer look: https://www.dartlang.org/articles/idiomatic-dart/

[hedwall]

I remember RJS or what it was called, ruby compiled to javascript used in early Rails projects.

Everyone I know that used it then have repented, it was apparently horrible..

[flowerpot]

There is also opal, which looks pretty promising. http://opalrb.org

[Alupis]

> python/ruby ... in the browser

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)

[andreasvc]

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.

[brazzy]

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.

[andreasvc]

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.

[Alupis]

I'm afraid it's not that simple.

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.

[zo1]

A non-issue... All of those things/features you mention as problems could simply be removed from the python interpreter included with the browser.

Will some of it leak through? Possibly. Does that mean we should do it or try? Of course not.

[Alupis]

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.

[andreasvc]

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.

[dragonwriter]

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

[Alupis]

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)

[dragonwriter]

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

[frowaway001]

For God's sake, you are wrong. Just stop it.

[Mikeb85]

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

[brazzy]

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.

[Mikeb85]

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

[zo1]

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

[Alupis]

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

[dragonwriter]

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

[zo1]

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.