3 ms·

One can do a great many things with disciplined Javascript, and I shudder to think what Twitter was trying to do on their front-end that caused a 5x increase in

One can do a great many things with disciplined Javascript, and I shudder to think what Twitter was trying to do on their front-end that caused a 5x increase in load time compared to server-side template-rendering. That being said, I would very much welcome a high-performance alternative to Javascript that also runs in any browser -- something in the spirit of C or Java, which could be embedded in Javascript and vice versa.

gavanwoolery 13y ago
I agree - but moreover, I'd like to see a single, cohesive replacement for the whole web stack. One standardized language to handle styling, scripting, server-side, and the document (in fact, let's just get rid of the notion of a document - we are building dynamic applications now, not documents). I understand that one reason we have separate languages is in light of security, but I think this could be made even better with special permissions (like unix file permissions but for code functionality/access).
- GeneralMayhem 13y ago
  Client- and server-side code is separated in literally every application to use a network, because they must necessarily be run on different computers. In most applications they can be the same language (C, C++, Java, etc.), but they have to be separate programs. I think what you're mostly complaining about is the JS lock-in on the browser side, which is a legitimate complaint, but a different one. re:HTML - What's the difference between a dynamic document and a dynamic application, really? With JS and CSS3, HTML is unrecognizable - pair it with something like Backbone.Marionette, and the only thing HTML is doing is defining your display in a structured way, more like the XML definitions of an Android view than an old-school document.
steveklabnik 13y ago
You should check out ASM.js. It might not strictly be necessary to get a new universal language. It's a really interesting project.
breckinloggins 13y ago
> That being said, I would very much welcome a high-performance alternative to Javascript that also runs in any browser -- something in the spirit of C or Java, which could be embedded in Javascript and vice versa. Possible steps in that direction: - Google Native Client: run native code in a sandbox [1] - asm.js: A strict subset of JavaScript that can be optimized to native or near-native speed [2] I much prefer the asm.js approach. I agree that there's a need for NaCl, but if we look at the browser as a sandboxed virtual machine that everyone has, we should all agree on a bytecode specification for that virtual machine. We pick JavaScript "because it is there". Once all browsers speak native asm.js, then you can compile your client-side code in whatever language you want, even C/C++ (see Emscripten for example). [3][4] [1] https://developers.google.com/native-client/ https://developers.google.com/native-client/ [2] https://blog.mozilla.org/mbest/2013/06/25/asm-js-its-really-fast-backwards-compatible-and-now-in-the-release-version-of-firefox/ https://blog.mozilla.org/mbest/2013/06/25/asm-js-its-really-... [3] https://github.com/kripken/emscripten https://github.com/kripken/emscripten [4] http://games.slashdot.org/story/13/03/28/2113234/emscripten-and-new-javascript-engine-bring-unreal-engine-to-firefox http://games.slashdot.org/story/13/03/28/2113234/emscripten-...
gsnedders 13y ago
Basically, what Twitter did was load a bare wireframe that loaded JS, and then that made a request to the server to get the content. If you cut out the second request, you've instantly saved the latency before that second request is even made, as well as the extra roundtrip time.

gavanwoolery 13y ago

I agree - but moreover, I'd like to see a single, cohesive replacement for the whole web stack. One standardized language to handle styling, scripting, server-side, and the document (in fact, let's just get rid of the notion of a document - we are building dynamic applications now, not documents). I understand that one reason we have separate languages is in light of security, but I think this could be made even better with special permissions (like unix file permissions but for code functionality/access).

GeneralMayhem 13y ago
Client- and server-side code is separated in literally every application to use a network, because they must necessarily be run on different computers. In most applications they can be the same language (C, C++, Java, etc.), but they have to be separate programs. I think what you're mostly complaining about is the JS lock-in on the browser side, which is a legitimate complaint, but a different one. re:HTML - What's the difference between a dynamic document and a dynamic application, really? With JS and CSS3, HTML is unrecognizable - pair it with something like Backbone.Marionette, and the only thing HTML is doing is defining your display in a structured way, more like the XML definitions of an Android view than an old-school document.

steveklabnik 13y ago

You should check out ASM.js. It might not strictly be necessary to get a new universal language. It's a really interesting project.

breckinloggins 13y ago

> That being said, I would very much welcome a high-performance alternative to Javascript that also runs in any browser -- something in the spirit of C or Java, which could be embedded in Javascript and vice versa. Possible steps in that direction: - Google Native Client: run native code in a sandbox [1] - asm.js: A strict subset of JavaScript that can be optimized to native or near-native speed [2] I much prefer the asm.js approach. I agree that there's a need for NaCl, but if we look at the browser as a sandboxed virtual machine that everyone has, we should all agree on a bytecode specification for that virtual machine. We pick JavaScript "because it is there". Once all browsers speak native asm.js, then you can compile your client-side code in whatever language you want, even C/C++ (see Emscripten for example). [3][4] [1] https://developers.google.com/native-client/ https://developers.google.com/native-client/ [2] https://blog.mozilla.org/mbest/2013/06/25/asm-js-its-really-fast-backwards-compatible-and-now-in-the-release-version-of-firefox/ https://blog.mozilla.org/mbest/2013/06/25/asm-js-its-really-... [3] https://github.com/kripken/emscripten https://github.com/kripken/emscripten [4] http://games.slashdot.org/story/13/03/28/2113234/emscripten-and-new-javascript-engine-bring-unreal-engine-to-firefox http://games.slashdot.org/story/13/03/28/2113234/emscripten-...

gsnedders 13y ago

Basically, what Twitter did was load a bare wireframe that loaded JS, and then that made a request to the server to get the content. If you cut out the second request, you've instantly saved the latency before that second request is even made, as well as the extra roundtrip time.