Live data from Hacker News

React is holding me hostage

emnudge.dev

261–270 of 553 posts

Re: React is holding me hostage

#261

Earlier quoted context omitted.

> All blow up events come from a loud and extremely small minority. But whether they are making noise or signal, does not depend on number of people! Fair, this instance is 100% noise imo. We're engineers - we should be able to judge when something is silly. > React continues to dominate others because it has corporate backing while Vue doesn't. And angular was popular for the same reason before angular 2. I have nev…

AngularJS and Angular (what you referred to as Angular 1 and 2) are completely different frameworks. It’s a branding issue, not a technical one. Angular, from version 2 to 15 in the past 8 years, has been completely backwards compatible, and even stayed on the same paradigms. Angular code from 8 years ago looks almost the same as modern code. Which is much more stable than react’s codebase.

>It’s a branding issue, not a technical one.

I mean, for a single version bump (Google called it Angular 2.0) to render not only the code not migrate-able, but the entire paradigms on which the framework was based on is basically unheard of in an enterprise-targeting framework.

That’s an egg-on-face technical fail.

Re: React is holding me hostage

#262

I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for…

> Templates are a no go for me. I use them for blogs or static websites, but applications are easier to make and maintain with actual javascript.

Could you expand on this. You assert that "applications" are easier to maintain with JS, but blogs are not?

Are you defining "application" here as something with dynamic and interactive content?

Also, why is it easier to "make and maintain"? I'm not necessarily disagreeing, just curious as to why you believe this.

Re: React is holding me hostage

#263

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…

> the modern webapp experience is so miserable for the average person. I see this claim a lot and I'm curious what this is based on, can somebody drop some links to further reading?

Sadly all I have is more anecdotes, but you can get those yourself by asking any non tech worker what they think of using any software.

Re: React is holding me hostage

#264

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…

React/competitor performance that people use to compare frameworks is about rendering performance. E.g. React takes 100ms longer to rerender 10,000 elements (random numbers for the example). In these situations the actual real world difference will be negligible.

Site performance is much more API based, and that’s the same regardless of frontend. React has more library solutions to optimize the UX though, as it’s the most mature and popular.

Re: React is holding me hostage

#265

Earlier quoted context omitted.

That’s highly dependent on the type of product / customers you have. If you’re running an online shop selling ice cream, going from 100ms to 2ms list sorting speed isn’t gonna get you more sales. I’d argue most online products are ice cream shops to some degree.

The data seems to indicate otherwise: https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-... > A 2017 Akamai study shows that every 100-millisecond delay in website load time can hurt conversion rates by 7% > 10 years ago, Amazon found that every 100ms of latency cost them 1% in sales

With SSG and to a lesser extend SSR, React has close to zero impact on the initial page load. It’s all just HTML.

Re: React is holding me hostage

#266
> I recently read someone’s astonishment at how smoothly the React ecosystem’s transition to Hooks was - how everyone was unilaterally in agreement on its benefit. This is not the past I remember. I remember quite a bit of a contention. Particularly on the orange site, but not exclusive to it.

Does anyone have a source?

Re: React is holding me hostage

#267

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.

The purpose of a good framework is to make developers productive, regardless of their level of expertise.

A junior dev isn't going to be build as fast or as clean as a more experienced dev, but a good framework promotes speed and provides guardrails to prevent mistakes.

To that end my experience with React -- same as the author's -- is that React does not have this characteristic and provides many ways to shoot yourself in the foot.

Re: React is holding me hostage

#268
In case you're feeling alone. I detest hooks and I'm glad I was able to get out of front-end dev before they became wide-spread. I loved react at first with class components and its friendly lifecycle. It was designed to be understandable and self-documenting. It was a pleasure to write self-contained components. The move to function components, redux, and hooks stripped all of that away.

I'm glad others have found value in the evolution of react, but it always felt like watching a tragedy from the outside as the newest Abramov idea seeped through the ecosystem.

Re: React is holding me hostage

#269

I don't understand the animosity around useEffect. It executes a function based on a list of dependent variables. That's it. Once you understand that, its purpose becomes very clear. You don't want to rerender? Use useEffect with an empty array! Or don't use any state variables! You want to show something new to your customers / users without rerendering? Well sorry, that's impossible, regardless of any framework you…

I agree, and I'd like an anti-hooks person to explain their thoughts a bit more. My impression is that they believe useEffect inclines devs to cause side-effects in the component, quickly making the logic of a component difficult to follow- for example, a useEffect that sets a state that kicks off another useEffect that sets another state that kicks off another useEffect...

But this problem existed before hooks: old school React devs will remember the days of class-based components with humongous componentDidUpdate methods peppered with calls to this.setState(...) that did the same thing.

My own impression is that hooks offer better lifecycle controls overall, with the side effect (heh..) of handing devs an arsenal of footguns that will inevitably go off if they don't fully understand the hooks or where to use them or how React detects and triggers a re-render. So in a way I agree with the author of the original article here, but in the sense that React devs should probably not use hooks until they understand how re-renders happen and why to avoid that and only then should they be handed one footgun at a time.

Re: React is holding me hostage

#270
I've been mostly using React from ClojureScript, via reagent and re-frame. I've mostly avoided the hype of hooks, except in interop where they've been a pain. And I second the sentiment of Mike Thompson, who says [0]:

> Humans have a cognitive bias: "what is focal is presumed causal".

> Political leaders know this. They like presenting good news themselves because they like to be "seen" as causal of good stuff, but they'll get a press secretary to deliver bad news. Movie directors know how to use this when framing their protagonists within the story.

> Unfortunately, the React team have lost themselves in this bias. They keep trying to make the most focal part of the system (components) also be the causal part. Please stop doing that! It is a mistake. Events are what's causal - they embody the user's intent.

> Just to be clear, I love React. What an utterly brilliant idea and great execution. I'm deeply grateful because, wow!, did it change things. It is just that I preferred React when it was only trying to be the V part of MVC. Everything since has been downhill.

[0]: https://day8.github.io/re-frame/FAQs/LoadOnMount/#why-this-d...

Post reply on HN