Live data from Hacker News

React is holding me hostage

emnudge.dev

301–310 of 553 posts

Re: React is holding me hostage

#301

Earlier quoted context omitted.

Vue is more akin to the old way of doing things with static templates (Jinja, Mustache, Erb, PHP), just with a dynamic twist. React is not perfect, it's bloated, but the reason it took off is that it brought something new to the table as a general and programmatic way to construct UIs. Being a child of Facebook helped it achieve dominance but considering that before React we had angular (shudder) and jquery, React's…

Not sure if you've worked with Vue 3's "composition API", but it is very different from Vue 2's "options API". The composition API is bliss. What's more important with Vue and fine-grained reactivity is that it is very forgiving of mistakes and poor practices that in React would cause much more significant side effects and performance issues.

Vue in general has been a godsend to me at least. When I was in college, we used AngularJS for web development courses at the time. My first job had me working with Qt and Tkinter. When I finally had the chance to do web development again, my team chose Vue and it was so easy to pick up from my AngularJS background.

My current team is using Vue 3 with the Composition API and it is way more forgiving with mistakes than the Options API. I've helped transition 3 developers so far to Vue 3 and they all love what Vue has to offer when compared to React.

Re: React is holding me hostage

#302

Earlier quoted context omitted.

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

Sorry. The biggest problem is that useEffect's mental model is based on data change and not on events.

So instead of "do something when this action/event happens" we get "do something when this data changes". Which ends up being abused a lot, as developers who aren't familiar with this mental model (which is most of them), tend to lump up every action into a data change.

So instead of something like (contrived example):

  openAlert() {
    alert("I'm an alert");
  }
  return 
people do:

  const [alertOpen,setAlertOpen] = useState(false);
  useEffect(()=>{
    if (alertOpen){
      alert("I'm an alert");
    }
    return ()=>setAlertOpen(false); //if they even remember to unregister
  },[alertOpen])

  return 
Beyond that there are multiple other problems:

- the fact that useEffect (and hooks in general) is order dependent and can't be put inside branching (so I can't start an affect after an event happens).

- the fact that inside useEffect you read the data of the previous render is very unintuitive (I.E. your data is stale).

- the need to always put all your dependencies that are used inside useEffect in the dependency array explicitly - which can be even harder when dependencies are dynamic - is also a problem for many.

There's probably a few more, but that off the top of my mind.

The fact that there needs to be several eslint rules in order for people to not footgun themselves constantly is quite a red flag on it's own.

Re: React is holding me hostage

#303
post #192

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…

> 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 then I would always expect that to cascade down the node tree. That could cause further updates. And more renders. That behavior is on me. If the framework decided not to cascade some updates that would be weird. It's not that the properties shouldn't be update…

I really appreciate your optimism about switching to a different framework/ etc. and I would have felt the same earlier in my career where I didn't have so many non work commitments, financial and otherwise. But to me now this reads as wishful thinking; switching track is difficult, especially when your existing skill set represents a large chunk of the demand in the marketplace. (And I say this having recently sucessfully made the switch from React to Svelte)

No doubt there are individuals with circumstances that make switching tech stack harder due to the demands on their time elsewhere, and I feel for those devs being stuck on a stack they don't enjoy (I was a PHP dev for a decade, I understand their pain). But I also think that those problems are temporary. You might be stuck on something for a few years, but in the grand plan that is your career spending even a couple of hours a week to move to something that you don't hate is worthwhile.

It'd be awesome if everyone who dislikes React could spend a month immediately learning Svelte or Solid, or Kotlin or Swift, but that's obviously not possible. All I'm saying is that if you're not doing anything to change your future then you should seriously consider if the problem is as bad as you might say it is.

Re: React is holding me hostage

#304

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 v…

You say you detest hooks, but didn't elaborate why. Can you explain more? Is it just a preference for the class-based model of overriding lifecycle methods?

I don't know about the GP, but hooks are fundamentally an attempt to stick a state managing effects system into a language that is designed to use objects to manage state. This gives you something approximating the worst of both worlds - your 'functional' components are not pure, and the effect management system is something you have to deeply understand to use correctly, but it clashes with the rest of the language.

Re: React is holding me hostage

#305

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?

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.

I've been involved in quite a lot of usability testing and I'm often positively surprised by the responses. Which is why I'm sort of skeptical when reading such claims. Also because I think user experience overall has improved, by a lot, the standards now are so much higher than the used to be.

I think it almost always comes down to one thing: Can people achieve the thing they want to achieve in a somewhat efficient way?

If the answer is yes there is lots of tolerance for all sorts of crap before people experience it in a negative way.

That means managing the experience. As example a multi minute upload process can be totally fine if handled properly, a .5s delay on an input can make it unusable. My point being; reality is a lot more nuanced than the blanket "it all sucks, and performance is everything" statement, and personally I don't think it's helpful. Unless we can actually look at metrics and assess their importance and how we can address them.

Don't get me wrong; we should absolutely keep trying to improve, especially crafting well made usable interfaces that are a delight to use. Performance is certainly very important, but it's not the be all end all of user experience and atm wrongly used to justify silly points why [my fav framework] is so much better than React.

Re: React is holding me hostage

#306

Earlier quoted context omitted.

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

> Having users is a path to monetisation but having a high performant app no one uses is not. These two things are also not the same. You start with "having users" and assume they're willing to pay and will stick around. You compare that to "having a high performance app no one uses" - explicitly limiting the scenario with an unrelated caveat that no one uses it. A better comparison would look only at having users vs…

Friend, your nitpicks here are of something I didn’t say.

I said explicitly “path to monetisation” not “assume they’ll pay and stick around”.

I hope you’ll agree that it’s easier to find a subset of users that will pay when your superset of all users is large vs a super(?)set of zero.

Re: React is holding me hostage

#307

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…

[dead]

Re: React is holding me hostage

#308
post #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,…

The way I look at it - the majority of value with blogs and static website is content. Hence the majority of change is of content.

For apps the majority of value is functionality and that's where a lot of changes happen.

The main problem of maintenance happens where there is the most change - in JSX programming (I.E. functionality) is a first class citizen and it lends it easier to change. With templates content is much more of a first-class citizen.

Of course this is all in the margins, you can write blogs/static sites well in react and applications well in template-based languages. The tradeoffs are just a bit skewed in favor of each, and it mostly manifests when you don't have time to be disciplined about changes.

Re: React is holding me hostage

#309

Earlier quoted context omitted.

Your dislike for ‘templates’ is much more a matter of personal preference than you’re letting on. Using language like “still using templates” makes me think that you don’t see any valid opposing view. I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have. But framing non-JSX approaches as objectively inferior is not in tune with the reality, being that this is something sensible peo…

> Templates are a no go for me It’s pretty hard to get more “this is my opinion rather than a statement of objective fact” than this. > I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have. Ok. Um… well, it’s hard to have a discussion if you won’t talk about it… …but, “code” templates allow autocomplete and type checking in a way that is an objectively distinctive superset of text…

Strongly agree. I just don’t get the hate for JSX.

JSX is objectively better than than the scores of custom DSL templating systems out there. If anything, I think JSX is not used and supported enough.

In the most general sense, JSX is just syntactic sugar for function composition. That it works well for html components is a side effect; it could certainly be used for more than that.

I

Re: React is holding me hostage

#310

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…

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

I dislike when JSX is framed as "just Javascript". It's really not - it's a templating language, just a very odd one - like its spiritual predecessor.

Personally I find JSX to be write-only and hard to reason about when looking at someone else's code.

Post reply on HN