Live data from Hacker News

React is holding me hostage

emnudge.dev

241–250 of 553 posts

Re: React is holding me hostage

#241

I've been feeling the same sentiment as the author. Having worked on 3 sizable React projects now (all started before I arrived), I can only conclude that beyond a toy phase -- once you have many hands working on React and *particularly* once you start managing sizable state -- there is only pain. The most recent case resulted in spending quite a bit of time explaining to a peer why we were experiencing an unexpected…

Are you saying that React is bad because a Junior Developer cannot bother to think about caching or at least open introductory materials before using a framework? If that's the kind of problems you deal with, that makes React one of the greatest framework ever.

Re: React is holding me hostage

#242

Earlier quoted context omitted.

How is performance not important in this context? React is very sluggish when updating many elements at once, for not very large values of "many". With some regularity, I've debugged React+MobX jank issues where a bigger update, such as switching from one panel to another, takes upwards of 200ms on a mid- or low-range machine. None of this is perceptible on our beefy dev boxes, which is why I think people disregard i…

Performance of frameworks is often irrelevant for products/applications. 1. Performance is very very rarely a contributor to a product success. Users prefer more features over more performant app all the time (both directly when asked and indirectly by what products they choose). 2. Rendering/client computation speed is rarely a contributor to real and perceived performance. It's almost always the async calls - how m…

> Performance is very very rarely a contributor to a product success

You might as well say, having users is very very rarely a contributor to a product success. We're over two+ decades into the 21st Century and we're still pushing a 20th Century mindset?

Why Lord? Why?

Re: React is holding me hostage

#243

Earlier quoted context omitted.

Performance of frameworks is often irrelevant for products/applications. 1. Performance is very very rarely a contributor to a product success. Users prefer more features over more performant app all the time (both directly when asked and indirectly by what products they choose). 2. Rendering/client computation speed is rarely a contributor to real and perceived performance. It's almost always the async calls - how m…

> Performance is very very rarely a contributor to a product success. Users prefer more features over more performant app all the time (both directly when asked and indirectly by what products they choose). I close sites all the time when they fail to work quickly. I have aborted orders on sites midway through when the interaction became sluggish enough that I wasn't confident in the value of the product anymore. Thi…

And I never click on Ads. Yet they work and drive a lot of traffic and money to sites. (Even after all the fraud)

Products almost never compete on performance, and the biggest, most popular ones are almost always the slower ones.

Regardless of your anecdotal evidence, there is a reason why this sentiment is prevalent in the industry - because PMs and devs who thought otherwise were quickly outcompeted by those that moved faster and released more features.

Re: React is holding me hostage

#244

Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a few seconds. I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. If a child component signals to a parent that the state has changed…

> If you're delegating all of your coding skill to the framework and expecting it to just magically work no matter what dodgy code design you throw at it then you're going to build a shitty app.

Not to disagreed with you here, but there are many frameworks out there which either claiming themselves as "full-stack" or trying to be as full-stack as possible.

The developers who uses these frameworks might just expect "(delegating your code to the framework) is how it suppose to be used"(, while blaming people who write "raw" JavaScript code as "hacky").

This is a problem which will occur whenever you want to standardize the workflow as well as the knowledge base for your team. Some approach is discarded in this process and what's left in the end are often "common practices" which nobody has reason to reject. If the "common practices" is to let the framework to do it, then that will be that.

Re: React is holding me hostage

#245
post #235

Earlier quoted context omitted.

I don't think you are living in the real world. Is Microsoft corporate? React is a first class choice in their frameworks. React is like nearly any other tool, use it well, and it's great. Well optimized React is lightweight to the client and a joy to test and debug. That said, Web Components are even better, but I'm guessing that's science fiction to you.

I don't think you are living in the real world. Most React applications do not end up like that in the real world. They turn into poorly architected over complicated nightmares, particularly on sprawling apps which is the reality in the corporate space. Not everyone is building hyper-focused single function tools which can be crammed in an SPA type framework. And the users suffer for this. One of the finest turds I'v…

RE: Microsoft

1) MSFT has already used React for far longer than 2 years.

2) They have basically never used the technologies you mentioned (WPF, Silverlight, WinUI). They offer them as UI toolkits that run in their Windows environment and that’s it. Their failure to market and support these technologies is independent of what they do for their own development strategy.

3) They bought GitHub and effectively own electron now. Many of their biggest apps are on electron (Teams, VS Code, Azure Data Studio).

Re: React is holding me hostage

#246
post #50

Not to start an unholy flame war, but if you were to start a new project and didn’t need to worry about the ecosystem or workforce, what framework would you choose? Vue? Svelte? Something else?

Web Components, Service workers, Lit.dev, htmx, declarative shadow dom. These are the modern tools you need.

Re: React is holding me hostage

#247

The whole thing around React is odd to me. People laugh at web development, especially the frontend, for changing libraries every week but you read a thread like this and everyone is so sure that React is a bad library and we should be using some newer library instead. I work with React daily and it has issues, but I find most issues can be worked around without much trouble. It's easy to hire people, onboard people,…

> It's easy to hire people, onboard people

Yes they'll know the React part. It's the Redux/Mobx/React Router/whatever snowflake libraries you chose part that will be more difficult. I really don't like incomplete solutions personally.

Re: React is holding me hostage

#248

Earlier quoted context omitted.

Performance of frameworks is often irrelevant for products/applications. 1. Performance is very very rarely a contributor to a product success. Users prefer more features over more performant app all the time (both directly when asked and indirectly by what products they choose). 2. Rendering/client computation speed is rarely a contributor to real and perceived performance. It's almost always the async calls - how m…

> Performance is very very rarely a contributor to a product success You might as well say, having users is very very rarely a contributor to a product success. We're over two+ decades into the 21st Century and we're still pushing a 20th Century mindset? Why Lord? Why?

> You might as well say, having users is very very rarely a contributor to success.

These two things are not even remotely the same thing.

Having users is a path to monetisation but having a high performant app no one uses is not.

In fact, if you have users despite performance, it suggests you have a home run product that can be optimised for performance.

Again, you can’t optimise your way to user growth.

Re: React is holding me hostage

#249
post #235

Earlier quoted context omitted.

I don't think you are living in the real world. Is Microsoft corporate? React is a first class choice in their frameworks. React is like nearly any other tool, use it well, and it's great. Well optimized React is lightweight to the client and a joy to test and debug. That said, Web Components are even better, but I'm guessing that's science fiction to you.

I don't think you are living in the real world. Most React applications do not end up like that in the real world. They turn into poorly architected over complicated nightmares, particularly on sprawling apps which is the reality in the corporate space. Not everyone is building hyper-focused single function tools which can be crammed in an SPA type framework. And the users suffer for this. One of the finest turds I'v…

I can look at the javascript of many "big corporate" websites and see they are often a sprawling mess of homebrew code. I'm sorry your electricity company's React website is bad, but I don't think an anecdote is data. Any framework can get abused, not using a framework doesn't mitigate the problem. But trying to update a site that uses a different approach for every little feature spread across many pages, without any idea of what a component is, that's a nightmare. At least you can sensibly incrementally improve React across a site's components with well worn tools, especially as a team.

I don't love Microsoft, but it's for the best they adopt a well known and rounded framework like React, rather than try to invent yet another of their own frameworks, like the ones you mentioned. I don't know why this has anything to do with Electron, since their React push is for their front end frameworks for their main corporate product, Office365 (or whatever it's called today).

Re: React is holding me hostage

#250

Earlier quoted context omitted.

Performance of frameworks is often irrelevant for products/applications. 1. Performance is very very rarely a contributor to a product success. Users prefer more features over more performant app all the time (both directly when asked and indirectly by what products they choose). 2. Rendering/client computation speed is rarely a contributor to real and perceived performance. It's almost always the async calls - how m…

> Performance is very very rarely a contributor to a product success You might as well say, having users is very very rarely a contributor to a product success. We're over two+ decades into the 21st Century and we're still pushing a 20th Century mindset? Why Lord? Why?

I might not as well say that. I in fact said something completely opposite - that users don't care about performance. Hence more features->more users.
Post reply on HN