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

481–490 of 553 posts

Re: React is holding me hostage

#481

Post by iudqnolq »

giovannibonetti wrote: post #332

One alternative is the Model-View-Update framework developed in the Elm language [1]. A few years ago, it influenced Redux [2], but JS doesn't have good ergonomics to support it, so people complained it was too verbose. Anyway, I brought Elm to the company I worked at two jobs ago, and it worked very well, since it is conceptually very simple. The experienced developers loved its explicitness, which made it possible…

I'd love to use Elm, but I'm completely uninterested in building off something where low-level hacks are impossible.

For example, I recently wrote a react component that diffs it's new state against the previous state and then calls an imperative map API to bring it into alignment. Ideal, no. But I'm not going to wait for the compiler devs to do something perfect before I write this app.

Re: React is holding me hostage

#482

Post by colin_jack »

Illniyar wrote: post #189
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…

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…

Not sure this is true. The following post has issues but I do find sense its argument that the result of what you are saying has been accelerated shrinkage of the mobile web as businesses increasingly use apps instead.

https://infrequently.org/2023/02/the-market-for-lemons/#shri...

Re: React is holding me hostage

#483

Post by hbrn »

MrJohz wrote: post #382
philliphaydon wrote: post #356

Earlier quoted context omitted.

JSX forces you into small tiny components because anything of any decent size becomes unmanageable. There's way too much mixing of JS into the template. Vue you can do Submit In React I've seen people do: if (!props.isFormValid) { return Submit ; } return Submit ; This is just an example, obviously you can write this better in React. My point is there's /always/ so much conditional markup like this in every react pro…

> JSX forces you into small tiny components I'm surprised you see that as a disadvantage, for me that's always the biggest advantage of JSX-style syntax! I don't want huge components that do everything, I want components to do as little as necessary to be actually useful. It's the same as if I were writing functions: keep them fairly small, make sure they're doing a specific thing usefully, and then compose them toge…

> I don't want huge components that do everything, I want components to do as little as necessary to be actually useful

Having lots of tiny components makes it harder to see the big picture.

Too big and too small are both bad, there's a balance you need to find. Components should be small enough to fit in your head, big enough to represent ideas. The difference is that it's natural for big components to be broken down into smaller ones when their size starts to cause pain. But nobody goes around merging smaller components into bigger ones to make them more readable. When your components are too tiny people just suffer through the pain and develop Stockholm syndrome.

> I'd try and fit more and more stuff into a single component until it the pain of maintaining it was greater than the pain of splitting it

I understand that it seems painful, but this is actually a great workflow: it forces the decision to split to be based on the real pain, not on your fantasies about future pain. Pain is a tool that helps you make good decisions. In that sense React is like Perl: easier to write, harder to reason about.

Re: React is holding me hostage

#484

Post by ZvG_Bonjwa »

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 think you've accidentally proven his point. Half the things you've mentioned have been around for half a decade at this point, and pretty much all of them have existed for at least 2+ years.

Frontend is still a fast moving space with a large ecosystem - and I get for some, that's not ideal. But this 'frontend fads' meme isn't really reflective of the current reality.

Webpack - 2012, Next - 2016, Nuxt - 2016, Nest - 2017, Parcel - 2018, Blazor - 2018, React Hooks - 2019, Vite - 2020, Vue 3 - 2020, ESBuild - 2020, Sveltekit - 2020

Re: React is holding me hostage

#485

Post by mattigames »

sli wrote: post #463
mattigames wrote: post #449

Earlier quoted context omitted.

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

It is a foogun because is only for a few specificic attributes (class) that it uses this specific convention, for other attributes it uses the normal HTML attributes, for example in JavaScript to add aria labels you do stuff like "ariaLabel" when using react you have to write "aria-label" instead.

Re: React is holding me hostage

#486

Post by mattigames »

scotty79 wrote: post #238
crooked-v wrote: post #215

Earlier quoted context omitted.

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

False, for a lot of attributes you have to use the HTML naming of the attributes, so is not consistent, for example to use aria-label you have to write it exactly like that (not ariaLabel as when using JS)

Re: React is holding me hostage

#487

Post by mbrochh »

I don't know. The guy just doesn't like hooks? I think hooks are absolutely amazing. I'm in charge of a very large codebase. We are currently migrating it from CRA to Remix, about 40% done. When I compare my Remix code with the old code, it's EVEN BETTER than the old stuff. Despite the gigantic codebase, I am always able to figure out what is going on (thanks to hooks, just read the function from top to bottom), where the data comes from, where it goes to. It's just all around a good developer experience. I have a feeling this guy just yearns back to simpler days where websites where static HTML & CSS.

I have also been able to consistently hire absolute greenhorns right out of tech bootcamps with zero formal computer science training and they were able to build features that made our company real money and push to production within the first two weeks. React can't be that bad.

Now that we threw out react-hook-forms (Remix does it all fine with default form APIs), Apollo (don't need their caching any more, so just sending plain GQL requests via fetch does the job), Redux (Context API is just fine), emotion (TailwindCSS is so so so so so much better)... our Remix codebase is basically pure HTML and Tailwind's css classes. It's a bliss.

Re: React is holding me hostage

#488

Post by happytoexplain »

blahblah1234567 wrote: post #412
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." Hyperbole. Web apps would not be so ubiquitous and popular for solving business problems if your claim was true.

It's not hyperbole, IMO, and this format of rationale is faulty. There are many reasons why technologies and platforms become ubiquitous. Asserting that being ubiquitous means it can't also be miserable for the user is demonstrably false, with almost unlimited examples throughout software history.

Re: React is holding me hostage

#489

Post by josephg »

eastbound wrote: post #431
gurraman wrote: post #190

Earlier quoted context omitted.

Same. We've been working on a huge React project for several years. Lots of graphs, 3d models etc ... and it is super-snappy. Only slow part is a WebGL-based chart component that visualizes 2-3 M rows of signal data. We can probably decimate the signal data to improve performance, but that has got nothing to do with us using React. N.B. No one is using the app from their mobiles. iPad and computers only. Our reasons…

Modularization. With React, you can delegate a component to one team and use it as a web-component. Actually, why aren’t web-components a thing, that’s another story. But componentization is why React creates clean code.

Huh? All of the modern web frameworks let you delegate a component to a team and use it. What does react do here thats special?

Honestly, if anything I find react's modularity story much weaker than the competition. In react there's no page-wide state and the story around styling components with CSS is a huge mess.

In comparison, Svelte components feel much more modular & self contained because the styles are embedded with the component in a standard way.

Re: React is holding me hostage

#490

Post by josephg »

unxdfa wrote: post #455
adql wrote: post #368

Earlier quoted context omitted.

Both Discord and MS Teams use React (afaik) and only one of them runs shit. Both are not exactly light tho

Both of them run like shit in my experience. I mean Discord is basically mIRC that looks a bit better with a shit version of zoom strapped on the side.

Yeah; and mIRC opened faster in 1997 than discord does today on a $3000 M1 mac.
Post reply on HN