[HN Gopher] Avoid Mini-Frameworks
___________________________________________________________________
Avoid Mini-Frameworks
Author : laike9m
Score : 105 points
Date : 2025-12-24 12:04 UTC (10 hours ago)
(HTM) web link (laike9m.com)
(TXT) w3m dump (laike9m.com)
| laike9m wrote:
| I 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
| hu3 wrote:
| 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.
| christophilus wrote:
| Basically, 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.
| aefalcon83 wrote:
| Oh, I know a small company that is affected by this problem,
| but your description of the cause is spot on.
| gaigalas wrote:
| > 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 wrote:
| If you have a very specific product with limited scope, a
| micro-framework would work just fine. My experience in the real
| world(tm) 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 wrote:
| 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.
| barrkel wrote:
| > _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.
| davnicwil wrote:
| 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.
| iTokio wrote:
| That's because React started as a small, focused library and
| evolved as even more than a framework, a whole ecosystem,
| complete with its own best practices
| davnicwil wrote:
| I don't agree. What I said about React providing structure
| and (lifecyle) hooks was true from the first version.
|
| The later stuff adds other ways of doing the same thing but
| a library it remains.
|
| That's as self described by the React team, and I think the
| consensus more broadly.
| simonw wrote:
| A hill I will die on is that React is a framework.
| jodrellblank wrote:
| React's homepage says "The library for" and "Go full-
| stack with a framework. React is a library. It lets you
| put components together, but it doesn't prescribe how to
| do routing and data fetching. To build an entire app with
| React, we recommend a full-stack React framework like
| Next.js or React Router." and "React is also an
| architecture. Frameworks that implement it let you..."
|
| React's Wikipedia page says "React ... is a free and
| open-source front-end JavaScript library", and has no
| mention of Framework.
|
| Why die on a hill that it "is" something it says it
| isn't?
|
| [] https://react.dev/
|
| [] https://en.wikipedia.org/wiki/React_(software)
| mablopoule wrote:
| > Why die on a hill that it "is" something it says it
| isn't?
|
| There's plenty of guru who say that they are the
| reincarnation of Jesus and/or Buddha, doesn't mean that
| we have to take their word for it.
|
| In the same vein, North Korea is officially the
| "Democratic People's Republic of Korea", even though it's
| obviously not a democracy.
| iammrpayments wrote:
| The meta about us page also says it is a privacy first
| company.
| simonw wrote:
| > Why die on a hill that it "is" something it says it
| isn't?
|
| Because I think they're wrong about that.
|
| If you'd prefer a different metaphor this is windmill I
| will tilt at.
|
| To provide a little more of a rationale: React code calls
| the code I write - the JSX and the handlers and suchlike.
|
| It's also pretty uncommon to see React used at the same
| time as other non-React libraries that handle UI stuff.
|
| Most importantly, the _culture_ and ecosystem of React is
| one of a framework. You chose React at the start of a
| project and it then affects everything else you build
| afterwards.
| davnicwil wrote:
| It's super interesting that you have this definition
| given your authorship of django (I mean, actually
| interesting, not 'interesting' :-)
|
| In another comment I used the example of rails as a kind
| of canonical 'framework' that can potentially do
| everything for you full stack, and django is in the same
| category, juxtaposed against something like React that
| cannot.
|
| To that, I think your last paragraph is the one I agree
| with most closely. It's true, but only for the view part
| of the app, right? I think that's where I get stuck on
| stretching to calling it a framework.
|
| I guess I can see it if you're defining your view/client
| as a separate logical entity from the rest of the stack.
| Which is totally reasonable. But I guess just not how I
| think about it.
| threatofrain wrote:
| The ecosystem is starting to move to the term
| metaframework to describe nextjs or tanstack. We're now
| getting layers upon layers upon layers.
| vbezhenar wrote:
| React is 100% framework. They even bring their own DSL. It's
| absurd to call React library.
|
| Library is something that can be pulled off project and
| replaced with something else. There's no non-trivial project
| where replacing React with anything would be possible. Every
| React web app is built around React.
| nicoburns wrote:
| Most people don't but you absolutely _can_ use React a
| library. When React was very new, it was popular to use it
| as a view layer with backbone.js. In that usage, it 's
| essentially a sophisticated templating library.
| foobarchu wrote:
| You can use Spring as a library if you really want to as
| well, but it's still a framework.
|
| Id maybe concede that frameworks are a subset of
| libraries. You can use most frameworks in a library
| fashion, but the opposite is not true (you'd need a mini
| framework)
| mablopoule wrote:
| 100% this. To this day the official website still describe
| itself as a library, and I'm convinced it's completely for
| marketing reasons, since 'framework' feels heavy and
| bloated, like Angular or Java Spring, while 'library' feels
| fast and lightweight, putting you in control.
|
| Framework can be more or less modular, Angular or Ember
| choose to be 'battery included', while React choose to be
| more modular, which is simply choosing the other end of the
| spectrum on the convenience-versus-flexibility tradeoff.
|
| React ostensibly only care about rendering, but in a way
| that force you to structure your whole data flow and
| routing according to its rules (lifecycle events or the
| 'rules of hooks', avoiding mutating data structures); No
| matter what they say on the official website, that's 100%
| framework territory.
|
| Lodash or Moment.js, those are actual bona fide libraries,
| and nobody ever asked whether to use Vue, Angular or
| Moment.js, or what version of moment-js-router they should
| use.
| davnicwil wrote:
| I think absurd is a bit strong. It'd be absurd to call
| something like rails a library.
|
| I think you can probably see that distinction already, but
| to spell it out React is described as a library precisely
| because it does just one thing - the view - and leaves it
| to you to figure out the entirety of the rest of the stack
| / structure of your app.
|
| Framework, at least to me, but I also believe commonly,
| means something that lets you build a full application end
| to end using it.
|
| You can't do that with React unless your app is just
| something that lives in the browser either in-memory or
| with some localstorage backing or something. If that's your
| app, then probably I'd agree React is your framework per
| se, but that's hardly ever the case.
|
| By the way, back to my original point, I still do think
| these things are impossible to define and in lots of ways
| these terms don't matter - if it's a framework for you,
| it's a framework - but I just had to defend my position
| since you described it as absurd :-)
| imtringued wrote:
| React is a framework for blatantly obvious reasons.
|
| It introduces JSX, which is technically speaking its own
| programming language independent of JavaScript.
|
| It defines hooks like useState() and useContext() for
| state management, meaning it is not UI only, plus
| "function based" components that act as a pseudo DSL that
| is pretending to be functional JavaScript (which it
| isn't).
|
| Most of the time you're expected to render the entire
| page body via react.
|
| You couldn't get further away from the idea of a library.
| 0x696C6961 wrote:
| Is an `EventEmitter` a framework or a library?
| baobun wrote:
| Neither. It's an implementation of the interface in question.
| andsoitis wrote:
| > Is an `EventEmitter` a framework or a library?
|
| It is best described as a pattern implementation (observer /
| pub-sub).
|
| Example Node.js EventEmitter usage:
|
| _const EventEmitter = require( 'events');
|
| emitter.on('data', handler);
|
| emitter.emit('data', value);_
|
| -----------
|
| You explicitly instantiate it. You explicitly register
| listeners. You explicitly emit events. It does nothing unless
| you call it. There's no lifecycle, no main loop, no required
| structure.
|
| EventEmitter is not a framework because it does not define
| application structure. It doesn't own the program's control
| flow. It doesn't decide when your code runs (beyond callbacks
| you register). It does not enforce conventions or
| architecture.
|
| People sometimes call it a framework incorrectly because of
| two sources of confusion:
|
| 1. Callback-based APIs feel like inversion of control. But
| this is partial IoC, not framework-level iOc.
|
| 2. It is often embedded inside frameworks. Examples: Express
| routes, React synthetic events, Electron internals.
| ricardobeat wrote:
| A library. It doesn't define how you structure your
| application in any way.
| baobun wrote:
| If you look above the unorthodox library/framework distinction,
| I think the criticism is about birthing new (inadvertently
| leaky) abstraction layers with new semantics to capture the
| specifics of the domain. Often with either esoteric words
| attached to supposedly novel patterns, and/or unconventional
| usage of existing terminology.
|
| The promise is to simplify and unify things but as noted, such
| efforts often have the opposite effects.
|
| "Teams are struggling with properly adopting FooTech - our
| FooBarTool wraps it in a beautiful package and magically solves
| everything with a single command and one config file"
|
| "We should template all this yaml"
| wouldbecouldbe wrote:
| Yeah had so many discussion with senior developers in my life
| to argue for just keeping things simple, but my god they love
| abstractions. They are clearly always very smart and
| understand the code base well. Maybe it's their intelligence
| wanting to be more utilised or maybe they are bored and
| trying to over engineer simple problems
| foobarchu wrote:
| I would narrow this down further. Programmers (myself
| guilty) live abstractions _they control_. It gives them the
| ability to tweak little things and feel like they 've done
| it in a more maintainable way.
|
| Programmers HATE using other people's abstractions, which
| is why "mini frameworks" tend to tall apart after expanding
| to teams that don't have control over it. In my experience,
| this leads to new mini frameworks wrapping the first one,
| forever targeting a static version of the underlying MF, to
| allow for adding new appendages without going through a
| gatekeeper.
| ozim wrote:
| It is easier to write your own code than to understand
| someone's else code.
|
| It would be much better if we get more humble people who
| get down to work to understand why and how existing code
| or framework works instead of trying to work around it or
| simply throwing all away and writing their own code.
|
| Thera are of course some exceptions - but those are like
| pro athletes - no you are not the one, learn existing
| code instead of making excuses about some edge cases you
| ran into so you have to rewrite all from scratch.
| skydhash wrote:
| This view needs to be balanced. There's a lot of cases
| where the previous code didn't abstract the domain well,
| or the domain has changed (mostly at the application
| level). Fighting the ill-fitted abstraction is a real
| chore in this case and quickly lead to complex code.
|
| I'm all for aggressive refactoring if it leads to
| something simpler.
| andoando wrote:
| But the whole software stack is built on abstractions on
| abstractions on abstractions. Its just a matter of finding
| the right ones
| dpark wrote:
| > magically solves everything
|
| This is the real problem. Too often frameworks/libraries are
| geared towards making things magic instead of making things
| solid. Magic solutions are usually very one dimensional. e.g.
| The Magic only works for a really narrow use case, or at low
| load. I don't think this is specifically a problem with "mini
| frameworks" but homegrown stuff exhibits this more, if only
| because magic solutions tend to die in the wild when the bug
| tracker is full of "this only works for trivial case; make it
| actually work".
|
| When frameworks/libraries advertise how easy they are to get
| started, there is often a lot of magic to make it trivial to
| start and they don't scale to real projects without breaking
| through all the magic abstractions.
| TOGoS wrote:
| > inadvertently leaky
|
| I think this is the main problem.
|
| I don't mind layers of abstraction _when they work well and
| their components compose nicely_. Like a well-designed
| programming language. These can actually be quite fun to work
| with.
|
| Layers of abstraction where the boundaries between that layer
| and those around it are fuzzy to non-existent and where
| certain cases magically work and everything else is a janky
| mess because it was never designed to work are what give me
| headaches and want to throw my work laptop out the window on
| a regular basis.
| oncallthrow wrote:
| > A library is something you call.
|
| > A framework is some kind of application scaffolding that
| normally calls you.
|
| There is no real distinction between these two.
| bavell wrote:
| There is:
|
| https://en.wikipedia.org/wiki/Inversion_of_control
| forinti wrote:
| Frameworks abide by the Hollywood Principle and the Greyhound
| Principle:
|
| Don't call us, we'll call you.
|
| Leave the driving to us.
| exasperaited wrote:
| > A library is something you call. > A framework is some kind
| of application scaffolding that normally calls you.
|
| I think I broadly agree with this. In essence, libraries don't
| impose an application-level life cycle. Frameworks, generally,
| do.
|
| The rest of the article, I don't know....
|
| The most successful, long-running app I maintain has a mini-
| framework that allowed me to assemble what I need piecemeal
| rather than relying on any off-the-shelf framework that would
| have been obsoleted several times over in the seventeen-year
| lifespan of this code.
|
| I guess about one in three things I do in it require me to dip
| into my framework code to look at it, but this is mostly to
| remember how it works! About one in five things have required
| me to make a small progressive change.
|
| Twice in its lifetime a core component has been swapped out
| (mailer and database library).
|
| And twice in its lifetime, because it is beginning to converge
| on a general web framework, I have considered porting the code
| _out_ of it and into a general framework, which might make it
| easier to hand over. One day, I suspect, something will break
| compatibility in a way that makes that the sensible route, but
| the code works, fast, has a pretty obvious set of abstractions,
| and there are implicit examples of everything it can do in
| everything it already does.
|
| Almost all articles like this start out with "here is a thing I
| claim is a generalised problem that I am sure you should not
| do", that is a well-meaning but false generalisation, and is
| then caveated to the point where no new point is being made.
|
| Underneath they are always: don't write bad code. If you do,
| learn from it.
|
| If I'd followed the advice of this article when I started this
| project, I would by now have rewritten the entire thing more
| than once, for little gain.
|
| Much more concise and much more sensible: consider whether your
| additional levels of abstraction have value.
|
| But do mini frameworks have value? Sure they do, especially if
| there is setup and teardown that every function needs to do.
| adpatersbad wrote:
| > Wrapping libraries makes a lot of sense
|
| The best assumption to start with is that adapters are bad by
| default, because they are an unnecessary layer to maintain (and
| potentially a point of failure and bottleneck depending on what
| they are and do). Then, make the argument for the adapter as a
| guilty until proven innocent case.
|
| If you can make a solid case for it, fine. There are many solid
| cases for adapters, e.g. drivers for a database or hardware.
|
| Never write an adapter that you can handle more scalably,
| flexibly, and almost as easily by calling something directly.
| ka_veli wrote:
| A potential counter point here is that wrappers help reducing
| churn if the library being wrapped is actively developed -
| this can apply to both external libraries and ones developed
| by other internal teams. A wrapper limits the surface area
| that needs updating and can make some otherwise quite painful
| upgrades easier, at the cost of maintaining the wrapper
| itself. As ever, it's a situational thing of course!
| dpark wrote:
| Wrappers are a great idea if you need a small set of what the
| library provides. Also very valuable if the library you are
| using doesn't have good support for testing.
|
| Certainly you should not wrap a library "just because". The
| benefit of doing so should be easy to articulate.
| k__ wrote:
| It's the same with app, application, program, software, tool,
| etc.
| imtringued wrote:
| The word "concept" here is doing extreme amounts of heavy
| lifting here.
|
| If I had to bring the point home I'd say that the author
| himself committed the very mistake he is warning against in
| that very sentence.
|
| Frameworks define conventions and non-language features
| (language feature=data structures, callable functions, etc)
| that cannot be expected to be understood by simply reading the
| existing code and therefore need to be learned explicitly by
| reading the documentation of the framework. Frameworks are
| allowed to bend rules and expectations, because you're supposed
| to learn and be aware of them ahead of time.
|
| This directly applies to the irresponsible use of the word
| "concept". The meaning of what he was trying to convey cannot
| be understood based on simply reading the sentence.
| laike9m wrote:
| Thanks for the comment. I think you're spot on, and I should
| have explained more clearly what "concept" means in this
| context.
| locknitpicker wrote:
| > A framework is some kind of application scaffolding that
| normally calls you.
|
| This. A framework relies extensively on inversion of control.
| It provides the overall software architecture of an
| application, and developers just inject the components called
| by the app to customize some aspects.
| narvidas wrote:
| As 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.
| wouldbecouldbe wrote:
| 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
| Lukas_Skywalker wrote:
| I don't like dismissing technologies on the basis of being
| ,,magic", since the magic could often just as well be called
| abstraction, and the line between them is often personal
| preference.
|
| The abstracted-away logic in a Laravel application can either
| be called magic or abstraction, but so can the optimizations of
| a database query planner.
|
| I think often you still need to know the underlying mechanism,
| but it is still useful to get the innards out of the way.
| hasley wrote:
| The problem is not the abstraction itself.
|
| The problem is that your code has to work _within_ this
| abstraction and can only solve problems covered by the
| inventors of the abstraction.
| senbrow wrote:
| It's useful to get "glue" code out of the way while building,
| but to the point in the article it all becomes very difficult
| to debug and maintain once there are problems in the that
| layer.
|
| Spring Boot and other similar frameworks come to mind; by
| forcing huge amounts of indirection you lose a lot of
| visibility of your call stack because the convenient "glue"
| code is now orchestrating everything at runtime, but that
| code isn't yours, and it isn't easily inspected or fixed.
| hasley wrote:
| In case "framework" is understood as something that calls my
| code and that forces me to write my code in a certain way, I
| totally agree.
|
| And I think twice before I use a framework. Frameworks enforce
| a certain way of programming which you can never be sure to
| match the problems you will have to solve in the future.
| Libraries don't do this - at least not to the extent of a
| framework. Libraries are composable building blocks.
|
| Nevertheless, there may be applications where frameworks are
| beneficial (e.g. GNU Radio).
| chrisweekly wrote:
| I had to look up BOCTAOE (But Of Course There Are Obvious
| Exceptions)
|
| "Good magic decomposes into sane primitives" highlights an
| essential distinction: not all magic is bad (but it's not
| always clear at first which kind of magic is in play).
| asim wrote:
| I 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...
| mkoubaa wrote:
| "shared infrastructure owned by dedicated teams" must be nice, I
| have to say
| smetj wrote:
| Somehow, somewhere there is a pleasant balance between DRY and
| non-DRY which is different for everybody. God forbid having a
| colleague who sees a thing repeating and slaps an abstraction
| over it at whatever cost because DRY!
| anon5739483 wrote:
| This is why I use Ruby on Rails. Shared constraints and boring
| conventions age better than clever mini-frameworks built around
| one team's mental model.
| oncallthrow wrote:
| This. This. This. I currently work in a codebase where so much
| code has been abstracted away for "cleanliness" that it's
| impossible to understand what code is actually running.
|
| The worst is when three lines of completely standard code
| (immediately understandable to anybody inline) get ,,helpfully"
| lifted out into a utility function.
| oncallthrow wrote:
| By the way, the reason behind all of this, like so many ills of
| our industry, is the completely broken promotion culture.
| layer8 wrote:
| While I agree that the promotion culture appears to be broken
| in the US, I can assure you that these kinds of over-
| abstractions happen completely regardless of promotion
| culture.
| petcat wrote:
| It's why I've always eschewed stuff like flask even when I felt
| like Django was going to be overkill. The problem is that,
| especially for web apps, everybody needs the same stuff. You need
| to handle cookies and forms and auth. You need to be able to
| inspect and manage your data. You need to be able to do tokens
| and password resets.
|
| At the end of the day. You end up cobbling together a bespoke,
| worse version of Django anyway.
| simonw wrote:
| This was great. I enjoyed the alternative definition of
| "framework" as something that introduces new concepts (differing
| from the more common idea that it's code that calls YOUR code.)
|
| This article reminded me of two classic pieces of writing.
|
| The first is 20+ years old now: Joel Spolsky's law of leaky
| abstractions:
|
| https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
|
| One of the reasons these mini-frameworks lead to problems is that
| they _leak_. They don 't cover every case which means you
| inevitably have to fully understand what they are doing for you
| in order to debug them or work around their limitations. Your
| cognitive load goes up!
|
| The second is Will Larson's "Migrations: the sole scalable fix to
| tech debt."
|
| https://lethain.com/migrations/
|
| The OP complains that they've never seen a technology migration
| at Google that finished. Will advocates for migrations to be
| driven by a team that both coaches other teams on the migration
| and then, crucially, _finish the job themselves_ to make
| absolutely sure it gets done to 100% completion.
| chanux wrote:
| Making good abstractions is hard.
|
| And it is very easy to start feel like you know you have a great
| abstraction when you don't. And unfortunately it's easy and fun
| to make abstractions, kinda like making babies. And has kind of
| similar weight to it too.
|
| I just have to say.. stay safe out there.
| bogzz wrote:
| > stay safe out there
|
| Are you the Internet of Bugs gentleman?
| PaulHoule wrote:
| Mini-frameworks would be dangerous at a place like Google where
| smart people think they are smart. I think they're heaven sent
| for smart people who think they're stupid.
|
| Distributed (multithreaded, concurrent, ...) systems are a
| counterexample that are highly vulnerable to snake oil. In normal
| software it makes sense to build up from a small set of
| intellectually coherent primitives. In those cases you inevitably
| end up with poor performance and usually reliability if you try
| that. Java started out with a snake oil approach to threading
| (synchronized!) and Doug Lea talked some sense into them and now
| we have java.util.concurrent which has a rich set of primitives
| which are pragmatic and meet the real requirements, not a vision
| of purity.
|
| On the other hand, If it was a mini-framework to pound out
| numerous not-so-simple HTML form applications it could greatly
| enrich your life and your team's.
| ozim wrote:
| This is a curse of lots of software companies:
|
| ** mini-frameworks is a realization of the creator's mental
| model, but it's not everyone's mental model**
|
| People being smart enough to make their own understanding work
| well - but not smart enough to see they are just pushing their
| way of doing things and not working on something "generally
| understood".
| huqedato wrote:
| I don't really understand the concept. What is the definition of
| "mini-framework" ? The author should have given a few examples.
|
| I have the impression that he confuses "obscure" with "mini".
| Either framework or library..
| gethly wrote:
| Frameworks promised faster development cycle, lest code and
| uniform codebase. But over the years, this proved to fail to
| deliver except in certain minority of cases.
|
| I think modern programmers nowadays understand that it is much
| better to take the path of libraries than frameworks as it
| provides them with the same functionality of a framework(which is
| just a bundle of libraries), but with the freedom of implementing
| their code however they want, unlike wit ha framework, which
| forces certain structure and style as frameworks had to made
| certain decisions for the programmer in order to be a functional
| and comprehensive tool. This lack of freedom will usually bite
| most programmes LATER, when it is too late to go back and
| refactor code or change style and whatnot.
|
| And that inherently also makes small frameworks even less usable
| than the larger ones.
|
| YMMV, but not really.
| erkok wrote:
| Having been around in the industry for a while I'm seeing
| abstractions being misused all the time. Being guilty of it
| myself also when I was younger.
|
| For me, the only purpose of an abstraction is to reduce
| complexity, but often times I'm seeing it being used to reduce
| repetitiveness, which often times replaces well understood more
| verbose code with less understood less verbose and less flexible
| alternative. For me, as a team lead, easy to read code is far
| more important than subjectively perceived elegant abstraction
| that everyone then has to learn how to use, and potentially fight
| with.
|
| In many cases I have noticed people jumping into abstracting away
| a complexity right away, often times ending up with a leaky or
| inflexible abstraction. To those people I say, do that painful
| thing at least 10 times, then think about abstracting it away,
| since then you probably have some level of understanding about
| the pain you're trying to alleviate and all the nuances that
| comes with that domain.
| laike9m wrote:
| Exactly
| sunir wrote:
| It's a simple math problem. And it is also Conway's law that says
| all software design follows the organization that built it--that
| is all software design is political.
|
| A framework calls you. You call a library.
|
| A framework constrains the program. A library expands the
| program.
|
| It's easier to write a library that is future proofed because it
| just needs to satisfy its contract.
|
| It's harder to write a framework because it imposes a contract on
| everything that depends on it.
|
| Just like it is hard to write tort law without a lot of
| jurisprudence to build out experience and test cases, it is hard
| to write a framework from only one use case.
|
| No one likes lawyers because they block you from doing what you
| want. This is the problem with frameworks.
|
| However the government likes laws because they block you from
| doing what you want. Same with whomever is directing engineering
| that wants all other programmers to work in a consistent way.
| lpghatguy wrote:
| In my career, I've found that this problem crops up the most when
| a team is unable to make impactful changes to a system that they
| depend on. It's so much easier (and requires less collaboration
| and fewer approvals!) to build an abstraction over some core
| system than to actually fix the core system, even if fixing the
| core system is always the better choice.
|
| I was very guilty of this as a young go-getter engineer! Why try
| to convince another team that something should be fixed if I can
| just paper over it?
| lostdog wrote:
| I also think the author is understating how bad the original
| framework was. I've seen some of these and the "itchy points"
| are real true problems. The team supporting the framework
| decides that fixing the pain won't get them promo because it
| doesn't show up in any metrics, and certainly they won't accept
| your submitted improvements. Your only choice is to wrap it.
|
| Of course, since their thing is a framework, your wrapper must
| be a framework too. (Is it possible to wrap a framework into a
| library?)
|
| The end of the story is even sadder. You work on your
| replacement and wrapper, and oh no, the framework you are
| wrapping has problems or slowness because of the framework it
| depends upon!
| mircerlancerous wrote:
| I'm not sure I can accept the findings of this article. It seems
| to me that all the concerns and issues can be summed up to bad
| design. A mini framework should be designed to be easy to adapt
| and extend, and any layer on top should be just as easy to
| further adapt and extend. That to me is the crux of this, "avoid
| frameworks that are difficult to adapt and extend".
| scott_w wrote:
| I feel like "bad design" is too reductive. The article is an
| attempt to explain _why_ it's bad. What are the practical
| problems it introduces?
|
| I think it could go a little further in explaining what I think
| the root cause of the issue is: the people developing this mini
| framework do not have the time or focus to turn it into a full
| framework. Compare to Django, Rails, React who, whatever your
| opinion, clearly have time and mission to build, test and
| document a framework for others to use.
|
| The very nature of working for a SaaS company means your true
| goal is to build shit for your customers. Any internal tooling
| has to overcome this large hurdle to get the attention it needs
| to be able to truly thrive. And rightly so.
| daxfohl wrote:
| Yes, this little-known blog post from 2015 with a similar line of
| thought was one of the most influential of my career:
| https://tomasp.net/blog/2015/library-frameworks/
|
| The modern variant of this is "platform vs service". At my
| previous company, it seemed like the only path to promotion was
| "platform" something something. So every org was in the middle of
| some way over-budget rewrite of their services as some big
| bloated platform thing, incompatible with every other team's
| platform, with less functionality than their old services
| offered. I don't know why leadership sees all these failures and
| seems to think "ooh, that's exactly what I want for my team too!"
| But you can't get a promotion if you're not platformizing.
| 0xbadcafebee wrote:
| This is one of the rare HN thinkpieces that's actually correct.
| You cannot remove essential complexity. You can shuffle it
| around, but it never goes away; you will have to deal with it.
| You can try to hand it off to someone else, like another team.
| But that actually makes it worse, because there's still some
| critical piece you depend on that's hidden behind the silo walls.
|
| Rather than trying to hide things to "ease adoption", the correct
| answer is to educate people. Devs hate learning things. But once
| they learn the new thing, the pain goes away, and the results are
| better. The more you try to avoid it, the more problems you
| create later.
| willj wrote:
| This reminds me a bit of using LLM frameworks like langchain,
| Haystack, etc., especially if you're only using them for the chat
| completions or responses APIs and not doing anything fancy.
| CharlieDigital wrote:
| > Start fresh. Don't build a wrapper around the existing
| framework, build your own from scratch.
|
| I don't know about this one. We have a mini-framework that's
| kinda GraphQL but not quite. REST-ish, but not quite. Weakly
| documented and constantly dealing with edge cases. Breaks all
| sorts of standard OpenAPI tooling because the schema returned is
| monstrous. Used to cause all sorts of issues with TypeScript and
| stack recursion. Requires a ton of code -- owned by one guy -- to
| make the OpenAPI doc generation to work correctly.
|
| I keep thinking "Just use GraphQL" because it's basically GQL at
| this point...except jankier.
| lostdog wrote:
| The right number of frameworks in a company is log10(number of
| employees). Go over this limit, and everyone needs to learn too
| many frameworks with too little support, examples, tools, and
| documentation.
___________________________________________________________________
(page generated 2025-12-24 23:00 UTC)