7 ms·

Ask HN: Any alternative to JavaScript in sight?

42 points by digamber_kamat 15y ago

I see people are writing mp3 decoders in JavaScript and what not. Javascript is probably lingua de franca of web (quoted Jeff Atwood). And in last 2 years we have used JS in ways like never before. Does anyone feel that sooner or later JS will probably turn out to be not-so-suitable for stuff we want to do ? Are there any attempts being made to provide an reliable alternative or can JS itself evolve ?

bauchidgw 15y ago
coffeescript - it's just javascript, but with a touch of awesomeness.
- VMG 15y ago
  And without proper stack traces. Don't get me wrong, I love coffescript, but it clearly is a hack. The internet landscape would look very different if browsers had a standardized bytecode interpreter.
  - cpr 15y ago
    Source-level stack traces are coming, to Firefox first. I would imagine WebKit will follow. IE perhaps not, but, personally, I intend to ignore IE in future web apps, until it mostly catches up with the front runners.
  - luismgz 15y ago
    Not just a hack. Recognized developers such as Brendan Eich (creator of javascript) or Douglas Crockford (author of Javascript: The Good Parts) say that Coffeescript is good stuff. Coffeescript is a "transpiler", a source-to-source compiler wich translates a high level, very flexible and powerfull language such as coffeescript into plain old javascript. It doesn't change the underlying language at all, it keeps its object model and its data types. It just adds a more expressive and succinct syntax, inspired in python and ruby (and these languages have a very well deserved reputation for expressiveness and joy amongst programmers for a reason).
rw 15y ago
What, specifically, would you like to see changed? It is evolving: Coffeescript, node, npm, and V8 are four examples. It can feel good to code in JS, just like it can in Python or Ruby (or Scheme :-) ).
reedlaw 15y ago
Why is JS not "reliable"? Any language can be a JS alternative. Do you mean you want an alternative language that runs natively in browsers?
- arethuza 15y ago
  "alternative language that runs natively in browsers" That's already been done: http://code.google.com/chrome/nativeclient/ http://code.google.com/chrome/nativeclient/
  - chc 15y ago
    That doesn't run in browsers, it runs in one browser — Chrome.
knowtheory 15y ago
Well there's always been interesting talk about getting LLVM to run in browsers, which would be wicked cool, and open up a lot of different programming languages. That said, JavaScript really is an awesome language to use, if you can get over the syntax. So i really can't see how JS would be unsuitable for future use, especially in light of the changes that have happened and continue to come down the pipeline in newer versions of JS. Coffeescript is a fantastic view of the power and capabilities of JavaScript packaged in a way that is considerably more elegant to look at and use on a daily basis. Check out the talk that Brendan Eich and Jeremy Ashkenas did at JSConf (http://news.ycombinator.com/item?id=2662846 http://news.ycombinator.com/item?id=2662846 ). Javascript really is going to be a development powerhouse for the foreseeable future. And i'm actually happy about that.
- jerf 15y ago
  No one language can meet every need. Even if it has been done, Javascript is a terrible language to write an MP3 decoder in, relative to more suitable languages. So if we're continuing to expand what the browser can do, shouldn't we expand what languages we can express them in? Why do we have to write our WebGL programs in Javascript? Javascript isn't a terribly great bytecode language, either, unless you're basically just writing a thin skin over Javascript. The logical conclusion of this line of argument is pretty much NaCL: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ Is that the anwser? Is there some intermediate where Javascript isn't the only choice for everything but we don't go to the other extreme? Beats me, but we'll all find out together. But my main point is that it definitely is not the case that Javascript is just the answer to everything and the situation is just peachy keen as it is. It isn't the answer to everything. No one language is. Either we get something else into the client, or we face some combination of wasted effort jamming programs into a language that doesn't really want them and applications simply never written because they don't work well with Javascript's abstractions. Maybe that's OK too, maybe we want a distinction between "native" and "web" app.
  - knowtheory 15y ago
    So i'm curious what you mean by "more suitable languages" for writing an mp3 decoder. Also which of Javascript's abstractions are do you think are so inherently unsuitable? As far as general purpose programming languages Javscript does pretty well with regard to object semantics. That's why things like Coffeescript are as powerful as they are. Javascript certainly doesn't have the elegance that say Ruby or Python has built in, but thanks to JavaScript's powerful and flexible nature, a lot of those capabilities are possible to build on top of JS's core. http://documentcloud.github.com/underscore/ http://documentcloud.github.com/underscore/ (which was also written by jashkenas and others) is a great example of this. On the performance front, given all of the work that's gone into the various browser implementations of JS, that you could call it unsuitable from a performance standpoint. Could perhaps elaborate on this further?
zrl 15y ago
Some effort is being made to bring other languages to the web. Emscripten is a backend for LLVM to produce javascript code (should work with any LLVM frontend). NACL (native client) is a project by google to allow code to be compile for a more secure subset of x86 and to run on a browser safely. I'm not sure on the stability or use of either. GWT (google web toolkit) is a project that compiles java to javascript. This one should be fairly stable and seems to be well supported.
jinushaun 15y ago
While server-side JS such as Node.js might be a fad, client-side JS is firmly entrenched. Given the speed at which the browser developers and standards groups agree on implementing new standards (read: slow), client-side Javascript is here to stay. However, CoffeeScript provides an interesting look into the future of Javascript. I also see a similar thing happening with CSS and Less, where people are no longer waiting for browsers to support features developers want. And lastly, I personally really enjoy coding in Javascript. The ugliest part about it is the DOM and Jquery successfully hides that. I think part of the reason Node.js is so popular because of the strength and programmer joy of the language.
davidw 15y ago
Nitpick: "Lingua franca", not "lingua de franca" http://en.wikipedia.org/wiki/Lingua_franca http://en.wikipedia.org/wiki/Lingua_franca Also: no, probably not. We're still dealing with browsers that are 10 years old, so even if you were to release a browser, with, say, Tcl as the default language, it'd be years before it was something you could count on being everywhere. See: positive network externalities, and "lock in".
phillmv 15y ago
No? It's only important because everyone has a javascript interpreter. The point will become moot as Javascript interpreters get good enough to allow us to run with languages that compile down to Javascript and enable more optimizations like typed arrays.
frobozz 15y ago
What do you think it might turn out to be unsuitable for? Just like some languages have tools to translate them to C, there's no reason why you wouldn't use a tool to compile from a language more appropriate to your task, into javascript.
stephenjudkins 15y ago
I think JavaScript will stick around for quite awhile. However, the viability and popularity of languages that compile to JavaScript will probably continue to increase. Besides CoffeeScript, which mostly only offers syntactic improvements to JavaScript, there are several projects which compile very different languages to JS, including: * Emscripten (http://emscripten.org/ http://emscripten.org/) compiles arbitrary LLVM bitcode to JavaScript. Since clang and GCC can both target LLVM, a whole lot can be compiled to JavaScript. The Python interpreter (http://syntensity.com/static/python.html http://syntensity.com/static/python.html) and the Bullet physics engine (http://www.syntensity.com/static/bullet.html http://www.syntensity.com/static/bullet.html) are both particularly impressive. * Google Web Toolkit (http://code.google.com/webtoolkit/ http://code.google.com/webtoolkit/) compiles Java to JavaScript. It's used in many real projects. Scala+GWT (http://scalagwt.gogoego.com/ http://scalagwt.gogoego.com/) aims to use this toolchain to compile Scala code, though it's not yet production-ready. * The reductio ad absurdum of this approach is http://bellard.org/jslinux/ http://bellard.org/jslinux/, a x86 PC emulator written in JavaScript. You can run almost any language in the web browser with that! See https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang... for a (possibly exhaustive) list of languages like this. Whether these approaches can deliver passable performance for legacy browsers is an open question. However, for newer browsers it's safe to assume this general approach holds a lot of promise.
- nxn 15y ago
  Since all of these compile down to javascript, they all suffer from at least some limitations of javascript -- the main one being performance. Yes, all browser manufacturers are trying to make it as fast as they can, but I sincerely doubt I will see the day javascript can run as fast as a statically typed and (jit) compiled language that isn't being executed by the browser. And when I say that, I don't mean little synthetic scenarios where some piece of javascript manages to be faster than something gcc spit out. I've already seen those, and they don't impress me any more so than a hummer being able to look like a ferrari if you get the angle and lights just right. I'm a fan of P/NaCl for this reason. Their approach goes directly at the problem instead of banging on a square peg for years and years until it barely manages to fit through a round hole. By the way, that is the only way I can describe using html/js/css for application development at this point. If it makes me sound bitter/angry, it's probably because I've been doing it for too long and grown tired of how tedious and limited it is.
jules 15y ago
Google's Native Client [1] is one answer. It allows you to run native code safely in the browser. It's goal is also to support LLVM IL to run safely in the browser. This way you could potentially use all your favorite languages at nearly full speed, and also have access to the DOM and other browser APIs. Another answer is to compile your favorite language down to Javascript. This gets you the expressiveness at the cost of a slowdown in runtime speed. Languages like Coffeescript are very close to Javascript so they don't incur much overhead by doing this, but even this approach can't go as fast as code running on Native Client. [1] http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/
neilk 15y ago
> Does anyone feel that sooner or later JS will probably turn out to be not-so-suitable for stuff we want to do ? Be more specific. Every programming language is not-so-suitable for stuff we want to do. > Are there any attempts being made to provide an reliable alternative or can JS itself evolve ? What's "unreliable" about JS? The lack of standardization in available features among browsers? That's an issue, but it will be dealt with, one way or another. C gained a huge infrastructure of tools and standards to make it more portable, and platforms that didn't or couldn't keep up are no longer used. This presentation from Velocity 2011 shows just how far JS has come. The author suggests that in the next iteration will be type inference in JS engines and/or optional explicit typing in the language. http://www.slideshare.net/newmovie/know-yourengines-velocity2011 http://www.slideshare.net/newmovie/know-yourengines-velocity...
dstein 15y ago
The number of new features added to JavaScript in the past year is substantial. Between Canvas, WebGL, WebSockets, WebWorkers, Audio Data, TouchEvents, the number of permutations of new kinds of browser-based apps you can build will keep anyone busy for years. Then add NodeJS, and CouchDB, and the use of JSON as a data interchange and there are things you can do entirely in JavaScript that no other language can do. If JavaScript continues to be improved (Harmony, V8/Spidermonkey engines, etc) then I see no other language on the horizon that will replace it.
- kwamenum86 15y ago
  Everything you listed actually has nothing to do with Javascript as a language. These are new frameworks for the and clientside APIs, not language features.
  - dstein 15y ago
    That's like saying the addition of the DOM did not improve Javascript. Standardized API's do matter, and do improve programming languages.
ignifero 15y ago
I would like to see an alternative to the WWW altogether. WWW is no longer a collection of hyperlinked documents, which was its initial purpose but a multitude of technologies running on browsers that use HTTP in nonstandard ways because it's ubiquitous. HTML is getting obsolete, with the most popular websites being essentially javascript apps. Maybe it's time for a new system like Java to create cross platform GUI apps from the cloud, that is not constrained by the browser and HTTP's limitations.
- lautis 15y ago
  I believe the most popular website is essentially an interface for this collection of hyperlinked documents. Document browsing is still one of the killer features of web. HTML is not a bad layout engine for GUI apps. It may not have been initially been designed as one, but after 15 years of development it seems to be pretty pleasant to work with as there are people who want to build their desktop apps with HTML. Obviously, the standard request-response model of HTTP is limiting for interactive apps. Bi-directional communication within request isn't possible and handshaking is a bit too expensive. But hey, this problem is actually solved: http://dev.w3.org/html5/websockets/ http://dev.w3.org/html5/websockets/.
kenjackson 15y ago
I'd like to see a statically typed language available. There is relatively little I do that requires dynamic typing, but so much of my experience would be better with static typing. I'm not saying to get rid of JS, but it would be nice to have a first class alternative.
- robin_reala 15y ago
  JS is adding limited static typing in typed arrays: https://developer.mozilla.org/en/javascript_typed_arrays https://developer.mozilla.org/en/javascript_typed_arrays
  - samth 15y ago
    Nothing about Typed Arrays is static typing.
- Ruudjah 15y ago
  Thanks. I thought I was the only one with this experience.
CLaRGe 15y ago
JavaScript will be superseded by, what else, C/C++. Right now there are no JavaScript killer applications on the web. Adobe and Microsoft tried with their respective wares, but Apple interceded and stopped both. It's hard to imagine now, but something will come along that, like web services, finds a slick way to give the folks what they want, performance. And that innovation will be written in C.
haikurion 15y ago
I think the execution of native code from the browser is slowly creeping in, in such a way that you'll be free to choose your language as you are in non-browser areas. Google native client, webGL and the ultra-new webCL are glimpses into the future. Javascript has served us well, but if we can avoid unnecessary computation as well as make use of existing code bases, then I am sure we will, eventually.
orangea 15y ago
http://altjs.org/ http://altjs.org/
sktrdie 15y ago
Frankly I really like JavaScript. I don't want the language to change, even though it has its flaws. I just love the ability to have data-structures as simple as objects and arrays which have evolved into a standard data exchange format (JSON). Then you can also have functions inside objects and everything becomes really flexible and really easy to design. I've tried many different languages, including the real pretty ones such as Ruby and Python, and I just have more fun using JavaScript because of how free-form it is.
- Stiffy 15y ago
  That flexibility is indeed useful for scripts and adding minor interactivity to an otherwise static web page. However, people are now using JavaScript for development that far exceeds those uses. JavaScript is just not suitable for larger applications. Once your application starts exceeding a few thousands of lines of code, the problems become very clear. You soon wish you were using a language like C++, Java, C#, Python, or Ruby. Toss in a development team made up of at least several people, if not more, and the pain becomes far greater.
  - sktrdie 15y ago
    I was never able to personally judge that statement. My experiences show that the flexibility of JavaScript only improved maintainability of the software written in it. http://npmjs.org/ http://npmjs.org/ is a list of solid software (also large software) written in JavaScript. So I don't think your statement, about maintainability being connected with how flexible a language is, can be proven to be true.
    - Stiffy 15y ago
      By "larger applications", I wasn't talking about jQuery, Node.js or anything built upon them. I'm talking about real software systems with, at a very minimum, tens of thousands of lines of code. More realistically, we're talking systems with hundreds of thousands, if not several million, lines of code. C++ can scale up to codebases that large. Java and C# can handle it, as well. Even Python and Ruby can, if care is taken. JavaScript cannot. You'll be hitting numerous maintenance barriers far before then, when you're still well under 10,000 lines of code.
liquidcool 15y ago
While I realize that Flash is no longer in vogue these days, ActionScript 3 is a really nice language and I'm surprised nobody else has mentioned it. It provides things like optional static typing for speed improvements, code clarity, and improved tooling/refactoring, as well as classes and packages for organizing larger code bases. It's more of what Brendan Eich envisioned JavaScript 2 to be. That said, Apple is making it really hard for developers to choose it for all but intranet apps (for which it's really well suited). I second GWT and the responses here have prompted me to look into CoffeeScript, so thanks for asking this!
Detrus 15y ago
Mozilla is working on Rust https://github.com/graydon/rust/wiki/Language-FAQ https://github.com/graydon/rust/wiki/Language-FAQ. Google has Go http://golang.org/ http://golang.org/. To run compiled binaries from such languages you'll use Native Client http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ and Pepper APIs which let you access HTML5. Go gets rid of some insecure low level things like pointers, keeps such things in an unsafe package to discourage its use. They intend to make it seamlessly compatible with NaCl. C/C++ code needs to be modified to work there. JS is already not suitable for lots of stuff. Vendors are stretching its capabilities with big teams of fancy programmers implementing fancy VMs with big chunks written in assembler. At Google I/O they mentioned V8 is about as fast as it will get. Then bigger teams are writing massive APIs because even with fast VMs the language isn't fast enough to roll your own CSS/XAML/MXML/HTML parsers or 2D rendering contexts. So you're forced to wait or hack together things like LESS, CoffeeScript, Stylus in an attempt to communicate with the overlords. With the browsers becoming the operating system for many users, you need a runtime that's as powerful as a regular operating system. Google and Mozilla are major players and it's nice to see them exploring alternatives. But even if NaCl/Go is superior technologically, it may not overcome JavaScript's business and political momentum. As usual, technology is not chosen based on technological merit, but business considerations like legacy, lock in, etc. Perhaps NaCl/Go approach will succeed but it will be too little too late. Kinda feels that way with Flash and Browsers, they're finally serious platforms but might be too far behind Objective-C, C# and Java on mobiles.
jensnockert 15y ago
I don't think that the problem is that javascript is bad, but that it will kill most other scripting languages just by being in the right place at the right time. It will be harder and harder for ruby/python/perl/x to compete with js in the future just because people know js and because it essentially runs everywhere fast. WebCL, WebGL and friends will cover anything with extreme computational needs, and that will be everything you need to learn to write applications in the future, unfortunatly.
yottabyte47 15y ago
Check out http://runrev.com/ http://runrev.com/

bauchidgw 15y ago

coffeescript - it's just javascript, but with a touch of awesomeness.

VMG 15y ago
And without proper stack traces. Don't get me wrong, I love coffescript, but it clearly is a hack. The internet landscape would look very different if browsers had a standardized bytecode interpreter.
- cpr 15y ago
  Source-level stack traces are coming, to Firefox first. I would imagine WebKit will follow. IE perhaps not, but, personally, I intend to ignore IE in future web apps, until it mostly catches up with the front runners.
- luismgz 15y ago
  Not just a hack. Recognized developers such as Brendan Eich (creator of javascript) or Douglas Crockford (author of Javascript: The Good Parts) say that Coffeescript is good stuff. Coffeescript is a "transpiler", a source-to-source compiler wich translates a high level, very flexible and powerfull language such as coffeescript into plain old javascript. It doesn't change the underlying language at all, it keeps its object model and its data types. It just adds a more expressive and succinct syntax, inspired in python and ruby (and these languages have a very well deserved reputation for expressiveness and joy amongst programmers for a reason).

rw 15y ago

What, specifically, would you like to see changed? It is evolving: Coffeescript, node, npm, and V8 are four examples. It can feel good to code in JS, just like it can in Python or Ruby (or Scheme :-) ).

reedlaw 15y ago

Why is JS not "reliable"? Any language can be a JS alternative. Do you mean you want an alternative language that runs natively in browsers?

arethuza 15y ago
"alternative language that runs natively in browsers" That's already been done: http://code.google.com/chrome/nativeclient/ http://code.google.com/chrome/nativeclient/
- chc 15y ago
  That doesn't run in browsers, it runs in one browser — Chrome.

knowtheory 15y ago

Well there's always been interesting talk about getting LLVM to run in browsers, which would be wicked cool, and open up a lot of different programming languages. That said, JavaScript really is an awesome language to use, if you can get over the syntax. So i really can't see how JS would be unsuitable for future use, especially in light of the changes that have happened and continue to come down the pipeline in newer versions of JS. Coffeescript is a fantastic view of the power and capabilities of JavaScript packaged in a way that is considerably more elegant to look at and use on a daily basis. Check out the talk that Brendan Eich and Jeremy Ashkenas did at JSConf (http://news.ycombinator.com/item?id=2662846 http://news.ycombinator.com/item?id=2662846 ). Javascript really is going to be a development powerhouse for the foreseeable future. And i'm actually happy about that.

jerf 15y ago
No one language can meet every need. Even if it has been done, Javascript is a terrible language to write an MP3 decoder in, relative to more suitable languages. So if we're continuing to expand what the browser can do, shouldn't we expand what languages we can express them in? Why do we have to write our WebGL programs in Javascript? Javascript isn't a terribly great bytecode language, either, unless you're basically just writing a thin skin over Javascript. The logical conclusion of this line of argument is pretty much NaCL: http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ Is that the anwser? Is there some intermediate where Javascript isn't the only choice for everything but we don't go to the other extreme? Beats me, but we'll all find out together. But my main point is that it definitely is not the case that Javascript is just the answer to everything and the situation is just peachy keen as it is. It isn't the answer to everything. No one language is. Either we get something else into the client, or we face some combination of wasted effort jamming programs into a language that doesn't really want them and applications simply never written because they don't work well with Javascript's abstractions. Maybe that's OK too, maybe we want a distinction between "native" and "web" app.
- knowtheory 15y ago
  So i'm curious what you mean by "more suitable languages" for writing an mp3 decoder. Also which of Javascript's abstractions are do you think are so inherently unsuitable? As far as general purpose programming languages Javscript does pretty well with regard to object semantics. That's why things like Coffeescript are as powerful as they are. Javascript certainly doesn't have the elegance that say Ruby or Python has built in, but thanks to JavaScript's powerful and flexible nature, a lot of those capabilities are possible to build on top of JS's core. http://documentcloud.github.com/underscore/ http://documentcloud.github.com/underscore/ (which was also written by jashkenas and others) is a great example of this. On the performance front, given all of the work that's gone into the various browser implementations of JS, that you could call it unsuitable from a performance standpoint. Could perhaps elaborate on this further?

zrl 15y ago

Some effort is being made to bring other languages to the web. Emscripten is a backend for LLVM to produce javascript code (should work with any LLVM frontend). NACL (native client) is a project by google to allow code to be compile for a more secure subset of x86 and to run on a browser safely. I'm not sure on the stability or use of either. GWT (google web toolkit) is a project that compiles java to javascript. This one should be fairly stable and seems to be well supported.

jinushaun 15y ago

While server-side JS such as Node.js might be a fad, client-side JS is firmly entrenched. Given the speed at which the browser developers and standards groups agree on implementing new standards (read: slow), client-side Javascript is here to stay. However, CoffeeScript provides an interesting look into the future of Javascript. I also see a similar thing happening with CSS and Less, where people are no longer waiting for browsers to support features developers want. And lastly, I personally really enjoy coding in Javascript. The ugliest part about it is the DOM and Jquery successfully hides that. I think part of the reason Node.js is so popular because of the strength and programmer joy of the language.

davidw 15y ago

Nitpick: "Lingua franca", not "lingua de franca" http://en.wikipedia.org/wiki/Lingua_franca http://en.wikipedia.org/wiki/Lingua_franca Also: no, probably not. We're still dealing with browsers that are 10 years old, so even if you were to release a browser, with, say, Tcl as the default language, it'd be years before it was something you could count on being everywhere. See: positive network externalities, and "lock in".

phillmv 15y ago

No? It's only important because everyone has a javascript interpreter. The point will become moot as Javascript interpreters get good enough to allow us to run with languages that compile down to Javascript and enable more optimizations like typed arrays.

frobozz 15y ago

What do you think it might turn out to be unsuitable for? Just like some languages have tools to translate them to C, there's no reason why you wouldn't use a tool to compile from a language more appropriate to your task, into javascript.

stephenjudkins 15y ago

I think JavaScript will stick around for quite awhile. However, the viability and popularity of languages that compile to JavaScript will probably continue to increase. Besides CoffeeScript, which mostly only offers syntactic improvements to JavaScript, there are several projects which compile very different languages to JS, including: * Emscripten (http://emscripten.org/ http://emscripten.org/) compiles arbitrary LLVM bitcode to JavaScript. Since clang and GCC can both target LLVM, a whole lot can be compiled to JavaScript. The Python interpreter (http://syntensity.com/static/python.html http://syntensity.com/static/python.html) and the Bullet physics engine (http://www.syntensity.com/static/bullet.html http://www.syntensity.com/static/bullet.html) are both particularly impressive. * Google Web Toolkit (http://code.google.com/webtoolkit/ http://code.google.com/webtoolkit/) compiles Java to JavaScript. It's used in many real projects. Scala+GWT (http://scalagwt.gogoego.com/ http://scalagwt.gogoego.com/) aims to use this toolchain to compile Scala code, though it's not yet production-ready. * The reductio ad absurdum of this approach is http://bellard.org/jslinux/ http://bellard.org/jslinux/, a x86 PC emulator written in JavaScript. You can run almost any language in the web browser with that! See https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang... for a (possibly exhaustive) list of languages like this. Whether these approaches can deliver passable performance for legacy browsers is an open question. However, for newer browsers it's safe to assume this general approach holds a lot of promise.

nxn 15y ago
Since all of these compile down to javascript, they all suffer from at least some limitations of javascript -- the main one being performance. Yes, all browser manufacturers are trying to make it as fast as they can, but I sincerely doubt I will see the day javascript can run as fast as a statically typed and (jit) compiled language that isn't being executed by the browser. And when I say that, I don't mean little synthetic scenarios where some piece of javascript manages to be faster than something gcc spit out. I've already seen those, and they don't impress me any more so than a hummer being able to look like a ferrari if you get the angle and lights just right. I'm a fan of P/NaCl for this reason. Their approach goes directly at the problem instead of banging on a square peg for years and years until it barely manages to fit through a round hole. By the way, that is the only way I can describe using html/js/css for application development at this point. If it makes me sound bitter/angry, it's probably because I've been doing it for too long and grown tired of how tedious and limited it is.

jules 15y ago

Google's Native Client [1] is one answer. It allows you to run native code safely in the browser. It's goal is also to support LLVM IL to run safely in the browser. This way you could potentially use all your favorite languages at nearly full speed, and also have access to the DOM and other browser APIs. Another answer is to compile your favorite language down to Javascript. This gets you the expressiveness at the cost of a slowdown in runtime speed. Languages like Coffeescript are very close to Javascript so they don't incur much overhead by doing this, but even this approach can't go as fast as code running on Native Client. [1] http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/

neilk 15y ago

> Does anyone feel that sooner or later JS will probably turn out to be not-so-suitable for stuff we want to do ? Be more specific. Every programming language is not-so-suitable for stuff we want to do. > Are there any attempts being made to provide an reliable alternative or can JS itself evolve ? What's "unreliable" about JS? The lack of standardization in available features among browsers? That's an issue, but it will be dealt with, one way or another. C gained a huge infrastructure of tools and standards to make it more portable, and platforms that didn't or couldn't keep up are no longer used. This presentation from Velocity 2011 shows just how far JS has come. The author suggests that in the next iteration will be type inference in JS engines and/or optional explicit typing in the language. http://www.slideshare.net/newmovie/know-yourengines-velocity2011 http://www.slideshare.net/newmovie/know-yourengines-velocity...

dstein 15y ago

The number of new features added to JavaScript in the past year is substantial. Between Canvas, WebGL, WebSockets, WebWorkers, Audio Data, TouchEvents, the number of permutations of new kinds of browser-based apps you can build will keep anyone busy for years. Then add NodeJS, and CouchDB, and the use of JSON as a data interchange and there are things you can do entirely in JavaScript that no other language can do. If JavaScript continues to be improved (Harmony, V8/Spidermonkey engines, etc) then I see no other language on the horizon that will replace it.

kwamenum86 15y ago
Everything you listed actually has nothing to do with Javascript as a language. These are new frameworks for the and clientside APIs, not language features.
- dstein 15y ago
  That's like saying the addition of the DOM did not improve Javascript. Standardized API's do matter, and do improve programming languages.

ignifero 15y ago

I would like to see an alternative to the WWW altogether. WWW is no longer a collection of hyperlinked documents, which was its initial purpose but a multitude of technologies running on browsers that use HTTP in nonstandard ways because it's ubiquitous. HTML is getting obsolete, with the most popular websites being essentially javascript apps. Maybe it's time for a new system like Java to create cross platform GUI apps from the cloud, that is not constrained by the browser and HTTP's limitations.

lautis 15y ago
I believe the most popular website is essentially an interface for this collection of hyperlinked documents. Document browsing is still one of the killer features of web. HTML is not a bad layout engine for GUI apps. It may not have been initially been designed as one, but after 15 years of development it seems to be pretty pleasant to work with as there are people who want to build their desktop apps with HTML. Obviously, the standard request-response model of HTTP is limiting for interactive apps. Bi-directional communication within request isn't possible and handshaking is a bit too expensive. But hey, this problem is actually solved: http://dev.w3.org/html5/websockets/ http://dev.w3.org/html5/websockets/.

kenjackson 15y ago

I'd like to see a statically typed language available. There is relatively little I do that requires dynamic typing, but so much of my experience would be better with static typing. I'm not saying to get rid of JS, but it would be nice to have a first class alternative.

robin_reala 15y ago
JS is adding limited static typing in typed arrays: https://developer.mozilla.org/en/javascript_typed_arrays https://developer.mozilla.org/en/javascript_typed_arrays
- samth 15y ago
  Nothing about Typed Arrays is static typing.
Ruudjah 15y ago
Thanks. I thought I was the only one with this experience.

CLaRGe 15y ago

JavaScript will be superseded by, what else, C/C++. Right now there are no JavaScript killer applications on the web. Adobe and Microsoft tried with their respective wares, but Apple interceded and stopped both. It's hard to imagine now, but something will come along that, like web services, finds a slick way to give the folks what they want, performance. And that innovation will be written in C.

haikurion 15y ago

I think the execution of native code from the browser is slowly creeping in, in such a way that you'll be free to choose your language as you are in non-browser areas. Google native client, webGL and the ultra-new webCL are glimpses into the future. Javascript has served us well, but if we can avoid unnecessary computation as well as make use of existing code bases, then I am sure we will, eventually.

orangea 15y ago

http://altjs.org/ http://altjs.org/

sktrdie 15y ago

Frankly I really like JavaScript. I don't want the language to change, even though it has its flaws. I just love the ability to have data-structures as simple as objects and arrays which have evolved into a standard data exchange format (JSON). Then you can also have functions inside objects and everything becomes really flexible and really easy to design. I've tried many different languages, including the real pretty ones such as Ruby and Python, and I just have more fun using JavaScript because of how free-form it is.

Stiffy 15y ago
That flexibility is indeed useful for scripts and adding minor interactivity to an otherwise static web page. However, people are now using JavaScript for development that far exceeds those uses. JavaScript is just not suitable for larger applications. Once your application starts exceeding a few thousands of lines of code, the problems become very clear. You soon wish you were using a language like C++, Java, C#, Python, or Ruby. Toss in a development team made up of at least several people, if not more, and the pain becomes far greater.
- sktrdie 15y ago
  I was never able to personally judge that statement. My experiences show that the flexibility of JavaScript only improved maintainability of the software written in it. http://npmjs.org/ http://npmjs.org/ is a list of solid software (also large software) written in JavaScript. So I don't think your statement, about maintainability being connected with how flexible a language is, can be proven to be true.
  - Stiffy 15y ago
    By "larger applications", I wasn't talking about jQuery, Node.js or anything built upon them. I'm talking about real software systems with, at a very minimum, tens of thousands of lines of code. More realistically, we're talking systems with hundreds of thousands, if not several million, lines of code. C++ can scale up to codebases that large. Java and C# can handle it, as well. Even Python and Ruby can, if care is taken. JavaScript cannot. You'll be hitting numerous maintenance barriers far before then, when you're still well under 10,000 lines of code.

liquidcool 15y ago

While I realize that Flash is no longer in vogue these days, ActionScript 3 is a really nice language and I'm surprised nobody else has mentioned it. It provides things like optional static typing for speed improvements, code clarity, and improved tooling/refactoring, as well as classes and packages for organizing larger code bases. It's more of what Brendan Eich envisioned JavaScript 2 to be. That said, Apple is making it really hard for developers to choose it for all but intranet apps (for which it's really well suited). I second GWT and the responses here have prompted me to look into CoffeeScript, so thanks for asking this!

Detrus 15y ago

Mozilla is working on Rust https://github.com/graydon/rust/wiki/Language-FAQ https://github.com/graydon/rust/wiki/Language-FAQ. Google has Go http://golang.org/ http://golang.org/. To run compiled binaries from such languages you'll use Native Client http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ and Pepper APIs which let you access HTML5. Go gets rid of some insecure low level things like pointers, keeps such things in an unsafe package to discourage its use. They intend to make it seamlessly compatible with NaCl. C/C++ code needs to be modified to work there. JS is already not suitable for lots of stuff. Vendors are stretching its capabilities with big teams of fancy programmers implementing fancy VMs with big chunks written in assembler. At Google I/O they mentioned V8 is about as fast as it will get. Then bigger teams are writing massive APIs because even with fast VMs the language isn't fast enough to roll your own CSS/XAML/MXML/HTML parsers or 2D rendering contexts. So you're forced to wait or hack together things like LESS, CoffeeScript, Stylus in an attempt to communicate with the overlords. With the browsers becoming the operating system for many users, you need a runtime that's as powerful as a regular operating system. Google and Mozilla are major players and it's nice to see them exploring alternatives. But even if NaCl/Go is superior technologically, it may not overcome JavaScript's business and political momentum. As usual, technology is not chosen based on technological merit, but business considerations like legacy, lock in, etc. Perhaps NaCl/Go approach will succeed but it will be too little too late. Kinda feels that way with Flash and Browsers, they're finally serious platforms but might be too far behind Objective-C, C# and Java on mobiles.

jensnockert 15y ago

I don't think that the problem is that javascript is bad, but that it will kill most other scripting languages just by being in the right place at the right time. It will be harder and harder for ruby/python/perl/x to compete with js in the future just because people know js and because it essentially runs everywhere fast. WebCL, WebGL and friends will cover anything with extreme computational needs, and that will be everything you need to learn to write applications in the future, unfortunatly.

yottabyte47 15y ago

Check out http://runrev.com/ http://runrev.com/