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.
I like Django's ORM for good schema migration. Other "ORMs" people build do not often have a good story around that. So often it's because developers aren't experiencing the best ORMs they could.
People who avoid ORMs endup writing their own worse ORM*. ORMs are perfect if you know how and when to uses them. They encapsulate a lot of the mind numbing work that comes with raw sql such as writing inserts for a 50 column database.
100%. I once tried to optimize a SQL query, moving away from the ORM, so I can have more control of the query structure and performance.
I poorly implemented SOLID design principles, creating a complete mess of a SQL Factory, which made it impossible to reason about the query unless I had a debugger running and called the API directly.
Writing is just half the job. Now try migrations, or even something as fundamental as ”find references” on a column name. No, grep is not sufficient, most tables have fields called ”id” or ”name”.
A bad ORM. Every application that accesses an SQL database contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of an ORM.
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.
The best is when you use an orm in standard ways throughout your project and can drop down to raw sql for edge things and performance critical sections… mmmmm. :chefs kiss:
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.
I believe jOOQ is Java's database "sweet spot". You still have to think and code in a SQL-ish fashion (its not trying to "hide" any complexity) but everything is typed and it's very easy to convert returned records to objects (or collections of objects).
At least when I see raw sql I know me and the author are on a level playing field. I would rather deal with a directory full of sql statement that get run than some mysterious build tool that generates sql on the fly and thinks its smarter than me.
For example, I'm working on a project right now where I have to do a database migration. The project uses c# entity framework, I made a migration to create a table, realized I forgot a column, deleted the table and tried to start from scratch. For whatever reason, entity framework refuses to let go of the memory of the original table and will create migrations to restore the original table. I hate this so much.
You can use EF by writing the migrations yourself ("database first"). Also, whatever problem you have there seems to be easily fixed either by a better understanding of how EF's code generation works, or by more aggressive use of version control.
But seriously, yeah, every time I see a complaint about ORMs, I have to wonder if they ever wrote code on an "average team" that had some poor developers on it that didn't use ORMs. The problems, as you describe them, inevitably are worse.
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?
at the very least, if you are really writing lots of INSERTs by hand I bet you are either not quoting properly or you are writing queries with 15 placeholders and someday you'll put one in the wrong place.
ORMs and related toolkits have come a long way since they were called the "Vietnam of Computer Science". I am a big fan of JooQ in Java
Note both of these support both an object <-> SQL mapper (usually with generated objects) that covers the case of my code sample above, and a DSL for SQL inside the host language which is delightful if you want to do code generation to make query builders and stuff like that. I work on a very complex search interface which builds out joins, subqueries, recursive CTEs, you name it, and the code is pretty easy to maintain.
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.
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.
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.
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.
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).
Ecto is a gold-standard ORM, in no small part because it doesn't eat your database, nor your codebase. It lives right at the intersection, and does it's job well.
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.
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.
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.
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.
Perhaps because databases were fundamental to the first programs I ever built (in the ancient 19xx's), but damn, I cannot believe how many so-called experienced devs - often with big titles and bigger salaries - cannot write SQL. It's honestly quite shocking to me. No offense, but wow.
Thing is, this used to be trivial to me, but I spent several years in a purely frontend role, so didn't interact directly with databases at all.
Moreover, the market promotes specialization. The other day I had a conversation with a friend who is rather a generalist and we contrasted his career opportunities with those of a person I know who started out as a civil engineer, but went into IT and over the course of about four years specialized so heavily in Angular, and only that, that now makes more than the two of us combined.
He can't write an SQL statement - I'm not sure he was ever introduced to the concept. How does that feel?
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.
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.
Prisma has shown me that anything is possible with an ORM. I think they may have changed this now, but at least within the last year, distincts were done IN MEMORY.
They had a reason, an I'm sure it had some merit, but we found this out while tracking down an OOM. On the bright side, my co worker and I got a good joke to bring up on occasion out of it.
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.
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.
Weeks of handwriting SQL queries can save you hours of profiling and adding query hints.
If you want a maintainable system enforce that everything goes through the ORM. Migrations autogenerated from the ORM classes - have a check that the ORM representation and the deployed schema are in sync as part of your build. Block direct SQL access methods in your linter. Do that and maintainability is a breeze.
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.
The only time I've seen migrations randomly fail was when others were manually-creating views that prevented modifications to tables. Using the migrations yourself for local dev environments is a good mitigation, except for that.
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!!
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.
Object-relational mapping (ORM) is a key concept in the field of Database Management Systems (DBMS), addressing the bridge between the object-oriented programming approach and relational databases. ORM is critical in data interaction simplification, code optimization, and smooth blending of applications and databases. The purpose of this article is to explain ORM, covering its basic principles, benefits, and importance in modern software development.
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.
No it doesn’t. This post reads like someone tired of working in an industry run by extremely insecure people that just need a little help at absolutely every step of the journey. Other industries call that unqualified.
I have a personal web app that I wrote in react 16 with babel set up by createReactApp directly from the react docs. it’s been stuck with a list of features I want to add in my spare time but all 3 of those have bitrotted out so that in my minor spare time over the last 2 years or so, instead of being able to add some feature, I spend 2 to 3 hours trying to update it to the latest, fail, and no progress is made.
my latest attempt was to see if one of the LLMs could do it. nope.
I’ve thought about starting from scratch but don’t have the time
I think you will have a much better time if you generate a new, empty React project with Vite and just drop your existing components into it. I almost suggested not updating at all and keeping your dependencies as they are, but createReactApp was too much of a bloated mess even in its heyday.
Yeah. The frontend world is a mess. I also faced similar issue with my personal website. Now I just keep my packages versions up to date and do any breaking changes updates as soon as possible. It's annoying, but it's better this way than having to re-write/refactor the whole thing every time.
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.
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?
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.
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!
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.
For me it's more like I bounce back and forth avoiding the pains from whatever the last project was using. Same with front-end frameworks vs vanilla JS etc.
For example, you work with ORMs and then you see all the problems with them as you maintain the project, so on your next app you create an app that is raw SQL. Then after maintaining that for awhile you start to see all the pitfalls of that approach and why people created ORMs in the first place. Then someone mentions the latest and greatest ORM that promises to be better this time and you use it, saving you from raw SQL you'd jumped to last time....ad infinitum.
> 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.
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.
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.
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.
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.
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.
Depends on the context. I came from a ruby, nodejs, java, gawk background to Erlang (not elixir).
The first question I posed to the Erlang community was exactly that: what are the build tools, what are the unit testing frameworks and how is a project setup.
Not because I didn’t know what these tool/concepts did but because I wanted to know what is the state of the art in Erlang tooling.
I have my sea legs, including the wooden one, but just not yet in Erlang. Why Erlang? Because it’s completely different to everything else!
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.
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!'.
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.
Buy wildcard certificates from a vendor, install them everywhere you find you need them manually, don't write down where you put them or when they're going to expire. Cross your fingers the private key doesn't get leaked.
Collect every metric possible and set up arbitrary blanket alerting thresholds and black-box anomaly detection and tune nothing ever. Now you can hire a whole team dedicated just to suffering from alert fatigue.
Standardize on a single LTS OS release across all your infrastructure and wait until the absolute last possible second to start trying to switch to the new current LTS release, biting off about a decade of OS changes to everything everywhere all at once.
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!
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?
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.
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).
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.
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.
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.
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.
I see it like this: with every line of code I write, I make an assumption about the final outcome. Making that assumption means that other possible outcomes aren’t possible.
The more code, the more assumptions.
Until eventually a fixed and very fragile outcome is reached. The so-called first release. Everything is well balanced and based on assumptions I have made based on the information I have been given along the way.
Turns out though my first assumption was wrong.
Now the engineering comes in. Make it look like my first assumption wasn’t wrong, but it was falsely communicated to me. Blame others for my own failings. It called human engineering and it’s great fun.
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.
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.
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.
> Always, Always Require a Compilation Step [...] as opposed to, say, writing code as it will be run
I have a hard time believing that writing vanilla JS is superior to using a compiled language in any but very simple cases. Seems like bad advice to me.
Node now executes TS directly without a build step. This includes TypeScript that only executes in the browser. Just import the given code file into your Node application and then send the output as a string:
my_script.toString();
Boom, strongly typed code with no compile step that executes in both Node and the browser.
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.
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.
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.
Seeing as how FastAPI is only six years old, not sure that works as a great example. One of those projects which has never released a 1.0, so not comforting on backwards compatibility.
People who don't "over engineer" also don't track errors. So you might be losing a bunch of users because your website is broken on their devices, and you'll never know. You can't repro it because your locale doesn't match theirs.
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.
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.
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.
The point is that freshly updated code has the same chance of being buggy.
You want me to believe that in the npm "ecosystem" they have LTS branches that only get security updates? For anything besides maybe a few large libraries with companies behind them?
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.
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.
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?
> 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 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.
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.
- 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.
1. Dependencies break your project only if added unpinned. Most modern package managers will pin dependencies for you.
Now, what if a dependency does break? Well, you can replace it with another dependency, or you can write one from scratch. Using dependencies allows you to save time earlier, and then only spend time writing your own libraries once you hit a roadblock.
2. Frameworks are similar to dependencies. They allow you to save time at the beginning of projects when you're not fully aware of your requirements, and then you're free to write from scratch when you have enough users and resources to do so.
3. Compilation is lightning fast these days because many tools are written in Rust. Projects built using Vite, for example, take a few seconds to build on a 10 year old laptop.
To summarize, these things don't result in websites that will require a lot of time and energy to maintain.
I fixed my 10 year-old webapp yesterday. There were only a couple of easy-to-fix issues. I could've fixed them without AI but AI does help speed things up.
The problem is when looking at it 10 years later I want to rebuild it from scratch because the code and build system look so different than what we do now. I'm not sure yet if it will take a long time though, at least if I accept to keep jquery and avoid typescripting everything.
I could have built an web app in 2015 using C without any frameworks or build system. That doesn't mean I wouldn't want to rewrite it from scratch in 2025.
Rewriting things from scratch is something that everyone wants to do as time passes, regardless of the tech stack used initially.
Once a dependency turns into a security vulnerability, you can either replace it, or write your own library like I suggested. It's more cost effective and time efficient than writing your own libraries from scratch for every project.
For example, I'd rather install React Router for routing in a React app instead of writing my own routing library. I guess some people will reply "grrr React, just use static HTML bro". Okay cool.
Your comment reads like someone who deliberately does not measure things to avoid confrontations against your conveniences and biases.
For example modern compilation may very well be faster than in the past, but your application and experience could be still even faster without compilation.
Frameworks also come at a substantial cost. They are highly restrictive, super massive, and almost always unnecessary. I can understand why people use them, but again your application and experience could be dramatically faster without them. People tend to prefer frameworks when they lack the confidence to build without them, but for those of us that frequently measure things large frameworks are always a net negative.
> your application and experience could be still even faster without compilation
I doubt it. Compilation actually improves developer experience and speeds up the process of releasing apps because you have a standardized way to release your app to production.
I seriously can't understand the hate against compilation because it's never been a roadblock for me, especially these days when most builds take a few seconds on slow CPUs. I guess it's cool to hate things for no reason.
> Frameworks also come at a substantial cost. They are highly restrictive, super massive, and almost always unnecessary.
This is highly subjective. Frameworks have been nothing but a huge productivity boost for me. For example, I can spin up feature-complete API using FastAPI in a few hours instead of spending weeks building my own framework to do the same thing.
> People tend to prefer frameworks when they lack the confidence to build without them
Doubt it. People mostly choose frameworks because they want to get work done instead of wasting their employer's money on non-profitable endeavours.
> for those of us that frequently measure things large frameworks are always a net negative
Could be that you're measuring the wrong thing. At the end of the day, engineers need to ship features so that the company can generate revenue. Frameworks are great at facilitating that process. I'm no Math expert but this seems like a net positive to me.
I would love to see some numbers then. Until then, I'll just assume that using build tools and frameworks means one is a junior developer to be bogus claim.
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.
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..."
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.
To be fair, once bundling is part of the equation, using typescript becomes effectively free. The frameworks are another story but typescript itself is one of the more reasonable choices.
JSDoc would be unequivocally the superior choice if the browsers themselves hadn’t begun to make just opening the html file problematic by requiring HTTP origins for various parts of the API.
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.
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.
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!
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.")
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."
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.
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.
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.
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.
> 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.
> 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.
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.
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.
> 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.
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.
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 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.
100%
If a dev thinks that all SQL can be written by hand then they probably haven’t worked with a complex application that relies on complex data.
A good question to ask them is: what problems do ORMs solve? Good answers are:
Schema Changes + migration
Security
Code Traceability (I have a DB field, where is it used)
Code Readability
Standardisation - easy hiring.
Separation of data layer logic and application layer logic.
Code organisation, most ORMs make you put methods that act on a table in a sensible place.
I like Django's ORM for good schema migration. Other "ORMs" people build do not often have a good story around that. So often it's because developers aren't experiencing the best ORMs they could.
Homegrown ORMs are universally terrible and a lot of the anti ORM crowd are really anti homegrown ORM.
I’ve used Django, SQLalchemy and Hibernate. All three have good migration stories.
People who avoid ORMs endup writing their own worse ORM*. ORMs are perfect if you know how and when to uses them. They encapsulate a lot of the mind numbing work that comes with raw sql such as writing inserts for a 50 column database.
100%. I once tried to optimize a SQL query, moving away from the ORM, so I can have more control of the query structure and performance.
I poorly implemented SOLID design principles, creating a complete mess of a SQL Factory, which made it impossible to reason about the query unless I had a debugger running and called the API directly.
I find that Claude writes boilerplate SQL very well, and is effectively an 'ORM' for me - I just get plain SQL for CRUD.
Complex queries I write myself anyway, so Claude fills the 'ORM' gap for me, leaving an easily understood project.
Writing is just half the job. Now try migrations, or even something as fundamental as ”find references” on a column name. No, grep is not sufficient, most tables have fields called ”id” or ”name”.
I did that once on a hobby project, accidentally. When I realized the corner I had painted myself into I abandoned it.
> - 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.
A bad ORM. Every application that accesses an SQL database contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of an ORM.
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.
They're making the tongue-in-cheek observation that those who don't use an ORM end up reinventing one, poorly.
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.
The best is when you use an orm in standard ways throughout your project and can drop down to raw sql for edge things and performance critical sections… mmmmm. :chefs kiss:
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.
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.
I believe jOOQ is Java's database "sweet spot". You still have to think and code in a SQL-ish fashion (its not trying to "hide" any complexity) but everything is typed and it's very easy to convert returned records to objects (or collections of objects).
Sir, sqlc for example.
I know exactly what's going on, while getting some level of idiocy protection (talking about wrong column names, etc).
At least when I see raw sql I know me and the author are on a level playing field. I would rather deal with a directory full of sql statement that get run than some mysterious build tool that generates sql on the fly and thinks its smarter than me.
For example, I'm working on a project right now where I have to do a database migration. The project uses c# entity framework, I made a migration to create a table, realized I forgot a column, deleted the table and tried to start from scratch. For whatever reason, entity framework refuses to let go of the memory of the original table and will create migrations to restore the original table. I hate this so much.
You can use EF by writing the migrations yourself ("database first"). Also, whatever problem you have there seems to be easily fixed either by a better understanding of how EF's code generation works, or by more aggressive use of version control.
Their point is they understand sql and dbs. They shouldnt need to learn EF and all its footguns.
i think you should just create another migration with alter table that adds that column
Poor developers use tools poorly, film at 11.
But seriously, yeah, every time I see a complaint about ORMs, I have to wonder if they ever wrote code on an "average team" that had some poor developers on it that didn't use ORMs. The problems, as you describe them, inevitably are worse.
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?
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.
all of this is solved by an sql query builder DSL
[dead]
You really want something that lets you write
at the very least, if you are really writing lots of INSERTs by hand I bet you are either not quoting properly or you are writing queries with 15 placeholders and someday you'll put one in the wrong place.ORMs and related toolkits have come a long way since they were called the "Vietnam of Computer Science". I am a big fan of JooQ in Java
https://www.jooq.org/
and SQLAlchemy in Python
https://www.sqlalchemy.org/
Note both of these support both an object <-> SQL mapper (usually with generated objects) that covers the case of my code sample above, and a DSL for SQL inside the host language which is delightful if you want to do code generation to make query builders and stuff like that. I work on a very complex search interface which builds out joins, subqueries, recursive CTEs, you name it, and the code is pretty easy to maintain.
I always see this sentiment here but I just havent experienced any of it in 14 years with the Django ORM.
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.
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.
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.
The simplest can just be:
> 50 teams
At that scale any tool will break down without good architecture, ORM or not.
You've never had to use
Django has SQL logging so you can see what your queries will do! It's wild.
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.
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.
Stream the db to the clients post page load and validate client requests against a cache on the server.
Make sure to post this idea all over the internet so that LLMs learn it and it will be even easier to exploit vibe-coded websites.
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).
Ecto is a gold-standard ORM, in no small part because it doesn't eat your database, nor your codebase. It lives right at the intersection, and does it's job well.
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.
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.
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.
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.
> It’s like a little treat! An after dinner mint!
You completely changed my perspective on simple SQL housekeeping. https://m.youtube.com/watch?v=qYPW3O6VhXo&t=48s
Perhaps because databases were fundamental to the first programs I ever built (in the ancient 19xx's), but damn, I cannot believe how many so-called experienced devs - often with big titles and bigger salaries - cannot write SQL. It's honestly quite shocking to me. No offense, but wow.
Thing is, this used to be trivial to me, but I spent several years in a purely frontend role, so didn't interact directly with databases at all.
Moreover, the market promotes specialization. The other day I had a conversation with a friend who is rather a generalist and we contrasted his career opportunities with those of a person I know who started out as a civil engineer, but went into IT and over the course of about four years specialized so heavily in Angular, and only that, that now makes more than the two of us combined.
He can't write an SQL statement - I'm not sure he was ever introduced to the concept. How does that feel?
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.
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.
Prisma has shown me that anything is possible with an ORM. I think they may have changed this now, but at least within the last year, distincts were done IN MEMORY.
They had a reason, an I'm sure it had some merit, but we found this out while tracking down an OOM. On the bright side, my co worker and I got a good joke to bring up on occasion out of it.
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.
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.
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.
ORM hate might as well be a free square on "HN web development blog post Bingo".
Weeks of handwriting SQL queries can save you hours of profiling and adding query hints.
If you want a maintainable system enforce that everything goes through the ORM. Migrations autogenerated from the ORM classes - have a check that the ORM representation and the deployed schema are in sync as part of your build. Block direct SQL access methods in your linter. Do that and maintainability is a breeze.
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.
Why can't one use ORM and then flag queries which are slow? This is trivial.
Inspect the actual SQL query generated, and if needed modify ORM code or write a SQL query from scratch.
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
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
The only time I've seen migrations randomly fail was when others were manually-creating views that prevented modifications to tables. Using the migrations yourself for local dev environments is a good mitigation, except for that.
Business opportunity: Invent a type system that prevents N+1 queries.
Or just use MongoDB. No ORM needed.
Very practical, like a credit card.
Let's you do what you want here and now and then pay dearly for it afterwards :-)
Pro tip. Don't use Django migrations. Manage the database first and mirror it in orm later.
Why? Isn't this easier to screw up the prod db?
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!!
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.
Yeah EF is amazing
Just in case:
Object-relational mapping (ORM) is a key concept in the field of Database Management Systems (DBMS), addressing the bridge between the object-oriented programming approach and relational databases. ORM is critical in data interaction simplification, code optimization, and smooth blending of applications and databases. The purpose of this article is to explain ORM, covering its basic principles, benefits, and importance in modern software development.
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.
No it doesn’t. This post reads like someone tired of working in an industry run by extremely insecure people that just need a little help at absolutely every step of the journey. Other industries call that unqualified.
I have a personal web app that I wrote in react 16 with babel set up by createReactApp directly from the react docs. it’s been stuck with a list of features I want to add in my spare time but all 3 of those have bitrotted out so that in my minor spare time over the last 2 years or so, instead of being able to add some feature, I spend 2 to 3 hours trying to update it to the latest, fail, and no progress is made.
my latest attempt was to see if one of the LLMs could do it. nope.
I’ve thought about starting from scratch but don’t have the time
I think you will have a much better time if you generate a new, empty React project with Vite and just drop your existing components into it. I almost suggested not updating at all and keeping your dependencies as they are, but createReactApp was too much of a bloated mess even in its heyday.
Yeah. The frontend world is a mess. I also faced similar issue with my personal website. Now I just keep my packages versions up to date and do any breaking changes updates as soon as possible. It's annoying, but it's better this way than having to re-write/refactor the whole thing every time.
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.
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?
> 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.
They're kind of like Border Collies that way, aren't they
I don't know. Do Border Collies like belly rubs?
I thought it was "engineers aren't smart, they're just lazy so they always find the easiest way to fix something."
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!
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.
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
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.
Certain tools, or rather: ecosystems encourage overengineering and overhyping more than others.
For me it's more like I bounce back and forth avoiding the pains from whatever the last project was using. Same with front-end frameworks vs vanilla JS etc.
For example, you work with ORMs and then you see all the problems with them as you maintain the project, so on your next app you create an app that is raw SQL. Then after maintaining that for awhile you start to see all the pitfalls of that approach and why people created ORMs in the first place. Then someone mentions the latest and greatest ORM that promises to be better this time and you use it, saving you from raw SQL you'd jumped to last time....ad infinitum.
> 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.
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.
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.
Sometimes it's just more fun to over-engineer things.
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.
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.
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.
This seems to me to be exactly what the post is about.
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.
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
Depends on the context. I came from a ruby, nodejs, java, gawk background to Erlang (not elixir).
The first question I posed to the Erlang community was exactly that: what are the build tools, what are the unit testing frameworks and how is a project setup.
Not because I didn’t know what these tool/concepts did but because I wanted to know what is the state of the art in Erlang tooling.
I have my sea legs, including the wooden one, but just not yet in Erlang. Why Erlang? Because it’s completely different to everything else!
Depends on the language. This one is pretty settled in Ruby.
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!
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!'.
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.
This is just work. No point in dying over this.
Backend version:
- Install a rolling release distro by hand
- Install stuff without using packages or configuration management by hand without documenting them
- Install stuff on bare metal without using containers or a hypervisor. Bonus points for unlabeled spaghetti patch cable rat's nest.
- Don't automate deployment or upgrades
- Don't have backups of anything
- Don't have a plan for patching, DDoS mitigation, or DR/BCP
Buy wildcard certificates from a vendor, install them everywhere you find you need them manually, don't write down where you put them or when they're going to expire. Cross your fingers the private key doesn't get leaked.
Collect every metric possible and set up arbitrary blanket alerting thresholds and black-box anomaly detection and tune nothing ever. Now you can hire a whole team dedicated just to suffering from alert fatigue.
Standardize on a single LTS OS release across all your infrastructure and wait until the absolute last possible second to start trying to switch to the new current LTS release, biting off about a decade of OS changes to everything everywhere all at once.
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!
I enjoyed the concept of "a complication step". Can't see the results of changes until my code has finished complicating.
Author here: I didn’t realize that misspelling until now. But I like it. Gonna leave it. Thanks for pointing it out ha!
The medium is the massage.
Haha I’m not sure if the compilation/complication mixup was intentional, but it made me laugh :D
AI hallucinations again ;)
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?
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.
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).
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.
Absolutely, everybody gets their say here.
Hmm, was only mildly snarky in my opinion
I agree, but my ego is incredibly fragile sometimes.
good of you to notice, but yeah, in my opinion, you kind of overreacted. All good though:)
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.
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.
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.
I see it like this: with every line of code I write, I make an assumption about the final outcome. Making that assumption means that other possible outcomes aren’t possible.
The more code, the more assumptions.
Until eventually a fixed and very fragile outcome is reached. The so-called first release. Everything is well balanced and based on assumptions I have made based on the information I have been given along the way.
Turns out though my first assumption was wrong.
Now the engineering comes in. Make it look like my first assumption wasn’t wrong, but it was falsely communicated to me. Blame others for my own failings. It called human engineering and it’s great fun.
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
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.
It is not random. All the mentioned problems come from a single source.
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.
> Where's the engineering?
not every problem has a technical solution.
These aren't "problems" with a "solution". These are software-level decisions that have both pros and cons.
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.
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.
> Always, Always Require a Compilation Step [...] as opposed to, say, writing code as it will be run
I have a hard time believing that writing vanilla JS is superior to using a compiled language in any but very simple cases. Seems like bad advice to me.
Node now executes TS directly without a build step. This includes TypeScript that only executes in the browser. Just import the given code file into your Node application and then send the output as a string:
Boom, strongly typed code with no compile step that executes in both Node and the browser.I think the author meant to say use as many build steps as possible
the nuance of the statement lies in the first word, repeated for emphasis
Im pretty sure that most packages and frameworks break less than your own code…
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.
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.
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.
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.
But did running Windows Update ever break the website?
Indeed. And did it require a Jira ticket to rearchitecture the app.
guess it depends on def of framework. I would say using .net mvc is a framework.
Are you saying that because you have to touch it all the time, you're sure it's up to date?
I suppose that's one way to look at it.
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.
Seeing as how FastAPI is only six years old, not sure that works as a great example. One of those projects which has never released a 1.0, so not comforting on backwards compatibility.
> npm update
Patient: Doctor, it hurts when I do this.
Doctor: Don't do this than.
My own code doesn't break without me working on it.
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.
If I worked on it for 10 minutes 5 years ago then it’s definitely not taking lots of time and energy
As far as you know.
People who don't "over engineer" also don't track errors. So you might be losing a bunch of users because your website is broken on their devices, and you'll never know. You can't repro it because your locale doesn't match theirs.
Neither do your dependencies. Unless the maintainer somehow hacks into your server and updates them for you?
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.
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.
> 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.
The point is that freshly updated code has the same chance of being buggy.
You want me to believe that in the npm "ecosystem" they have LTS branches that only get security updates? For anything besides maybe a few large libraries with companies behind them?
While ironically leaving themselves open to supply chain attacks.
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.
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.
Put a cryptocurrency miner on it; that will literally require lots of time and energy.
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?
> 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?
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?".
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.
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.
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.
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.
1. Dependencies break your project only if added unpinned. Most modern package managers will pin dependencies for you.
Now, what if a dependency does break? Well, you can replace it with another dependency, or you can write one from scratch. Using dependencies allows you to save time earlier, and then only spend time writing your own libraries once you hit a roadblock.
2. Frameworks are similar to dependencies. They allow you to save time at the beginning of projects when you're not fully aware of your requirements, and then you're free to write from scratch when you have enough users and resources to do so.
3. Compilation is lightning fast these days because many tools are written in Rust. Projects built using Vite, for example, take a few seconds to build on a 10 year old laptop.
To summarize, these things don't result in websites that will require a lot of time and energy to maintain.
I fixed my 10 year-old webapp yesterday. There were only a couple of easy-to-fix issues. I could've fixed them without AI but AI does help speed things up.
The problem is when looking at it 10 years later I want to rebuild it from scratch because the code and build system look so different than what we do now. I'm not sure yet if it will take a long time though, at least if I accept to keep jquery and avoid typescripting everything.
I could have built an web app in 2015 using C without any frameworks or build system. That doesn't mean I wouldn't want to rewrite it from scratch in 2025.
Rewriting things from scratch is something that everyone wants to do as time passes, regardless of the tech stack used initially.
Every pinned dependecy is a security vulnerability, sooner or later.
Once a dependency turns into a security vulnerability, you can either replace it, or write your own library like I suggested. It's more cost effective and time efficient than writing your own libraries from scratch for every project.
For example, I'd rather install React Router for routing in a React app instead of writing my own routing library. I guess some people will reply "grrr React, just use static HTML bro". Okay cool.
Your comment reads like someone who deliberately does not measure things to avoid confrontations against your conveniences and biases.
For example modern compilation may very well be faster than in the past, but your application and experience could be still even faster without compilation.
Frameworks also come at a substantial cost. They are highly restrictive, super massive, and almost always unnecessary. I can understand why people use them, but again your application and experience could be dramatically faster without them. People tend to prefer frameworks when they lack the confidence to build without them, but for those of us that frequently measure things large frameworks are always a net negative.
> your application and experience could be still even faster without compilation
I doubt it. Compilation actually improves developer experience and speeds up the process of releasing apps because you have a standardized way to release your app to production.
I seriously can't understand the hate against compilation because it's never been a roadblock for me, especially these days when most builds take a few seconds on slow CPUs. I guess it's cool to hate things for no reason.
> Frameworks also come at a substantial cost. They are highly restrictive, super massive, and almost always unnecessary.
This is highly subjective. Frameworks have been nothing but a huge productivity boost for me. For example, I can spin up feature-complete API using FastAPI in a few hours instead of spending weeks building my own framework to do the same thing.
> People tend to prefer frameworks when they lack the confidence to build without them
Doubt it. People mostly choose frameworks because they want to get work done instead of wasting their employer's money on non-profitable endeavours.
> for those of us that frequently measure things large frameworks are always a net negative
Could be that you're measuring the wrong thing. At the end of the day, engineers need to ship features so that the company can generate revenue. Frameworks are great at facilitating that process. I'm no Math expert but this seems like a net positive to me.
Engineers measure things. Junior developers say "doubt it" and guess at the results.
> This is highly subjective.
It is measurable.
At the end of the day actual engineers measure things. Junior developers deliver features.
I would love to see some numbers then. Until then, I'll just assume that using build tools and frameworks means one is a junior developer to be bogus claim.
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.
Anything that allows visitors to submit data to the website. Abuse actors will show up sooner or later.
Not using a framework was one of the worst decisions that was taken in a former job.
I work in one now. Somebody decided to write and maintain our own control suite and JS framework.
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..."
> 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.
> 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.
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.
To be fair, once bundling is part of the equation, using typescript becomes effectively free. The frameworks are another story but typescript itself is one of the more reasonable choices.
JSDoc would be unequivocally the superior choice if the browsers themselves hadn’t begun to make just opening the html file problematic by requiring HTTP origins for various parts of the API.
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.
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.
It's better than the OP article. The OP article is "argument by I-says-so".
It’s also mostly applicable to those inexperienced at web development, who write 99% of the posts and comments along these lines.
How about spending a month (2 new devs to be fair) setting up Cucumber Selenium without anyone knowing what it will be used for ?
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!
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.")
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."
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)
Acquire as much vendor lock-in as possible - everyone pulling in all directions equally means that your position is going to be incredibly stable!
yea, I dumped react for nextjs, and then dumped nextjs for eleventy. never been happier.
You didn't dump React, it's still there in your dependencies.
now go vanilla!
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.
If you want a reliable stack step 1 is don’t rely on Google
Case in point: https://news.ycombinator.com/item?id=44675053
Run it on nextjs with kubernetes.
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
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.
I'm struggling to find any meaningful takeaway here. This post has zero value.
You forgot to add containers and self host (and configure the server)
Yes, let's build our website as a completely static SPA and then deploy it on a self hosted Kubernetes cluster.
A context is missing.
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.
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.
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.
> 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.
> 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.
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.
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.
A classical example might be https://www.npmjs.com/package/is-odd
JavaScript's weak typing and implicit type conversions get in the way of reasonability though:
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.
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.
> 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.
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.
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.
And then you need a dependency to glue them together...And now you want to provide data..And now you want to put content in children.
And you went from a simple nginx extension to again full blown software.
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.
You serve html/js just like that? How about Docker here and there?
I like php and boostrap.
You want a cookie?
i do not like cookie
React-Native
Gacha Web!
Finally we have our web 3.0!
...