4 ms·

JavaScript conquers the server

31 points by gulbrandr 15y ago

gulbrandr 15y ago
"Just as businesses try desperately to avoid tying up capital in inventory, a programmer's job is to think like a factory boss, treat RAM as capital, and avoid consuming any of it. " I found this analogy excellent.
- cageface 15y ago
  This seems a little backwards to me. Wouldn't you want to make sure you're using every possible byte? Isn't this why Linux essentially uses all available ram for I/O caching? Obviously you don't want to waste memory, but if it's sitting there unused you're probably missing some caching opportunities.
  - dspillett 15y ago
    Yes and no. You want to use as much RAM as you have available, but for data not code. You want your code, including the framework it is using, to take as little RAM as possible - then there is more available for data (either held specifically in your structures or cached/buffered by the OS to avoid I/O operations).
  - JonnieCache 15y ago
    You should be utilising the maximum amount of the RAM that is available, while still requiring a minimal amount for the thing to run fast.
sktrdie 15y ago
They didn't mention my https://github.com/lmatteis/apejs https://github.com/lmatteis/apejs
- gulbrandr 15y ago
  Neither did they mention all server-side javascript solutions listed here: http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaS...
  - sktrdie 15y ago
    It was a joke, no need to downvote.
    - gulbrandr 15y ago
      It's not me.
jlind 15y ago
I enjoyed this article. I'm familiar with JavaScript but haven't really had the time to learn about these server-side engines. Great use of analogies to explain how some of them work.
gary4gar 15y ago
Article Summary: 1) Node.JS or other JavaScript platforms are NOT ready for prime-time. Only good for experimentation or prototyping. 2) For coding in callback style that javascript on servers needs, extreme discipline is required. Else, it will make your code hard to debug or maintain aka "callback hell". 3) Currently, projects like Node.js are not maintaining compatibility & things break often. that's not their current focus. This makes them unfriendly to enterprises. 4) Current state of Documentation is poor as the project are constantly changing at rapid pace. Tutorials just scratch the surface. 5) Event loop Style of programming is worth looking at for building real-time applications with thousands of concurrent users. 6) Some of ideas from Node.JS & other Javascript server side frameworks might be adopted into other languages.

31 points by gulbrandr 15y ago

"Just as businesses try desperately to avoid tying up capital in inventory, a programmer's job is to think like a factory boss, treat RAM as capital, and avoid consuming any of it. " I found this analogy excellent.

cageface 15y ago
This seems a little backwards to me. Wouldn't you want to make sure you're using every possible byte? Isn't this why Linux essentially uses all available ram for I/O caching? Obviously you don't want to waste memory, but if it's sitting there unused you're probably missing some caching opportunities.
- dspillett 15y ago
  Yes and no. You want to use as much RAM as you have available, but for data not code. You want your code, including the framework it is using, to take as little RAM as possible - then there is more available for data (either held specifically in your structures or cached/buffered by the OS to avoid I/O operations).
- JonnieCache 15y ago
  You should be utilising the maximum amount of the RAM that is available, while still requiring a minimal amount for the thing to run fast.

sktrdie 15y ago

They didn't mention my https://github.com/lmatteis/apejs https://github.com/lmatteis/apejs

gulbrandr 15y ago
Neither did they mention all server-side javascript solutions listed here: http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaS...
- sktrdie 15y ago
  It was a joke, no need to downvote.
  - gulbrandr 15y ago
    It's not me.

jlind 15y ago

I enjoyed this article. I'm familiar with JavaScript but haven't really had the time to learn about these server-side engines. Great use of analogies to explain how some of them work.

gary4gar 15y ago

Article Summary: 1) Node.JS or other JavaScript platforms are NOT ready for prime-time. Only good for experimentation or prototyping. 2) For coding in callback style that javascript on servers needs, extreme discipline is required. Else, it will make your code hard to debug or maintain aka "callback hell". 3) Currently, projects like Node.js are not maintaining compatibility & things break often. that's not their current focus. This makes them unfriendly to enterprises. 4) Current state of Documentation is poor as the project are constantly changing at rapid pace. Tutorials just scratch the surface. 5) Event loop Style of programming is worth looking at for building real-time applications with thousands of concurrent users. 6) Some of ideas from Node.JS & other Javascript server side frameworks might be adopted into other languages.