4 ms·

That's a lot of words to extol building your own framework for each project you start. I know the articles ends with saying this isn't what is being suggested..

That's a lot of words to extol building your own framework for each project you start. I know the articles ends with saying this isn't what is being suggested... but it looks like it. With regards to the stated drawbacks of frameworks: > comply with their API Is a fair point I guess. It's also the obvious tradeoff that everyone is willingly accepting. It also isn't strictly true either In most frameworks, like React, there are escape hatches to do things however you want. I've written React components that hand over control of the rendered element to some pure JS code to do some animation with a library that doesn't speak React for example. > upgrades are effectively forced I guess so. These updates often come with perf improvements, new features and only rarely do they remove existing API's. Not having to maintain an impromptu custom framework means someone else is focusing on optimising for me while I focus on business logic. > train to learn how they work Isn't this exactly the same as bringing in a new developer to work on your custom web app build that does everything differently to everyone else? he has to learn your strategies for routing, caching, state propagation, etc, and has no external resources to help him. > compromise with the drawbacks implied by delegating control I think this is a good point for web apps with a very high performance requirement. I don't see the problem with almost everything else though. > lose skills. A number of developers either don’t know much about the lower-level APIs (because they always used the framework layer instead) or live in the past This has been true since before all of the big web app frameworks became popular. I don't see the frameworks themselves being responsible for lazy developers.

thrashh 5y ago
I wouldn’t call React a framework personally. To me it’s a library like moment.js or ramda.
- tashoecraft 5y ago
  I’d call it both. There’s the use case of adding small react components sprinkled through an application, in this case it’s a library. Then there’s the use case of having everything be a react component, and you use lots of react specific libraries, and a react router, react form handler, etc etc. that’s react the framework.
- have_faith 5y ago
  React is a sort-of-library that exposes an API to plug in the missing pieces to produce a framework. OP of the article would probably actually like it. Want to write your own routing or state management? by all means go ahead.
- simonw 5y ago
  I know the React team like to claim that it's a library, not a framework, but I don't buy that at all. My definition of a framework is code which defines the architecture of the rest of your application. React as practiced in the real world absolutely does this. Theoretically you could plug it in as just the library that does the templating, but I've never seen a real-world codebase for which that appears to be true. I'm ready to be convinced otherwise!
  - mikeryan 5y ago
    I was on team “React is a Library” but for the most part that changed when the hooks and context API were added. The addition of those, relatively simple, tools made it possible to not need the additional state management libraries like Redux/MobX etc that, up until then, were necessary add-ons to manage state and data. This made React more of a full Framework in my opinion. That being said React can still be dropped into a relatively static page to add small bits of interactivity. So at this point React seems to span both Framework and Library depending on the use case.
- boredtofears 5y ago
  React defines the shape of most of the code in your code base in a way that neither moment.js or Ramda does. You can call it a library, but it sure quacks like a framework.
- optymizer 5y ago
  React is a framework, not a library.
- LAC-Tech 5y ago
  In every react project I've worked on, the majority of the business logic was written inside components (the old "code behind" anti-pattern from WinForms days), and about half the files had the extension "jsx" or "tsx". It also required the use of a react specific browser extension to debug effectively. React is a de-jure library, but a de-facto framework.
shane_b 5y ago
> Isn't this exactly the same as bringing in a new developer to work on your custom web app build that does everything differently to everyone else? he has to learn your strategies for routing, caching, state propagation, etc, and has no external resources to help him. it does seem that way. i’d add that even with established technologies, a company should have a set way to do stuff that is trained internally. frameworks et al frequently have multiple strategies or you want to extend a framework primitive.
- ozim 5y ago
  You overestimate knowledge retention. At one point there is a new hire who instead of learning why and how stuff was done starts overdoing everything because "previous people were shitty developers". You will have easier time hiring people with standard stack as well, no one wants to work on hodgepodge of code where some dev 2 years ago did something and left never to be found again. Developers don't want to invest in some magic stack because it will be easier for them to switch jobs if they keep doing Angular/React. If someone would be claiming he was building web apps without frameworks I assume he was not working in teams or at least not in teams of big companies. Which would be a red flag for me.
  - shane_b 5y ago
    i don’t think building your own framework is a good idea. react still has plenty of possible patterns to decide between even after making the decision to use it. a team should have decided upon ways to do stuff even inside of a framework/technology/language.
ozim 5y ago
I agree with all points in comment and would add: - frameworks forcing updates is good, your custom code still having that XSS for 20 years you don't even know is liability not a "saving of money" - frameworks are bringing XSS protections, navigation fixes, do a lot of things better than would be done by random devs from scratch - loosing skills is just Plato saying "if kids start writing things down, their memory will deteriorate" or people who pride in writing SQL by hand that ORMs are bad and I saw enough of "proud SQL writers" making more problems for the project than helping and I still know how to write SQL and the same I could use JavaScript browser API by reading some documentation if I need to

thrashh 5y ago

I wouldn’t call React a framework personally. To me it’s a library like moment.js or ramda.

tashoecraft 5y ago
I’d call it both. There’s the use case of adding small react components sprinkled through an application, in this case it’s a library. Then there’s the use case of having everything be a react component, and you use lots of react specific libraries, and a react router, react form handler, etc etc. that’s react the framework.
have_faith 5y ago
React is a sort-of-library that exposes an API to plug in the missing pieces to produce a framework. OP of the article would probably actually like it. Want to write your own routing or state management? by all means go ahead.
simonw 5y ago
I know the React team like to claim that it's a library, not a framework, but I don't buy that at all. My definition of a framework is code which defines the architecture of the rest of your application. React as practiced in the real world absolutely does this. Theoretically you could plug it in as just the library that does the templating, but I've never seen a real-world codebase for which that appears to be true. I'm ready to be convinced otherwise!
- mikeryan 5y ago
  I was on team “React is a Library” but for the most part that changed when the hooks and context API were added. The addition of those, relatively simple, tools made it possible to not need the additional state management libraries like Redux/MobX etc that, up until then, were necessary add-ons to manage state and data. This made React more of a full Framework in my opinion. That being said React can still be dropped into a relatively static page to add small bits of interactivity. So at this point React seems to span both Framework and Library depending on the use case.
boredtofears 5y ago
React defines the shape of most of the code in your code base in a way that neither moment.js or Ramda does. You can call it a library, but it sure quacks like a framework.
optymizer 5y ago
React is a framework, not a library.
LAC-Tech 5y ago
In every react project I've worked on, the majority of the business logic was written inside components (the old "code behind" anti-pattern from WinForms days), and about half the files had the extension "jsx" or "tsx". It also required the use of a react specific browser extension to debug effectively. React is a de-jure library, but a de-facto framework.

shane_b 5y ago

> Isn't this exactly the same as bringing in a new developer to work on your custom web app build that does everything differently to everyone else? he has to learn your strategies for routing, caching, state propagation, etc, and has no external resources to help him. it does seem that way. i’d add that even with established technologies, a company should have a set way to do stuff that is trained internally. frameworks et al frequently have multiple strategies or you want to extend a framework primitive.

ozim 5y ago
You overestimate knowledge retention. At one point there is a new hire who instead of learning why and how stuff was done starts overdoing everything because "previous people were shitty developers". You will have easier time hiring people with standard stack as well, no one wants to work on hodgepodge of code where some dev 2 years ago did something and left never to be found again. Developers don't want to invest in some magic stack because it will be easier for them to switch jobs if they keep doing Angular/React. If someone would be claiming he was building web apps without frameworks I assume he was not working in teams or at least not in teams of big companies. Which would be a red flag for me.
- shane_b 5y ago
  i don’t think building your own framework is a good idea. react still has plenty of possible patterns to decide between even after making the decision to use it. a team should have decided upon ways to do stuff even inside of a framework/technology/language.

ozim 5y ago

I agree with all points in comment and would add: - frameworks forcing updates is good, your custom code still having that XSS for 20 years you don't even know is liability not a "saving of money" - frameworks are bringing XSS protections, navigation fixes, do a lot of things better than would be done by random devs from scratch - loosing skills is just Plato saying "if kids start writing things down, their memory will deteriorate" or people who pride in writing SQL by hand that ORMs are bad and I saw enough of "proud SQL writers" making more problems for the project than helping and I still know how to write SQL and the same I could use JavaScript browser API by reading some documentation if I need to