Avoid Mini-Frameworks
laike9m.com
Avoid Mini-Frameworks
1–10 of 119 posts
Re: Avoid Mini-Frameworks
#2I wrote this article to reflect a pattern I observed (and hate) while working in Google, but I'm sure this is not a company specific problem. Would be interested to hear other people's stories :)
I can be found here:
Re: Avoid Mini-Frameworks
#3Basically, premature abstraction / abstraction at the wrong boundaries coupled with the political power to force adoption of the bad abstraction. Yep. That’s an annoying attribute of working at a big corp. I prefer working in tiny teams and companies for this and many other reasons.
Re: Avoid Mini-Frameworks
#4> Introduce new concepts that doesn't exist in the original stack
That is also true for "macro" frameworks.
> Wraps around the company/org-shared tech stack or framework
That is often also true for "macro" frameworks.
> Creators claim that the framework "magically" solves many problems, and push more people to use it
That is often also true for "macro" frameworks.
---
It is not clear from the reader's perspective what actually characterizes a "micro" framework. It's also not clear why the size is the issue here, when all complaints seems to be about design or quality.
Is googletest a micro or macro framework? Is google/zx a micro or a macro framework? Give us some clarifying examples. Actual things people can look for, not internal unknowable projects. There must be some exceptions too (silver bullet rules don't exist), mention them.
Also, rethink the title. Maybe "makeshift frameworks" is better terminology, as it more accurately reflects the problem that is described in the content.
Re: Avoid Mini-Frameworks
#5> real and only difference between a library and a framework, is whether it introduces new concepts
This isn't what is normally understood in software engineering by those terms.
A library is something you call.
A framework is some kind of application scaffolding that normally calls you.
You can use more than one library. You normally only have one framework in-process.
I found the blog post a little hard to parse. Is it an argument against wrapping frameworks, or wrapping libraries?
I agree that wrapping frameworks is fraught with danger. I can't quite agree for wrapping libraries. Wrapping libraries makes a lot of sense if you're only using a tiny fraction of the library functionality, the breadth of the wrapper's API is much smaller than the library's API, wrapping it enables you to substitute it (whether for a smaller / faster / whatever dependency in the future, or for testing, etc.), and so on.
Re: Avoid Mini-Frameworks
#6As a rule of thumb, "magic" is a code smell. Libraries should be preferred over frameworks whenever possible.
A toolbelt of small utility-like composables are often easier to maintain and reason about. This results in added explicitness (i.e. less magic, fewer surprises).
Personal experience shows that the immediate efficiency gains of a framework often get diminished in the face of all the hacks people introduce later, just to work around the remaining 10% of cases that the framework did not anticipate or traded-off against.
Please note this is a comment based on personal experience and professional preference.
BOCTAOE.
Re: Avoid Mini-Frameworks
#7> real and only difference between a library and a framework, is whether it introduces new concepts This isn't what is normally understood in software engineering by those terms. A library is something you call. A framework is some kind of application scaffolding that normally calls you. You can use more than one library. You normally only have one framework in-process. I found the blog post a little hard to parse. I…
these things are hard, maybe impossible to define.
For example I mostly agree with your calls/called definition but you also get self-described libraries like React giving you defined structure and hooks that call your code.
Re: Avoid Mini-Frameworks
#8As a rule of thumb, "magic" is a code smell. Libraries should be preferred over frameworks whenever possible. A toolbelt of small utility-like composables are often easier to maintain and reason about. This results in added explicitness (i.e. less magic, fewer surprises). Personal experience shows that the immediate efficiency gains of a framework often get diminished in the face of all the hacks people introduce lat…
I remember using Laravel a while back and it had quite some magic but it was done right and made a lot of things much easier
Re: Avoid Mini-Frameworks
#9I never heard the term mini framework before but I like it. Applied within that context it makes sense. I was at Google 2011-2013 through an acquisition and witnessed some of what the author is describing. Actually something very specific comes to mind. There was a SQL library built on top of BigTable, Google's internal columnar data store, I think it was called Megastore [1]. The team implementing a new product decided to use it over BigTable directly because what it would mean for ease of development but it turned out as soon as they needed to do any data migration it was locking the entire database (or I guess the table? Aka BigTable). Anyway at the time this was a major issue and they had to revert to BigTable best practices as opposed to what this library was doing. Because essentially it was a library layer, not some new data store. Eventually Google built a different SQL based data store to replace the whole thing which you can see the open source version known as CockroachDB, which some ex-googlers invented.
Moral of the story, abstractions always fail the edge cases, especially at scale. But when the entire eng org adopts something, it works much better. Everyone has to be bought in. Which at Google scale is hard.
https://research.google/pubs/megastore-providing-scalable-hi...
Re: Avoid Mini-Frameworks
#10I wrote this article to reflect a pattern I observed (and hate) while working in Google, but I'm sure this is not a company specific problem. Would be interested to hear other people's stories :) I can be found here: https://x.com/laike9m https://mastodon.social/@laike9m
Thanks for the article. I generally agree that adding more layers in an attempt to "fix" lower layers is often a fools errand. And just a quick typo I noticed and I'm smugling in this comment: legondary->legendary.