Live data from Hacker News

I finally escaped Node

acco.io

11–20 of 181 posts

Re: I finally escaped Node

#11
post #10

> data structures Spending too much time upfront thinking about the perfect data structure is a bad idea. Long walks on the beach and fasting is not going to deliver your perfect data structure. People (other than yourself) using your product and observing evolving requirements over time will reveal an optimal data structure. Rapid iteration and real-world usage is the key. I can’t count the number of times I thought…

> Why use a gendered pronoun here? It’s a bit unfair that the only non-specific gendered pronoun relates to a bad programming practice.

Spoiler alert, but making mistakes isn't just a male issue. Real representation means taking the bad with the good.

Re: I finally escaped Node

#12
post #8

I'm just getting in to Node, coming from only having used PHP and then Laravel. Is it a bad time? Using Sails.js for rapid prototyping.

No. Node is very widely used, it does work, and of course: A thing nobody criticizes is a thing nobody uses. I think you should be fine.

Re: I finally escaped Node

#13
post #8

I'm just getting in to Node, coming from only having used PHP and then Laravel. Is it a bad time? Using Sails.js for rapid prototyping.

I think you’ll probably be fine with node too. Different people gel with different languages for all sorts of different reasons.

I had done c++, java, bash, python, but it wasn’t until javascript, and specifically NodeJS that I really started enjoying programming.

I would start out with a lighter web framework than sails if you are just starting out, especially if you are new to web programming.

I initially started with sails too but found it was always getting in the way, making it difficult to figure out what was going on. Since it used express under the hood, I switched to Express and it was immediately 10x easier to build stuff. That was my experience.

These days I would probably be totally fine using any framework, but I’ve been mostly happy sticking with express.

Re: I finally escaped Node

#14
post #9

The article focuses on server-side Node, rather than its role as a CLI tool. Compared to V8, Ruby, Python, and PHP are not performant. Node’s libuv network library was highly concurrent and Node built single-core concurrency into the runtime and libraries; multi-core concurrency, however, is not best-of-class. IMO, Ryan Dahl made two fundamental mistakes in both Node and Deno that make them uncompetitive for simple s…

[deleted]

Re: I finally escaped Node

#15
post #10

> data structures Spending too much time upfront thinking about the perfect data structure is a bad idea. Long walks on the beach and fasting is not going to deliver your perfect data structure. People (other than yourself) using your product and observing evolving requirements over time will reveal an optimal data structure. Rapid iteration and real-world usage is the key. I can’t count the number of times I thought…

> Why use a gendered pronoun here? It’s a bit unfair that the only non-specific gendered pronoun relates to a bad programming practice. Spoiler alert, but making mistakes isn't just a male issue. Real representation means taking the bad with the good.

I agree. Women also code, which means we also make mistakes.

Equality means no mercy

Re: I finally escaped Node

#16

I agree with some points author is making, but overall I wouldn't put them either on Node.js runtime, or Node.js ecosystem. a) Erratic max latency IME Node.js performs well if you are not pushing its limits. If you have a service receiving 25k+ requests per second, you should better benchmark it, regardless of the language. Horizontal scaling should be configured based on the results of the benchmark. b) Cognitive ov…

> You know what's an even worse cognitive overhead? Languages without strong typing, like Elixir. I see this mentioned many times, but when I do my impression (which might be wrong) is that you haven't written Elixir or Erlang for any thing more serious than tutorials or docs examples. Besides, elixir is technically (?) strongly typed - but not statically typed. Regarding async/await, compared to the things you get i…

I've been using Elixir for five years and I think it's sorely missing a better type system. I've done fine without it and have gotten entirely used to it but that doesn't mean things wouldn't be better with one.

I only really started noticing as I started to build more complex Typescript systems how much it helps. My teammate shipped a bug in Elixir yesterday that would have been caught by a static type checker

Re: I finally escaped Node

#17
post #4

Earlier quoted context omitted.

> Languages without strong typing, like Elixir. Have you ever actually worked with elixir? In practice the (strong) dynamic typing of elixir is not a problem. I have not written a type error that has made it to prod in tens of thousands of lines of code. The last type error I made only showed up extremely rarely (once a week or so) and it didn't matter because the supervisory tree restarted the process that threw it.…

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.

Having spent a lot of time in both it's hard to argue it's as easy in Elixir. You can do it reasonably with a lot of tests but it's nowhere near the same experience as TS

Re: I finally escaped Node

#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 economically impossible to vet and review dependencies

- There'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's approach of updating patch versions upon installation, we have had too many broken builds from one day to another w/out code changes. The state of documentation of a lot of projects is non-existent.

- Lack of multi threading. We have used all the options, including RPC implementations, but that doesn't even come close to approaches like Java threads or go routines. Neither in performance, nor in maintainability.

- Lack of typing. That's probably the biggest one. Yes, we use TypeScript, quite extensively even. But TypeScript brings its own problems. First, it's only declarative. If you have a `something: number`, there's no guarantee that it'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'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.

Is node a bad technology? Not at all. I'd not chose it for enterprise, big or long-lived projects, though. It's a very good technology for a lot of things, especially smaller projects. We are building on Java + Spring Boot now.

Re: I finally escaped Node

#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 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).

On top, any organization can hire JS devs with relative ease. And the same devs can also use the same skills to build a frontend.

I am not a JS/TS/Node fan but unfortunately it seems we do not have a better story to sell right now and we are stuck here for a while.

Post reply on HN