5 ms·

disclaimer: I don't like react. Outside of dom node diffing and a focus on components I don't think it brings much to the table considering the considerable com

disclaimer: I don't like react. Outside of dom node diffing and a focus on components I don't think it brings much to the table considering the considerable complexity it brings. It seems like react gets re-written and APIs undergoes drastic changes every few months. I'm not complaining about churn (I don't write react), but rather that maybe React isn't the right tool to be hyping up, or pointing newcomers to JS at to look into/use. I don't remember any other supposedly simple library having had this many major rewrites/api changes. I don't think I've ever seen something like this in KnockoutJS or even Angular1 for a long time (even though the way you had to handle $scope and apply/digest cycles was terrible). Relative newcomers like Mithril and Vue seem to get this stuff right without requiring as much breaking changes. Maybe they owe their simplified structures to some of the new thought to what React inspired, but it seems like they're actually simple (Vue's documentation is amazing, concise, and you can actually render Vue in the browser to get started quickly). Maybe it's time to rethink whether React is a good tool. There's no way I would recommend React to anyone (beginner or intermediate) over something like Vue these days. For example, I don't know what HOC (and am thoroughly uninterested, it sounds like the same kind of thing you only need to know when you're chest-deep in React land) is but it sounds like a hack necessary because of a bad design decision. [EDIT] - Took a few seconds to look up HOCs (Higher Order Components) and they're a bad example of what I think is incidental complexity inside React but I think my point still stands. To clarify, here's my thesis: React is complex (both internally, evidenced by multiple rewrites, and with the tooling it forces you to use, evidenced by needing to download a zip file to start, or touch webpack), but masquerades as a simple library.

acjohnson55 9y ago
For the most part, the changes really shouldn't affect typical users. The biggest change in React from a dev perspective was function components, maybe 2 years ago. If you keep your state outside of React, it's dead simple to use. I think it's a great library and has only really gotten simpler and better. But, to each their own.
- hardwaresofton 9y ago
  I agree that it's getting simpler and better -- tons of dedicated developers are making that happen. I wasn't trying to say that the rewrite shouldn't have happened or something, I just feel like there's a lot of zealotry festering, so many companies are picking React just to attract developers (anecdotal evidence: https://www.youtube.com/watch?v=u80GTmVtdG4&t=2898s https://www.youtube.com/watch?v=u80GTmVtdG4&t=2898s). My problem is that it was being marketed (heavily) as simple and amazing at the beginning when it simply wasn't. From what I remember, the FB team was explicit about it not being for beginners, but the amount of marketing and trumpeting made that basically impossible, and now bootcamps are teaching it to beginners. I just am super tired of having to talk people out of using it on their first project after learning and using HTML+CSS for the first time. I always sound like the insane person, saying "react is complicated" when all the marketing and blogs and everything else is saying "react is simple".
  - sibeliuss 9y ago
    const Name = (props) => <div>{props.name}</div> const Age = (props) => <div>{props.age}</div> const App = () => <div><Name name={'Zed'}/><Age age={20} /></div> Is about as simple as it gets. This sort of composability can go _very_ far without needing any of the other API methods.
    - hardwaresofton 9y ago
      I looked up HOCs not long after writing the comment, and I agree -- this is much better than the mixin approach that used to be the way (though if I remember correctly, mixins were considered 'temporary' at the time). This isn't a benefit of react though -- this is just react incorporating a well known functional paradigm, which I don't mind. IMO If react was simple, this would have been the way to do it from the start -- no mixins detour. This answer would have fallen out (as it now has), if they simply didn't offer a way to inherit functionality, in that manner. If a component is truly just a function from state to output, the obvious way to combine them IS higher order functions.
Niksko 9y ago
A HOC is nothing more than a factory in traditional OO programming. Just because you see an acronym you don't understand, doesn't mean the entire framework is flawed
- hardwaresofton 9y ago
  I should have looked up HOC before I wrote that bit -- Higher Order Components do not seem like a particuarly bad design decision, but IIRC this pattern was introduced somewhere around the launch of React 16? Also, I'm not sure the characterization as a factory is correct, seems closer to higher order functions (at the very least name wise), and/or enhancing features by composition.
  - sibeliuss 9y ago
    Components are just functions -- HOC's are higher order functions. The pattern dropped out like all patterns drop out -- from use. Its nothing specific to React, but to functional programming
    - hardwaresofton 9y ago
      Just replied in the other spot -- I understand the similarities now, but I think this points to react still not being as simple as it could be -- if components were really as simple as being functions from state to UI, reacts API would be drastically smaller. My point is that it's not that simple (for better or for worse, some of the added complexity in the API IS essential IMO), but people still say things like "components are just functions" like it really is that simple. For example: https://reactjs.org/docs/react-component.html#static-getderivedstatefromprops https://reactjs.org/docs/react-component.html#static-getderi... This note: > Note that if a parent component causes your component to re-render, this method will be called even if props have not changed. You may want to compare new and previous values if you only want to handle changes. Things like that are indications of hidden complexity, in my experience.
      - danabramov 9y ago
danabramov 9y ago
We maintain more than 50,000 components at Facebook, and I don’t believe your assessment that “APIs undergoes drastic changes every few months” is accurate. The component API has barely changed since the initial release five years ago. When we need to make changes, it’s the team of 8 people that need to port all those dozens of thousands of components to new APIs. It would be infeasible for us to break APIs every few months, or to do so in a manual way. This is why we embrace automatic codemod scripts. There have been some breaking changes between major releases (which have a roughly yearly—not monthly—cadence) but we always provided automatic scripts that convert your code as much of your code as possible automatically: https://github.com/reactjs/react-codemod https://github.com/reactjs/react-codemod. We also call attention to the automated migration scripts in all major release blog posts (for example: https://reactjs.org/blog/2017/09/26/react-v16.0.html#upgrading https://reactjs.org/blog/2017/09/26/react-v16.0.html#upgradi...). That’s the only way we could maintain dozens of thousands of components while still moving the library forward. I hope this information is helpful. You can read more about our commitment to stability without stagnation here: https://reactjs.org/docs/design-principles.html#stability https://reactjs.org/docs/design-principles.html#stability
- hardwaresofton 9y ago
  I apologize -- I should have written "API internals". I did not mean to state that the component API changed a lot, just seemingly that the internals did, with fiber and the like. I understand the team is hard at work making React better, and there is absolutely no doubt that you are succeeding and react is getting better. However, the amount of large internal changes indicates that as you improve and (most likely) shed unneeded complexity, that there must have been complexity to shed. Obviously no one is perfect, and hindsight is 20/20, but for such a "small" (yes, interacting with the dom is actually super duper hard, and edgecases abound) scope, I've seen more large-ish overhauls than I am comfortable with. Many internal changes makes me feel like react is more Mongo than RethinkDB (the latter being a document store that actually got most things right and was well engineered but no one ever heard of while mongo started with a badly engineered product, good marketing, and pivoted to relative reliability and good engineering). I want to also note that I'm not in the target audience for a post like this. There are tons of people who lovingly and productively use React -- I'm not one of them. I am just dumbfounded when people bill react as simple but have never heard of something like Mithril that actually is simple (almost "stupidly" so), and another post at the top of HN means there's that many more people I have to convince to pick something at least slightly simpler when they start doing web development for the first time.

acjohnson55 9y ago

For the most part, the changes really shouldn't affect typical users. The biggest change in React from a dev perspective was function components, maybe 2 years ago. If you keep your state outside of React, it's dead simple to use. I think it's a great library and has only really gotten simpler and better. But, to each their own.

hardwaresofton 9y ago
I agree that it's getting simpler and better -- tons of dedicated developers are making that happen. I wasn't trying to say that the rewrite shouldn't have happened or something, I just feel like there's a lot of zealotry festering, so many companies are picking React just to attract developers (anecdotal evidence: https://www.youtube.com/watch?v=u80GTmVtdG4&t=2898s https://www.youtube.com/watch?v=u80GTmVtdG4&t=2898s). My problem is that it was being marketed (heavily) as simple and amazing at the beginning when it simply wasn't. From what I remember, the FB team was explicit about it not being for beginners, but the amount of marketing and trumpeting made that basically impossible, and now bootcamps are teaching it to beginners. I just am super tired of having to talk people out of using it on their first project after learning and using HTML+CSS for the first time. I always sound like the insane person, saying "react is complicated" when all the marketing and blogs and everything else is saying "react is simple".
- sibeliuss 9y ago
  const Name = (props) => <div>{props.name}</div> const Age = (props) => <div>{props.age}</div> const App = () => <div><Name name={'Zed'}/><Age age={20} /></div> Is about as simple as it gets. This sort of composability can go _very_ far without needing any of the other API methods.
  - hardwaresofton 9y ago
    I looked up HOCs not long after writing the comment, and I agree -- this is much better than the mixin approach that used to be the way (though if I remember correctly, mixins were considered 'temporary' at the time). This isn't a benefit of react though -- this is just react incorporating a well known functional paradigm, which I don't mind. IMO If react was simple, this would have been the way to do it from the start -- no mixins detour. This answer would have fallen out (as it now has), if they simply didn't offer a way to inherit functionality, in that manner. If a component is truly just a function from state to output, the obvious way to combine them IS higher order functions.

Niksko 9y ago

A HOC is nothing more than a factory in traditional OO programming. Just because you see an acronym you don't understand, doesn't mean the entire framework is flawed

hardwaresofton 9y ago
I should have looked up HOC before I wrote that bit -- Higher Order Components do not seem like a particuarly bad design decision, but IIRC this pattern was introduced somewhere around the launch of React 16? Also, I'm not sure the characterization as a factory is correct, seems closer to higher order functions (at the very least name wise), and/or enhancing features by composition.
- sibeliuss 9y ago
  Components are just functions -- HOC's are higher order functions. The pattern dropped out like all patterns drop out -- from use. Its nothing specific to React, but to functional programming
  - hardwaresofton 9y ago
    Just replied in the other spot -- I understand the similarities now, but I think this points to react still not being as simple as it could be -- if components were really as simple as being functions from state to UI, reacts API would be drastically smaller. My point is that it's not that simple (for better or for worse, some of the added complexity in the API IS essential IMO), but people still say things like "components are just functions" like it really is that simple. For example: https://reactjs.org/docs/react-component.html#static-getderivedstatefromprops https://reactjs.org/docs/react-component.html#static-getderi... This note: > Note that if a parent component causes your component to re-render, this method will be called even if props have not changed. You may want to compare new and previous values if you only want to handle changes. Things like that are indications of hidden complexity, in my experience.
    - danabramov 9y ago

danabramov 9y ago

We maintain more than 50,000 components at Facebook, and I don’t believe your assessment that “APIs undergoes drastic changes every few months” is accurate. The component API has barely changed since the initial release five years ago. When we need to make changes, it’s the team of 8 people that need to port all those dozens of thousands of components to new APIs. It would be infeasible for us to break APIs every few months, or to do so in a manual way. This is why we embrace automatic codemod scripts. There have been some breaking changes between major releases (which have a roughly yearly—not monthly—cadence) but we always provided automatic scripts that convert your code as much of your code as possible automatically: https://github.com/reactjs/react-codemod https://github.com/reactjs/react-codemod. We also call attention to the automated migration scripts in all major release blog posts (for example: https://reactjs.org/blog/2017/09/26/react-v16.0.html#upgrading https://reactjs.org/blog/2017/09/26/react-v16.0.html#upgradi...). That’s the only way we could maintain dozens of thousands of components while still moving the library forward. I hope this information is helpful. You can read more about our commitment to stability without stagnation here: https://reactjs.org/docs/design-principles.html#stability https://reactjs.org/docs/design-principles.html#stability

hardwaresofton 9y ago
I apologize -- I should have written "API internals". I did not mean to state that the component API changed a lot, just seemingly that the internals did, with fiber and the like. I understand the team is hard at work making React better, and there is absolutely no doubt that you are succeeding and react is getting better. However, the amount of large internal changes indicates that as you improve and (most likely) shed unneeded complexity, that there must have been complexity to shed. Obviously no one is perfect, and hindsight is 20/20, but for such a "small" (yes, interacting with the dom is actually super duper hard, and edgecases abound) scope, I've seen more large-ish overhauls than I am comfortable with. Many internal changes makes me feel like react is more Mongo than RethinkDB (the latter being a document store that actually got most things right and was well engineered but no one ever heard of while mongo started with a badly engineered product, good marketing, and pivoted to relative reliability and good engineering). I want to also note that I'm not in the target audience for a post like this. There are tons of people who lovingly and productively use React -- I'm not one of them. I am just dumbfounded when people bill react as simple but have never heard of something like Mithril that actually is simple (almost "stupidly" so), and another post at the top of HN means there's that many more people I have to convince to pick something at least slightly simpler when they start doing web development for the first time.