Live data from Hacker News

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

marmelab.com

81–90 of 574 posts

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

#81

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?

TL – Teelöffel (teaspoon, unit of measurement)

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

#82

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 use functional components only for things without state. If anything has state I use class components because otherwise you go mad. ;)

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

#83

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 ;-)

Personally, I found Vue was the best solution for CRUD-like use cases, where the complexity is in the sheer variety and volume of UIs you need to maintain. Whereas React works better for more complex interactions.

That being said, the Vue2 -> Vue3 migration has felt pretty frustrating. It's felt like, with enough work, I could eventually get Vue to behave similar to React.

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

#84
post #14

Earlier quoted context omitted.

While I agree that the intent of Context isn't state management, but its functionality in practice is nearly identical to state management. I know and agree this has been discussed to death, so please be patient while I beat this long-dead horse. In the beta React docs, Context is described as: "Context lets the parent component make some information available to any component in the tree below it—no matter how deep—…

Context is useful for certain cases, but plain old useState/useReducers are the workhorses. I think the beta docs are pretty good about explaining the tradeoffs ( https://beta.reactjs.org/learn/passing-data-deeply-with-cont... ). To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling. Passing props around and having some local state works very well for large parts of many application…

> To me one of the biggest issue is that almost everyone is deeply afraid of prop drilling.

Prop Drilling is considered an anti-pattern for good reason.

It very quickly turns your project into an absolute mess, making it impossible to determine where props are coming from and where data is actually set.

Keeping that clean is one of the most important things you can do in a frontend codebase imo.

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

#85
post #13

Agree with a lot of this, but, some quibbles: 1. yes, un/controlled forms are messed up and need work 2. yes, contexts should replace Redux and Redux should go away. but in practice having a few contexts is pretty manageable. Currently we use Redux for all the dynamic state and contexts for everything else and it works pretty well. It is quite easy, also, to write your only little `useSelector()` wrapper around a non…

Nice blog post, the part about jQuery UI is spot on. There is lots of talk here about how a bit of jQuery is all sites need, but it always turns into a giant pile of complexity when writing all of the transitions rather than just the state that you want.

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

#86

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.

Nope, I'm with you. React inventing a half-baked, partial re-implementation of objects/classes (in a language that already has them!) with super-weird declaration syntax & runtime behavior, just to avoid telling their userbase "Ok you will have to use classes sometimes, for certain functionality", was when I started looking around, because they were clearly out of real problems to solve that were sufficiently good-looking-on-a-résumé, and it was just gonna go downhill from there.

Class components were/are just fine.

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

#87

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…

Same background here.

I don’t believe in quitting cold turkey and I don’t think there’s anything available to fully replace all aspects of React. We’re instead gradually transitioning our internal ecosystem to use less React-specific stuff, positioning us to migrate (or not) in the next few years.

- Move from CSS-in-JS to vanilla CSS

- Avoid React-specific libraries, both developing them internally or when selecting third-party deps

- Keep business logic out of React components whenever possible

Etc

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

#88
It may be due to the codebase I'm working on, but I doubt it since I assume I have decent colleagues (I'm in a FAANG), but I just fucking hate React.

I spent years working on Angular before changing team, and there everything makes sense instantly. It's just normal programming, normal MVC, normal everything, and you basically only need to learn about the syntaxic sugar for data-binding and stuff like this.

In React it seems like they reinvented the wheel and they thought a circle was too easy so they made it in a 5 dimensional shape. You have 18 ways of doing anything and they are all deprecated, your logic and your template are mixed which turns your application into an unreadable mess, every single aspect is overengineered to death, requiring you to call useState() to have a fucking boolean that you can update, everything is stored in a variable or declared as a function instead of in classes, etc.

I'll have to give a try to React from scratch where it's not on an existing codebase, but I don't think that's the real issue.

It's been more confusing for me to go from Angular to React than to learn a functional language after years working with imperative ones.

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

#90

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…

That’s the thing though - hooks aren’t JS. They don’t allow for control flow. Hooks are a language that superficially looks like JS. I’m with you on not inventing new languages, and I wish that React didn’t step so far off that path itself…

> hooks aren’t JS

They literally are.

> hooks aren’t JS

The code in React executing components relies on hooks running in a consistent order each time the component runs, but the existence of a runtime context that has expectations about side effects (and hooks are side effects) doesn't make it “not javascript”.

Post reply on HN