7 ms·

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 muta

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

dreamer7 7y ago
Exactly! JSX is much easier to use compared to angular templating.
Nican 7y ago
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...
tannhaeuser 7y ago
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.
- crubier 7y ago
  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.
  - izietto 7y ago
    > 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
    - crubier 7y ago
      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).
      - izietto 7y ago
        > 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)
        crubier 7y ago
        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.
        spaceribs 7y ago
- DonHopkins 7y ago
  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%C3%A4user_Gate https://en.wikipedia.org/wiki/Tears_in_rain_monologue#Tannh%... https://en.wiktionary.org/wiki/%E6%8E%A2%E6%B5%B7 https://en.wiktionary.org/wiki/%E6%8E%A2%E6%B5%B7
  - tannhaeuser 7y ago
    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 :)
    - DonHopkins 7y ago
      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_Eldritch https://en.wikipedia.org/wiki/The_Three_Stigmata_of_Palmer_E...
      - ofrzeta 7y ago
        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.
- jbergens 7y ago
  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.
  - Cthulhu_ 7y ago
    Better yet, avoid it entirely and stick to using React's Context (https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html) or if you have to, useReducer() (https://reactjs.org/docs/hooks-reference.html#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)
    - lukevp 7y ago
      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.
igammarays 7y ago
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?
- crubier 7y ago
  >> 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.

dreamer7 7y ago

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

Nican 7y ago

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...

tannhaeuser 7y ago

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.

crubier 7y ago
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.
- izietto 7y ago
  > 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
  - crubier 7y ago
    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).
    - izietto 7y ago
      > 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)
      - crubier 7y ago
        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.
        spaceribs 7y ago
DonHopkins 7y ago
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%C3%A4user_Gate https://en.wikipedia.org/wiki/Tears_in_rain_monologue#Tannh%... https://en.wiktionary.org/wiki/%E6%8E%A2%E6%B5%B7 https://en.wiktionary.org/wiki/%E6%8E%A2%E6%B5%B7
- tannhaeuser 7y ago
  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 :)
  - DonHopkins 7y ago
    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_Eldritch https://en.wikipedia.org/wiki/The_Three_Stigmata_of_Palmer_E...
    - ofrzeta 7y ago
      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.
jbergens 7y ago
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.
- Cthulhu_ 7y ago
  Better yet, avoid it entirely and stick to using React's Context (https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html) or if you have to, useReducer() (https://reactjs.org/docs/hooks-reference.html#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)
  - lukevp 7y ago
    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.

igammarays 7y ago

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?

crubier 7y ago
>> 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.