Before you comment with "So you want us to write everything ourselves?", make sure you read the paragraph that starts with "Many people will argue that not using a framework means write everything yourself. This is a false dichotomy."
I feel like this response is common enough that it's almost a trope.
"Oh you don't like leaky abstraction X, so what we should all code in binary!?"
I think it comes from a kind of "Just World" spin off whereby all abstractions are considered pretty much equal, and it's cavalier to not code to the "highest" of these, no matter how many rickety chairs you've piled on top of each other to get that high.
Not all abstractions are created equal. As an example, choosing to use vanilla JS over react is not the same as hand-coding assembly instead of using C, Zig or Rust.
I'd go so far as to extend the statistics aphorism about models to software abstractions: all abstractions are wrong (/leaky?), but some are useful for now.
The problem with software abstractions is that they, unlike the fundamental laws of physics, model code organization and business logic that frequently changes. These changes often make no sense beyond "VP lifer thought it was a good idea" so our house of cards is built on ever shifting sands. No abstraction short of a pointer can survive that.
No I get that all abstractions leak on some level. But some leak a lot more than others. And as an industry we don't seem to have good mental models or languages around that.
More than once I've seen using the abstraction + working around the leaks being more complex than just using the the thing underneath the abstraction.
I have no pithy phrase to describe that scenario, without the "why don't we just code in binary" retort.
If your argument is that using someone else’s abstractions is bad because you can write your own (which is what this article is saying), then the standard cliched reply is accurate. Cliches are cliches for a reason.
Indeed. This excerpt from that paragraph is a good thesis for the essay as a whole:
> The point is not to never use frameworks, but to isolate them. To call them from a single place. One that we own. That we are responsible for and that we limit very much in what it can touch.
> > The point is not to never use frameworks, but to isolate them. To call them from a single place. One that we own. That we are responsible for and that we limit very much in what it can touch.
I had the misfortune of working on a project which abstracted a framework. It was awful. It ended up being an ad-hoc component that was half-façade, half-adapter that was inadvertently tightly-coupled with the framework. It added an awful lot of complexity with the only tradeoff being theoretically being able to abstract away the underlying framework.
It was not worth it. It created far more problems than those that it solved.
I think an easy example of that is what frustrates me the most in JS-land: everything has it's own CLI. Why? Quick start: `npm run nouveau-framework create@app 365 --with-voodoo`.
I don't want that. I want (maybe, at my discretion!) to add your framework as a dependency, read some API docs, and just start plugging it in where necessary.
But they all focus on greenfield projects, they all think the whole project is about/driven by them.
This does frustrate! On more than one occasion I've spun up a create-x-app project just to see what an implementation looks like to then do it manually inside an existing project.
Then again when I'm greenfielding having the option to be up and running in 2 minutes is rather nice.
