Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoid Mini-Frameworks

laike9m.com

Post reply on HN
Print view View original

41–50 of 119 posts

Re: Avoid Mini-Frameworks

#41

Post by gaigalas »

anon5739483 wrote: post #35
gaigalas wrote: post #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 wha…

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…

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.

Re: Avoid Mini-Frameworks

#42

Post by bogzz »

chanux wrote: post #37

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.

> stay safe out there

Are you the Internet of Bugs gentleman?

Re: Avoid Mini-Frameworks

#43

Post by wouldbecouldbe »

baobun wrote: post #15
barrkel wrote: post #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. I…

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 o…

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

Re: Avoid Mini-Frameworks

#44

Post by chrisweekly »

narvidas wrote: post #6

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 lat…

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

Re: Avoid Mini-Frameworks

#45

Post by adpatersbad »

barrkel wrote: post #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. I…

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

Re: Avoid Mini-Frameworks

#46

Post by jodrellblank »

simonw wrote: post #32
iTokio wrote: post #12

Earlier quoted context omitted.

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

A hill I will die on is that React is a framework.

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)

Re: Avoid Mini-Frameworks

#47

Post by mablopoule »

vbezhenar wrote: post #22
davnicwil wrote: post #7

Earlier quoted context omitted.

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.

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.

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.

Re: Avoid Mini-Frameworks

#48

Post by mablopoule »

jodrellblank wrote: post #46
simonw wrote: post #32

Earlier quoted context omitted.

A hill I will die on is that React is a framework.

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

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

Re: Avoid Mini-Frameworks

#49

Post by ozim »

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

Re: Avoid Mini-Frameworks

#50

Post by davnicwil »

vbezhenar wrote: post #22
davnicwil wrote: post #7

Earlier quoted context omitted.

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.

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.

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 :-)

Post reply on HN