Both is still a framework, «main loop out of your hands» takes priority.
Frameworks surely can be nested, the intermediate-framework defines callbacks for top-level-framework, those callbacks do some of the work but call your callbacks for fine-grained choces.
A lot of this comes down to it's really hard to design good APIs. A widely used official framework has probably had a lot of work put into its API design. Something quickly built probably hasn’t. Plus, as soon as you start creating new abstractions there's going to be impedance mismatch with the underlying ones.
One of the benefits of categories / class extensions — the ability to define new methods on external classes — is that they let you add functionality to existing frameworks, solving pain points without having to wrap everything in a new layer.
This! I did find Ousterhout's Philosophy of Software Design quite good at articulating what makes a good API/framework. Abstractions can simplify, but simplicity is one of the hardest thing to achieve.
Strong agree. I don't even like internal company projects to wrap libraries across services. At the last business I worked for we (5-6 engineers) used yt-dlp in a few places and there were a couple suggestions over the years to wrap it in an internal library. My counter-suggestion was always that the uses were either different enough that combining them into a library doesn't reduce the amount of work but increases the maintenance burden in various ways, or the uses are similar enough that we should roll out a service (we were using microservices) that would do the video downloading for us. Maybe with a monorepo it's a good idea but in my experience trying to over-apply DRY makes life harder.
Time is a flat circle. We had this discussion 15-20 years ago with PHP and then Rails came and then Symfony and other PHP frameworks that established themselves as the standard came.
And now we have things like React and I would take any mini framework of a random person over it.
I think the article is directionally right, but I don't think it locates the distinction in the right place. I would ask two questions:
Does the underlying library/framework have a clear semantics about how things work, or is it more vibes/fuck around find out?
Does the higher level library/framework have a clear semantics of how it works, or is it more vibes/fuck around find out?
What do I mean by "fuck around and find out?" Questions arise about what an operation should do, whether something is a bug, etc, and there's no clear answer, or if there is an answer, it's a matter of taste more than anything that can be justified to others. Decisions are often made by fiat.
If the answer is yes/yes, then it's probably safe to use the higher level abstraction. There's still a question about whether it pays its way, but at least it should not be too hard to move back and forth between the levels.
If it's no/yes, I think you'll have a bad time--it takes a lot of work to build a stable foundation on top of something poorly defined. If it's yes/no, that's also quite bad, you're losing a lot for the higher level framework, and the lack of clear semantics often leads to the "only one person knows how this works" problem.
If it's no/no, it's probably a complicated case by case scenario, you may not have a lot of great options.
I agree a lot with this article, having dealt with teams that built dsls over existing languages that forced people into bad practices and made it hell to change the foundation.
I think it's related to inner platform effect, and oil shell introduced this term or interior vs exterior extendability
Frustrating boilerplate and repetitive code can be easily solved with shared snippets, served by e.g. Simple Completion Language Server for cross-editor completions. Our team adopted such solution few months ago, and it reduces context switching during the review process (no need to dig through the layers of abstractions).
stephenr | 4 hours ago
I'm not sure I really agree with that definition.
The definition I've read (a long time ago, I forget where) that gave the most succinct description was:
A library is code your code invokes/calls.
A framework is code that invokes/calls your code.
erock | 2 hours ago
What happens when it’s both? And what happens when a framework is built on a framework?
k749gtnc9l3w | 2 hours ago
Both is still a framework, «main loop out of your hands» takes priority.
Frameworks surely can be nested, the intermediate-framework defines callbacks for top-level-framework, those callbacks do some of the work but call your callbacks for fine-grained choces.
snej | 5 hours ago
A lot of this comes down to it's really hard to design good APIs. A widely used official framework has probably had a lot of work put into its API design. Something quickly built probably hasn’t. Plus, as soon as you start creating new abstractions there's going to be impedance mismatch with the underlying ones.
One of the benefits of categories / class extensions — the ability to define new methods on external classes — is that they let you add functionality to existing frameworks, solving pain points without having to wrap everything in a new layer.
sebastien | 3 hours ago
This! I did find Ousterhout's Philosophy of Software Design quite good at articulating what makes a good API/framework. Abstractions can simplify, but simplicity is one of the hardest thing to achieve.
WilhelmVonWeiner | 6 hours ago
Strong agree. I don't even like internal company projects to wrap libraries across services. At the last business I worked for we (5-6 engineers) used yt-dlp in a few places and there were a couple suggestions over the years to wrap it in an internal library. My counter-suggestion was always that the uses were either different enough that combining them into a library doesn't reduce the amount of work but increases the maintenance burden in various ways, or the uses are similar enough that we should roll out a service (we were using microservices) that would do the video downloading for us. Maybe with a monorepo it's a good idea but in my experience trying to over-apply DRY makes life harder.
stephenr | 4 hours ago
Isn't "rolling out a (micro)service" just "wrap it in an internal library" with extra steps, and accessed via HTTP?
Vaelatern | 3 hours ago
I suspect with lower maintenance demands because the running environment is consistent. Library authors have it hard.
wink | 5 hours ago
Time is a flat circle. We had this discussion 15-20 years ago with PHP and then Rails came and then Symfony and other PHP frameworks that established themselves as the standard came.
And now we have things like React and I would take any mini framework of a random person over it.
hyperpape | 6 hours ago
I think the article is directionally right, but I don't think it locates the distinction in the right place. I would ask two questions:
What do I mean by "fuck around and find out?" Questions arise about what an operation should do, whether something is a bug, etc, and there's no clear answer, or if there is an answer, it's a matter of taste more than anything that can be justified to others. Decisions are often made by fiat.
If the answer is yes/yes, then it's probably safe to use the higher level abstraction. There's still a question about whether it pays its way, but at least it should not be too hard to move back and forth between the levels.
If it's no/yes, I think you'll have a bad time--it takes a lot of work to build a stable foundation on top of something poorly defined. If it's yes/no, that's also quite bad, you're losing a lot for the higher level framework, and the lack of clear semantics often leads to the "only one person knows how this works" problem.
If it's no/no, it's probably a complicated case by case scenario, you may not have a lot of great options.
mccd | 2 hours ago
I agree a lot with this article, having dealt with teams that built dsls over existing languages that forced people into bad practices and made it hell to change the foundation.
I think it's related to inner platform effect, and oil shell introduced this term or interior vs exterior extendability
https://www.oilshell.org/blog/2023/06/narrow-waist.html
I think it's better to try to build exterior extensible tooling.
heavyrain266 | 23 minutes ago
Frustrating boilerplate and repetitive code can be easily solved with shared snippets, served by e.g. Simple Completion Language Server for cross-editor completions. Our team adopted such solution few months ago, and it reduces context switching during the review process (no need to dig through the layers of abstractions).