Comment by EGreg | Hacker News Reader

Comment by EGreg | Hacker News Reader

I disagree with the article's sentiment. I'm glad the web is focusing on Javascript. Here's why: the web is a nice, text-based environment that is safe to execute on your computer. Each web resource may contain active scripts but they are pretty innocuous.

Native applications are binary and can do all sorts of nasty things. Sure, this sandbox is supposed to be safe, but what if it's not? When an application is delivered over the web, one should really make sure that it wasn't somehow changed or sabotaged. Right now this is impossible. At the very least, this proposal would have to be implemented so we can trust what is being downloaded: http://news.ycombinator.com/item?id=2024164

Here is what I suggest: native libraries should expose their objects to javascript, which should do the majority of the work. Kind of like PhoneGap does on the phones. These native libraries (like OpenGL, say), should be served from cdns over httpc:// and the user agent can verify that they are safe after downloading them.

According to Brendan Eich, the designer of Javascript:

    JS had to "look like Java" only less so, be Java's
    dumb kid brother or boy-hostage sidekick. Plus, I had
    to be done in ten days or something worse than JS would
    have happened.

(See comments from http://www.jwz.org/blog/2010/10/every-day-i-learn-something-... for that and more from him)

Given that constraint, JS is an amazing hack. But it's 2011 now. Why should we have to use Javascript for client code in the browser--why shouldn't we be able to use Ruby, or Python, or C#, or Clojure, or Haskell, or F#, or Lua, or whatever else we want? It seems ridiculous to me that we're having a resurgence of language innovation on the desktop and on the server, but not in the browser.

We can. http://mozakai.blogspot.com/2010/08/emscripten-llvm-to-javas... or its kin will definitely see a place in the future of web development.

x86 is a sucky architecture to target but we target it cause that's what's worked on. Path of least resistance. Same will happen to JavaScript as a bytecode target, inevitably, and when it's abstracted away and browsers speed up even faster, we won't be bothered by the pain points, just use the implementation.

Can you tell me how this is different from, say, Java? The fact that you are happy to run arbitrary binary code that was compiled for a specific platform? So now we are supposed to "write once compile everywhere" like C++, and then ship that to platforms? That is not in the spirit of the web AT ALL. If you want Java, at least THAT is write once, RUN anywhere. And why isn't running Java more seamless? I think answering THAT will be helpful to the original discussion.

Because ECMAScript turned out to be pretty awesome, and is now the de facto standard on the web.

If you don't like Javascript, your best alternative right now is to make a language that compiles into it. Take whatever "nice" features you want. Here was my crack at it: http://news.ycombinator.com/item?id=2044752

Creating a language that compiles to JavaScript without essentially being an alternative syntax for JavaScript or being agonizingly slow is surprisingly difficult. I'm not aware of a single one. Do you know of any? Your "language that compiles into it" falls into the former category.

Off the top of my head I know of haXe, York Haskell Compiler. And WebSharper on F# allows you to do some cool stuff.

Languages like CoffeeScript do fall into the "alternative syntax" category. And things like emscripten (and some others I've seen) probably fall into the latter. If you try to abstract out a traditional VM on top of Javascript, you're likely to get poor results.

As another commenter suggests, though, we have a language like Haxe, which is much more than just an alternative syntax. And GWT does a very good job with Java -- with the exception of some corner cases, it's usually as fast as hand-written Javascript, and often faster because of a great deal of static optimization. The Google Closure compiler arguably defines a different language (if you turn on "advanced optimizations", it only accepts an effectively-statically-typed Javascript variant).

Reply on news.ycombinator.com