4 ms·

Isn't it just the case that nodejs is the least worst way of writing a concurrent web server? we know it's not perfect, but what is?

by mslider 12y ago

pjc50 12y ago
A whole class of programmers have learnt to write continuation-passing code in Javascript for asynchronous operations, as that's the way AJAX works. Moreover, it's the only way you can do things in the browser. Node is web-browser style javascript programming, detached from the browser GUI and given the ability to accept inbound connections. Along with this has come a whole slew of fun wheel-reinvention around frameworks and templating engines.
bphogan 12y ago
I'd like to think that if we weren't all watching Node we'd have more people to pitch into other things. I hear a lot of bluster about "learn new things" but I often just see people sticking with what they know. When the bright minds of web development are figuring out new ways to make JavaScript less awful, those minds aren't focusing on other solutions. FWIW I think Elixir holds a lot of promise for the future. Projects like https://github.com/dynamo/dynamo https://github.com/dynamo/dynamo look really cool. Of course, it's new, and alpha. But maybe we could all give it a try?
- wcummings 12y ago
  Erlang pretty much blows Node.js out of the water, in terms of sophistication of concurrency primitives (to mention one thing). Erlang is really just syntax on top of BEAM, which is pretty tailored to the language (you'll notice Elixir and Erlang share identical types etc). Elixir adds some nice metaprogramming features, and I love that it exists. Erlang is used for a lot of Important Things in production, and its value to many developers is stability and fault tolerance. Erlang moves slow. It's nice to see a sister language that can more rapidly develop new language features (maybe some of the goods ones will get added to Erlang (: Joe Arms post about Elixir is pretty interesting [1] [1] http://joearms.github.io/2013/05/31/a-week-with-elixir.html http://joearms.github.io/2013/05/31/a-week-with-elixir.html
meritt 12y ago
I'd argue the simple approach of having a web server (nginx, apache) send requests to a pool of workers (perl, php, python, ruby) is considerably superior.
- aikah 12y ago
  the problem is can workers do something else while waiting for the db to respond? AND are all libs built for that use case? tbe only advantage of nodejs is you have no choice but to write code a certain way.
  - general_failure 12y ago
    The biggest webservices of today like google search, facebook, aws are all written using models that your parent suggests. Are you saying if these guys rewrite all their code in Go, they will basically cut down 50% of their operation costs or something? What exactly does 'worker can do something else' translate to?
  - erjiang 12y ago
    Technically, yes - the workers can be multithreaded. If you put multithreaded workers behind an event-loop web server (both nginx or apache can do this), then they can handle many http keep-alives as well. It's not the same thing as using an event loop throughout the whole stack, but it's pretty effective.
  - meritt 12y ago
    When you take the time to learn relational databases, sql, normalization and maybe some caching, suddenly you don't find yourself spending very much time waiting on the DB. If something indeed is going to take that long, perhaps you shouldn't be making the user wait on it either. Queue that shit.
voidlogic 12y ago
I've spend a lot of time porting node.js code to Go. While the Go applications typically get an unfair benefit of being the result of the refactor, they have without fail (in my XP) had similar to drastically better runtime characteristics, while I would argue (and my teammates agree), being much simpler to read and maintain. I have have written a few web apps in Go as well spending most of my time writing things like high performance proxies, CDNs and databases in Go, and IMHO Go is a "more least worst" way to write highly concurrent code compared to node.

Isn't it just the case that nodejs is the least worst way of writing a concurrent web server? we know it's not perfect, but what is?

by mslider 12y ago

Isn't it just the case that nodejs is the least worst way of writing a concurrent web server? we know it's not perfect, but what is?

pjc50 12y ago

A whole class of programmers have learnt to write continuation-passing code in Javascript for asynchronous operations, as that's the way AJAX works. Moreover, it's the only way you can do things in the browser. Node is web-browser style javascript programming, detached from the browser GUI and given the ability to accept inbound connections. Along with this has come a whole slew of fun wheel-reinvention around frameworks and templating engines.

bphogan 12y ago

I'd like to think that if we weren't all watching Node we'd have more people to pitch into other things. I hear a lot of bluster about "learn new things" but I often just see people sticking with what they know. When the bright minds of web development are figuring out new ways to make JavaScript less awful, those minds aren't focusing on other solutions. FWIW I think Elixir holds a lot of promise for the future. Projects like https://github.com/dynamo/dynamo https://github.com/dynamo/dynamo look really cool. Of course, it's new, and alpha. But maybe we could all give it a try?

wcummings 12y ago
Erlang pretty much blows Node.js out of the water, in terms of sophistication of concurrency primitives (to mention one thing). Erlang is really just syntax on top of BEAM, which is pretty tailored to the language (you'll notice Elixir and Erlang share identical types etc). Elixir adds some nice metaprogramming features, and I love that it exists. Erlang is used for a lot of Important Things in production, and its value to many developers is stability and fault tolerance. Erlang moves slow. It's nice to see a sister language that can more rapidly develop new language features (maybe some of the goods ones will get added to Erlang (: Joe Arms post about Elixir is pretty interesting [1] [1] http://joearms.github.io/2013/05/31/a-week-with-elixir.html http://joearms.github.io/2013/05/31/a-week-with-elixir.html

meritt 12y ago

I'd argue the simple approach of having a web server (nginx, apache) send requests to a pool of workers (perl, php, python, ruby) is considerably superior.

aikah 12y ago
the problem is can workers do something else while waiting for the db to respond? AND are all libs built for that use case? tbe only advantage of nodejs is you have no choice but to write code a certain way.
- general_failure 12y ago
  The biggest webservices of today like google search, facebook, aws are all written using models that your parent suggests. Are you saying if these guys rewrite all their code in Go, they will basically cut down 50% of their operation costs or something? What exactly does 'worker can do something else' translate to?
- erjiang 12y ago
  Technically, yes - the workers can be multithreaded. If you put multithreaded workers behind an event-loop web server (both nginx or apache can do this), then they can handle many http keep-alives as well. It's not the same thing as using an event loop throughout the whole stack, but it's pretty effective.
- meritt 12y ago
  When you take the time to learn relational databases, sql, normalization and maybe some caching, suddenly you don't find yourself spending very much time waiting on the DB. If something indeed is going to take that long, perhaps you shouldn't be making the user wait on it either. Queue that shit.

voidlogic 12y ago

I've spend a lot of time porting node.js code to Go. While the Go applications typically get an unfair benefit of being the result of the refactor, they have without fail (in my XP) had similar to drastically better runtime characteristics, while I would argue (and my teammates agree), being much simpler to read and maintain. I have have written a few web apps in Go as well spending most of my time writing things like high performance proxies, CDNs and databases in Go, and IMHO Go is a "more least worst" way to write highly concurrent code compared to node.