5 ms·

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

• davnicwil 10mo ago
  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 10mo ago
    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 10mo ago
      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 10mo ago
      A hill I will die on is that React is a framework.
      • jodrellblank 10mo ago
        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://react.dev/ [] https://en.wikipedia.org/wiki/React_(software) https://en.wikipedia.org/wiki/React_(software)
        • mablopoule 10mo ago
          > 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 10mo ago
          The meta about us page also says it is a privacy first company.
        • simonw 10mo ago
          > 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.
  • vbezhenar 10mo ago
    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 10mo ago
      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 10mo ago
        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 10mo ago
      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 10mo ago
      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 :-)
• 0x696C6961 10mo ago
  Is an `EventEmitter` a framework or a library?
  • baobun 10mo ago
    Neither. It's an implementation of the interface in question.
  • andsoitis 10mo ago
    > 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 10mo ago
    A library. It doesn’t define how you structure your application in any way.
• baobun 10mo ago
  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 10mo ago
    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 10mo ago
      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 10mo ago
        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.
• oncallthrow 10mo ago
  > 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 10mo ago
    There is: https://en.wikipedia.org/wiki/Inversion_of_control https://en.wikipedia.org/wiki/Inversion_of_control
    • ldng 10mo ago
      Not every framework use IoC.
• forinti 10mo ago
  Frameworks abide by the Hollywood Principle and the Greyhound Principle: Don't call us, we'll call you. Leave the driving to us.
• exasperaited 10mo ago
  > 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 10mo ago
  > 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 10mo ago
    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 10mo ago
    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__ 10mo ago
  It's the same with app, application, program, software, tool, etc.
• imtringued 10mo ago
  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 10mo ago
    Thanks for the comment. I think you're spot on, and I should have explained more clearly what "concept" means in this context.
• locknitpicker 10mo ago
  > 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.
• boxed 10mo ago
  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.
• est 10mo ago
  > 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 10mo ago
    That's not how i understood it. Wrappers can typically be unwrapped. Frameworks are a lot harder to circumvent.