[barrkel]

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

[baobun]

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"

[dpark]

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

[bccdee]

That's one thing I'll say for in-house "mini-frameworks": Real frameworks often try to present a smooth façade of abstraction which is hard to punch holes through. An in-house "mini-framework," though, is often just a hodgepodge of compostable abstractions which you can individually take or leave without too much hassle.

Of course, your hodgepodge ecosystem will eventually ends up a bit of a mess, but I'll take that over a flashy off-the-shelf framework that insists on handling everything itself.

[gejose]

> lot of magic to make it trivial to start and they don’t scale to real projects

Ruby on Rails is probably a great counter example here though.

[TOGoS]

I have never really grokked Ruby on Rails and I passionately hate all the frameworks that try to adapt it to some other language.

That said, I suspect that Ruby on Rails itself occupies kind of a special space where the magic is acceptable because people who write Ruby are used to having very very sharp tools and have learned to wield them carefully. Give that magic to a PHP or Java programmer and there is immediately gallons of blood on the floor.

(says former Rubyist who was put off by the RoR stuff because I'm apparently more of a Haskeller at heart.)

[wouldbecouldbe]

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]

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]

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.

[hogrug]

It's a mixed bag.. If you spend much time in a poorly reviewed ecosystem then you are quickly taught that if you try to make things work in their broken crap you will lose a lot of time and have no code to demonstrate you were working at all.

If you always inject the same repair layer approach of your own crap then you ship more reliably and have your pleased client and your lock-in. The pleased client then has to decide if they should listen to a replacement who says you are insane but can't seem to ship anything.

[skydhash]

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.

[baobun]

It sounds like you are agreeing - that digging into the existing layers can be a good idea that is often neglected or resisted to a fault. That we should treat existing software less like black boxes.

There are caveats here too of course - forking every single thing and excessive NIH syndrome comes with their own costs and risks.

[andoando]

But the whole software stack is built on abstractions on abstractions on abstractions. Its just a matter of finding the right ones

[swordfeng]

You know what I feel when I see someone adding a dependency injection framework to a micro micro service with merely 6 classes...

[TOGoS]

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

[baobun]

I concede I had a bit of second thoughts after posting the comment you replied to.

After all, hindsight is 20/20 and at the end of the day a major part of our work is making (appropriate) abstractions. Picking good terminology is sometimes hard. I guess to point out that the message shouldn't be read as "all abstractions bad (stop trying)" but to be more conscious about them and to restrain from piling new "magic" on top of a tower of old apocrypha.

[exasperaited]

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

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

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]

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.

[locknitpicker]

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

[forinti]

Frameworks abide by the Hollywood Principle and the Greyhound Principle:

Don't call us, we'll call you.

Leave the driving to us.

[boxed]

Let me introduce you to development on Apple platforms, where "framework" is literally the term for all libraries since the NeXT days.

imo it's better to just figure out the definition in the current context, than try to force your own definition unto others. You can't anyway.

[imtringued]

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]

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

[davnicwil]

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.

[vbezhenar]

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.

[mablopoule]

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]

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]

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.

[nicoburns]

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]

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)

[rictic]

Agree, for modern React with hooks. A React component looks like a normal function, only you can't call it. Only React can call it, in order to set up its hooks state.

[8n4vidtmkvmk]

JSX has at least transcended React. Not sure I'd still call it a DSL... Unless maybe you consider what it compiles to a factor. Which would be fair.

[iTokio]

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

[simonw]

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

[jodrellblank]

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)

[simonw]

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

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.

[mablopoule]

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

The meta about us page also says it is a privacy first company.

[threatofrain]

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

[davnicwil]

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.

[est]

> Is it an argument against wrapping frameworks, or wrapping libraries?

I think English is not OP's first language, framework here basically means wrappers.

[8n4vidtmkvmk]

That's not how i understood it. Wrappers can typically be unwrapped. Frameworks are a lot harder to circumvent.

[k__]

It's the same with app, application, program, software, tool, etc.

[0x696C6961]

Is an `EventEmitter` a framework or a library?

[andsoitis]

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

A library. It doesn’t define how you structure your application in any way.

[baobun]

Neither. It's an implementation of the interface in question.

[oncallthrow]

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

There is:

https://en.wikipedia.org/wiki/Inversion_of_control

[ldng]

Not every framework use IoC.