3 ms·

Whether you like the model or not, the fact is that JavaScript with it's callback/event based model is what browsers understand. And the internet isn't going a

Whether you like the model or not, the fact is that JavaScript with it's callback/event based model is what browsers understand. And the internet isn't going anywhere anytime soon. Node is an attempt at using this successful model on the server too where is can solve massive scalability issues using the exact paradigm front-end devs already know. Also while there are many technical ways to make code look blocking, but really be running other events under the hood, it's this exact implicit running of "other stuff" that makes writing threaded code so hard. You have to assume that things can change between every function call because you don't know if somewhere down the chain it's doing pseudo-blocking. JavaScript's model is simple, you provide callbacks and you know exactly at what boundaries things can happen asynchronously. In summary, node is one way of doing it. We think it's a better model and it's proven itself in the browser. If you think another model is better, than by all means go for it! Let the leapfrogging begin ;)

_delirium 16y ago
I agree this is currently the best way of using similar models on both the client and server side. It'll be interesting to see if anything changes, on either side or both, when webworkers (browser threads) get more widespread support. At least it's likely that more direct comparisons of the programming models will be possible in the future.
jamwt 16y ago
I think javascript is a fine little language. But: I don't make my server-side language decisions based on what happens to be in the browser. To think that a language required for use in such a constrained environment is just _coincidentally_ also the best language to use server-side where people have been doing event-based programming for decades seems... unlikely. It would be as ridiculous as asserting that we should all use postscript in the browser because that's the standard we've been using in printers for the last 20 years. I suppose if you make the argument that browsers dictate that developers _must_ learn javascript, and therefore, with Node.js they can also program server-side without ever needing to learn a second language, that is a sound argument. I don't, however, know many good programmer that spend a career knowing exactly one language.
- creationix 16y ago
  I never said JavaScript is best language to use server-side. That would be insane. I'm just saying that it worked well for the browser (mostly because it was forced on us, but still) and node is an experiment to try the same thing on the server. It's a lot better than writing C, (which is what Ryan was doing before starting node) since JS has closures, anonymous functions and other functional niceties that make event based programming much easier. The fact that you can now code your server-side code in the same language and paradigm as your client-side code is a huge bonus, but was not the reason node was created. V8 is an amazing VM and it's a language that lots of talented developers know. Why not let them loose on the server and see what comes out of this talent. Given the constraint of using JavaScript on the server, node is the best solution. If you don't want that constraint, then maybe erlang or something with no-shared state is a better solution.
  - frognibble 16y ago
    Javascript might not even be the best language for the browser. The browser programming model was set in stone years before significant applications were built in the browser. If we had a choice about the browser programming model, then it seems likely that better programming models would have emerged based on the experience.

_delirium 16y ago

I agree this is currently the best way of using similar models on both the client and server side. It'll be interesting to see if anything changes, on either side or both, when webworkers (browser threads) get more widespread support. At least it's likely that more direct comparisons of the programming models will be possible in the future.

jamwt 16y ago

I think javascript is a fine little language. But: I don't make my server-side language decisions based on what happens to be in the browser. To think that a language required for use in such a constrained environment is just _coincidentally_ also the best language to use server-side where people have been doing event-based programming for decades seems... unlikely. It would be as ridiculous as asserting that we should all use postscript in the browser because that's the standard we've been using in printers for the last 20 years. I suppose if you make the argument that browsers dictate that developers _must_ learn javascript, and therefore, with Node.js they can also program server-side without ever needing to learn a second language, that is a sound argument. I don't, however, know many good programmer that spend a career knowing exactly one language.

creationix 16y ago
I never said JavaScript is best language to use server-side. That would be insane. I'm just saying that it worked well for the browser (mostly because it was forced on us, but still) and node is an experiment to try the same thing on the server. It's a lot better than writing C, (which is what Ryan was doing before starting node) since JS has closures, anonymous functions and other functional niceties that make event based programming much easier. The fact that you can now code your server-side code in the same language and paradigm as your client-side code is a huge bonus, but was not the reason node was created. V8 is an amazing VM and it's a language that lots of talented developers know. Why not let them loose on the server and see what comes out of this talent. Given the constraint of using JavaScript on the server, node is the best solution. If you don't want that constraint, then maybe erlang or something with no-shared state is a better solution.
- frognibble 16y ago
  Javascript might not even be the best language for the browser. The browser programming model was set in stone years before significant applications were built in the browser. If we had a choice about the browser programming model, then it seems likely that better programming models would have emerged based on the experience.