211–220 of 247 posts
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.
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 runni…
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
Earlier quoted context omitted.
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 re…
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.
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?
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 runni…
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 l…
> 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…
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 bi…
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.
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.
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…
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.
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…
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.
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 runni…
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…