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