Live data from Hacker News

Soft deletion probably isn't worth it

brandur.org

511–514 of 514 posts

Re: Soft deletion probably isn't worth it

#511
post #454

Earlier quoted context omitted.

What percentage of production Node.js systems use Adonis? It's probably vanishingly low. Laravel is nice, and it's been gaining a lot of adoption in new applications, but the GP said "90s PHP" for a reason. Modern Node JS backends are often littered with hand rolled SQL queries, poor MVC separation, and lots of shoddy, half baked model layers—often without using any library whatsoever. Which is a real shame, because…

How is hand rolled SQL queries something bad?

Bad. Like really bad. Unless you're doing it for some small corner case where you need up to the list bit of performance, raw SQL queries and mapping them to objects or manually moving or many pulsating the result sets manually is really bad. Specially for others having to maintain your code 3 years later.

There's a reason ORMs are so popular.

Re: Soft deletion probably isn't worth it

#512

Earlier quoted context omitted.

I don't know why you're ragging on Node.js users or even PHP for that matter as both ecosystems have this stuff covered too. Also you're comparing language/runtime with an actual framework and then dogging those users... If you want to compare Rails with Node/PHP then I'd suggest comparing with things like Laravel (PHP), Adonis (Node) and you'll find everything you can do in Rails is done in Node/PHP too.

I have to admit I'm getting a bit of fatigue reviewing frameworks in Node that are claimed to be batteries-included and similar to Rails/Django/Laravel. SailsJS, Redwood, NestJS, Remix, Prisma (ORM compared to Active Record). They all have an exciting landing page, clean looking documentation... but once you dig in further the feature set starts looking very Anyways I appreciate the name drop of Adonis. I'll have to…

Most "full stack" frameworks in the node ecosystem consider themselves "full stack" just because you can run code on the server. See the Fresh (deno) discussion here in HN from a few weeks ago.

To me a framework which doesn't come with a clear way to do translations, background jobs, query builder, ORM, migrations, asset bundling, validations, error handling, etc it is not full stack. It is just "server code compatible" at best.

Re: Soft deletion probably isn't worth it

#513

Earlier quoted context omitted.

In rails you get these things for free. What I don't get is why everyone rolls their own framework with node.js. It's basically 90s PHP all over again. EDIT: Soft delete is a trivial piece of code when the framework has a well defined transaction system for its ORM. It's not really related to Rails per se. Your statement is extremely disingenuous, while trying to look smart. Audit trails _can_ be(but don't have to be…

> It's basically 90s PHP all over again. Which is funny because Laravel give you this for free as well through it's ORM. Soft deletes are an easily solved problem with $table->softDeletes() in your migration.

I think the key on this comment is "90s". Modern PHP is very different. As you say, Laravel makes trivial and a joy to use things that in 90s PHP are like today's node.

Re: Soft deletion probably isn't worth it

#514
post #454

Earlier quoted context omitted.

How is hand rolled SQL queries something bad?

Bad. Like really bad. Unless you're doing it for some small corner case where you need up to the list bit of performance, raw SQL queries and mapping them to objects or manually moving or many pulsating the result sets manually is really bad. Specially for others having to maintain your code 3 years later. There's a reason ORMs are so popular.

Personally I prefer the opposite, I have managed many old projects (10+ years old) and I always prefer raw SQL over some outdated ORM that is hard to configure and finetune. With SQL I have access to one of the most powerful query languages in existence that can never be matched by an database layer written in general purpose language.

Raw SQL can be a bit problematic if it is spread out in the entire code base with little structure ("littered"), however that is relatively easy to fix by centralizing the queries with a repository pattern. It is much harder to fix an ORM ten years later.

Do we know why ORM's are popular? I don't think it has to do with that ORM's are good, rather that developers want to avoid SQL because lack of experience, but that is me guessing based on my prejudice (I was myself in that category as a junior).

I have written in the past why ORM's are bad https://news.ycombinator.com/item?id=27407690

Post reply on HN