3 ms·
Server side dev folks have always enjoyed choice of language/system when it comes to building. You can simply choose the thing that works best for you, that you
by sriku 12y ago
Server side dev folks have always enjoyed choice of language/system when it comes to building. You can simply choose the thing that works best for you, that you're more comfortable with, is most performant for your app, etc. On the client side, we have ... javascript. While JS is pretty fast these days everywhere and we can cross compile with emscripten and all, I'm almost tempted to say that the true web standard for programmability on both client-side and server side ought to be some kind of a byte-code .. a concept the Java guys had right way back.
If you consider that we have PNaCl compiling llvm-bitcode to native within the browser, Emscripten cross compiling llvm-bitcode to asm.js (which Firefox's engine converts to native), Safari's engine compiling js itself to llvm-bitcode, I'm thinking why not make llvm-bitcode an open web standard? That way, any language that compiles to llvm-bitcode would be equally usable on the server side and on the client side.
The biggest potential downside to that would probably be educational. I learn a lot by looking at source code and the web was always open in that way, though with minified JS these days that's not so possible any more. However, it might make it easier to distribute source code in any language, since a module can then compile and run such code right in the browser.
edit: These thoughts came up when I was thinking about how TJ won't be able to take his work with him as he moves to Go. Well, I suppose he wants to do new kind of work for which Go is better suited, but is then all of the prior work just a brief view along the journey?