Live data from Hacker News

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

marmelab.com

191–200 of 574 posts

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

#191
post #139

Earlier quoted context omitted.

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-lo…

what are you using these days?

Mainly Vue. It's OK and pretty widely used, which gets you decent library support and such. If I were starting from scratch and didn't have organizational/team inertia & experience to consider, I'd probably give things like htmx a hard look.

I'd have to re-evaluate the current Android landscape because it's been a while, but I might still consider React Native only for that platform, because having RN smooth the rough edges off Android dev made it a lot more pleasant and quick, with far less time lost fighting the platform and working around/replacing bad 1st party stuff piecemeal. But maybe it's gotten better-enough in the last 4ish years that it's no longer tempting to drag in RN just to avoid native Android dev.

In general though, I just no longer default to advocating React for highly-interactive sites or "webapps", as I did for a while.

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

#192
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…

Hotwire, unpoly, htmx and other html-over-the-wire tools are making it easier to do most of what you’d use react for without the tooling headaches.

https://dev.to/rajasegar/html-over-the-wire-is-the-future-of...

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

#193

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.

No, you're not the only one. Apart from useState, which is elegant, I hate others with passion. How can a replacement for lifecycle methods be called useEffect? Seriously? Great article, couldn't agree more with them.

useEffect is poorly designed for sure. It's the single most common source of react bugs I've seen and most developers have to refresh themselves on it if they don't use it for more than a few months because it is totally unintuitive.

A lot of third party hooks are really good though, being able to hook a dependency rather than create higher order components saves a lot of time and is conceptually much easier.

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

#194

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 is the abbreviation for the unit teaspoon in German, the way ts is the abbreviation for teaspoon in English.

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

#195
> And I thought that reference counting was a native feature of all languages with a garbage collector. But no, I have to micromanage dependencies myself because you don't know how to do it.

So annoyingly enough... There's not anything inherent to the language that makes it impossible to get a list of closure references for a function, other than it's not something JavaScript exposes. In a hypothetical future version of JS, this could be a first-class feature of the function API.

... because what JavaScript really needs is yet another feature to support one framework's special-caee needs. ;)

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

#196

Earlier quoted context omitted.

Fair enough. Though, the first question is - why does the component do so many things? Do they all need to be in a single component or can you break them apart? For the cases when this is not possible, I agree, useEffect works better than classes lifecycle methods. But do you really want a system which caters to a small percent of use-cases at the expense of readability in others? And the improvement, to my eyes, is…

It's not a matter of doing too many things. Lifecycle methods exist to be used, and the moment you have any behavior that requires multiple lifecycle hooks, you will run into these issues. So I'd say it's not a small-percentage of use-cases at all, and you'll often see the benefits of hooks immediately.

My experience is exact opposite, let's agree to disagree.

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

#197
post #99

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 totally agree. I actually stopped using React around the time hooks were announced. In retrospect it's still not clear if hooks were even a good idea. Changing the core methodology of a project used by millions of developers at the time was extremely irresponsible. They basically made obsolete all React educational resources overnight. I'm sure people making money by producing React educational content were very ha…

There was no way to make async rendering possible with classes. It was necessary and they spent a lot of time trying different approaches that'd continue the old paradigm, but it couldn't be done.

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

#198

Earlier quoted context omitted.

Are you finding much "professional traction" with Vue? I really like Vue and use it for personal projects but React seems to dominate the job postings.

Vue is mostly used in China, where there is a preference for Chinese tech.

Really? What are they using for things like containerization, observability, testing, or even compilers and operating systems?

Really curious if there's an alternative word for all these core tools in the west.

From my understanding Vue was heavily adopted in China because it was the only major framework that had its docs translated into Chinese by Evan himself (initially at least). Guessing this isn't accurate nor the case?

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

#199

Earlier quoted context omitted.

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-lo…

It is purely because `this.state` is hard for V8 to optimize, nothing more and nothing less. They did it for their own purposes, for better performance on low-end machines. You can almost certainly just use classes for 99% of use cases

Funny that this whole hooks mess could have probably been better resolved with investment in developing optimization patches for v8 rather than attempting to "fix" React

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

#200

I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each oth…

They mostly encourage bad practice by design and people do what these tools give an affordance for which is why the results are broken.
Post reply on HN