Live data from Hacker News

React I love you, but you're bringing me down

marmelab.com

71–80 of 574 posts

Re: React I love you, but you're bringing me down

#71

As a developer who’s been working with React since the beta, I can confidently say that the author is speaking the truth. Especially so near the end of the article where they can’t seem to quit React. For all the annoyances of Hooks, they really are a godsend when it comes to composing state. And refs do indeed suck, but they sucked even more with class based components. I can’t tell you how many times I was able to…

Well, I work for a fortune 100 company and we use Vue. After using React, I strongly prefer Vue, so I would say it is the greener JS pasture ;-)

Re: React I love you, but you're bringing me down

#72
post #45

Does anyone do server side rendering these days? I fail to see the point in SPA apps for the majority of web apps. At my work we have an ancient Dojo frontend and a newer react one being build. Its a few list views that the user can filter and a few forms with validation. It's a ridiculous amount of complexity to avoid loading a page. I could do almost everything for half the effort with server side HTML from Django…

You should try again and reconsider if your team truly doesn't have an answer.

Most everyone using React should be using Nextjs or similar level of frameworks. Server rendering comes out of the box. On the other hand, it really isn't too complex anymore. With Next, Sveltekit, Remix, Nuxt, and friends, you get simple, hardened tooling out of the box. And you've decoupled frontend from api which many teams find very helpful to split responsibilities and allow certain features to move at different paces.

Re: React I love you, but you're bringing me down

#73

I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.

> They have their place. How so? There is nothing that a class-based component can do that a hook-based component can't (EDIT: Except for error boundaries). I'd go as far as to say class-based components are strictly inferior because they force you split your behavior logic across lifecycle methods and are not easily composable. I've been able to support much more complex behavior easily with hooks (e.g., connection…

You still need to use class components for error boundaries.

https://reactjs.org/docs/error-boundaries.html

Re: React I love you, but you're bringing me down

#74

I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.

> They have their place. How so? There is nothing that a class-based component can do that a hook-based component can't (EDIT: Except for error boundaries). I'd go as far as to say class-based components are strictly inferior because they force you split your behavior logic across lifecycle methods and are not easily composable. I've been able to support much more complex behavior easily with hooks (e.g., connection…

Isn't it also easier to get subtle lifecycle bugs with them, because you can forget one.

Re: React I love you, but you're bringing me down

#75
I really hope React doesn't handle dependencies automatically. There have been many frameworks that have done that in the past. It does not end well with an application of any decent size.

A pre-compile step that statically adds dependencies to your code might be a reasonable compromise, but those dependencies do need to be explicit.

The rest of the stuff makes a lot of sense though.

Re: React I love you, but you're bringing me down

#76

As a developer who’s been working with React since the beta, I can confidently say that the author is speaking the truth. Especially so near the end of the article where they can’t seem to quit React. For all the annoyances of Hooks, they really are a godsend when it comes to composing state. And refs do indeed suck, but they sucked even more with class based components. I can’t tell you how many times I was able to…

> Has anyone else here successfully left for greener JS pastures?

I've simply stopped doing any frontend development contract work *. Until the whole JavaScript world pulls its head out of its bottom, I'll leave that niche to other people.

* I'll do JS and React if I really have to, but I'm actively avoiding any client-side focused projects.

Re: React I love you, but you're bringing me down

#77

Earlier quoted context omitted.

I'm also a TL (which makes me a teaspoon here in Germany, which I like more than the tech lead title). I understand how the development can be faster with Svelte, but ecosystem argument really hits home. You'd get to 80% with Svelte perhaps much faster than React, but that missing library for, say, drag-and-drop makes that last 20% itself plus "hey let's develop our own drag-and-drop library in-house which should be…

What is a teaspoon?

Yeah, I also didn't get the 'teaspoon' reference.

Re: React I love you, but you're bringing me down

#78

I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.

I'm definitely a novice when it comes to React, but I've shipped a beta version of an internal took using it. I never understood the emphasis on functional components. Everything I did using them was made more complicated and less obvious, especially for colleagues who are not familiar with React or JS in general.

React is built on components which are objects (both in a programming and GUI sense). Using OOP to describe them just makes so much more sense to me.

Re: React I love you, but you're bringing me down

#79
post #74

Earlier quoted context omitted.

> They have their place. How so? There is nothing that a class-based component can do that a hook-based component can't (EDIT: Except for error boundaries). I'd go as far as to say class-based components are strictly inferior because they force you split your behavior logic across lifecycle methods and are not easily composable. I've been able to support much more complex behavior easily with hooks (e.g., connection…

Isn't it also easier to get subtle lifecycle bugs with them, because you can forget one.

Oh yeah, that's the worst. Since logic related to a behavior must be split up across multiple methods, it's really hard to tell if you've actually implemented it correctly. With effects, the setup and teardown is in the same function and can be moved around as a unit.

Re: React I love you, but you're bringing me down

#80
post #57

We tried to use other frameworks but finally came back to React for only one reason. It's easier to hire for React. The talent pool for React is almost 10 times that of other frameworks. And for now, this reason is good enough for us.

Good point. But then again, if the engineer is good, switching between say React, Vue and Svelte shouldn’t be too hard. EDIT: To clarify, I mean picking up one of the three if you already know another one.
Post reply on HN