3 ms·
As a long time writer of JavaScript I say bring it on. If you want JavaScript to succeed outside client browsers in a big way you must to consider performance.
by swannodette 15y ago
As a long time writer of JavaScript I say bring it on. If you want JavaScript to succeed outside client browsers in a big way you must to consider performance. If it wasn't for incredible perf gains in the past couple of years you would not see JavaScript pushing into the server side.
However JavaScript performance still leaves much to be desired - http://stackoverflow.com/questions/6216888/is-nodejs-faster-than-clojure http://stackoverflow.com/questions/6216888/is-nodejs-faster-....
I want JavaScript to close the gap without sacrificing dynamism. And it won't - these feature are entirely optional and they free the implementors to make assumptions which allow further optimization.
"Pay for what you use"
To be totally honest I don't see myself writing plain JavaScript much longer, I'm closing in on 7 years now. At work I use quite a bit of CoffeeScript and very likely in the near future I'll leverage ClojureScript.
- true_religion 15y agoWhy not allow for C extensions to Javascript, and create a compiler capable of easy generation of these extensions with optional typing? An example of this would be Cython for Python, which lets you get to C speed within 1 to 5% slow down due to interfacing with Python, and it has you write in a Pythonic dialect of C/C++.
- william42 15y agoBecause, all else being equal, writing your code in one language is better than writing your code in two languages.
- chromatic 15y agoWhy not allow for C extensions to Javascript... Because that's a terrible, stop-gap optimization strategy. You can't JIT over the FFI boundary without some heroic API, and distributing compiled/compilable code is quite a hassle.