4 ms·

- Yes there are better tools individually for prototyping, perf, concurrency ... but Node does pretty well on all this points, so it's arguably a strong all rou

- Yes there are better tools individually for prototyping, perf, concurrency ... but Node does pretty well on all this points, so it's arguably a strong all rounder - Node's package manager npm is fantastic, and (imo) gets package management more right than 90% of other package managers - There are 1000s of high quality actively maintained modules on npm to get you started on things (and 1000s of garbage ones, so you have to be careful) - The "holy grail" web app architecture (server rendering of frontend JS components coupled with client side rendering in a SPA) is only possible by running some JS on the server - Sharing JS UI components between the backend and frontend is a huge DX and productivity win - Another huge maintenance win is using the same language across the whole stack (frontend, backend and devops/automation) - With ES6, JS is slowly turning into a pretty cute language, check it out :) - A nice level of cross-pollination between JS and those geniuses in the ClojureScript community is bringing some really nice functional programming approaches and projects to Node/JS - You can use Node and JS to compile to both native desktop apps and native mobile apps. Having a centralised UI library of JS components that you can leverage for your desktop app, mobile app, frontend SPA and backend static rendering sounds pretty good to me!

yulaow 11y ago
I would just like to disagree on the "high quality" of modules. Personally I worked for a year in a very long lasting project about a specific type of social network. In the team I was the first one to push for the use of nodejs, react and mongo and... my god if I regretted it. The quality of node package is very bad in general. Like the most part are totally garbage. I don't know from where you come and what you used before, I worked only with java, php and ruby for the backend and in those i found: - far higher Documentation quality... like, node modules documentation is not even REMOTELY comparable: it is often extremely outdated, with very poor examples, the most of the times these example are not even working or are using functions deprecated since 3-4 versions of the module itself. - a infinite amount of bugs and undocumented behaviors rarely already reported and, when reported, just ignored for months. I usually would find infinite workarounds instead of solutions - extreme use of "I can do it better, so here my fork". I passed the big part of the time running from bug report to bug report and reading in the comments discussions about "The main maintainer of this package does not want to solve this problem of mine... so i made this other module, totally identical to this one but I just added this little hack, which totally broke the standard way of doinf things of this module, some functionalities I needed and never implemented the last 8-9 months of commits here." and chain this. Like this happened a dozen time each months when someone suggested "Why we don't try this module that says it solve our needs?" - No standards anywhere.
- Wintamute 11y ago
  Maybe your team chose bad modules? You seem to know what a bad module looks like (bad docs, bugs, many forks, hanging PRs, undocumented behaviour), so why did your team use ones like that? It's true, you have to be careful ... there are so many npm modules that there are many garbage ones too. But there are many very high quality ones too. Be more careful about how you choose one, and if you can't find a good one for your needs, then don't settle for a bad one - roll the feature yourself, or adjust the functionality of your app. But in my experience there are high quality modules available for the major components of apps.
  - mgkimsal 11y ago
    > But there are many very high quality ones too. Doesn't mean there are any 'high-quality' ones appropriate for the specific task. > Be more careful about how you choose one, and if you can't find a good one for your needs, then don't settle for a bad one - roll the feature yourself, or adjust the functionality of your app. So now you're just contributing to the problem of yet another package in the ecosystem?
    - Wintamute 11y ago
      > Doesn't mean there are any 'high-quality' ones appropriate for the specific task. Yes, which is why I said if you can't find one then roll the feature yourself. > So now you're just contributing to the problem of yet another package in the ecosystem? Nope, I didn't say write and publish a npm module. I said "roll the feature yourself", meaning just write it privately for your app. Having lots of packages isn't bad for the ecosystem, it makes Node and npm unique and amazing. But picking bad npm modules, which is entirely avoidable, is bad for your project - that's all I meant.
      - mgkimsal 11y ago
        > Having lots of packages isn't bad for the ecosystem, it makes Node and npm unique and amazing. But picking bad npm modules, which is entirely avoidable, is bad for your project - that's all I meant. Having an ecosystem where, say, 70% of the choices I make can be 'bad' is probably not a great ecosystem. I hope it shakes out in the next year or so and there's less choice. There's enough choices I have to make in my own application layer - having to make X more choices about code I didn't write and how all those pieces fit together (and how they'll be maintained going forward) just doesn't feel like a good long-term platform. But... people have the 'choice' to use it if they want ;)
angersock 11y ago
I've heard a lot of observations about npm, but being unduly burdened with quality in package management has not yet been one of them! Bundler and hex, for example, are faaaar better--just consider how long it took them to figure out shrinkwrapping, or flat structure to support Windows.

yulaow 11y ago

I would just like to disagree on the "high quality" of modules. Personally I worked for a year in a very long lasting project about a specific type of social network. In the team I was the first one to push for the use of nodejs, react and mongo and... my god if I regretted it. The quality of node package is very bad in general. Like the most part are totally garbage. I don't know from where you come and what you used before, I worked only with java, php and ruby for the backend and in those i found: - far higher Documentation quality... like, node modules documentation is not even REMOTELY comparable: it is often extremely outdated, with very poor examples, the most of the times these example are not even working or are using functions deprecated since 3-4 versions of the module itself. - a infinite amount of bugs and undocumented behaviors rarely already reported and, when reported, just ignored for months. I usually would find infinite workarounds instead of solutions - extreme use of "I can do it better, so here my fork". I passed the big part of the time running from bug report to bug report and reading in the comments discussions about "The main maintainer of this package does not want to solve this problem of mine... so i made this other module, totally identical to this one but I just added this little hack, which totally broke the standard way of doinf things of this module, some functionalities I needed and never implemented the last 8-9 months of commits here." and chain this. Like this happened a dozen time each months when someone suggested "Why we don't try this module that says it solve our needs?" - No standards anywhere.

Wintamute 11y ago
Maybe your team chose bad modules? You seem to know what a bad module looks like (bad docs, bugs, many forks, hanging PRs, undocumented behaviour), so why did your team use ones like that? It's true, you have to be careful ... there are so many npm modules that there are many garbage ones too. But there are many very high quality ones too. Be more careful about how you choose one, and if you can't find a good one for your needs, then don't settle for a bad one - roll the feature yourself, or adjust the functionality of your app. But in my experience there are high quality modules available for the major components of apps.
- mgkimsal 11y ago
  > But there are many very high quality ones too. Doesn't mean there are any 'high-quality' ones appropriate for the specific task. > Be more careful about how you choose one, and if you can't find a good one for your needs, then don't settle for a bad one - roll the feature yourself, or adjust the functionality of your app. So now you're just contributing to the problem of yet another package in the ecosystem?
  - Wintamute 11y ago
    > Doesn't mean there are any 'high-quality' ones appropriate for the specific task. Yes, which is why I said if you can't find one then roll the feature yourself. > So now you're just contributing to the problem of yet another package in the ecosystem? Nope, I didn't say write and publish a npm module. I said "roll the feature yourself", meaning just write it privately for your app. Having lots of packages isn't bad for the ecosystem, it makes Node and npm unique and amazing. But picking bad npm modules, which is entirely avoidable, is bad for your project - that's all I meant.
    - mgkimsal 11y ago
      > Having lots of packages isn't bad for the ecosystem, it makes Node and npm unique and amazing. But picking bad npm modules, which is entirely avoidable, is bad for your project - that's all I meant. Having an ecosystem where, say, 70% of the choices I make can be 'bad' is probably not a great ecosystem. I hope it shakes out in the next year or so and there's less choice. There's enough choices I have to make in my own application layer - having to make X more choices about code I didn't write and how all those pieces fit together (and how they'll be maintained going forward) just doesn't feel like a good long-term platform. But... people have the 'choice' to use it if they want ;)

angersock 11y ago

I've heard a lot of observations about npm, but being unduly burdened with quality in package management has not yet been one of them! Bundler and hex, for example, are faaaar better--just consider how long it took them to figure out shrinkwrapping, or flat structure to support Windows.