[gaigalas]

> 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.

[anon5739483]

If you have a very specific product with limited scope, a micro-framework would work just fine. My experience in the real world™ is as such: people start with micro-frameworks and keep bolting on stuff to the point where it would have been better if they started with a macro-framework in the first place. At least there is better compatibility between framework components and a clear upgrade process. I agree with the "makeshift framework" terminology by the way. One way or another, my experience is that products that start with micro-frameworks, over time turn into a "makeshift framework" over time regardless. If the scope is clear and limited from the start, micro-frameworks are great. If unsure, micro-framework is a no go (for me).

[gaigalas]

My experience in the real world is that the majority of people choose the largest "macro" framework available and go with that. It's what happens most often.

The "micro framework" phase happens when that "macro" framework fails to deliver something. It happens way less often than a team picking a big estabilished tool.

However, the sizes never mattered. That is likely what causes the confusion in the first place ("it's large so it must have lots of things I want", "it's small so it must be easy to understand").

The real red herring is focusing on the size (or LOC, or any vague metric) instead of other more relevant architectural properties.

[laike9m]

Maybe I should have written it more clearly, but the mini-frameworks I described in the article are not makeshift -- instead they're permanent and stay forever, expanding as time goes, until being replaced by something else.

[gaigalas]

I know what you mean! I've lived through those myself.

However, for a beginner, specially if said beginner never worked in a larger company with resources to produce an internal framework, they might think you're referring to Flask or something like that (btw Flask-style microframework use can go very wrong but it's another completely different issue).

That's why I'm being nitpicky. The people who'll get the post are likely already experienced enough to evaluate those frameworks themselves.