<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>hn_throwaway_99</author><text>To each their own. I was a Java engineer for most of my career since the early 00s, switched to Node a couple years ago (primarily running Apollo GraphQL server in Node), and I find myself &lt;i&gt;so&lt;/i&gt; much more productive now. Addressing each of your points:&lt;p&gt;1. Yes, I think it&amp;#x27;s true that server-side Node isn&amp;#x27;t really usable without tight reliance on NPM. That said, I think NPM has improved by leaps and bounds over the past few years and it now makes it quite easy to have a stable and secure set of dependencies. Integrating our build with npm audit (and audit-resolver) and other tools like snyk, using package lock files, and keeping dependencies up-to-date on a regular schedule has worked very well for us.&lt;p&gt;2. Again, I think the NPM ecosystem has settled down in the past few years and I don&amp;#x27;t see as much churn. While there has been some issues with large projects (e.g. lodash and moment) going into hibernation, that&amp;#x27;s been fine for us.&lt;p&gt;3. I&amp;#x27;ve found all of our uses for multithreading were better served by having an event system publish events that were then handled by serverless functions. The &lt;i&gt;lack&lt;/i&gt; of multithreading, and the way Node manages concurrency, has been a godsend. Just check out the recent GitHub report where they were accidentally leaking information from &lt;i&gt;other users&lt;/i&gt; into their sessions.&lt;p&gt;4. Typescript (combined with autogenerating typescript type files from GraphQL schema definitions) has been honestly heaven for us, and the benefits I&amp;#x27;ve seen with the structural-based typing of TS made me realize the huge number of times I had to battle the nominal-based typing of Java and the immense pain that caused.</text><parent_chain><item><author>cygned</author><text>We went away from node as a backend technology for a bunch of reasons. Here&amp;#x27;s a list of the biggest pain points:&lt;p&gt;- Lack of a good standard API; compared to environments like Java, C# or Go, node&amp;#x27;s standard library is significantly sparse.&lt;p&gt;- The tendency for small libraries&amp;#x2F;frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it&amp;#x27;s economically impossible to vet and review dependencies&lt;p&gt;- There&amp;#x27;s a tendency in the ecosystem to abandon projects rather soon (~1-2 years) and to keep changing things. Further, we have had several situations where maintainers did not respect semver, combined with npm&amp;#x27;s approach of updating patch versions upon installation, we have had too many broken builds from one day to another w&amp;#x2F;out code changes. The state of documentation of a lot of projects is non-existent.&lt;p&gt;- Lack of multi threading. We have used all the options, including RPC implementations, but that doesn&amp;#x27;t even come close to approaches like Java threads or go routines. Neither in performance, nor in maintainability.&lt;p&gt;- Lack of typing. That&amp;#x27;s probably the biggest one. Yes, we use TypeScript, quite extensively even. But TypeScript brings its own problems. First, it&amp;#x27;s only declarative. If you have a `something: number`, there&amp;#x27;s no guarantee that it&amp;#x27;s actually a number upon execution, so if you have a bug in a layer interacting with another system, that might fail a couple levels deep. You hence end up with type checks at some places and you cannot really trust it anyway. Second, TypeScript&amp;#x27;s tooling is slow and has some annoying quirks (e.g. aliases not being resolved upon compilation). Having aliases allowing to shorten import paths is a big, big win, though. Third, the typing, given the complexity of JavaScript, can be confusing, sometimes even seemingly impossible to get right.&lt;p&gt;Is node a bad technology? Not at all. I&amp;#x27;d not chose it for enterprise, big or long-lived projects, though. It&amp;#x27;s a very good technology for a lot of things, especially smaller projects. We are building on Java + Spring Boot now.</text></item></parent_chain></comment><story><title>I finally escaped Node</title><url>https://acco.io/i-escaped-node</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>FlyingSnake</author><text>I would upvote this comment a hundred times if I could. I had got a Node project in my previous gig and I hated it every minute. The team got immensely productive when we migrated it to Golang.&lt;p&gt;In the times of RESTful APIs and µServices, is there really a need for node? JVM, C#, Elixir, Golang etc provide excellent development experience and are battle tested the way single-threaded Node just hasn&amp;#x27;t been.</text><parent_chain><item><author>cygned</author><text>We went away from node as a backend technology for a bunch of reasons. Here&amp;#x27;s a list of the biggest pain points:&lt;p&gt;- Lack of a good standard API; compared to environments like Java, C# or Go, node&amp;#x27;s standard library is significantly sparse.&lt;p&gt;- The tendency for small libraries&amp;#x2F;frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it&amp;#x27;s economically impossible to vet and review dependencies&lt;p&gt;- There&amp;#x27;s a tendency in the ecosystem to abandon projects rather soon (~1-2 years) and to keep changing things. Further, we have had several situations where maintainers did not respect semver, combined with npm&amp;#x27;s approach of updating patch versions upon installation, we have had too many broken builds from one day to another w&amp;#x2F;out code changes. The state of documentation of a lot of projects is non-existent.&lt;p&gt;- Lack of multi threading. We have used all the options, including RPC implementations, but that doesn&amp;#x27;t even come close to approaches like Java threads or go routines. Neither in performance, nor in maintainability.&lt;p&gt;- Lack of typing. That&amp;#x27;s probably the biggest one. Yes, we use TypeScript, quite extensively even. But TypeScript brings its own problems. First, it&amp;#x27;s only declarative. If you have a `something: number`, there&amp;#x27;s no guarantee that it&amp;#x27;s actually a number upon execution, so if you have a bug in a layer interacting with another system, that might fail a couple levels deep. You hence end up with type checks at some places and you cannot really trust it anyway. Second, TypeScript&amp;#x27;s tooling is slow and has some annoying quirks (e.g. aliases not being resolved upon compilation). Having aliases allowing to shorten import paths is a big, big win, though. Third, the typing, given the complexity of JavaScript, can be confusing, sometimes even seemingly impossible to get right.&lt;p&gt;Is node a bad technology? Not at all. I&amp;#x27;d not chose it for enterprise, big or long-lived projects, though. It&amp;#x27;s a very good technology for a lot of things, especially smaller projects. We are building on Java + Spring Boot now.</text></item></parent_chain></comment><story><title>I finally escaped Node</title><url>https://acco.io/i-escaped-node</url></story>