Live data from Hacker News

I finally escaped Node

acco.io

71–80 of 181 posts

Re: I finally escaped Node

#71
post #48
post #43

Earlier quoted context omitted.

How do you feel about the impact on developer productivity after migrating to Java + Spring Boot? I haven't used Java in a long while and every time that I try to come back to it, I get driven away by the difficulty and complexity to do simple things (thinking of annotations, dependency injection, complicated design patterns). It feels like an effort of one hour of Node or Python programming (or even Go) would take 1…

Great question. I was very concerned about that, too. I strongly recommend learning Domain Driven Design before diving into Spring, you will recognize a lot of patterns and it then makes sense how things work. Even things like having an interface + an implementation for basically everything becomes apparent. I had a lot of bad experience with Spring and Jakarta EE in the past, but I can assure you Spring Boot does a…

+1 for DDD in any strong-type-first language like Java or C#. Even if you land in a system that was designed horizontal-layer "at speed", you can retrofit good language, aggregate boundaries and migrate to a world away from spaghetti. Speaking as someone who usually works on code bases 10+ years old.

Great comment, and the root comment too.

Re: I finally escaped Node

#72
post #19

We went away from node as a backend technology for a bunch of reasons. Here's a list of the biggest pain points: - Lack of a good standard API; compared to environments like Java, C# or Go, node's standard library is significantly sparse. - The tendency for small libraries/frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it's econo…

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 so much more productive now. Addressing each of your points:

1. Yes, I think it's true that server-side Node isn'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.

2. Again, I think the NPM ecosystem has settled down in the past few years and I don't see as much churn. While there has been some issues with large projects (e.g. lodash and moment) going into hibernation, that's been fine for us.

3. I'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 lack 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 other users into their sessions.

4. Typescript (combined with autogenerating typescript type files from GraphQL schema definitions) has been honestly heaven for us, and the benefits I'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.

Re: I finally escaped Node

#73
post #38
post #33

Earlier quoted context omitted.

Because otherwise you end up with thousands of incomplete and incompatible implementations all fighting to be the best or running out of steam after a month or two. Node is a hellscape from a db perspective

Most people have moved on from ORMs and the like, since most DBs are not SQL anymore and supporting all of the different DB types is just too hard.

I'm not sure I could disagree more.

I'd phrase it more like "ORMs are as popular as they always were, most DBs today are SQL DBs, same as always, and the only recent change in the last 10 years is people have stopped speculating that NoSQL is going to replace SQL DBs, and accepted they will be, at most, specialised tools for niche uses.".

Obviously that's just my subjective opinion, but the Stack Overflow 2020 dev survey (https://insights.stackoverflow.com/survey/2020#technology-da...) has it MySQL, Postgres, MS SQL Server, SQLite, MongoDB. DB Engines (https://db-engines.com/en/ranking) has it as Oracle, MySQL, MS SQL Server, Postgres, MongoDB, and in both cases there's a STEEP falloff after the top couple entries.

I'm not sure either of those is a super reliable source, but I don't know of any better ones.

Re: I finally escaped Node

#74
post #19

We went away from node as a backend technology for a bunch of reasons. Here's a list of the biggest pain points: - Lack of a good standard API; compared to environments like Java, C# or Go, node's standard library is significantly sparse. - The tendency for small libraries/frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it's econo…

How do you share code between client and server? That's key

Re: I finally escaped Node

#75
post #68
post #19

We went away from node as a backend technology for a bunch of reasons. Here's a list of the biggest pain points: - Lack of a good standard API; compared to environments like Java, C# or Go, node's standard library is significantly sparse. - The tendency for small libraries/frameworks leads to a very high number of third party code with all the problems attached; bigger attack surface, licensing challenges, it's econo…

- Lack of a good standard api: I don't understand this one. I've never had a problem with its documentation and the API always seemed fine to me, but I don't use C# or Go so maybe I'm missing out? - There's a tendency in the ecosystem to abandon projects rather soon: This can certainly happen, but it's important to choose libraries and frameworks carefully. My node servers (Express.js) are extremely light weight, so…

Was the Java utility one that started and didn't run for very long, like a command line application? The JVM (at least the Oracle one) takes a long time to start up, so any application that runs on the JVM takes a long time to start up. The JVM is much better for long running processes.

Re: I finally escaped Node

#76
post #31

Earlier quoted context omitted.

You can do this with any web framework.

You are right, pretty much any modern web framework. So my original point still stands :)

Your original point was that node.js has an edge because it has something nobody else has - low memory footprint, low latency, quick time-to-market, scalable. If the response is that "any modern web framework"can do it, then your point does not stand at all.

Re: I finally escaped Node

#77
post #20

From the title, I was expecting the article on something along the lines of how, where and why developers can move from Node.js. However the arguments are not so solid and there is no migration path. We all know Elixir is great but the adoption and maturity is low as compared to JS. Yes, Node is not perfect but (with TypeScript added) tell me a development platform that can run under 100 MB of memory, handle most req…

> tell me a development platform that can run under 100 MB of memory, handle most requests under 50 ms, can spin up a http service in a day or so and still perform well under load (and scales horizontally with ease). I'll plug Vert.x here but just about anything these days depending on your workload. > can spin up a http service in a day Surely this is a typo?

Vert.x is flat out amazing. For node developers, I recommend them taking a look at using it with Kotlin. A Typescript developer can feel awfully "at home" writing a Vert.x/Kotlin web service.

Re: I finally escaped Node

#79
post #7

Earlier quoted context omitted.

How is refactoring? I was considering moving from Node to Elixir, but now that I’m using TypeScript it does feel like I would be giving something up. It’s a breeze to make broad changes knowing the compiler will prevent me from missing a code path, etc.

Write your tests, gradually make red go to green. Super rewarding. Code coverage reports are a thing. You should be writing your tests async (including tests that leave the VM) in elixir, that will give you a chance to catch and raise asserts on race conditions which will stress ouct timings in your vm, etc. https://youtu.be/hvgdWQuriB4

Thanks for sharing this, looks like a really useful series of videos :)

Re: I finally escaped Node

#80
Javascript these days is a very productive language, especially with Typescript. Node however, with its lack of a remotely passable standard library, is not doing it justice.

The async await is amazing and top level await works just fine in a browser console. The fact that node still has it behind a flag is... I mean, they surely have their reasons and I don't know enough to question the decisions of the maintainers, but it feels detached from modern times when using.

Node is not web, don't know why they hesitate so much before remotely breaking things. I'm not advocating for moving fast and breaking things, remind you, I'm just saying that the io.js kick maybe needs to happen again.

Post reply on HN