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 ?
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/) 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) and the Bullet physics engine (http://www.syntensity.com/static/bullet.html) are both particularly impressive.
* Google Web Toolkit (http://code.google.com/webtoolkit/) compiles Java to JavaScript. It's used in many real projects. Scala+GWT (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/, 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-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.
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.
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.
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.
To run compiled binaries from such languages you'll use Native Client 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.
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 ).
Javascript really is going to be a development powerhouse for the foreseeable future. And i'm actually happy about that.
The logical conclusion of this line of argument is pretty much NaCL: 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.
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/ (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?
On the expressiveness front: Javascript doesn't support proper lexical scoping. It's object model is broken. It doesn't use proper abstractions in the standard library. Etc. These can all be fixed by compiling another language to Javascript, but then you lose on the performance side.
CoffeeScript incurs no penalty when compiling to Javascript; in fact, in many cases it's faster than handwritten code.
No, that's the wrong way of thinking about it entirely.
When you create a language, you must unavoidably privilege some ways of thinking and working above others. You must make some things easier, at the expense of making some things harder. There's no one set of answers that works universally.
Suppose I want to make an immutable language. Can I program Javascript purely immutably? Well... sort of. You can try, anyhow, but you'll get no help from the compiler, and any existing libraries will be all but useless, it's really a new language. Suppose I want to prove things in Javascript; with both mutable values and object prototypes that can be freely rewritten at any time, it's infeasible. Suppose I need C++; where's my private variables? Expressable? Sure. Useful? No; Javascript has made them much harder while working on making its object system powerful in different ways. That's not a criticism; a language has to make some things harder when it makes some things easier, to be a criticism I'd have to be calling it a "bad tradeoff", which in most cases it isn't.
It's not whether a thing can be done, it's how well it can be done, and Javascript isn't the best at everything. And "how well" something can be done matters, because the harder you make it, the less likely someone is to do it. No amount of theorizing how that doesn't have to be the case will change that.
There's nothing that any Turing Complete language can't do (with the proper hooks into the machine it's running on, anyhow), but no one language can be the best choice for everything. I wouldn't want to try to make an OS out of Javascript. Now, I personally wouldn't want to try to make one out of C particularly either, but Javascript would be even worse.
So either we lock all those apps out of the browser, or we make them much harder to write than they would be in a language actually suited to them. There's a time for C and a time for assembler and a time for Haskell and a time for C# etc. etc. Languages profoundly affect what gets written in them.
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".
I'm not saying to get rid of JS, but it would be nice to have a first class alternative.
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 :-) ).
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!
If JavaScript continues to be improved (Harmony, V8/Spidermonkey engines, etc) then I see no other language on the horizon that will replace it.
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.
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.
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.
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.
I think your experience with JavaScript comes from reading code made by bad developers. If your software is written by good people it will be maintainable even in JavaScript.
Nothing of this is related to the free-formness of JavaScript. Python and Ruby are also dynamically typed.
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.
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.
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-velocity...
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.
That's already been done: http://code.google.com/chrome/nativeclient/
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/.
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.