Comment by mcv | Hacker News Reader

Comment by mcv | Hacker News Reader

I'm not a hardcore React user; I'm currently working with React, but I came here through jQuery, Angular 1, web components, and Vue. I've done two React projects: one really tiny one as an assessment where JSX was an eye-opener; components were classes, and React was simple and fun back then.

Now I'm working on a gigantic React project, and I'm surprised it's still working. It's all based on function components with all the hooks, higher order components, middleware components, and tons of other stuff. It works, and it's clearly maintainable, but it's not pretty. Endless useEffects after each other make it hard to see what's going on. Every change requires changes in half a dozen files at least; DRY is clearly not a concern here.

I'm not a React expert, but I think function components and hooks were a mistake.

One thing that strikes me is that years ago everybody was excited about ES5 finally adding classes, and now everything seems to be moving away from classes.

I think JSX is still a cool idea and an interesting alternative to templating, but I also think that if I were to pick a frontend framework now, I'd go with Svelte.

If you have lots of useEffects and the code is confusing, that just means you're not writing your code well. I've architected and shipped multiple react projects that generate min 100M + USD in revenue, so I'd say I'm well versed in production react. It is weird, sure. All web technologies are kind of weird. But it works great for large web applications.

Keep your functions small. Re-use is key - whether its hooks or components. Keep state sane by writing small functions that handle a couple state items internally, or create a parent state using context around a group of components.

React gets a lot of hate, but most of it is unfounded. It is just a tool. I see people write 800+ loc react components and wonder why it is "so confusing". The problem is obvious. The goal of using any technology is to make money, nobody cares (end of the day, just being real lol) about any of these esoteric practices that happen under the hood with effects, etc. Write good code and most problems disappear.

Unless you're working at Meta on react, or you have some burning desire to build tools like this (and honestly only <5% of devs who contribute will contribute something meaningful), there's no reason to pick so many fights with these tools.

Just use it by accepting its features and limitations, and craft your UI project well enough that it is maintainable and keeps printing money. Anything beyond that is a waste of time/effort.

Any good resources to learn more on this (working with production react)?

Endless useEffects is an indication that useEffect is being used incorrectly. In mostly projects you should only see a few instances of useEffect.

This might be helpful https://react.dev/learn/you-might-not-need-an-effect

If the same problem pops up a lot when using a framework, then at some point the framework is to blame. Yelling at developers "you are doing it wrong!" is meaningless, frameworks should naturally lead people towards the correct behaviors.

React does no such thing.

Not a problem with the library, but a documentation issue. The advice around how to correctly use useEffect was a bit ambiguous in the old documentation, but thankfully is much better in the new docs.

I find Angular much easier to reason about than the current state of React/Next. Which is funny because the biggest criticism of Angular years ago was its learning curve. Yet React seems to have become even more convoluted.

React and angular both had much bigger learning curves than vue. But between google and Facebook, I don’t think vie stood a chance popularity wise, even though I think it was the better of the frameworks at the time.

Vue didn't stand a chance? I think it's pretty popular, isn't it? The company behind it doesn't matter that much to the popularity.

Oh i dont think you remember when Facebook launched React at their big conference. It absolutely does matter.

I wasn't there, so no, I don't remember that. Thing is, plenty of technologies launched by large companies at big conferences have failed to catch on. And plenty that were created by just some people without a big corporation have been wildly successful.

One reason you don’t want a class for every component is that standard JS minifiers won’t compress method call names, but can compress imported function names. So the cost in the minified bundle between a class component and an equivalent function component is huge, multiplied out by the complexity of the component.

`this.handleClick` vs `c`.

I still use classes for building data structured but don’t think creating classes should be encouraged by a framework.

They can do it, it is just turned off by default and require more advanced configuration.

https://github.com/terser/terser#cli-mangling-property-names...

I don’t know any codebase that’s enabled these kinds of transforms because the compiler doesn’t know if a type’s properties will be introspected or iterated, so the transform is likely to break at runtime

> So the cost in the minified bundle between a class component and an equivalent function component is huge

Does this actually matter though? It's going to be gzipped anyway right?

Gzip compression will eliminate the repetition on the wire, but smaller uncompressed bundles will parse and start executing faster than larger bundles. For us this is most noticeable on Android which has the slowest hardware on average of all the platforms we support.

> One thing that strikes me is that years ago everybody was excited about ES5 finally adding classes, and now everything seems to be moving away from classes.

For me the key advantage is much less boilerplate, readability and portability. The problem with `Stateless` components up until the introduction of hooks is that if you wanted state you had to write your component as a class so you ended up with components written in two totally different syntaxes with one being much more heavy on boilerplate.

The last key advantage i see is it brought the "React Components" way of sharing to logic. Previously every piece of logic you shared had to be connected to a react component, so you ended up with many "Providers" that were just a div with logic. Now with Context and Hooks you can easily transport that logic without the use of a Provider (well you still need one with Context but that a slightly different story).

Makes sense. I'm not sure I've ever written a stateless component. Almost every non-trivial component is bound to have some sort of state, doesn't it?

> Almost every non-trivial component is bound to have some sort of state, doesn't it?

No, not at all. Any nontrivial component is going to have some sort of conditional rendering, but whether the inputs are supplied explicitly as function arguments or implicitly as state is for the most part orthogonal to what you do with them.

Reply on news.ycombinator.com