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.
skinkestek · 7h ago
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 the query.)
- No clear separation of concerns — data access logic scattered everywhere like confetti.
- Some homegrown “SQL helper” that saves you from writing SELECT *, but now makes it a puzzle to reconstruct a basic query in a database
- Bonus points if the half-baked data access layer is buried under layers of “magic” and is next to impossible to find.
In short: I’m not anti-SQL, but I am vary of people who think they need hand-write everything in every application including small ones with a 5 - 50 simultaneous users.
tetha · 7h ago
I'd say, pure SQL gives you a higher performance ceiling and a lower performance and security floor. It's one of these features / design decisions that require diligence and discipline to use well. Which usually does not scale well beyond small team sizes.
Personally, from the database-ops side, I know how to read quite a few ORMs by now and what queries they result in. I'd rather point out a missing annotation in some Spring Data Repository or suggest a better access pattern (because I've seen a lot of those, and how those are fixed) than dig through what you describe.
nsksl · 5h ago
> - Some homegrown “SQL helper” that saves you from writing SELECT *, but now makes it a puzzle to reconstruct a basic query in a database
>- Bonus points if the half-baked data access layer is buried under layers of “magic” and is next to impossible to find.
It’s really funny because you’re describing an ORM perfectly.
skinkestek · 1h ago
I don't know what kind of ORM you have used but I probably wouldn't like it either.
My ORM does extremely much more than those "SQL helper" classes and it logs SQL nicely to the console or wherever I ask it to to log.
And it is easy to find it, just search for @Entity.
sam_lowry_ · 6h ago
In Java, the sweet spot is JDBCTemplate. Projects based on JDBCTemplate succeed effortlessly while teams muddle through JPA projects.
It is not that JPA is inherently bad, it's just that such projects lack strong technical leadership.
CafeRacer · 6h ago
Sir, sqlc for example.
I know exactly what's going on, while getting some level of idiocy protection (talking about wrong column names, etc).
strken · 7h ago
I'm wary of people who are against query builders in addition to ORMs. I don't think it's possible to build complicated search (multiple joins, searching by aggregates, chaining conditions together) without a query builder of some sort, whether it's homegrown or imported. Better to pull in a tool when it's needed than to leave your junior devs blindly mashing SQL together by hand.
On the other hand, I agree that mapping SQL results to instances of shared models is not always desirable. Why do you need to load a whole user object when you want to display someone's initials and/or profile picture? And if you're not loading the whole thing, then why should this limited data be an instance of a class with methods that let you send a password reset email or request a GDPR deletion?
Scarblac · 9h ago
I always see this sentiment here but I just havent experienced any of it in 14 years with the Django ORM.
sethammons · 8h ago
My life is this in django. Querysets have been passed around everywhere and we've grown to 50 teams. Now, faced with ever slower dev velocity due to intertwined logic, and reduced system performance with often wildly non performant data access patterns, we have spent two years trying to untangle our knot of data access, leading to a six month push requiring disruption to 80% of team's roadmaps to refactor to get the ORM objects not passed around, but to use plain types or DTOs, which will only then allow us to migrate a core part of our database which is required for both product development and scaling needs.
Here's the thing. In five of six companies I have worked at, this story is the exact same. Python, Ruby, Elixir. Passing around ORM objects and getting boundaries mixed leading to more interdependencies and slower velocities and poor performance until a huge push is required to fix it all.
Querysets within a domain seems fine, but when you grow, domains get redefined. Defining good boundaries is important. And requires effort to maintain.
bb88 · 2h ago
One thing that's interesting about Django I thought was that tools like celery will "pickle" orm objects, when they really should be passing the pk's of the objects.
The other thing that's interesting about Django is that you can subclass queryset to do things like .dehydrate() and .rehyrdrate() which can do the translations between json-like data and orm representations.
Then replace the model manager (in Django at least) with that queryset using queryset.as_manager().
If you're trying to decompose the monolith, this is a good way to start -- since it allows you an easier time to decompose and recompose the orm data.
I believe your case is not specific to Django ORM in particular but to the inherent complexity of various teams working together on a single project.
For greenfield projects, you have a chance of splitting the codebase into packages with each one having its own model, migrations and repository, and if you want to cross these boundaries, make it an API, not a Django model. For existing projects this is hard to do most of the time though.
rahimnathwani · 8h ago
You've never had to use
.extra()
?
ormsaregreat · 8h ago
Hitting the database should be avoided in a web application, and use keys as much as possible.
All heavy objects should be previously cached in disk.
Tade0 · 9h ago
A couple of years ago I had an opportunity to fill a fullstack role for the first time in several years.
First thing I noticed was that I couldn't roll an SQL statement by hand even though I had a distinct memory of being able to do so in the past.
I went with an ORM and eventually regretted it because it caused insurmountable performance issues.
And that, to me, is the definition of a senior engineer: someone who realised that they've already forgotten some things and that their pool of knowledge is limited.
ethbr1 · 5h ago
My definition of a senior engineer is someone who can think of most of the ways to do a thing... and has the wisdom to chose the best one, given the specific situation’s constraints.
mattmanser · 8h ago
ORMs are absolutely fantastic at getting rid of the need for CRUD queries and then boilerplate code for translating a result set to a POCO and vide versa. They also allow you to essentially have a strongly typed database definition. It allows you to trivialise db migrations and versioning, though you must learn the idiosyncrasies.
What they are not for is crafting high performance query code.
It literally cannot result in insurmountable performance issues if you use it for CRUD. It's impossible because the resulting SQL is virtually identical to what you'd write natively.
If you try to create complex queries with ORMs then yes, you're in for a world of hurt and only have yourself to blame.
I don't really understand people who still write basic INSERT statements. To me, it's a complete waste of time and money. And why would you write such basic, fiddly, code yourself? It's a nightmare to maintain that sort of code too whenever you add more properties.
FridgeSeal · 7h ago
Plenty of tools out here doing plain sql migrations with zero issues.
At my day job everyone gave up on attempting to use the awkward ORM dsl to do migrations and just writes the sql. It’s easier, and faster, and about a dozen times clearer.
> I don't really understand people who still write basic INSERT statements
Because it’s literally 1 minute, and it’s refreshingly simple. It’s like a little treat! An after dinner mint!
I jest, I’m not out here hand rolling all my stuff. I do often have semi-involved table designs that uphold quite a few constraints and “plain inserts” aren’t super common. Doing it in sql is only marginally more complex than the plain-inserts, but doing them with the ORM was nightmarish.
I like Ecto's approach in Elixir. Bring SQL to the language to handle security, and then build opt-in solutions to real problems in app-land like schema structs and changesets. Underneath, everything is simple (e.g. queries are structs, remain composable), and at the driver layer it taks full advantage of the BEAM.
It's hard to find similarly mature and complete solutions. In the JS/TS world, I like where Drizzle is going, but there is an unavoidable baseline complexity level from the runtime and the type system (not to criticize type systems, but TS was not initially built with this level of sophistication in mind, and it shows in complexity, even if it is capable).
npteljes · 8h ago
This fully matches my experience, and my conclusions as well. I'd add that I often don't get to pick whether the logic will be more on the ORM side, or on the DB side. I end up not caring either - just pick a side. Either the DB be dumb and the code be smart, or the other way around. I don't like it when both are trying to be smart - that's just extra work, and usually one of them fighting the other.
vimto · 7h ago
This is a common sentiment because so many people use ORMs, and because people are using them so often they take the upsides for granted and emphasise the negatives.
I've worked with devs who hated on ORMs for performance issues and opted for custom queries that in time became just as much a maintenance and performance burden as the ORM code they replaced. My suspicion is the issues, like with most tools, are a case of devs not taking the time to understand the limits and inner workings of what they're using.
amonith · 9h ago
That sounds plausible in theory, but I've been developing big ol' LOB apps for more than 10 years now and it happens very very sporadically.
I mean bloated joins is maybe the most common, but never near enough bloated to be an actual problem.
And schema changes and migrations? With ORMs those are a breeze, what are you're on about. It's like 80% of the reason why we want to use ORMs. A data type change or a typo would be immediately caught during compilation making refactoring super easy. It's like a free test of all queries in the entire system.
I assume that we're talking about decent ORMs where schema is also managed in code and a statically typed language, otherwise what's the point.
We're on .NET 8+ and using EF Core.
cluckindan · 7h ago
There is a solution engineered specifically for avoiding N+1 queries and overfetching: GraphQL.
More specifically a GraphQL-native columnar database such as Dgraph, which can leverage the query to optimize fetching and joining.
Or, you could simply use a CRUD model 1:1 with your database schema and optimize top-level resolvers yourself where actually needed.
Prisma can also work, but is more susceptible to N+1 if the db adapter layer does separate queries instead of joining.
tossandthrow · 9h ago
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)
CafeRacer · 6h ago
The reason why I dislike ORMs is that you always have to learn a custom DSL and live in documentation to remember stuff. I think AI has more context than my brain.
Sql does not really needs fixing. And something like sqlc provides a good middle ground between orms and pure sql.
tonyhart7 · 8h ago
we have AI that scans for any potential query N+1 right now
people forget how sql works??? people literally try to forget on how to program
more and more programmer use markdown to "write" code
FridgeSeal · 8h ago
But think of how much time you’ll save needing to map entities to tables!!!! Better to reinvest that time trying to make the ORM do a worse job, automatically instead!!
ormsaregreat · 8h ago
Pro tip. Don't use Django migrations. Manage the database first and mirror it in orm later.
pjc50 · 8h ago
Eh, nobody wants to transfer rows to DTOs by hand.
My personal opinion is that ORMs are absolutely fine for read provided you periodically check query performance, which you need to do anyway. For write it's a lot murkier.
It helps that EF+LINQ works so very well for me. You can even write something very close to SQL directly in C#, but I prefer the function syntax.
rckt · 9h ago
The post feels more like a rant, like the author has a beef with some sort of a project or a client. Even a static blog is easier to manage with tools rather than writing it in pure HTML.
I have my personal website running on svelte. When I decided to have a blog, I quickly came up with a solution to use markdown to html converter and just added a couple of routes to existing setup and voila, the blog is up and running. I don't care that it depends on several packages. Publishing a post takes just a push to my repo.
1dom · 8h ago
You're clearly a better person than the author then.
They said at the start they were going on personal experience. I relate deeply to what they're saying: it's most definitely not a rant/beef against another project/client, it's most definitely the learnings of someone who's been producing personal websites for decades, has kicked themselves a few times in the process and can sarcastically poke fun at their journey in front of others.
judge123 · 11h ago
The problem isn't the tool or the dependency—it's the developer's temptation to over-engineer. We grab a framework because we lack the discipline to keep something simple. Is self-control in coding just a lost art now?
Cthulhu_ · 9h ago
> Is self-control in coding just a lost art now?
Yes; a lot of people don't code because they need to make something work, they code for the joy of it. When the software they need to write is boring or solved - like another CRUD app, front- or back-end - instead of picking the boring and easy to build and comprehend languages and frameworks, they will make it interesting for themselves. Learn a new language, framework, or design paradigm; follow whatever is trending at the moment, etc.
A lot of new software is over-engineered from the start. A lot of that is cargo cult as well, e.g. big companies use microservices in their custom k8s cluster, therefore we should use microservices in our custom k8s cluster too.
dotancohen · 9h ago
> they will make it interesting for themselves.
Engineers love to solve problems. If there are no problems readily at hand, they will create some.
BobaFloutist · 3h ago
They're kind of like Border Collies that way, aren't they
dotancohen · 17m ago
I don't know. Do Border Collies like belly rubs?
kunley · 10h ago
Certain tools, or rather: ecosystems encourage overengineering and overhyping more than others.
atoav · 16m ago
Not for me. But I am in the unique situation of sometimes having to spin up 12 projects a week only to come back to two of them 5 weeks later unpredictably.
This means I treat every project like a letter to my future self that needs to be 100% self explainatory and work even if the environment around the project changed. And this means as few moving parts as possible.
lmpdev · 9h ago
Also the inverse though
Things like Wordpress sound super simple - you don’t even need to code!
But you do need to worry about managing an entire Apache server, managing a crappy database, hardcoding bullshit in PHP, cronjobs, cloud deployment and the fact that almost all “features” of it like plugins and themes etc are massive security vulnerabilities
I think the pitfall to avoid ITT is that there’s a single source of maintenance effort - there are likely many!
rglullis · 9h ago
If the problem you are trying to solve is "I need to put content online and have a storefront for my product", there are plenty of hosting providers who will happily take care of all the headache from Wordpress for less than $10/month.
lmpdev · 8h ago
I’m aware but the OP was about “Making websites”
I was mainly providing an alternate example to “over-engineering is the only source of complexity” train of thought this thread largely has
rglullis · 8h ago
To me it seems like a distinction without a difference.
If you can "make a website" by using a third-party provider but instead you opt into running wordpress on your own, you are still over-engineering.
mettamage · 10h ago
> We grab a framework because we lack the discipline to keep something simple.
I grab a framework to also keep my skills relevant, especially if I'm not practicing them in my day job. If I didn't have that impulse, I'd keep it simple all the time. I'm really good at it, because I really dislike complexity as it requires me to remember more things and I don't really like that feeling.
I'll optimize if I absolutely have to.
Not that businesses ever cared about this attitude. I mean, I've seen it work. The work that I do with LLMs is quick and pragmatic. No need to put stuff into production when it's just a prototype. No need to use a framework if gluing an LLM with some Python code and a well crafted prompt produces the result we need. It allows me to ship in days, not weeks. Obviously, if one then wants it productionized, additional work needs to be put into it and possibly the code needs to be refactored. But, in my opinion, that's the time and place where that type of stuff should happen.
ThatMedicIsASpy · 8h ago
I make choices one of that is build a website in php. I do things from scratch so it involved learning the server, the setup (security/docker/podman), the stack (php/js/css/html). My limits made me do things. The code was and is ugly. Everything is a mess. There is no routing my URLs are pretty because of nginx rewrites. My limits make design choices like no user data because I cannot be sure about security. Once it is up and running you look at things like bootstrap to learn basics of css. Then you want it all gone because you learned the way of css.
I have no problem with sql but an ORM makes what I know about sql very ugly.
whstl · 8h ago
I have never seen this as the justification for using a framework.
As a rationalization, sure, but never as the reason.
They do offer more than coding standards.
johnisgood · 10h ago
I intentionally avoided using a framework mainly to keep my code simple, and because the framework was too inflexible and I could not achieve what I wanted to.
cpursley · 9h ago
So you then ended up building your own half baked of a … wait for it … framework, without even realizing it. Nothing wrong with that, it can be fun - just depends on if your goals are shipping or playing around.
johnisgood · 8h ago
Yes I did, but it serves only one purpose, it is not a general framework, and it is much more minimal. The "framework" is not intended to be used by anyone. The project is, but not as a dependency.
MOARDONGZPLZ · 10h ago
This seems to me to be exactly what the post is about.
donatj · 9h ago
I always get a kick out of the posts from the people in language communities who post "I'm new to <language>, what framework should I use?"
It's like asking "I'm new to driving, what brand of nitros should I be using"
Nah dude, get your sea legs first
LanceH · 58m ago
Depends on the language. This one is pretty settled in Ruby.
politelemon · 13m ago
Run it on nextjs with kubernetes.
card_zero · 11h ago
I enjoyed the concept of "a complication step". Can't see the results of changes until my code has finished complicating.
throw-qqqqq · 9h ago
Haha I’m not sure if the compilation/complication mixup was intentional, but it made me laugh :D
anonzzzies · 9h ago
Pro tip to get ahead and get all this and more for free: use nextjs and prisma. Guaranteed pain and misery; because they move fast and break things, you can look forward to weekly vunerabilities and breaking changes!
pwdisswordfishz · 8h ago
Put a cryptocurrency miner on it; that will literally require lots of time and energy.
jwpapi · 10h ago
Im pretty sure that most packages and frameworks break less than your own code…
bravesoul2 · 10h ago
I think the issue is API breakage. Does your 5 year old NextJS project still work after npm update? Probably not!
What about your simple Go server or FastAPI server. Probably yes.
victorbjorklund · 9h ago
So don't run npm updates because sure then you have the security risks that you have some old code and that is five years old and hasn't been worked on for five years and you also have you missing out on new functions and optimizations. However if you have a five-year-old project that you handwritten everything by yourself you probably have a lot of security issues there too assuming that you are using complicated functions like you would have in Next.js. So then you would have to update a lot more than you would need to bring an old Next.js project up to date. You would need to rewrite all your code from scratch almost.
bravesoul2 · 8h ago
Yes run updates of course. The question is how much of a headache you want.
You can:
Use Next.js (frequently changing lots of transitive deps, suffers from Node ecosystem churn too)
Roll your own framework
OR (FANFARE....)
Use simpler arguably more professional tools. That 10 year old .NET MVC site. Guess what. Still works. Still secure.
threetonesun · 49m ago
10 year old .NET is running on a Windows server that, I hope, you've done some security updates on. Having worked on most web facing stacks out there that might have been the worst one you could have picked as a "future proof" deployment, unless you're comparing them all as something you release once and then never touch again.
codeptualize · 8h ago
Any decent sized project will encounter breaking changes in dependencies.
The big frontend frameworks have great backward compatibility and usually provide codemods that automatically update your project.
If you install UI components and other libraries that might get abandoned or have breaking changes in major version updates you might have to put in more effort, that's not different in Go or Python.
raincole · 8h ago
> npm update
Patient: Doctor, it hurts when I do this.
Doctor: Don't do this than.
aktuel · 10h ago
My own code doesn't break without me working on it.
bapak · 9h ago
Correct. It's broken by default because you're the only user and worked on it for 10 minutes 5 years ago. Probably wrote no tests for it.
Compare that to something like jQuery where all the edge cases have already been accounted for 10 years ago.
namenotrequired · 8h ago
If I worked on it for 10 minutes 5 years ago then it’s definitely not taking lots of time and energy
iLoveOncall · 9h ago
Neither do your dependencies. Unless the maintainer somehow hacks into your server and updates them for you?
brabel · 9h ago
People in web development tend to allow dependencies to auto-update. It’s kind of a necessary evil in that the alternative is to do it only manually and then falling behind on security vulnerabilities updates and potentially getting hacked.
victorbjorklund · 9h ago
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 might work, but for the rest of us, we are probably not guaranteed to ever write code that is 100% bug free for five years.
nottorp · 7h ago
> 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...
Bigpet · 8h ago
You can math that out pretty well.
If your code has a breakage chance of 50% and your dependencies all have a breakage chance of 1% then with 70 dependecies you get to 50.5% breakage chance from dependencies.
pfoof · 10h ago
I host my blog using plain HTML and I have a compile step - a Python script that converts markdown to HTML, which minimizes the energy I spend on... wrapping everything in HTML tags?
lelanthran · 8h ago
> I host my blog using plain HTML and I have a compile step - a Python script that converts markdown to HTML, which minimizes the energy I spend on... wrapping everything in HTML tags?
If I had to do it again, I'd go with Python, but because it started off as a small 5 line shell script I thought "Why bother with Python?".
zwnow · 9h ago
If you have a business website, customers expect a clean site with good visuals and a great user experience. Unless you are as big as Amazon. Sadly overengineering things is a necessary evil nowadays. If I had the choice I wouldn't even build websites mobile friendly but well... got no choice.
blueflow · 9h ago
Hey, customers are people too, and they can and will say "no", too. "good looking" doesn't do it when it cannot do basic things.
zwnow · 9h ago
Customers will use the thing that feels best, if there's a different tool that offers more but looks bad, most customers won't swap. People will use what they are accustomed to.
bubblyworld · 11h ago
I don't see the value in posts like this. It's just a random list of things that can go wrong in software projects, with no discussion of trade-offs at all. Where's the engineering?
lmpdev · 9h ago
Engineering is broader than just trade-offs
Broad heuristics can be very effective
We make decisions on many more datapoints than can be put into what sometimes amounts to a “for and against” list
bubblyworld · 9h ago
Obviously engineering is broader than just trade-offs. I agree that broad heuristics can be useful but the ones proposed in this article just seem bad. Dependencies are (again, obviously?) really useful in many contexts. Same with build steps and frameworks.
kunley · 10h ago
It is not random. All the mentioned problems come from a single source.
bubblyworld · 10h ago
They don't really, as far as I can tell. There are lots of independent good and bad reasons to go down each of the roads in the article. Dependencies make a lot of sense in a lot of cases (e.g. the recent article on date parsing). So do build steps (static API doc generators anyone?). I think chalking it up to one thing is a bit too reductionist.
MOARDONGZPLZ · 10h ago
Basically they’re saying implicitly to be principled about adopting frameworks and other dependencies, evaluating whether they’re needed for one’s project before adopting them. It’s a pretty thought provoking post, even if it may be too subtle for some folks.
bubblyworld · 10h ago
No need for the random snark? I mean, again, we're in extremely obvious territory here. Just doesn't seem appropriate for hacker news front-page (to me).
brabel · 9h ago
You don’t get to decide that, the people voting on HN do, they did and they disagree with you, just accept you can’t agree with a large set of people all the time.
bubblyworld · 8h ago
Absolutely, everybody gets their say here.
fragmede · 9h ago
What makes their random snark any better than your original comment though? There was no need for you to come in and say that you don't see any value here. If you don't see any value here, just move on to the next post.
bubblyworld · 8h ago
I mean, I'm curious why this is such a highly upvoted article, which is why I'm engaging with this comment thread. I think criticism of the article is fine (although I acknowledge I could have been less blunt). It's the unnecessary criticism of my character that I object to.
hiAndrewQuinn · 10h ago
What about the trade off of being principled in the first place? I was much more principled back when I refused to use any programming language that wasn't based off of the lambda calculus, and I also got a lot less done as a result.
tropicalfruit · 10h ago
> Where's the engineering?
not every problem has a technical solution.
bubblyworld · 9h ago
These aren't "problems" with a "solution". These are software-level decisions that have both pros and cons.
tropicalfruit · 7h ago
well you've decided they're "software-level". this article title talks about "time and energy".
most of the time the real trade off is financial.
especially now with AI generated boilerplate and npm commands that shit out 10,000 lines of code at a keystroke.
bubblyworld · 6h ago
I don't think the choice of metric matters to my point (I'm just calling it software-level because these are decisions you make while writing software). These decisions come with both pros and cons either way, which it sounds like you agree with.
dtj1123 · 8h ago
If you took this seriously you'd write everything in assembly to avoid dependancy on a language that will one day break. Picking a set of dependancies that are built on well reasoned, clean abstractions is a far better apporach than rolling your own solution to every problem you encounter.
fifticon · 8h ago
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 better, those multiple inconsistent
implementations affecting and breaking each other!
One you have this going, there are some easy bonus pickings:
Whenever B happens, "fix" it with weird extra incancations inside your own toolset, cleverly avoiding any attempt at (2) above.
If you succeed at this, several developers can, combining these techniques to sabotage and trigger a veritable pinball game of strange breaking effects.
Note: CSS is a great place to start this game!
anonzzzies · 8h ago
1. do all devops on the side and make sure everything is running complex multi az kubernetes clusters with as many aws buzzword services you managed to read when you asked gpt 'how super secure aws k8s for complex 900 node nextjs microservice setup thanks!'.
1dom · 8h ago
I feel personally attacked. I love it.
Here's some more:
- People only visit your personal website knowing they can personally read, understand, audit and approve every single line of code that ever went into it. This means you don't really have a personal website unless you meticulously wrote every single line and every single change is clearly described and accessible on github (and sourcehut, and forgejo, and the rest. What sort of monster uses only Github nowadays?)
- Remember to explain every single self-doubting existential thought that went into producing (or not producing) your website: people aren't there for objective, intellectual, educational tech content, they're probably more interested in self-deprecating metacognition.
sillycube · 8h ago
This js dev trend is toxic. You must choose a framework that requires npm and compilation. Why can't we stay with the PHP way? Upload the code, refresh the page, and everything is updated.
iamsanteri · 9h ago
I was expecting more like, "translate it into many languages your website users won't keep updating and give them access to edit your site's design freely as they see fit..."
donalhunt · 9h ago
Anything that allows visitors to submit data to the website. Abuse actors will show up sooner or later.
rf15 · 6h ago
Acquire as much vendor lock-in as possible - everyone pulling in all directions equally means that your position is going to be incredibly stable!
maelito · 9h ago
Not using a framework was one of the worst decisions that was taken in a former job.
jokab · 8h ago
I work in one now. Somebody decided to write and maintain our own control suite and JS framework.
victorbjorklund · 9h ago
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 copy-pasting the same header and footer into every HTML file. Then, when you want to update something, you have to manually change every single page. Trust me I been in that hell many years ago.
Frameworks solve these problems efficiently. Sure, some frameworks can be overly complex (I'm personally not a fan of Next.js), but that's a problem with the specific framework, not the idea of using a framework at all. But many frameworks make things much simpler and let you avoid reinventing the wheel. You could write your own scripts (in practice a mini-framework) but eventually you'll hit limitations, especially as your project grows or you start working with others. At that point, you'll probably end up switching to an established framework anyway.
If you're already using something like PHP with server-side rendering and templates, that's fine too—you've just chosen a different kind of framework (it is still some kind of framework. Just not a client-side one). I just don't buy into the idea that avoiding all build steps and frameworks is somehow more "pure." It feels a bit like a hipster take: "I'm going to write everything from scratch and avoid all tools just to show that I can."
Bigpet · 8h ago
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").
Isn’t using something like the Google closure compiler considered a good thing? This post seems to suggest tools like that in your pipeline should be avoided.
philipwhiuk · 8h ago
If you want a reliable stack step 1 is don’t rely on Google
crinkly · 11h ago
We are good at not even getting that far. Have a platform team and spent a month setting up CI, github repo, onboarding, writing terraform and stuff and not even get around to doing a web site in the first place!
TheOtherHobbes · 10h ago
But only after marketing, management, and other stakeholders have spent six months defining what the site should do and what it should look like, based on vibes and personal preferences. ("I like this one. Make it look like this.")
skinkestek · 8h ago
How about spending a month (2 new devs to be fair) setting up Cucumber Selenium without anyone knowing what it will be used for ?
jeswin · 8h ago
> Always, Always Require a Compilation Step
And from the linked post on the same website.
> if you write vanilla HTML, CSS, and JS, all you have to do is put that code in a web browser and it runs.
Very (very, very) few large projects use plain JS (instead of TS) these days. Let's stop acting like all these people don't know what they're doing.
This post is probably applicable to selected tiny and small projects. And for some of those, it may be better if there was no JS at all.
pwdisswordfishz · 8h ago
> Very (very, very) few large projects use plain JS (instead of TS) these days. Let's stop acting like all these people don't know what they're doing.
There are much better arguments to use TypeScript than "five billion flies can't be wrong". Most other popular tech choices are in fact rather silly.
cardanome · 8h ago
I have seen companies that had ten times as many microservices than devs, our industry is full of cargo culting, ignorance and resume driven development.
While there is sometimes good reason to use TS, often you might be better served using JSDoc so you have type safety without the compilation step.
I currently see the direct comparison as my company has one project that uses old-school php backed rendering with a bit of vanilla js sprinkled it and one with modern React and TS. The React team is significantly less productive and the code is much harder to maintain, has more bugs, is less performant and harder ton onboard people to. But when I suggest that a new project does not not need to be a SPA, I always get booed.
xg15 · 8h ago
OK, but that's essentially "argument by authority" + "everyone is doing it".
They certainly have their reasons and they definitely aren't stupid, but it would be more useful to know what those reasons are and in what scope they are applicable.
jeswin · 8h ago
Why types are good (even essential) for large projects has been documented quite extensively. Internet pushed JS to the forefront and as projects increased in scope and ambition, types became unavoidable.
More recently, see how there's a strong push towards types in Python. AI/ML is to Python what the internet was for JS. And types are here.
raincole · 8h ago
It's better than the OP article. The OP article is "argument by I-says-so".
presentation · 8h ago
It’s also mostly applicable to those inexperienced at web development, who write 99% of the posts and comments along these lines.
shiggaz · 9h ago
You forgot to add containers and self host (and configure the server)
baobabKoodaa · 8h ago
Yes, let's build our website as a completely static SPA and then deploy it on a self hosted Kubernetes cluster.
tropicalfruit · 10h ago
working at a certain faang made me realise even the most simplest trivial task can become endlessly complicated
most of it from my observation is people justifying their own roles, where the real value they bring is arguable imo
bapak · 9h ago
I'm the person who automates things. Before making things complicated, people would just copy paste crap from SO and hope it worked.
Then came linters and everyone hates me. But you know the codebase is slightly less buggy/shitty thanks to them.
The funniest thing to me is people thinking they don't need tests, linters, type checkers, because they're so good at it.
timeon · 8h ago
You serve html/js just like that? How about Docker here and there?
nicman23 · 8h ago
I like php and boostrap.
jokab · 8h ago
You want a cookie?
nicman23 · 2h ago
i do not like cookie
pstadler · 8h ago
I'm struggling to find any meaningful takeaway here. This post has zero value.
epolanski · 11h ago
On one hand I agree, one should approach issues as they come, but there's solutions that are hard to ignore such as the need for reusable fragments/components on different pages which already make a cry for dependencies.
Even admitting one wants to go with bare bone web components authoring and maintaining them is expensive, requires lit or something.
Thus, what's the solution? Some sort of templating? Again, you're bringing on dependencies.
aDyslecticCrow · 10h ago
PHP is actually a pretty good HTML preprocessor language. Not sure why it was blasted from this planet. Maybe because people abused it as a "rest" endpoint or backend, and burned themselves out from using the wrong tool for the job (even as php evolved to be pretty good backend for this too)
A small amount of PHP as a templater for simple raw HTML and JS segments is pretty nice.
fragmede · 9h ago
Because debugging it is a nightmare. It's really awesome for what it's good at, but inline templating after a certain level of complexity is a recipe for madness. The problem is, projects start off small and un-complex, but by the time it gets too complicated, you're in too deep and porting it something else takes extra time.
ghusto · 11h ago
> Thus, what's the solution? Some sort of templating? Again, you're bringing on dependencies.
If your "dependency" is yourself because you wrote your own template for your specific needs, is that still a dependency?
I wrote a templating solution for my own repeated sections and I'm so glad. It does exactly what I need, it's simple for me to understand if ever it grows large and I need a refresher, and easily expandable.
lelanthran · 6h ago
> On one hand I agree, one should approach issues as they come, but there's solutions that are hard to ignore such as the need for reusable fragments/components on different pages which already make a cry for dependencies.
Now, you may argue that that is a dependency, but it doesn't have any of its own, you can make a copy of it, serve it from your primary domain, and you're done.
DocTomoe · 11h ago
I think the emphasis is in 'indiscriminatly'. The goal is not to have absolutely zero dependencies, just don't depend on dependencies that you could reasonably implement yourself.
JavaScript's weak typing and implicit type conversions get in the way of reasonability though:
>>> '13' % 2
0
>>> 'nan' % 2
NaN
>>> NaN % 2
NaN
>>> null % 2
0
this package ensures that you have a sane complement to is-odd, e.g. `!isOdd(someVar)` is always even (in the domain of natural numbers). A naive implementation of is-odd: `(some_var % 2 === 1)`, does not have a sane complement.
Anyway, to include this package as a dependency is indeed overkill. I would most likely opt for vendoring this package into the project (including licenses and acknowledgement), as the code is unlikely to change and is MIT licensed.
johannes1234321 · 9h ago
The question is: how likely is it that I get the trash input in and do I care about the result if the input is trash? Modulo two works well for a lot of cases where this is needed. (Which probably is size of a container (array) or alternating something in a loop.
kome · 11h ago
> but there's solutions that are hard to ignore such as the need for reusable fragments/components on different pages which already make a cry for dependencies.
honestly ctrl+c, ctrl+v of hand written html. and i'm cool as a cucumber.
epolanski · 9h ago
Been there, done that. You implement just a header navigation change, now you're copy pasting across 12 different files.
But wait, now you want to add an active state to your navigation links, and you're manually changing the `class="active"` in 12 different files...
I could go on, it doesn't scale beyond triviality, albeit LLMs do help speeding up.
johnisgood · 8h ago
That is why you can include a header.html, nav.html, and footer.html if you so wish! There are many ways to do this. :P Depends on your use case.
nottorp · 7h ago
If you don't go through two different ORMs - running on separate AWS VMs of course - and then to a third server that has the actual database, it's not professional.
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.
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 the query.)
- No clear separation of concerns — data access logic scattered everywhere like confetti.
- Some homegrown “SQL helper” that saves you from writing SELECT *, but now makes it a puzzle to reconstruct a basic query in a database
- Bonus points if the half-baked data access layer is buried under layers of “magic” and is next to impossible to find.
In short: I’m not anti-SQL, but I am vary of people who think they need hand-write everything in every application including small ones with a 5 - 50 simultaneous users.
Personally, from the database-ops side, I know how to read quite a few ORMs by now and what queries they result in. I'd rather point out a missing annotation in some Spring Data Repository or suggest a better access pattern (because I've seen a lot of those, and how those are fixed) than dig through what you describe.
>- Bonus points if the half-baked data access layer is buried under layers of “magic” and is next to impossible to find.
It’s really funny because you’re describing an ORM perfectly.
My ORM does extremely much more than those "SQL helper" classes and it logs SQL nicely to the console or wherever I ask it to to log.
And it is easy to find it, just search for @Entity.
It is not that JPA is inherently bad, it's just that such projects lack strong technical leadership.
I know exactly what's going on, while getting some level of idiocy protection (talking about wrong column names, etc).
On the other hand, I agree that mapping SQL results to instances of shared models is not always desirable. Why do you need to load a whole user object when you want to display someone's initials and/or profile picture? And if you're not loading the whole thing, then why should this limited data be an instance of a class with methods that let you send a password reset email or request a GDPR deletion?
Here's the thing. In five of six companies I have worked at, this story is the exact same. Python, Ruby, Elixir. Passing around ORM objects and getting boundaries mixed leading to more interdependencies and slower velocities and poor performance until a huge push is required to fix it all.
Querysets within a domain seems fine, but when you grow, domains get redefined. Defining good boundaries is important. And requires effort to maintain.
The other thing that's interesting about Django is that you can subclass queryset to do things like .dehydrate() and .rehyrdrate() which can do the translations between json-like data and orm representations.
Then replace the model manager (in Django at least) with that queryset using queryset.as_manager().
If you're trying to decompose the monolith, this is a good way to start -- since it allows you an easier time to decompose and recompose the orm data.
The simplest can just be:
For greenfield projects, you have a chance of splitting the codebase into packages with each one having its own model, migrations and repository, and if you want to cross these boundaries, make it an API, not a Django model. For existing projects this is hard to do most of the time though.
First thing I noticed was that I couldn't roll an SQL statement by hand even though I had a distinct memory of being able to do so in the past.
I went with an ORM and eventually regretted it because it caused insurmountable performance issues.
And that, to me, is the definition of a senior engineer: someone who realised that they've already forgotten some things and that their pool of knowledge is limited.
What they are not for is crafting high performance query code.
It literally cannot result in insurmountable performance issues if you use it for CRUD. It's impossible because the resulting SQL is virtually identical to what you'd write natively.
If you try to create complex queries with ORMs then yes, you're in for a world of hurt and only have yourself to blame.
I don't really understand people who still write basic INSERT statements. To me, it's a complete waste of time and money. And why would you write such basic, fiddly, code yourself? It's a nightmare to maintain that sort of code too whenever you add more properties.
At my day job everyone gave up on attempting to use the awkward ORM dsl to do migrations and just writes the sql. It’s easier, and faster, and about a dozen times clearer.
> I don't really understand people who still write basic INSERT statements
Because it’s literally 1 minute, and it’s refreshingly simple. It’s like a little treat! An after dinner mint!
I jest, I’m not out here hand rolling all my stuff. I do often have semi-involved table designs that uphold quite a few constraints and “plain inserts” aren’t super common. Doing it in sql is only marginally more complex than the plain-inserts, but doing them with the ORM was nightmarish.
You completely changed my perspective on simple SQL housekeeping. https://m.youtube.com/watch?v=qYPW3O6VhXo&t=48s
It's hard to find similarly mature and complete solutions. In the JS/TS world, I like where Drizzle is going, but there is an unavoidable baseline complexity level from the runtime and the type system (not to criticize type systems, but TS was not initially built with this level of sophistication in mind, and it shows in complexity, even if it is capable).
I've worked with devs who hated on ORMs for performance issues and opted for custom queries that in time became just as much a maintenance and performance burden as the ORM code they replaced. My suspicion is the issues, like with most tools, are a case of devs not taking the time to understand the limits and inner workings of what they're using.
And schema changes and migrations? With ORMs those are a breeze, what are you're on about. It's like 80% of the reason why we want to use ORMs. A data type change or a typo would be immediately caught during compilation making refactoring super easy. It's like a free test of all queries in the entire system. I assume that we're talking about decent ORMs where schema is also managed in code and a statically typed language, otherwise what's the point.
We're on .NET 8+ and using EF Core.
More specifically a GraphQL-native columnar database such as Dgraph, which can leverage the query to optimize fetching and joining.
Or, you could simply use a CRUD model 1:1 with your database schema and optimize top-level resolvers yourself where actually needed.
Prisma can also work, but is more susceptible to N+1 if the db adapter layer does separate queries instead of joining.
(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)
Sql does not really needs fixing. And something like sqlc provides a good middle ground between orms and pure sql.
people forget how sql works??? people literally try to forget on how to program
more and more programmer use markdown to "write" code
My personal opinion is that ORMs are absolutely fine for read provided you periodically check query performance, which you need to do anyway. For write it's a lot murkier.
It helps that EF+LINQ works so very well for me. You can even write something very close to SQL directly in C#, but I prefer the function syntax.
I have my personal website running on svelte. When I decided to have a blog, I quickly came up with a solution to use markdown to html converter and just added a couple of routes to existing setup and voila, the blog is up and running. I don't care that it depends on several packages. Publishing a post takes just a push to my repo.
They said at the start they were going on personal experience. I relate deeply to what they're saying: it's most definitely not a rant/beef against another project/client, it's most definitely the learnings of someone who's been producing personal websites for decades, has kicked themselves a few times in the process and can sarcastically poke fun at their journey in front of others.
Yes; a lot of people don't code because they need to make something work, they code for the joy of it. When the software they need to write is boring or solved - like another CRUD app, front- or back-end - instead of picking the boring and easy to build and comprehend languages and frameworks, they will make it interesting for themselves. Learn a new language, framework, or design paradigm; follow whatever is trending at the moment, etc.
A lot of new software is over-engineered from the start. A lot of that is cargo cult as well, e.g. big companies use microservices in their custom k8s cluster, therefore we should use microservices in our custom k8s cluster too.
This means I treat every project like a letter to my future self that needs to be 100% self explainatory and work even if the environment around the project changed. And this means as few moving parts as possible.
Things like Wordpress sound super simple - you don’t even need to code!
But you do need to worry about managing an entire Apache server, managing a crappy database, hardcoding bullshit in PHP, cronjobs, cloud deployment and the fact that almost all “features” of it like plugins and themes etc are massive security vulnerabilities
I think the pitfall to avoid ITT is that there’s a single source of maintenance effort - there are likely many!
I was mainly providing an alternate example to “over-engineering is the only source of complexity” train of thought this thread largely has
If you can "make a website" by using a third-party provider but instead you opt into running wordpress on your own, you are still over-engineering.
I grab a framework to also keep my skills relevant, especially if I'm not practicing them in my day job. If I didn't have that impulse, I'd keep it simple all the time. I'm really good at it, because I really dislike complexity as it requires me to remember more things and I don't really like that feeling.
I'll optimize if I absolutely have to.
Not that businesses ever cared about this attitude. I mean, I've seen it work. The work that I do with LLMs is quick and pragmatic. No need to put stuff into production when it's just a prototype. No need to use a framework if gluing an LLM with some Python code and a well crafted prompt produces the result we need. It allows me to ship in days, not weeks. Obviously, if one then wants it productionized, additional work needs to be put into it and possibly the code needs to be refactored. But, in my opinion, that's the time and place where that type of stuff should happen.
I have no problem with sql but an ORM makes what I know about sql very ugly.
As a rationalization, sure, but never as the reason.
They do offer more than coding standards.
It's like asking "I'm new to driving, what brand of nitros should I be using"
Nah dude, get your sea legs first
What about your simple Go server or FastAPI server. Probably yes.
You can:
Use Next.js (frequently changing lots of transitive deps, suffers from Node ecosystem churn too)
Roll your own framework
OR (FANFARE....)
Use simpler arguably more professional tools. That 10 year old .NET MVC site. Guess what. Still works. Still secure.
The big frontend frameworks have great backward compatibility and usually provide codemods that automatically update your project.
If you install UI components and other libraries that might get abandoned or have breaking changes in major version updates you might have to put in more effort, that's not different in Go or Python.
Patient: Doctor, it hurts when I do this.
Doctor: Don't do this than.
Compare that to something like jQuery where all the edge cases have already been accounted for 10 years ago.
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 might work, but for the rest of us, we are probably not guaranteed to ever write code that is 100% bug free for five years.
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...
Same, except I skipped Python and went with bash (https://gist.github.com/lelanthran/2634fc2508c93a437ba5ca511... if you're curious).
If I had to do it again, I'd go with Python, but because it started off as a small 5 line shell script I thought "Why bother with Python?".
Broad heuristics can be very effective
We make decisions on many more datapoints than can be put into what sometimes amounts to a “for and against” list
not every problem has a technical solution.
most of the time the real trade off is financial.
especially now with AI generated boilerplate and npm commands that shit out 10,000 lines of code at a keystroke.
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 better, those multiple inconsistent implementations affecting and breaking each other!
One you have this going, there are some easy bonus pickings: Whenever B happens, "fix" it with weird extra incancations inside your own toolset, cleverly avoiding any attempt at (2) above.
If you succeed at this, several developers can, combining these techniques to sabotage and trigger a veritable pinball game of strange breaking effects.
Note: CSS is a great place to start this game!
Here's some more:
- People only visit your personal website knowing they can personally read, understand, audit and approve every single line of code that ever went into it. This means you don't really have a personal website unless you meticulously wrote every single line and every single change is clearly described and accessible on github (and sourcehut, and forgejo, and the rest. What sort of monster uses only Github nowadays?)
- Remember to explain every single self-doubting existential thought that went into producing (or not producing) your website: people aren't there for objective, intellectual, educational tech content, they're probably more interested in self-deprecating metacognition.
Frameworks solve these problems efficiently. Sure, some frameworks can be overly complex (I'm personally not a fan of Next.js), but that's a problem with the specific framework, not the idea of using a framework at all. But many frameworks make things much simpler and let you avoid reinventing the wheel. You could write your own scripts (in practice a mini-framework) but eventually you'll hit limitations, especially as your project grows or you start working with others. At that point, you'll probably end up switching to an established framework anyway.
If you're already using something like PHP with server-side rendering and templates, that's fine too—you've just chosen a different kind of framework (it is still some kind of framework. Just not a client-side one). I just don't buy into the idea that avoiding all build steps and frameworks is somehow more "pure." It feels a bit like a hipster take: "I'm going to write everything from scratch and avoid all tools just to show that I can."
And from the linked post on the same website.
> if you write vanilla HTML, CSS, and JS, all you have to do is put that code in a web browser and it runs.
Very (very, very) few large projects use plain JS (instead of TS) these days. Let's stop acting like all these people don't know what they're doing.
This post is probably applicable to selected tiny and small projects. And for some of those, it may be better if there was no JS at all.
There are much better arguments to use TypeScript than "five billion flies can't be wrong". Most other popular tech choices are in fact rather silly.
While there is sometimes good reason to use TS, often you might be better served using JSDoc so you have type safety without the compilation step.
I currently see the direct comparison as my company has one project that uses old-school php backed rendering with a bit of vanilla js sprinkled it and one with modern React and TS. The React team is significantly less productive and the code is much harder to maintain, has more bugs, is less performant and harder ton onboard people to. But when I suggest that a new project does not not need to be a SPA, I always get booed.
They certainly have their reasons and they definitely aren't stupid, but it would be more useful to know what those reasons are and in what scope they are applicable.
More recently, see how there's a strong push towards types in Python. AI/ML is to Python what the internet was for JS. And types are here.
most of it from my observation is people justifying their own roles, where the real value they bring is arguable imo
Then came linters and everyone hates me. But you know the codebase is slightly less buggy/shitty thanks to them.
The funniest thing to me is people thinking they don't need tests, linters, type checkers, because they're so good at it.
Even admitting one wants to go with bare bone web components authoring and maintaining them is expensive, requires lit or something.
Thus, what's the solution? Some sort of templating? Again, you're bringing on dependencies.
A small amount of PHP as a templater for simple raw HTML and JS segments is pretty nice.
If your "dependency" is yourself because you wrote your own template for your specific needs, is that still a dependency?
I wrote a templating solution for my own repeated sections and I'm so glad. It does exactly what I need, it's simple for me to understand if ever it grows large and I need a refresher, and easily expandable.
I side-stepped that completely, even on actual production web apps for clients, with this: https://github.com/lelanthran/ZjsComponent
Now, you may argue that that is a dependency, but it doesn't have any of its own, you can make a copy of it, serve it from your primary domain, and you're done.
A classical example might be https://www.npmjs.com/package/is-odd
Anyway, to include this package as a dependency is indeed overkill. I would most likely opt for vendoring this package into the project (including licenses and acknowledgement), as the code is unlikely to change and is MIT licensed.
honestly ctrl+c, ctrl+v of hand written html. and i'm cool as a cucumber.
But wait, now you want to add an active state to your navigation links, and you're manually changing the `class="active"` in 12 different files...
I could go on, it doesn't scale beyond triviality, albeit LLMs do help speeding up.
Finally we have our web 3.0!
...