coffeescript - it's just javascript, but with a touch of awesomeness.
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.
11–20 of 52 posts
coffeescript - it's just javascript, but with a touch of awesomeness.
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.
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 newe…
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.
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.
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.
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.
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 newe…
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 basicall…
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?
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...
Earlier quoted context omitted.
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 basicall…
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…
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.
If JavaScript continues to be improved (Harmony, V8/Spidermonkey engines, etc) then I see no other language on the horizon that will replace it.