Hacker News new | ask | show | jobs
by aledalgrande 2477 days ago
The main pain with Node, if you come from outside, is being able to know which modules are well supported, and will be for the years coming.

As an example, I spent quite a long time investigating ORM libraries for relational DBs, and the projects that were half dead were the majority.

Knex was suggested by everyone, but at that time the project leadership was changing so the future was uncertain. I settled on Sequelize, which had most of the functionality, but several points did not make sense:

- the documentation is hard to search

- I had to create a PR for sequelize-cli (separate module, that is not recommended for production!) to get the same functionality of `rails db:create`

- the syntax was changed to use Op instead of strings for security, in a minor version

- the way associations are defined is weird at best

- no support for ES6 in the cli, so all migrations are ES5

Etc.

And this is just for an API server. I looked into the frontend part and it was so much work.

I am still using Node for server processes when I have to, but I wouldn't recommend it over Rails. The way you can generate a simple app that does something useful, configure it and deploy it to Heroku in few hours is unchallenged.

3 comments

> know which modules are well supported, and will be for the years coming

Doesn't matter if you're coming from outside or not, no one can predict the future.

For example winston was probably the most recommended logging library (14k stars) and was a good recommendation at one point. But then they decided to do a rewrite for v3 which introduced a ton of bugs and incompatibilities. I spent several days trying to get it to log in the old format and failed and ended up downgrading back to v2.

This is a recurring theme in the js ecosystem (another example is react-router which is just a huge piece of shit and no one should depend on it despite its 37k stars).

Totally agree on the ecosystem being problem number one. A ton of modules that depend on a ton of other modules, poorly coded, not maintained, not tested.

Put on top the fact that NPM doesn't want to deal with version conflicts and installs 173 versions of the same package and you get a huge directory full of security warts.

I can kind of predict that Spring and Hibernate (Java) will be around the next 5 years.

The JS ecosystem is just immature.

Any suggestions for an alternative to react-router?
These replies to this question say it all for me. Routing should not be some library research task for the developer. How do I have time to review these packages and all of their million dependencies for security issues or just bad design.

No one does, they just throw it in production and hope whatever way they figure out how to get the thing they need done at that moment doesn't burn them later.

I would have said reach-router, as it seems fairly well thought through, is constrained, and was originally an attempt to correct deficiencies in react-router. But it's being merged into the next version of RR.

What anm89 says is on point. All solutions available are awful in their own special ways. If a router solution _is_ needed, and there's no chance you can't just rely on the browser history API, imo stick with RR despite it's major downsides, because at least there is the major benefit of vast community support; all solutions seem fairly shit otherwise (just cross your fingers you don't need to do any React Native work that needs a routing/navigation library cos hoo boy it's a shitshow)

Did you tried Router5( https://router5.js.org/ )

They have a react version. I experimented with it in one of the small projects i worked on. My experience was positive.

Most importantly, it's API is simple and easy to use.

My current favorite is Navi.

https://github.com/frontarm/navi

I had this issue recently where I wanted to revive an old side project I worked on a few years ago. The front-end was written with React + Redux + Webpack, which I assumed I would still be able to get running today, but it ended up turning into dependency hell (even though there were version numbers in the package.json, npm doesn't lock to those versions?!?).

The backend was written in Go, and I just ran go build and it worked without problems. The fact that it just worked without me having to change anything shows how important backwards compatibility is to that community.

The past few weeks I've been working on a backend Typescript project, and the number of packages I've seen that don't use semver or any similar versioning system makes me cringe. I even saw one that wore this as a badge of honour in their README :s If you release a library and you don't have a sensible versioning system, you are just making life harder for your users. (I'd argue for a CHANGELOG too - the GitHub releases section doesn't count)

NPM added the automatic lock file feature only after Yarn came up with it. I remember using Rails before Bundler was created. Man I don't wanna go through that ever again. Never use a package manager that doesn't cache versions!
FYI, if you want a decent Postgres client, check out `slonik` [0]. It doesn't support migrations, but there are other tools for that [1].

[0] https://github.com/gajus/slonik

[1] https://github.com/mmkal/slonik-tools