5 ms·

If I am building an HTTP(S) API server that is I/O heavy (which many are), I will pick Node every time until something else comes along to replace it. That is w

by rpedela 13y ago

If I am building an HTTP(S) API server that is I/O heavy (which many are), I will pick Node every time until something else comes along to replace it. That is what Node is specifically designed for and does it well. What is really great is that almost all non-trivial Node modules are also async, support streams, etc. I don't have to add a bunch of wrapper code to make some module/library behave async which I have to do in many of the other popular languages (C++, Java, Python, etc). Now is Node the best for everything? Nope, definitely not. I do agree with you that being able to share code between client and server is a poor argument. It is a rare case in my experience where anything but the most trivial JS code can be shared between client and server.

zaphar 13y ago
If I am building an HTTP(S) API server that is I/O heavy (which many are), I will pick Node every time until something else comes along to replace it. This is exactly what I'm talking about. There were languages/frameworks that beat node already out there before Node came along. It mystifies me why people think there weren't. Again the only motivation that actually makes any kind of sense for creating Node is shared code between client and server.
- rpedela 13y ago
  Yes. I am well aware of how to build an HTTP API server in many other languages. I have been doing this sort of thing for ~15 years which doesn't make me right, just experienced. The problem with most of those languages and frameworks is that as soon as you need something outside of that framework or core language, it is uncommon that the library is setup for async I/O, streaming, etc. You end up writing a lot of wrapper and/or glue code to string everything together. Or worse you find an amazing library, but because of its design it is difficult to make it do what you want so you resort to reinventing the wheel albeit poorly. Because of the nature of Node and its module ecosystem, much of that problem is solved. It isn't about using Node because it is cool or I like Javascript (which I hate BTW). It is about accomplishing my goal of an efficient HTTP API server much more quickly with Node than any of the other languages/frameworks that have come before. In my opinion, this is the niche Node does the best and if I have the choice I will choose it until another language/framework comes along to beat it.
  - blibble 13y ago
    every async io framework I've come across has something like runInThread(), which returns a callback. e.g. http://twistedmatrix.com/documents/10.1.0/core/howto/threading.html#auto1 http://twistedmatrix.com/documents/10.1.0/core/howto/threadi... not really much boilerplate...
    - rpedela 13y ago
      True, but now threads are involved. Which is totally fine and might be preferable depending on the use case. But for I/O specifically, utilizing select/poll/etc is usually faster, less memory overhead, and you don't need to add the complexity of threads. Like everything it depends on the use case. In my experience, threads are preferable when the API server does a lot of CPU work. But for I/O, select/poll/etc is usually preferable. It just depends. Node (and Javascript) is definitely missing proper support for threads which is a negative.

by rpedela 13y ago

zaphar 13y ago

If I am building an HTTP(S) API server that is I/O heavy (which many are), I will pick Node every time until something else comes along to replace it. This is exactly what I'm talking about. There were languages/frameworks that beat node already out there before Node came along. It mystifies me why people think there weren't. Again the only motivation that actually makes any kind of sense for creating Node is shared code between client and server.

rpedela 13y ago
Yes. I am well aware of how to build an HTTP API server in many other languages. I have been doing this sort of thing for ~15 years which doesn't make me right, just experienced. The problem with most of those languages and frameworks is that as soon as you need something outside of that framework or core language, it is uncommon that the library is setup for async I/O, streaming, etc. You end up writing a lot of wrapper and/or glue code to string everything together. Or worse you find an amazing library, but because of its design it is difficult to make it do what you want so you resort to reinventing the wheel albeit poorly. Because of the nature of Node and its module ecosystem, much of that problem is solved. It isn't about using Node because it is cool or I like Javascript (which I hate BTW). It is about accomplishing my goal of an efficient HTTP API server much more quickly with Node than any of the other languages/frameworks that have come before. In my opinion, this is the niche Node does the best and if I have the choice I will choose it until another language/framework comes along to beat it.
- blibble 13y ago
  every async io framework I've come across has something like runInThread(), which returns a callback. e.g. http://twistedmatrix.com/documents/10.1.0/core/howto/threading.html#auto1 http://twistedmatrix.com/documents/10.1.0/core/howto/threadi... not really much boilerplate...
  - rpedela 13y ago
    True, but now threads are involved. Which is totally fine and might be preferable depending on the use case. But for I/O specifically, utilizing select/poll/etc is usually faster, less memory overhead, and you don't need to add the complexity of threads. Like everything it depends on the use case. In my experience, threads are preferable when the API server does a lot of CPU work. But for I/O, select/poll/etc is usually preferable. It just depends. Node (and Javascript) is definitely missing proper support for threads which is a negative.