Hacker News Reader

Comment by crubier | Hacker News Reader

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

View on HN

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.

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.

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

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

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.

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.

Reply on news.ycombinator.com