Live data from Hacker News

How to make websites that will require lots of your time and energy

blog.jim-nielsen.com

191–200 of 247 posts

Re: How to make websites that will require lots of your time and energy

#191

Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.

People love to rant about ORMs. But as someone who writes both raw SQL and uses ORMs regularly, I treat a business project that doesn’t use an ORM as a bit of a red flag. Here’s what I often see in those setups (sometimes just one or two, but usually at least one): - SQL queries strung together with user-controllable variables — wide open to SQL injection. (Not even surprised anymore when form fields go straight into…

ORMs can be the starting point to optimize the queries when they need it manually with SQL.

There's also the reality that no two ORMs may be built to the same way and performance standard.

Re: How to make websites that will require lots of your time and energy

#192

Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.

At the end of day its a trade off. It would be an exception if anyone can remember their own code/customization after 3 months. ORMs or frameworks are more or less conventions which are easier to remember cause you iterate on them multiple times. They are bloated for a good reason, to be able to server much larger population than specific use cases and yes that does brings its own problems.

Re: How to make websites that will require lots of your time and energy

#193

Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.

People love to rant about ORMs. But as someone who writes both raw SQL and uses ORMs regularly, I treat a business project that doesn’t use an ORM as a bit of a red flag. Here’s what I often see in those setups (sometimes just one or two, but usually at least one): - SQL queries strung together with user-controllable variables — wide open to SQL injection. (Not even surprised anymore when form fields go straight into…

I think people should go all-in on either SQL or ORMs. The problems you described usually stem from people who come from the ORM world trying to write SQL, and invariably introducing SQL injection vulnerabilities because the ORM normally shields them from these risks. Or they end up trying to write their own pseudo-ORM in some misguided search for "clean code" and "DRY" but it leads to homegrown magic that's flaky.

Re: How to make websites that will require lots of your time and energy

#194

Earlier quoted context omitted.

That sounds like an awesome idea for a new, post-React web framework. Instead of simply packaging up an entire web SPA "application" and sending it to the client on first load, let's package the SPA app AND the entire database and send it all - eliminating the need for any server calls entirely. I like how you think!

I can unironically imagine legitimate use cases for this idea. I’d wager that many DBs could fit unnoticed into the data footprint of a modern SPA load.

Yes, probably a lot of storefronts could package up their entire inventory database in a relatively small (comparatively) JSON file, and avoid a lot of pagination and reloads. Regardless, my comment was, of course, intended as sarcasm.

Re: How to make websites that will require lots of your time and energy

#195

Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.

Or just use MongoDB. No ORM needed.

Re: How to make websites that will require lots of your time and energy

#196

I have a good one(?): 1. be multiple developers on the same project. 2. for each developer, use your own tools and techniques, insist on only handling those parts of the site that you did with your tools, and insist on never fully understanding those remaining parts of the site the other devs did. This will allow for all sorts of fun, including: - A multiple inconsistent implementations of the same thing - B even bet…

omg. this is what it's currently like at work. and i was told not to bring up coding standards in retrospectives. yes, i am salty AF about this. i'm dying inside.

Re: How to make websites that will require lots of your time and energy

#197

Always use ORMs and then spend the next year debugging N+1 queries, bloated joins, and mysterious performance issues that only show up in prod. Migrations randomly fail, schema changes are a nightmare, and your team forgets how SQL works. ORMs promise to abstract the database but end up being just another layer you have to fight when things go wrong.

Funny, I use prisma and pothos, with p99 at below 50ms - no N+1 (when it is not lower, then it is because there are sec framework and other fields that might not be mapped directly do the prisma schema)

Doesn't prisma do many sql features like distinct... In memory?

Re: How to make websites that will require lots of your time and energy

#198

Earlier quoted context omitted.

Funny, I use prisma and pothos, with p99 at below 50ms - no N+1 (when it is not lower, then it is because there are sec framework and other fields that might not be mapped directly do the prisma schema)

Doesn't prisma do many sql features like distinct... In memory?

Yes, but you can use the `nativeDistinct` preview feature rely on the DB to perform the operation.

You can see the related issue with more info:

https://github.com/prisma/prisma/issues/23846

Re: How to make websites that will require lots of your time and energy

#199

Earlier quoted context omitted.

But by that argument, if you try to write all of the code doing the functions just by yourself and not bring in any dependencies, and that code is now five years old and you haven't touched it for five years, you might have some security vulnerabilities too. It's not like you are always writing better code than the open source projects are. Unless you are one of the best developers in the world, then sure, then that…

> and that code is now five years old and you haven't touched it for five years, you might have some security vulnerabilities too Security vulnerabilities grow in unattended code then? Or they were there from the second the code was written but with some luck someone noticed them and fixed them? Old code isn't necessarily insecure just because it's old...

Doesnt matter if you count them from the second the code is written or when they are discovered. The same issue is in code written by someone else or yourself.

Re: How to make websites that will require lots of your time and energy

#200
post #70

Honestly, I don't agree with the mindset that frameworks and build steps should be avoided at all costs. Of course, you shouldn't pull in unnecessary NPM dependencies—that's just common sense. But using a compilation step or a framework can save you a lot of time and effort. For example, if you use a framework like Astro, you get a lot of functionality out of the box. If you try to do everything by hand, you end up c…

I don't think you're arguing against anything that was said in that post. There was never an "at all cost". The author was hedging even in the headlines ("indiscriminately", "before you know you need one" and "always, always").

Have a hard time imagine when you would benefit from just html files (unless it is literally a one pager that will never change)
Post reply on HN