I have the exact opposite opinion. React is the only sane way to do web development. All other approaches are deeply flawed by either relying on imperative mutations of the DOM instead of clean declarative code, or by relying on ugly templating syntax and data attributes instead of just using JS basic constructs like react. The power of react is just at its beginning, as we can see with things like react-three-fiber that was coded in a weekend initially and which is unthinkable in any other framework.

Edit typo

I'm not a React hater (in fact, I like it a lot when it fits) but I think when people criticize React, they're actually after the one-size-fits-all attitude displayed in comments such as yours. No, React is clearly not "the only sane way of doing web development" considering the web hosts many types of markup applications, the most successful ones predating React by decades.

Off topic: I've always meant to ask you: Is your name a Blade Runner reference, or are you a user something called "Tannhae"? ;)

https://en.wikipedia.org/wiki/Tears_in_rain_monologue#Tannh%...

https://en.wiktionary.org/wiki/%E6%8E%A2%E6%B5%B7

Don't interpret too much into it :) When I signed up to HN and had to choose a nick, I sat in my living room looking at a Tanne (a fir in German) outside, and chose Tannhäuser (literally, a man who lives in the woods) in a hurry. If anything, it's a (quite arrogant towards the HN crowd) reference to Richard Wagner's opera/character rather than Blade Runner.

Hopefully you're not disappointed :)

Tannhäuser Gate is only the most enigmatic reference of the best scene of the best movie in the universe, and I never heard of any mind altering substance called Tannhae that you were admitting to use (are you a Can-D user or a Chew-Z user? [1]), so I assumed it must be a Blade Runner reference! But now I understand it's a direct reference to what Roy Batty may have been indirectly and allegorically referencing, which is quite un-disappointing. ;)

[1] https://en.wikipedia.org/wiki/The_Three_Stigmata_of_Palmer_E...

Tannhäuser is also a opera by Richard Wagner (which refers to some older folk tale): This is probably what Philip K. Dick inspired to use that name.

I personally think React scales well both up and down but you can avoid Redux for small things. Use Mobx or some easier state management lib and you are all set.

Better yet, avoid it entirely and stick to using React's Context (https://reactjs.org/docs/context.html) or if you have to, useReducer() (https://reactjs.org/docs/hooks-reference.html#usereducer).

Of course, those are lightweight / 'native' (to react) alternatives to redux / state management; last time I used it there were some really neat (theoretical) advantages, such as a browser addon where you could do time traveling debugging (replay individual events) or push the state and all state changes into a support ticket for reproducibility. Purely theoretical though, and at the time using Redux added a lot of mental and labor overhead, especially when using it to manage forms. (personally, I think form data should never be part of a global state; it should be limited to a component that manages the data itself and does not leak it elsewhere. But, it depends on the situation, as always)

I think a blend of both is the best approach for most apps. Redux for global state, api interactions, etc. so that you get the power of middleware like thunk and saga and get great debugging support for overall app state, then anything local to a page or component (like you said, for form data) you use a react context and useContext it in child components to hook up events and manage page level state using useReducer or useState within your page component. This model has been very successful for us and helps partition state in an easy to understand way.

Only sane way, you missed a word. Of course there are other ways, but they clearly flawed in my opinion. I used to hate web development before 2014 and now I love it. Php is an awful language, jquery was a nightmare. Angular makes no sense hence why it keeps reinventing itself, Vue forces you to have some logic expressed using an ad hoc language in templates like it’s 2010 instead of just using JS constructs etc...

I stand by my point, I am yet to find a use case where some form of react is not the best solution. Whether it is server side rendered, a single page app, or statically rendered.

The only criticism I hear about react boil down to people complaining about bad practices that are not linked to react, but merely conflated with it, like not caring about bundle size, messing architecture or other aspects that are orthogonal.

> Whether it is server side rendered, a single page app, or statically rendered.

Nail meet hammer. Seriously though, what why you need a JS framework for static pages? What if your backend is in Go? What if you're doing heavy duty numerical analysis? What if your users want a Wordpress-like site? What if your team uses Rails or Drupal to quickly build sites?

You're saying React is better at everything?

> Vue forces you to have some logic expressed using an ad hoc language in templates

That's not true, you can use JSX with Vue, we do use that for one of our clients and it hasn't raised issues whatsoever

You are right indeed, but from a developer point of view at that point you could be using a react based framework and your experience would be the similar to vue with JSX.

Render functions returning JSX is the key brilliant idea invented by react and the fact that vue adopted it just proves the point even more:

React or the ideas at the core of react are not the mistake of the last decade but the blessing of the last decade for web development (and more).

> from a developer point of view at that point you could be using a react based framework and your experience would be the similar to vue with JSX

It will not, because Vue has a better integration with the data source (Vuex) and a better integration with the routing (Vue Router)

I mean, I agree that React is an awesome framework implemented upon great design ideas (pure functions and plain JS templates), but it has its shortcomings, that frankly make me still prefer Vue to React (mainly Redux and the router)

For routing react-router is just perfect. And for data source/state management there is plenty of choice, I use Apollo for global state/data source and useState for small state full interactions, I can’t see how it could get simpler.

But whatever floats you boat really, the point is that the nice part of vue are inspired by react anyway. I wish the two community merged, to be honest, I see no point in dividing for such small differences.

> But whatever floats you boat really

You specifically argued against that, your arguments seem to be highly religious in nature.

I don't know how many years you've worked in the industry but if you think React will be the dominant way of building apps for the next ten years, I have some Adobe Flash developers who I'm sure would like to say a few words.

haha! Former hotshot Flash ActionScript 3 Ninja Developer reporting for duty as requested.

Seriously though, JSX and TypeScript are nothing new. Both were part of ActionScript 3, a big language backed by a powerful company (Adobe). 15 years later, nobody even remembers it existed. How am I still making a comfortable living coding today? By not getting too attached to any language or framework... they are all just tools in the end.

So let the young ones be, time will eventually teach them those lessons, sooner than they think.

Huh? AS3 had XML integrated into it?

I remember E4X and Flex but not a JSX like syntax.

It wasn't exactly like JSX, more powerful as the XML was just another program data type to work with like strings and arrays.

The ideas behind react will still be big in ten years yes.

My arguments are not religious but based on facts, I can share my PhD thesis from 2016 about user interface specification languages, that includes a comparison of more than 20 different approaches including react.

Flash was always a proprietary platform and only fools would have bet their whole career on it back then. The situation of the ideas behind react, and browsers as a platform are very different.

I’m not betting my career on it though (I’m a CTO in a company which Is not centered around web stuff) but I do believe that these ideas will leave an impact in the industry, and this belief is backed by specifically studying this topic for 4years, plus my 15years in the industry.

I'm a UI architect of a major SaaS company who maintains our 4-5 products between 8-10 feature teams. I've worked in the web industry for 11 years.

My job is to enforce some semblance of sanity between very smart and clever engineers without heavily impacting their ability to deliver. My job entails much cat-herding, setting norms, and maintaining expectations.

Every day I thank the gods we went with Angular. It has saved us countless times, every refactor is a joy, every upgrade is painless, every component is easily shared.

I don't have to constantly worry about XSS, I don't have to explain how I want things structured (because the build fails if they don't structure it right), and I don't have to worry that if someone leaves, no one will know how to pick up and modify their project.

Do developers hate it? Absolutely! They want to get work done fast and pump out cool, clever, smart work! They see Angular as a hinderance to the objective of "doing" because now they need to know about all these damn opinions that aren't their own. Angular isn't for them, it's for everyone else.

By contrast, React enables selfish coding, which while totally okay when you have a few people and clear lines of ownership, does not scale well without strictly defined responsibilities and amazing cultural levels of synchronous decision-making.

I don't want a "you could..." in my framework... I want a "this is the way" in my framework. Thus me the dev before me... the dev after me can get on with things. It will not be the perfect solution but it will be a consistent solution... This is of course true for any framework.

I agree. I have to develop for both Angular and React for work, and I find my experience with React so much more relaxing. The logic between the what I see and what I think is straight forward. What I see is what I get. JSX is great.

Meanwhile, for Angular, I keep constantly going back to the documentation, trying to remember all the small details about templating, binding, decorators, modules, dependency injection, etc...

The alternative to React is not Angular or another JS framework. That was not just my anti-React rant, it was an anti-SPA rant in general. I still fail to see why people need to build an entire application twice, once on the server, and again on the client, except perhaps when you have very frontend-heavy interactivity requirements (like photoshop-in-the-browser or games). SPA's attempted to rebuild the entire HTML web-browser model, and they did it poorly. I yearn for the days of Rails/PHP/Django where the server "is" your application, and we use the web browser's native functionality as designed, with a much simpler application model, and, in most cases, a better end-user experience. That's enough for 80% of apps. A little bit of DOM manipulation is acceptable (i.e. jQuery / Vue.js) and easy to keep track of in your head since every page is a new context/state, instead of ever-increasing layers of abstraction for "state management" and "components". If you write clean HTML, the DOM is much easier to deal with than some state management library. If you could truly abstract away the DOM without ever thinking about it, I would agree with you, but you can't. You can't escape thinking about the DOM if you care at all about performance and debugging, and now you have to worry about the DOM AND your state abstractions. I'm not saying we have to go back to writing assembly code, but I'm saying JS frameworks are the leakiest abstraction ever designed.

That react-three-fiber project is cool, but engineering is not about you can do, it's about finding the best solution for a given set of requirements, and 95% of web apps don't need that kind of functionality - it's just unnecessary over-engineering at a huge overhead cost.

React devs love to talk about one-way-data flow and Flux state management. They forget state doesn't come from the client, it comes from the server. Why not carry this one-way-data-flow model all the way back to the database, which is where your state actually originates?

>> I still fail to see why people need to build an entire application twice, once on the server, and again on the client

I fully agree, and this is why I can’t understand why in 2020, some people still don’t understand that react/SPA and node backend for server side rendering are the best solution.

With react and server-side rendering you code your front end only once, of course. And the same codebase can be rendered on the server or on the client transparently. Same JS libraries can be used in the server, in the browser, in mobile apps with react native.

There is just the API on one side, and the frontend on the other side. Where the frontend is rendered does not matter.

Exactly! JSX is much easier to use compared to angular templating.

Not to interrupt a good rant against tech (in this era... very brave, btw) but you should look at react with the context api. I think everyone who’s used it is glad it removed redux’s boilerplate insanity. There’s even some other frameworks (the name escapes me now) that are like boilerplateless redux if ppl like that style of event driven state updates.

Hi, I'm a Redux maintainer.

Please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once:

https://redux-toolkit.js.org

Also, note that we have a new "Style Guide" docs page which specifically recommends patterns that we feel will lead to simpler code, like the "ducks" structure for single-file Redux logic:

https://redux.js.org/style-guide/style-guide

Finally, we're currently working on a major rewrite of the Redux core docs, with the goals of updating them for today's target audience and teaching easier-to-use patterns:

https://github.com/reduxjs/redux/issues/3592

(and by "we" I basically mean "me", since I'm not getting a lot of help with this effort so far.)

I'll also point out that while Context is a great tool for making data available to a nested subtree of components, it has major limitations in terms of processing frequent updates. We tried to use it internally in React-Redux v6, and it just wasn't sufficiently fast enough, which is why we had to rewrite the internals again in v7 to use direct subscriptions instead. So, very useful, but not a replacement for Redux.

Hi, I'm a software engineer.

Thank you for your work on Redux - I think it's fantastic!

Lots of hate in this thread, but React/Redux are great, even if that somehow makes me an imposter or a hipster or whatever the tools I use somehow say about me.

Thanks, and you're welcome!

I obviously didn't _create_ Redux, but I'll take a decent amount of credit for helping keep it relevant over the last few years (docs work, blog posts, answering questions, React-Redux updates, Redux Toolkit).

I'll say up front that it's definitely not as "necessary" as it was early on and that there's lots of other great alternatives out there, but yeah, I don't get the recurring waves of "I hate Redux" that seem to pop up on Twitter every few months.

FWIW, I talked about some Redux usage stats and where it fits in compared to other options in my "State of Redux" talk at Reactathon last year:

https://blog.isquaredsoftware.com/2019/03/presentation-state...

Looks like I should get to do an updated version of that talk later this year.

Wow! such a strong opinion warrants some more justification.

Having used both Angular (since 1.0) and React (only recently), it's obvious why React is more popular. Any decent engineer can be productive in React within a day since the concepts are so intuitive and simple. With Angular, if you don't really know how things work, you are going to struggle a lot for a while.

While i can't speak for the rendering performance, the design itself is definitely elegant and not built for "code monkeys" but real engineering productivity

I use React and I find it fine. I don't use Redux though, so it may be the reason why we had different experiences.

I think that just by using Hooks and Contexts you can get a lot done in a predictable way without adding too much complexity. With typescript and a proper IDE you get also wonderful type-checking and refactoring capabilities.

I used AngularJs (1.x) a lot before and in comparison it was both more complex and full of unexpected behaviors.

I have less experience with Angular (2+), but I found it much more complex and in some parts over engineered.

I can put a junior in react and be fairly sure that nothing too crazy will happen. I can't say the same for angular.

A lot of enterprises hiring juniors on the cheap actually thought of it in the opposite way. They saw Angular's rigidity as some sort of safety rails to help guide developers in the rightish direction. They thought React was the Wild Wild West of JS land ;D No manager got fired for choosing Angular. If only

I'm kind of surprised this is downvoted. There are definitely companies out there that chose Angular because it enforces writing code within the framework's style. It feels like bowling with the guard rails on, and if your team leans junior, it seems sensible to opt for that choice.

I'm not saying I personally agree with the decision, but I could see how management might conclude to chose Angular with that rationale.

I wouldn’t say the same no matter the domain - junior devs can and will surprise you, and because React gives you less guardrails for app architecture, it likely has the potential to go far worse.

Well obviously they'll be CR'd. If you stick to prop drilling and functional code there's far less you can do abjectly wrong.

Except wire up routing in a strange way, or pick a library for form validation or form framework, or come up with odd ways of structuring tests, picking a strange approach for animations, etc.

This is the cost when app architecture gets delegated to your developers over a high quality central solution, the quality is as good as your developers.

Those are the parts where you put a senior in charge. Hell I can't even do that in React, and have in the past literally hired a contractor to set that up for me.

> If you stick to prop drilling and functional code

Juniors new to React are unlikely to do so, IME (as a semi-new-to-React not-junior working on a team with new-to-React junior-ish devs -- by experience; there isn't a formal junior/not-junior distinction on our team.)

OTOH, if you do things you really shouldn't do in React, while they won't all be flagged, there's a very high probability it will result in at least related warnings pointing to it in the devtools console, so that's something.

> the whole React-Redux boilerplate mess... is the the result of an entire generation of code monkeys and job seekers who didn't design their technology stack with any real engineering consideration

What do you even mean?

Redux was a simple and elegant implementation of the unidirectional data flow (aka the Flux pattern). It came out during the time when the state of the art was Angular 1.x (aka AngularJS)'s two-way data binding, requiring a lot of dirty checking. Redux might or might not (the story is moot) have been influenced by Elm, which has exactly the same concept of actions, state modifications in response to actions, and re-renders in response to state modifications; all as pure functions; and Elm developers are finding this approach enjoyable and predictable. But even Elm aside, the pattern that redux is using, i.e. communicating via messages (actions) and subscribing to state changes in connected components, is a variation on the age-old, battle-tested event sourcing and pub/sub. What's so bad about that?

React != redux. I really like react, I really hate redux, so I use react without redux and it works just fine (we actually use tracker+minimongo from meteor for our app state and really like it)

My enjoyment of React grew exponentially once I moved from Redux to MobX.

I second this. In my last largish application, state was getting really messy and I needed a place to keep it all organized. I really tried hard to get Redux to work as at the time it was the tool that everyone was talking about. I struggled and couldn't make sense of it. Eventually I stumbled upon MobX and it just clicked. So easy to work with and checks all of my boxes. Productivity and happiness soared :)

Your thoughts on Hooks?

Is it just the pairing of React / Redux you find unappealing?

Your feedback is disappointingly vague but you seem passionate about it so I assume there’s something deeper here.

Oh man, don't say it. I've just started to learn React to improve my chances of landing into my first job, since all Java positions are either full-time or requires >4 years of previous relevant experience.

I wouldn’t worry about that. React won the framework war in most industries. The only places who really utilise Angular in my area are the same companies who build the JAVA backends you can’t get hired for, and even some of them are switching to react.

All in all you shouldn’t worry too much about employability if you pick and stick with something popular. Check your local job-market and stop worrying about what’s hipster cool on HN. There hasn’t been a single Rust or Go job listing in my entire region of Denmark for an entire year, mean while there are currently around 150 PHP positions open right now.

For better or worse, react is and will remain very employable.

If for you extrapolating types trying to fit a square into a circle every variable declaration and having 10 lines of decorators per file means less boiler-plate then yes angular is the better framework.

People who despice react because of redux(Boilerplate) should try mobx.

Or you know, use Redux because the boilerplate is gone... https://redux-toolkit.js.org/

You don't have to create actions or constants anymore, you just create your reducer functions and selectors, then use hooks to select and dispatch in your components.

Never got why people took up a completely different paradigm just because they couldn't figure out how to reduce their boilerplate...

Or use XState as Redux is only a half implementation of a state machine. It get's the job done but a state machine gives you far more structure and comprehensibility around state management.

https://github.com/davidkpiano/xstate

Which is great because you don't need a full state machine.

React can be that other half...