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

61–70 of 119 posts

Re: Avoid Mini-Frameworks

#61

Post by threatofrain »

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

The ecosystem is starting to move to the term metaframework to describe nextjs or tanstack. We're now getting layers upon layers upon layers.

Re: Avoid Mini-Frameworks

#62

Post by davnicwil »

simonw wrote: post #56
jodrellblank wrote: post #46

Earlier quoted context omitted.

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? 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, t…

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.

Re: Avoid Mini-Frameworks

#63

Post by dpark »

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…

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

Re: Avoid Mini-Frameworks

#64

Post by dpark »

adpatersbad wrote: post #45
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. d…

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.

Re: Avoid Mini-Frameworks

#65

Post by imtringued »

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…

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.

Re: Avoid Mini-Frameworks

#66

Post by imtringued »

davnicwil wrote: post #50
vbezhenar wrote: post #22

Earlier quoted context omitted.

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

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.

Re: Avoid Mini-Frameworks

#67

Post by foobarchu »

wouldbecouldbe wrote: post #43
baobun wrote: post #15

Earlier quoted context omitted.

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

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.

Re: Avoid Mini-Frameworks

#68

Post by foobarchu »

nicoburns wrote: post #33
vbezhenar wrote: post #22

Earlier quoted context omitted.

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.

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.

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)

Re: Avoid Mini-Frameworks

#69

Post by laike9m »

imtringued wrote: post #65
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…

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…

Thanks for the comment. I think you're spot on, and I should have explained more clearly what "concept" means in this context.

Re: Avoid Mini-Frameworks

#70

Post by locknitpicker »

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…

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

Post reply on HN