4 ms·

The reason for React’s “draw the rest of the owl” (which is a great way to describe it) mindset is that it’s born not as a framework but as a library, and to th

The reason for React’s “draw the rest of the owl” (which is a great way to describe it) mindset is that it’s born not as a framework but as a library, and to this day self-identifies as such. It by design tells you nothing about and is agnostic with respect to how you organise your code, where to put tests, what bundler to use, etc. IIRC React itself doesn’t even know anything about the Web or DOM, as that integration is supplied by the pluggable reconciler, which lives in a separate library (ReactDOM). One could argue that with the amount of batteries included perhaps it ought to undergo a grand status change, but until then it’s hard to blame on the authors of a library that they are not delivering a framework.

realusername 9mo ago
Indeed but while being a library is okay for math tools or pdf generation, it evidently didn't work well for building UI components.
- strogonoff 9mo ago
  Did it not work? Many successful and complex sites and apps use React—whether directly or via a framework (Next, Astro, or something homegrown)—and indeed many frameworks are built on React. > math tools or pdf generation In this case the original scope of the library was “reactive rendering”, which sort of makes sense.
  - realusername 9mo ago
    I've been there since the early days of React and I haven't seen a single React codebase which isn't a pile of duck-taped random packages, often leading to poor user performance. Maybe it can be done, maybe not, but the average front-end dev doesn't have the insights to fill the gaps that React has left.
    - strogonoff 9mo ago
      Some codebases are better than others, more mature open-source projects tend to be more polished, closed enterprisey things can be nightmare fuel, but that’s all probably universal to a degree and not specific to whether you’re using React or not. (OK, dependency mess is at least somewhat specific to JS.) My real development experience started with Django—arguably one of the best-documented proper frameworks out there even before it reached 1.x—and let me tell you: the kind of garbage I have seen once I started doing it professionally still makes me shudder[0]. I agree with you in the sense that the choice to forgo a framework and use only a bunch of libraries directly should be very carefully considered. Frameworks exist for a reason. The decision should be made with the full understanding that one would implicitly undertake a task to create a framework (even if it is a narrowly specialised one just for that project). A lot of what you do if you go with raw React will not actually be front-end development: prepare to be vetting dependencies for (or implementing yourself) very basic functionality, fighting bundlers, trying to get TS to use correct global typings for the context, managing version hell to get all of the above to interoperate, etc. (By the way, any mistake you make will be on you. Picked a test runner that was discontinued? Some transitive dependency got hijacked? There is no one else to blame. There’s no BDFL and expert core dev team vetting things, knowing when and how to write from scratch if there’s no trustworthy third-party implementation, orchestrating working version combinations, or writing migration guides.) [0] Indeed it would be hubris to claim I myself have never ever architected something I would later call a monster held together with bits of duct tape.
  - gf000 9mo ago
    It worked as in react is the de facto frontend choice. It didn't work as in if I were to ask for the router, state management, etc library, there would be a combinatorial explosion of react "frameworks", all sucking in different ways. I am (and supposedly grandparent also) on the option that react leaves out way too much that would still be well in the scope of a 'UI framework', and while modularity can be a good thing in certain things, more modular, more moving parts does increase complexity.
    - deleted 9mo ago
      [deleted]

realusername 9mo ago

Indeed but while being a library is okay for math tools or pdf generation, it evidently didn't work well for building UI components.

strogonoff 9mo ago
Did it not work? Many successful and complex sites and apps use React—whether directly or via a framework (Next, Astro, or something homegrown)—and indeed many frameworks are built on React. > math tools or pdf generation In this case the original scope of the library was “reactive rendering”, which sort of makes sense.
- realusername 9mo ago
  I've been there since the early days of React and I haven't seen a single React codebase which isn't a pile of duck-taped random packages, often leading to poor user performance. Maybe it can be done, maybe not, but the average front-end dev doesn't have the insights to fill the gaps that React has left.
  - strogonoff 9mo ago
    Some codebases are better than others, more mature open-source projects tend to be more polished, closed enterprisey things can be nightmare fuel, but that’s all probably universal to a degree and not specific to whether you’re using React or not. (OK, dependency mess is at least somewhat specific to JS.) My real development experience started with Django—arguably one of the best-documented proper frameworks out there even before it reached 1.x—and let me tell you: the kind of garbage I have seen once I started doing it professionally still makes me shudder[0]. I agree with you in the sense that the choice to forgo a framework and use only a bunch of libraries directly should be very carefully considered. Frameworks exist for a reason. The decision should be made with the full understanding that one would implicitly undertake a task to create a framework (even if it is a narrowly specialised one just for that project). A lot of what you do if you go with raw React will not actually be front-end development: prepare to be vetting dependencies for (or implementing yourself) very basic functionality, fighting bundlers, trying to get TS to use correct global typings for the context, managing version hell to get all of the above to interoperate, etc. (By the way, any mistake you make will be on you. Picked a test runner that was discontinued? Some transitive dependency got hijacked? There is no one else to blame. There’s no BDFL and expert core dev team vetting things, knowing when and how to write from scratch if there’s no trustworthy third-party implementation, orchestrating working version combinations, or writing migration guides.) [0] Indeed it would be hubris to claim I myself have never ever architected something I would later call a monster held together with bits of duct tape.
- gf000 9mo ago
  It worked as in react is the de facto frontend choice. It didn't work as in if I were to ask for the router, state management, etc library, there would be a combinatorial explosion of react "frameworks", all sucking in different ways. I am (and supposedly grandparent also) on the option that react leaves out way too much that would still be well in the scope of a 'UI framework', and while modularity can be a good thing in certain things, more modular, more moving parts does increase complexity.
  - deleted 9mo ago
    [deleted]