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

461–470 of 553 posts

Re: React is holding me hostage

#461

Post by creamyhorror »

_v7gu wrote: post #99
petilon wrote: post #70

Earlier quoted context omitted.

None of that is true in React hooks. The negative sentiment towards hooks that you see here is because it is weird and complicated. Want to see how much simpler code can get when you code without React or any such fat frameworks? Take a look: https://github.com/wisercoder/eureka/tree/master/webapp/Clie... You just need to know JavaScript, HTML and CSS, not much else. The code is simple, and yet maintainable. No need…

How can you ever be sure that your state is valid when you’re putting it on the DOM? Worse yet, only parts of the state is stored there. I can’t really call this code simple since it had to resort to timing hacks to get its functionality in order. A random 250ms delay and bam, bugs you cannot reliably reproduce

I'm not sure what timing hacks you're referring to - using setTimeout() with 0 delay? I think that's being done to defer execution of heavier functions and let other timeouts be handled first. Seems more like an optimisation rather than a hack to achieve basic functionality.

Re: React is holding me hostage

#462

Post by sli »

mattigames wrote: post #387
bern4444 wrote: post #95

Earlier quoted context omitted.

JSX has been around for 7 or so years... that's a good amount of time. Over half of your 13 years :) Do you avoid JSX when using Vue or other libraries that support JSX? Are you invoking the library function directly - React.createElement or vue's equivalent instead?

Yes I do, the only language I use for my personal projects is Typescript; I think JSX, .vue, .svelte they are all a mistake, JS is more than enough if you really need to use it to compose html. div('#wrapper', div('.container', span('.big', `It's not that hard`), button('.red', {route: home}, 'Home!') ) )

You should give Clojurescript a serious look. You can use that approach, but the resulting code is... well, readable.

Re: React is holding me hostage

#463

Post by sli »

mattigames wrote: post #449
crooked-v wrote: post #213

Earlier quoted context omitted.

JSX isn't a new language, it's syntactic sugar for React.createElement() or whatever other pragma you prefer (like the Preact or Vue equivalents).

Call it what you want, still is the worst kind of syntatic sugar, the one that forces me to use a transpiler but its full of footguns, like being unable to use "class" for the "class" attribute and I have to use className instead, or the one that has no syntax sugar for conditionals so instead you write horrible stuff like {isValid && isApproved && foobar && ...}

If you're going to call something a footgun, make sure it's an actual footgun and not simply using a different naming convention than the one you want. You want the HTML name while React uses the Javascript name.

https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelEl...

Re: React is holding me hostage

#464

Post by 0xblinq »

dagorenouf wrote: post #240
vouwfietsman wrote: post #222

Earlier quoted context omitted.

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.

That’s just your gut feeling, not what actual data shows.

Re: React is holding me hostage

#465

Post by 0xblinq »

Izkata wrote: post #227
thegeomaster wrote: post #141

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…

> issues where a bigger update, such as switching from one panel to another, takes upwards of 200ms on a mid- or low-range machine. We have a React+Redux search page where clicking checkboxes takes about that long to update the checkbox, on our good developer machines. I won't rule out we did something wrong (this page was pretty early in our React understanding), but we've also not managed to fix it due to how much…

I once worked for a pretty big and popular ticket selling company where you couldn’t type your credit card number too fast because it would miss numbers.

It was all redux’s magic and simplicity was making almost the entire thing rerender on every keystroke. Of course it was the developers fault, but it’s so easy to end in that situation that I blame the tools because to me when you shoot yourself in the foot that many times you start to ask yourself if what you have is a footgun.

Re: React is holding me hostage

#466

Post by 0xblinq »

codeptualize wrote: post #183
thegeomaster wrote: post #141

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?

Just go and use the “new” Reddit. Take any metric you want from there.

Re: React is holding me hostage

#467

Post by 0xblinq »

simmerup wrote: post #151
bayesian_horse wrote: post #147

Earlier quoted context omitted.

"Performance" matters a lot less than many other things like collaborating with other people, or getting the DOM manipulation right.

I read this sentiment as basically saying the users experience of the app matters less than the experience of the dev who works on it.

Well, for the dev (for many of them) that’s how it is. As long as my tools are shiny, f*k the users.

Re: React is holding me hostage

#468

Post by sa46 »

NayamAmarshe wrote: post #440
aelzeiny wrote: post #399

Earlier quoted context omitted.

> Don't use those...then an additional 4.9% can be handled with jotai... Needing Jotai on top of React's defacto state management is the issue. TFA talks about an ecosystem of libraries that attempt to fix React's shortcomings. Pure React does have undeniable shortcomings like proper, non-brittle routing.

Jotai is literally like a single file. Here's a video on how to use Jotai by writing your own in minutes: https://youtu.be/gg31JTZmFUw

Jotai may be small and focused, but is definitely not a single file: https://github.com/pmndrs/jotai/tree/main/src/

Re: React is holding me hostage

#469

Post by MrJohz »

ihateolives wrote: post #398
bernawil wrote: post #381

Earlier quoted context omitted.

People laugh at web development, especially the frontend, for changing libraries every week that's a 2016 meme. Things have been remarkable stable since.

Except React decided to change to hooks and break all their docs. And Vue decided to break things with ver 3. And then there's Next. No, Nuxt. Wait, no, it's Nest. Or Sveltekit. It's not frontend anymore, it's more like frontend on backend, but not quite. No, is both now, we got interactive islands. And web components. Oh and wasm. Or was it blazor? And we have webpack. No, Vite. Or Parcel? Almost forgot, it's esbuil…

I mean, that's just a laundry list of buzzwords. Yes, these are all things that exist, but that doesn't mean anyone has to learn them or that they're even used in a significant number of real-world codebases. It's like complaining about web development in Python, because there was Django, then Flask, Bottle, CherryPy, and now FastAPI, or Starlette, or Starlite, and Pydantic or attrs or dataclasses or whatever else. In practice, there are some fairly clear ecosystem best practices for the majority of cases, and a bunch of different alternatives because every ecosystem loves trying out different ways of doing things.

Re: React is holding me hostage

#470

Post by ojkelly »

dsego wrote: post #230
ojkelly wrote: post #67

Earlier quoted context omitted.

You can build serious UI’s without useEffect. But it’s a powerful escape hatch like rust’s `unsafe` block. Rust can do amazing things to ensure safety of your program, but there’s still times where a human can do it better. By signposting that, keeping it to limited blocks, and wrapping it up in a safe function you get the capability to do hard things, while exposing a safer API. useEffect is similar, it lets you wri…

It's still using the useEffect hook, but just wrapped in a useFetch or something. So technically you're not building a UI without useEffect, just hiding it, no?

How far down the rabbit hole do we need to go?

Because at some point your function call is manipulating registers on the CPU. If we go even further, the CPU needs to load its next instructions and then the data required.

Point being, we abstract and encapsulate complexity and provide a simpler API around it. It’s the only feasible way to manage the inherent complexity.

React builds up a virtual description of UI. react-dom and react native take that description and synchronise it to the UI layer.

If you need to do something extra, that they don’t handle like managing a map widget (ie mapbox) in React that only has an imperative API, it sure would be nice to do that yourself.

You can build a UI without useEffect. You can hide messy implementation details inside a well tested component, and contain where useEffect is being used.

And, you can understand how useEffect works so that you can use it without it having a negative effect on you.

Post reply on HN