11 ms·

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah

by dvcrn 6y ago

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class components only to learn that hooks are now a thing and they remove a lot of boilerplate code. Even with redux, redux supports hooks as well so you can scrap that entire connect() stuff alltogether. Just back to simple function components.

jchw 6y ago
It’s the price of success. Similarly, a lot of people now vehemently hate Go, and in a few years they’ll be complaining about the problems with Rust. (No idea about frontend because as far as I’m concerned React is still on top.) I don’t think it’s really too big of a deal, but I wish people would be more realistic and use less hyperbole. Everything has trade-offs, one’s own personal honey moon ending does not mean we were all blind and/or ignoring the faults with things.
- saagarjha 6y ago
  I don’t think it’s necessarily success, but novelty. C++ and Java are immensely popular and get nowhere near the vitriol that the thing you mentioned do. Often there’s a number of people on the opposite side cheerleading the thing as well, which underlines the apparent conflict. (Rust is already being complained about, by the way.)
  - christophilus 6y ago
    Really? I would have put C++ and Java near the top of the “most ridiculed languages” list.
    - majewsky 6y ago
      As the old mantra goes, "there are two types of languages, the ones that everyone complains about, and the ones that nobody uses".
      - shrimp_emoji 6y ago
        That's true because the more first-mover-y languages that came to dominate are shit compared to subsequent, more innovative ones. When the latter become dominant, there should be even more subsequent, innovative ones. And the cycle will repeat. But it's less net shittiness with every generation. And how many generations are we even in so far? C is '70s security gore, C++ is an '80s attempt to force OO memes that we've come to regret onto the '70s security gore, Python and Java are '90s OO memes in earnest, JavaScript and PHP were kludgy mistakes slapped together in a fit of desperate confusion to get some web shit to run, aaand...
  - neutronicus 6y ago
    As a C++ developer who occasionally helps a friend hack on a Rust hobby project, I've been waiting for the other shoe to drop on Rust. Not necessarily because I have many complaints about it, but because I consider it in essence very similar to C++17, with (not-too-)different syntax and a few different but important design decisions in the core language and standard library. Seeing it sold as a radical paradigm shift from C++ has always left me feeling that some people are in for disappointment down the line.
    - fpoling 6y ago
      C++ has no notion of a borrow checker and I am not aware of static checkers for the language that provides a coverage close to that of the Rust compiler. As I continue to see how very experienced C++ programmers make exploitable bugs that passes all reviews and that are compilation errors in Rust saying that Rust is C++ with a different syntax is very naive.
ggregoire 6y ago
> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel productive with it. Also, TypeScript is awesome.
- kreetx 6y ago
  What's a good place for front-end dev discussions, especially the type which are more on the meta-level?
  - deleted 6y ago
    [deleted]
  - fit2rule 6y ago
    http://lobste.rs http://lobste.rs is a good starting point. Not as much hate there..
    - wtmt 6y ago
      Related question: Does it still require hanging around and waiting for an invite to create an account? If yes, then I’m not going to try again and waste my time.
      - fit2rule 6y ago
        Its not hard to get an invite. I'd invite you if I knew your address. I consider this a slight inconvenience but still a better system than having the dang hammer around to pound spammers ..
  - m5r 6y ago
    Twitter can be a good place sometimes /r/webdev, /r/javascript and /r/reactjs too
runawaybottle 6y ago
A whole lot of people use it at work and witnessed valid criticisms. It’s not like we’re going to have the knives out when React/Angular is new. Give it a little time, see a few codebases, extend and build a few apps, then come back. Now people have some credible stuff to say. We can’t comment much about how great Hooks are after reading a few Medium posts. I’ll see in a few months when it’s all over the codebase. HN will be full of ‘we rebuilt our api in GraphQl and boy things are a mess’ in 2 years.
- jsjw7sbw 6y ago
  We rewrote our frontend in hooks and graphql 1 year ago. Hooks are fine, but graphql is a messy time sink for our usecase.
  - WiseWeasel 6y ago
    Did you also rewrite the backend for GQL? We've had great success and satisfaction with GQL, but it’s been limited to greenfield development so far. To me, one of the bigger wins with GQL on the front-end, aside from the obvious consolidation of requests, is access to react-apollo client's caching system, which can replace the use of state stores like redux for API data in many cases. I could see it being a challenge to rewrite a complex REST react app to GQL, since you'd be discarding a ton of data shuffling code, but we've been happy with the resulting simplification of our frontends.
    - gregkerzhner 6y ago
      I don't understand this hype about Apollo. Its trying to be some strange "semi-framework" that takes care of some of your application concerns while actively making it harder to take care of the rest. For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. For the former, I find writing GraphQL mutations more verbose and cumbersome than Redux. In the latter, you need to worry about fetching, changing and saving state every time you need to make a change. With Redux on the other hand, your current state is fetched and saved for you automatically and you just need to worry about describing the state change in the reducer. I also dislike the Query and Mutation components. The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. What this often means that any business logic associated with the request goes in the component as well, leading your components to become bloated and untested. The mutation component is even worse leading to super hard to understand code - you are basically writing your API request layer using HTML markup. For me its so much simpler to just have functions that call APIs directly instead of trying to understand some strange markup hierarchy. In short, I can see the appeal of Apollo if your app had very little frontend state and just needed to be a reflection of the server. However, as your codebase grows in complexity, the patterns that Apollo encourages you to use lead to bloated and unmaintainable code.
Alterlife 6y ago
Does this article qualify as 'hate' though? The author acknolwdges that he's new to react and is simply pointing out two things that he found challenging. Nothing surprising. Infact, I don't understand why the article is so highly upvoted.
- jchw 6y ago
  This was my first thought, but the parent comment is probably referring to the comments that were on top at the time it was written, rather than the article (which I agree, is fairly mundane, although I think it’s fine.)
- yakshaving_jgt 6y ago
  I don't think the author is a "he".
Kiro 6y ago
HN is a pretty hateful place in general.
- nurettin 6y ago
  I'm not sure if the stuff I see in HN threads qualify as hard feelings. They are more like jabs, prods, cheap shots, demands, begs and lots of bikeshedding with a smither of useful information here and there. I do appreciate the fact that they try to discourage the reddit style of rimshotting.
- gitgud 6y ago
  If you're coming from Reddit, Imgur or YouTube it seems like hate, but I've found it's simply a lack of humor... Any jokes, memes or puns are frowned upon the community 99% of the time. I suppose it's considered redundant or not-constructive...
  - hombre_fatal 6y ago
    That's only because 99% of jokes aren't as good as people thought they were when they pushed the submit button. HN has a great sense of humor. I know this of course because my jokes have been upvoted.
    - gitgud 6y ago
      Most jokes I see are downvoted and I can't recall seeing a single joke comment. That's not to say there zero humor here, just much much less than other less serious discussion forums.
  - cambalache 6y ago
    That is true, but it not just the lack the humor, it is the pretentiousness and the faux-politeness.
    - krapp 6y ago
      It's an elitist mirror to 4chan's edgelord culture in many ways.
sametmax 6y ago
I've been coding and training people in react for a while now, and here is my experience: - if you learned react by yourself years ago, you had to go through a lot of pain: the doc was terrible, the ecosystem a moving flaky target and conventions were not established. Things are better today, but it's not something you forget. Somebody starting react in 2018, and with create-react-app, will feel much happier. - if you come from projects were you sparkled JS a bit, and suddenly you move to SPA with react, which is the experience of many, it feels like a wall. In fact, for many, React is the gateway to JS, and it pays the price for it: if you dislike working with JS (which is not uncommon if you come from another language like Ruby, Python, etc), you associate it with React. If you don't do JS full time and suddently must embrace the full stack of it just to make a UI, it's overwhelming. And despite the message you can use bare bone react, nobody does that: you use react, you eat the burger tower with it. Webpack reputation espacially, tainted react reputation. - react has been oversold and overhyped. It doesn't help that the react community has been in deny of all its problems for years. They fixed many eventually, but before they did, they claimed it was all wonderful. It felt insulting for some people, espacially senior devs from other techs who knew the youngsters in front of them were full of it. - the whole store concept has been a debacle. First there was a mysterious name (it's a plane, it's a train, it's flux!), but no solution. Then there were too many. Then Redux won. But Redux is so full of boilerplate. But wait, "you don't need Redux". But then people hacked many solutions internally to avoid redux with no guidance. Then redux toolkit and react provider arrived. In general, react and its ecosystem changed too fast. Way too fast. Unless it's your full time job, it's very hard to keep up. If all techs did that, we'll never be working. Combine that with the JS community desire to always use the latest toy, and you get a rat race. People have work to do, they don't want to deal with drama. React ecosystem is a drama queen. - there is no convention on how to write a react project. Everytime you move to a project, it's a new project. You relearn the layout, the naming convention, the way store is handled, how things are passed around, the libs used for basic things, the testing infra, glue code for said libs, how you deal with css, the granularity of components, API best practices, etc. Not to mention the flavor you are in, depending of the version of react used and the fashion at the time. That's just for react. Then you deal with the other JS techs. - so now, how do you know what to do? Who to trust? Where to get the gospel from? Thousand of tutorials, many imcomplete, obsolete, unpractical, specialized or dishonest. Just the way to manipulate something as simple as props have so many variants with different implications, and you got them all online. All. Of. Them. If you come from the ordered and well established world of backend frameworks, it's a mad house. - then there are the gotachas. setState() is asynchronous, auto bind on createClass, but not on extends (but yes if render()). There you gotta call super(props), not here, useEffect dependancy management... React is full of them. - when the magic doesn't get you, it lets you down. Some basic operations, like settings classes, preventDefault, communicating with the parent, etc. that you do all the time, are incredibly verbose for no good reason ("it's just JS you all!). Most other libs have shortcuts for them. In fact, most react projects add libs to get on par. When I train people in react and they ask me how to do this simple thing, I get desperate looks: "really?". - integrating react with legacy frameworks like RoR, Symphony or Django is really, really not fun if you don't have a SPA with an REST API. And everybody does it differently. - react native code reuse was a lie. A damn lie. And its great perfs as well. Nobody likes to be lied to. - the immutability story is the last straw. I get the benefit of it. But for the vast majority of projects I met in the wild, the cost is way to high. This has so many ramifications I would need another comment just for this one. Bottom line, if you work with seasonned programmers like it's often heard on HN, you can make the best of react. If you don't, and I work a lot with schools, administrations, average corporate IT deps, etc., the cost of react is going to weight on the team. The teams that can manage React correctly are not that many outside of our bubble. And for the ones that can, the price of using react may just be not worth it. When I give the same exercice to do with Vue and React, beginners doing Vue finish in half the time. So I usually advice for Vue. Life is short, and you are probably not facebook at scale.
azangru 6y ago
I love React and write it, in Typescript, on a daily basis. However: - It starts you off with about 40kB of minified gzipped javascript; some developers feel that it's too much. - It is not and probably never will be the most performant framework out there, which upsets quite a few people (although the work that the React core team is doing with Concurrent Mode probably means that from the end user's perspective React will feel fast enough). - It has become the default way for many frontend developers to write JavaScript; I know I am personally guilty of that. This generates a lot of resentment from more experienced developers who have learned to prioritise minimalistic JavaScript bundles over developer experience.
- II-V-I 6y ago
  Your last point is a cause of some apprehension for me. In the team I'm currently working with one of my coworkers calls himself a React Developer, and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes. I've seen it in a couple of other individuals as well, and I feel it's becoming more widespread, though I hope I'm wrong. In these instances, I see the framework existing both in the code as well as the mind, and operating outside of it is often a leap too far.
  - JackMorgan 6y ago
    Personally, I'm super wary of any ____ developer. It's a fixed (vs growth) mindset that tells me they are specialists. I think specialists are best to be consulted by generalists, but not trusted with larger decisions outside their scope.
  - otachack 6y ago
    Maybe bring it up to him with constructive criticism? Tell him the wind tends to change direction and one shouldn't typecast themselves in this field.
    - II-V-I 6y ago
      I agree. Though this person can be a bit touchy when constructive criticism is aimed at them, this would most likely be beneficial for them, and also the team, in the medium/long run.
tarsinge 6y ago
> I am not so up to date with frontend dev but what's with the hate towards React these days? I don't use React day to day in a big team so I can't comment on the maintainability gains, but as a user all I see is websites degrading the experience when migrating to SPA. If state of the art front end engineering with React is Facebook or Reddit then it's hugely disappointing.
tannhaeuser 6y ago
Because it's overhyped to the point it's being used everywhere even for projects where there was no reason to ever go beyond basic static HTML + maybe vanilla js, if at all, by devs who want to pad their resume. At the same time, it taxes your mobile battery, and generally leads to a world of overcomplicated appified Chrome-only web sites when actually the web was meant as a straightforward mechanism for self-publishing and exchanging ideas. Finally, reading the umptieth take of a junior dev having his React epiphany, or worse, a staged React consultancy/course ad piece provokes counter-reaction, if only because it's intellectually insulting.
have_faith 6y ago
I think the number of concepts that need to be understood to be an efficient React developer has grown over the years just enough that it has become slightly frustrating to learn. It is still presented as a very simple small surface area framework but there's a lot of subtly with how many new concepts need to be understood now like hooks as an example. I think it just crossed a threshold and became less intuitive and more tiresome as a result unless you are embedded in React land and do React stuff all the time.
- dbbk 6y ago
  The useEffect example in this article to me is ludicrous. It makes absolutely no sense just looking at it.
  - deleted 6y ago
    [deleted]
nsonha 6y ago
> so you can scrap that entire connect() stuff alltogether To me that "entire stuff" is about the only thing that is good about redux (barely does dependency injection). See people need to understand that hook is a good API from the library authoring point of view (the react team's and react component library authors') it's not such a clean abstraction for people to write application on top of while unneccesarily make their code depend on magic react functions all over the place. I cant count how many "data fetching hook solutions" I've seen on twitter. If something does data fetching, then it needs to know about fetch() and may be a reactivity abstraction like promise or rx. A hook is completely unjustified.
- acemarke 6y ago
  Hi, I'm a Redux maintainer. Hooks definitely lead you towards a different approach for writing components with a different set of tradeoffs. I talked about this in my post "Thoughts on React Hooks, Redux, and Separation of Concerns" [0], and my ReactBoston 2019 talk on "Hooks, HOCs, and Tradeoffs". For React-Redux specifically, `connect` still works fine and we will be supporting it indefinitely. However, we're now recommending that people use our hooks API as the default approach, because it's typically simpler to work with and there's less indirection. [0] https://blog.isquaredsoftware.com/2019/07/blogged-answers-thoughts-on-hooks/ https://blog.isquaredsoftware.com/2019/07/blogged-answers-th... [1] https://blog.isquaredsoftware.com/2019/09/presentation-hooks-hocs-tradeoffs/ https://blog.isquaredsoftware.com/2019/09/presentation-hooks...

by dvcrn 6y ago

jchw 6y ago

It’s the price of success. Similarly, a lot of people now vehemently hate Go, and in a few years they’ll be complaining about the problems with Rust. (No idea about frontend because as far as I’m concerned React is still on top.) I don’t think it’s really too big of a deal, but I wish people would be more realistic and use less hyperbole. Everything has trade-offs, one’s own personal honey moon ending does not mean we were all blind and/or ignoring the faults with things.

saagarjha 6y ago
I don’t think it’s necessarily success, but novelty. C++ and Java are immensely popular and get nowhere near the vitriol that the thing you mentioned do. Often there’s a number of people on the opposite side cheerleading the thing as well, which underlines the apparent conflict. (Rust is already being complained about, by the way.)
- christophilus 6y ago
  Really? I would have put C++ and Java near the top of the “most ridiculed languages” list.
  - majewsky 6y ago
    As the old mantra goes, "there are two types of languages, the ones that everyone complains about, and the ones that nobody uses".
    - shrimp_emoji 6y ago
      That's true because the more first-mover-y languages that came to dominate are shit compared to subsequent, more innovative ones. When the latter become dominant, there should be even more subsequent, innovative ones. And the cycle will repeat. But it's less net shittiness with every generation. And how many generations are we even in so far? C is '70s security gore, C++ is an '80s attempt to force OO memes that we've come to regret onto the '70s security gore, Python and Java are '90s OO memes in earnest, JavaScript and PHP were kludgy mistakes slapped together in a fit of desperate confusion to get some web shit to run, aaand...
- neutronicus 6y ago
  As a C++ developer who occasionally helps a friend hack on a Rust hobby project, I've been waiting for the other shoe to drop on Rust. Not necessarily because I have many complaints about it, but because I consider it in essence very similar to C++17, with (not-too-)different syntax and a few different but important design decisions in the core language and standard library. Seeing it sold as a radical paradigm shift from C++ has always left me feeling that some people are in for disappointment down the line.
  - fpoling 6y ago
    C++ has no notion of a borrow checker and I am not aware of static checkers for the language that provides a coverage close to that of the Rust compiler. As I continue to see how very experienced C++ programmers make exploitable bugs that passes all reviews and that are compilation errors in Rust saying that Rust is C++ with a different syntax is very naive.

ggregoire 6y ago

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel productive with it. Also, TypeScript is awesome.

kreetx 6y ago
What's a good place for front-end dev discussions, especially the type which are more on the meta-level?
- deleted 6y ago
  [deleted]
- fit2rule 6y ago
  http://lobste.rs http://lobste.rs is a good starting point. Not as much hate there..
  - wtmt 6y ago
    Related question: Does it still require hanging around and waiting for an invite to create an account? If yes, then I’m not going to try again and waste my time.
    - fit2rule 6y ago
      Its not hard to get an invite. I'd invite you if I knew your address. I consider this a slight inconvenience but still a better system than having the dang hammer around to pound spammers ..
- m5r 6y ago
  Twitter can be a good place sometimes /r/webdev, /r/javascript and /r/reactjs too

runawaybottle 6y ago

A whole lot of people use it at work and witnessed valid criticisms. It’s not like we’re going to have the knives out when React/Angular is new. Give it a little time, see a few codebases, extend and build a few apps, then come back. Now people have some credible stuff to say. We can’t comment much about how great Hooks are after reading a few Medium posts. I’ll see in a few months when it’s all over the codebase. HN will be full of ‘we rebuilt our api in GraphQl and boy things are a mess’ in 2 years.

jsjw7sbw 6y ago
We rewrote our frontend in hooks and graphql 1 year ago. Hooks are fine, but graphql is a messy time sink for our usecase.
- WiseWeasel 6y ago
  Did you also rewrite the backend for GQL? We've had great success and satisfaction with GQL, but it’s been limited to greenfield development so far. To me, one of the bigger wins with GQL on the front-end, aside from the obvious consolidation of requests, is access to react-apollo client's caching system, which can replace the use of state stores like redux for API data in many cases. I could see it being a challenge to rewrite a complex REST react app to GQL, since you'd be discarding a ton of data shuffling code, but we've been happy with the resulting simplification of our frontends.
  - gregkerzhner 6y ago
    I don't understand this hype about Apollo. Its trying to be some strange "semi-framework" that takes care of some of your application concerns while actively making it harder to take care of the rest. For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. For the former, I find writing GraphQL mutations more verbose and cumbersome than Redux. In the latter, you need to worry about fetching, changing and saving state every time you need to make a change. With Redux on the other hand, your current state is fetched and saved for you automatically and you just need to worry about describing the state change in the reducer. I also dislike the Query and Mutation components. The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. What this often means that any business logic associated with the request goes in the component as well, leading your components to become bloated and untested. The mutation component is even worse leading to super hard to understand code - you are basically writing your API request layer using HTML markup. For me its so much simpler to just have functions that call APIs directly instead of trying to understand some strange markup hierarchy. In short, I can see the appeal of Apollo if your app had very little frontend state and just needed to be a reflection of the server. However, as your codebase grows in complexity, the patterns that Apollo encourages you to use lead to bloated and unmaintainable code.

Alterlife 6y ago

Does this article qualify as 'hate' though? The author acknolwdges that he's new to react and is simply pointing out two things that he found challenging. Nothing surprising. Infact, I don't understand why the article is so highly upvoted.

jchw 6y ago
This was my first thought, but the parent comment is probably referring to the comments that were on top at the time it was written, rather than the article (which I agree, is fairly mundane, although I think it’s fine.)
yakshaving_jgt 6y ago
I don't think the author is a "he".

Kiro 6y ago

HN is a pretty hateful place in general.

nurettin 6y ago
I'm not sure if the stuff I see in HN threads qualify as hard feelings. They are more like jabs, prods, cheap shots, demands, begs and lots of bikeshedding with a smither of useful information here and there. I do appreciate the fact that they try to discourage the reddit style of rimshotting.
gitgud 6y ago
If you're coming from Reddit, Imgur or YouTube it seems like hate, but I've found it's simply a lack of humor... Any jokes, memes or puns are frowned upon the community 99% of the time. I suppose it's considered redundant or not-constructive...
- hombre_fatal 6y ago
  That's only because 99% of jokes aren't as good as people thought they were when they pushed the submit button. HN has a great sense of humor. I know this of course because my jokes have been upvoted.
  - gitgud 6y ago
    Most jokes I see are downvoted and I can't recall seeing a single joke comment. That's not to say there zero humor here, just much much less than other less serious discussion forums.
- cambalache 6y ago
  That is true, but it not just the lack the humor, it is the pretentiousness and the faux-politeness.
  - krapp 6y ago
    It's an elitist mirror to 4chan's edgelord culture in many ways.

sametmax 6y ago

I've been coding and training people in react for a while now, and here is my experience: - if you learned react by yourself years ago, you had to go through a lot of pain: the doc was terrible, the ecosystem a moving flaky target and conventions were not established. Things are better today, but it's not something you forget. Somebody starting react in 2018, and with create-react-app, will feel much happier. - if you come from projects were you sparkled JS a bit, and suddenly you move to SPA with react, which is the experience of many, it feels like a wall. In fact, for many, React is the gateway to JS, and it pays the price for it: if you dislike working with JS (which is not uncommon if you come from another language like Ruby, Python, etc), you associate it with React. If you don't do JS full time and suddently must embrace the full stack of it just to make a UI, it's overwhelming. And despite the message you can use bare bone react, nobody does that: you use react, you eat the burger tower with it. Webpack reputation espacially, tainted react reputation. - react has been oversold and overhyped. It doesn't help that the react community has been in deny of all its problems for years. They fixed many eventually, but before they did, they claimed it was all wonderful. It felt insulting for some people, espacially senior devs from other techs who knew the youngsters in front of them were full of it. - the whole store concept has been a debacle. First there was a mysterious name (it's a plane, it's a train, it's flux!), but no solution. Then there were too many. Then Redux won. But Redux is so full of boilerplate. But wait, "you don't need Redux". But then people hacked many solutions internally to avoid redux with no guidance. Then redux toolkit and react provider arrived. In general, react and its ecosystem changed too fast. Way too fast. Unless it's your full time job, it's very hard to keep up. If all techs did that, we'll never be working. Combine that with the JS community desire to always use the latest toy, and you get a rat race. People have work to do, they don't want to deal with drama. React ecosystem is a drama queen. - there is no convention on how to write a react project. Everytime you move to a project, it's a new project. You relearn the layout, the naming convention, the way store is handled, how things are passed around, the libs used for basic things, the testing infra, glue code for said libs, how you deal with css, the granularity of components, API best practices, etc. Not to mention the flavor you are in, depending of the version of react used and the fashion at the time. That's just for react. Then you deal with the other JS techs. - so now, how do you know what to do? Who to trust? Where to get the gospel from? Thousand of tutorials, many imcomplete, obsolete, unpractical, specialized or dishonest. Just the way to manipulate something as simple as props have so many variants with different implications, and you got them all online. All. Of. Them. If you come from the ordered and well established world of backend frameworks, it's a mad house. - then there are the gotachas. setState() is asynchronous, auto bind on createClass, but not on extends (but yes if render()). There you gotta call super(props), not here, useEffect dependancy management... React is full of them. - when the magic doesn't get you, it lets you down. Some basic operations, like settings classes, preventDefault, communicating with the parent, etc. that you do all the time, are incredibly verbose for no good reason ("it's just JS you all!). Most other libs have shortcuts for them. In fact, most react projects add libs to get on par. When I train people in react and they ask me how to do this simple thing, I get desperate looks: "really?". - integrating react with legacy frameworks like RoR, Symphony or Django is really, really not fun if you don't have a SPA with an REST API. And everybody does it differently. - react native code reuse was a lie. A damn lie. And its great perfs as well. Nobody likes to be lied to. - the immutability story is the last straw. I get the benefit of it. But for the vast majority of projects I met in the wild, the cost is way to high. This has so many ramifications I would need another comment just for this one. Bottom line, if you work with seasonned programmers like it's often heard on HN, you can make the best of react. If you don't, and I work a lot with schools, administrations, average corporate IT deps, etc., the cost of react is going to weight on the team. The teams that can manage React correctly are not that many outside of our bubble. And for the ones that can, the price of using react may just be not worth it. When I give the same exercice to do with Vue and React, beginners doing Vue finish in half the time. So I usually advice for Vue. Life is short, and you are probably not facebook at scale.

azangru 6y ago

I love React and write it, in Typescript, on a daily basis. However: - It starts you off with about 40kB of minified gzipped javascript; some developers feel that it's too much. - It is not and probably never will be the most performant framework out there, which upsets quite a few people (although the work that the React core team is doing with Concurrent Mode probably means that from the end user's perspective React will feel fast enough). - It has become the default way for many frontend developers to write JavaScript; I know I am personally guilty of that. This generates a lot of resentment from more experienced developers who have learned to prioritise minimalistic JavaScript bundles over developer experience.

II-V-I 6y ago
Your last point is a cause of some apprehension for me. In the team I'm currently working with one of my coworkers calls himself a React Developer, and my experience has been that anytime an issue arises that may not be specific to React, this person's ability to problem solve significantly diminishes. I've seen it in a couple of other individuals as well, and I feel it's becoming more widespread, though I hope I'm wrong. In these instances, I see the framework existing both in the code as well as the mind, and operating outside of it is often a leap too far.
- JackMorgan 6y ago
  Personally, I'm super wary of any ____ developer. It's a fixed (vs growth) mindset that tells me they are specialists. I think specialists are best to be consulted by generalists, but not trusted with larger decisions outside their scope.
- otachack 6y ago
  Maybe bring it up to him with constructive criticism? Tell him the wind tends to change direction and one shouldn't typecast themselves in this field.
  - II-V-I 6y ago
    I agree. Though this person can be a bit touchy when constructive criticism is aimed at them, this would most likely be beneficial for them, and also the team, in the medium/long run.

tarsinge 6y ago

> I am not so up to date with frontend dev but what's with the hate towards React these days? I don't use React day to day in a big team so I can't comment on the maintainability gains, but as a user all I see is websites degrading the experience when migrating to SPA. If state of the art front end engineering with React is Facebook or Reddit then it's hugely disappointing.

tannhaeuser 6y ago

Because it's overhyped to the point it's being used everywhere even for projects where there was no reason to ever go beyond basic static HTML + maybe vanilla js, if at all, by devs who want to pad their resume. At the same time, it taxes your mobile battery, and generally leads to a world of overcomplicated appified Chrome-only web sites when actually the web was meant as a straightforward mechanism for self-publishing and exchanging ideas. Finally, reading the umptieth take of a junior dev having his React epiphany, or worse, a staged React consultancy/course ad piece provokes counter-reaction, if only because it's intellectually insulting.

have_faith 6y ago

I think the number of concepts that need to be understood to be an efficient React developer has grown over the years just enough that it has become slightly frustrating to learn. It is still presented as a very simple small surface area framework but there's a lot of subtly with how many new concepts need to be understood now like hooks as an example. I think it just crossed a threshold and became less intuitive and more tiresome as a result unless you are embedded in React land and do React stuff all the time.

dbbk 6y ago
The useEffect example in this article to me is ludicrous. It makes absolutely no sense just looking at it.
- deleted 6y ago
  [deleted]

nsonha 6y ago

> so you can scrap that entire connect() stuff alltogether To me that "entire stuff" is about the only thing that is good about redux (barely does dependency injection). See people need to understand that hook is a good API from the library authoring point of view (the react team's and react component library authors') it's not such a clean abstraction for people to write application on top of while unneccesarily make their code depend on magic react functions all over the place. I cant count how many "data fetching hook solutions" I've seen on twitter. If something does data fetching, then it needs to know about fetch() and may be a reactivity abstraction like promise or rx. A hook is completely unjustified.

acemarke 6y ago
Hi, I'm a Redux maintainer. Hooks definitely lead you towards a different approach for writing components with a different set of tradeoffs. I talked about this in my post "Thoughts on React Hooks, Redux, and Separation of Concerns" [0], and my ReactBoston 2019 talk on "Hooks, HOCs, and Tradeoffs". For React-Redux specifically, `connect` still works fine and we will be supporting it indefinitely. However, we're now recommending that people use our hooks API as the default approach, because it's typically simpler to work with and there's less indirection. [0] https://blog.isquaredsoftware.com/2019/07/blogged-answers-thoughts-on-hooks/ https://blog.isquaredsoftware.com/2019/07/blogged-answers-th... [1] https://blog.isquaredsoftware.com/2019/09/presentation-hooks-hocs-tradeoffs/ https://blog.isquaredsoftware.com/2019/09/presentation-hooks...