Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React is holding me hostage

emnudge.dev

Post reply on HN
Print view View original

231–240 of 553 posts

Re: React is holding me hostage

#231

Post by larsnystrom »

Illniyar wrote: post #225
theteapot wrote: post #158

Earlier quoted context omitted.

> Most frameworks outside react still use templates. Even when they support JSX like syntax (aka vue 2.0) the default are templates. 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. I've gravitated away from React towards Vue v3. Templates are working fine, well even. You still use similar amount of Javascript (probably les…

>Weird. useEffect is like the archetypal hook. The problem it purportedly solves was one of the main arguments they made for hooks existing in the first place -- https://reactjs.org/docs/hooks-intro.html#motivation . They just implemented it in a clunky way, and actually the problem could have been solved in an OO fashion without going to hooks at all, but now everything is a fucking hook. There was (and still is) a…

You keep saying useEffect has problems but you never mention what those problems are.

Re: React is holding me hostage

#232

Post by pas »

thegeomaster wrote: post #175
pas wrote: post #163

Earlier quoted context omitted.

My reading is the opposite. Basically all real end-to-end UX (actual performance included) depends on a collaborative effort. Someone mentioned that React is slow, it might take 200ms to update many elements.... and? Unless someone is making a fast-paced interactive game of DOM elements, it doesn't matter. Structuring the UX in a user friendly way matters infinitely more.

Structuring the UX in a user friendly way matters more, that doesn't mean random 200ms lags are OK. As you said, performance is UX too. I hear normal, non-tech people with average hardware complain about "lagginess" of their machines all the time. And usually the only application they use is Chrome. They won't say that they had a 200ms lag when they clicked on a button, but the overall experience degrades when things…

Random 200ms lag is different than showing a new panel full of elements.

I'm aware of those complaints. 95% is when people are using a thermal throttled old device, while the app in question is trying to smoothly animate a complete clusterfuck of a webpage (for bonus points it's usually in some god-awful WebView in an app).

It's not simply displaying new checkboxes, inputs, labels, buttons, it's multi-megabyte images with fancy CSS effects and so on.

> They won't say that they had a 200ms lag when they clicked on a button, but the overall experience degrades when things are slow to respond.

Of course, no questions there! But it's not because the "framework is not performant enough", it would be slow even in vanilla JS in 95+ % of situations.

> And when you sit that person in front of a good, optimized, snappy application, they will sing praise.

Yes. And it's because you say to the client/designer/productperson that hey, if you want snappiness even for the 99th percentile of your users (ranked by hardware), then let's test on that device, and let's forego that nice animation that you saw in that native app on your friend's iPhone 15 ÜberMaxPro.

And, not surprisingly, many of the aforementioned culprits will say "I want that shiny thing"

> but our industry behaves like a bunch of babies.

I don't think you're harsh at all! And I agree. Many IT workplaces went all-in with the infantilism. (Daycare for autist-savants! Colorful open-office with a playroom, maybe even a ball pit! You can't concentrate today? Don't worry, just play some table tennis, and try it again tomorrow! -- Contrast this with the endless office gray cubicle farms of the engineering departments ~50 years ago. Which is probably the other extreme of the spectrum. And I believe there's a healthy middle ground. Well maybe slacking off on HN is not exactly part of it.)

> Yet the teams there collaborate just fine.

The games industry is famously not in a "fine" place, I'd say :) But yes, of course, they have a clear target, and even if the process requires some blood sacrifice for the crunch times, it works, sometimes. Sometimes we get buggy things like Cyberpunk 2077, which was less-than-optimized for some target platforms.

Re: React is holding me hostage

#233

Post by bayesian_horse »

azangru wrote: post #191
bayesian_horse wrote: post #180

Earlier quoted context omitted.

The performance "disadvantage" of react (compared to what? SolidJS? handcrafted JS? some WASM thing?) is so small a user won't notice it in most apps in most places even if you don't actually optimize things. Then indeed, abstractions a team can agree on matter more. Getting state management right matters. Hiring people and getting them productive quickly matters. Those are strong points in favor of React and even An…

> The performance "disadvantage" of react (compared to what? SolidJS? handcrafted JS? some WASM thing?) is so small a user won't notice it How can you know this? The only scientific way to approach this question is with real-user metrics and analytics.

Experience from using React for many years tells me. Rarely have I needed to optimize anything related to react to make something visibly snappier, and most of the time it's not really React's fault.

And there are some benchmarks that show SolidJS and some other things are faster than React at specifically what React is doing (like dom manipulation/reconciliation etc).

And yes, I'm talking broad strokes!

Re: React is holding me hostage

#234

Post by davidy123 »

unxdfa wrote: post #212
codeptualize wrote: post #183

Earlier quoted context omitted.

> 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?

Try selling React shit to corporates who have corporate malware infested Edge running on overloaded Citrix nodes or the average corporate android that was made about 3 years ago. We still get And we actually can debug our product!

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.

Re: React is holding me hostage

#235

Post by unxdfa »

davidy123 wrote: post #234
unxdfa wrote: post #212

Earlier quoted context omitted.

Try selling React shit to corporates who have corporate malware infested Edge running on overloaded Citrix nodes or the average corporate android that was made about 3 years ago. We still get And we actually can debug our product!

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've seen recently is my electricity company's meter reading facility which is an over-engineered react interface for a single web form with two fields and a confirmation box. The whole thing pulls 590k down to do that and takes 5 seconds for the initial page load on an M1 MacBook Pro. That's the real end game for most people. The only reason it's like that is because the people who built it don't know how to do it any other way.

And lets be honest about Microsoft: they do everything from a front end or user interface perspective and randomly discontinue bad ideas about 5 years down the line. Like Silverlight, most of WPF, bits of ATL and MFC, an entire mobile phone platform that got rewritten. And their competing framework WinUI 3 doesn't even work properly. Their own O365 web platform is a fine example of where this turns into a buggy mess. I bet react is dead to them within 2 years on one of their schizophrenic switcharoos. The only reason they're into it now is to capture some market from Electron.

Re: React is holding me hostage

#236

Post by scotty79 »

pcthrowaway wrote: post #126
mattigames wrote: post #84

Earlier quoted context omitted.

"Doesn't reinvent the wheel" they literally created a whole new language called JSX, I have 13 years writing JS and I dislike React and JSX is one of the reasons. As far I can tell reason it's picked a lot of times now it's market share, people see that is more popular than the competition so they try to learn it, creating a feedback loop that just makes it more popular.

I actually like JSX a lot, but I'm baffled when people act like the very thin DSL used by svelte is any more unapproachable than JSX, or like JSX is somehow more javascript when it's a mish-mash of extended HTML (don't forget to use key as needed, and className), React components, and JS (expressions only, not statements... and weird-looking ones at that)

I recoil from svelte and such because when I see someone trying to invent an ad hoc language inside html attributes I get flashbacks to "transcluding" "directives" of Angular 2.

Re: React is holding me hostage

#238

Post by scotty79 »

crooked-v wrote: post #215
pcthrowaway wrote: post #126

Earlier quoted context omitted.

I actually like JSX a lot, but I'm baffled when people act like the very thin DSL used by svelte is any more unapproachable than JSX, or like JSX is somehow more javascript when it's a mish-mash of extended HTML (don't forget to use key as needed, and className), React components, and JS (expressions only, not statements... and weird-looking ones at that)

> don't forget to use key as needed, and className Those are part of React, not JSX itself. Compare Vue's use of JSX, for example, which just uses `class` and `for` instead of `className` and `htmlFor`.

React just went for JS naming of the attributes instead of html naming of the attributes. Reasonable, if annoying, choice.

Re: React is holding me hostage

#239

Post by zelphirkalt »

djtango wrote: post #160
CharlieDigital wrote: post #25

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…

Admittedly I haven't worked on a large multi team react project before but I thought the whole point was that Facebook found React scaled well with teams (vs the state of the art at the time) Not only can you componentise your UI code, but you can componentise your UI system meaning teams can develop independently of each other...

That's not what I see and hear though. People complain often about how complex things become with React and simple things take a long time to set up or develop, compared to rendering a simple template on the server side.

Usually people are not FB and people often do not have the same kind of strict development rules or enforced discipline, nor are they as many people as FB. Maybe the FB tool is not right for them.

Re: React is holding me hostage

#240

Post by dagorenouf »

vouwfietsman wrote: post #222
Illniyar wrote: post #189

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…

Although I agree with the sentiment of your post, #1 is blatantly wrong. Most of my successful work has been specifically outperforming the competition in a way that makes users choose our product. Performance is an orthogonal feature that improves all other features, and even changes what your clients can do with your system, as in making new workflows viable.

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.
Post reply on HN