91–100 of 130 posts
The goal behind "hooks" was to make React simpler for beginners. I build client-side apps since 2007, and React is getting too magical and complex for even for me. The NextJS influence is really making things worse, "use server" "use client" tags do not scale at all. The project clearly lacks mission, goal, leadership and direction. I'll use Preact in the next projects.
For some reason, I see people in this thread whom I believe don't really understand why hooks were invented. Put simply, just like closures hold state in a function, hooks compartmentalize the component's lifecycle, they are basically `function(state, lifecycle)`. I linked to a Flutter thread elsewhere (on the topic of adding hook-like constructs to Flutter as well) that I've seen as one of the best examples of why c…
The goal behind "hooks" was to make React simpler for beginners. I build client-side apps since 2007, and React is getting too magical and complex for even for me. The NextJS influence is really making things worse, "use server" "use client" tags do not scale at all. The project clearly lacks mission, goal, leadership and direction. I'll use Preact in the next projects.
I feel embarrassed when some of the great back end / system programmers I work with have to go in the front end code base and write React. They can submit patches to linux source like it's nothing but understanding React is just too hard for them.
At least for now, I don't see any urgency to switch from React. There's more React developers than Vue, Angular, Svelte, htmx, and Solid combined. React is not quite as ergonomic as Vue or Svelte, but all are swiftly approaching feature parity.
Vue and Sevlte don't seem to represent a big enough boost in productivity to justify rewriting an entire generation of codebases.
A lot of throwaway accounts on here recommending people switch to vue in 2024. At least for now, I don't see any urgency to switch from React. There's more React developers than Vue, Angular, Svelte, htmx, and Solid combined. React is not quite as ergonomic as Vue or Svelte, but all are swiftly approaching feature parity. Vue and Sevlte don't seem to represent a big enough boost in productivity to justify rewriting a…
Anecdote, we switched to React Native from a thing called Nativescript, primarily motivated by the dwindling development and support, and the huge overhead that Nativescript brought.
But I have to hold my hand up and say I didn't like Angular and the redux-style beating around the bush either.
Lots of valid points about the increase in complexity for React over the years, and that one should pick another more modern tech stack (Svelte, Solid, html, whatever), and I used to be thinking like that But since maybe 1-2 years, I am back and betting on React for most of my serious projects (for the ecosystem, the ease of hiring, etc), but the most important point is the following: React backwards compatibility is…
So, your team upgraded to React 18 without having to rewrite anything?
The goal behind "hooks" was to make React simpler for beginners. I build client-side apps since 2007, and React is getting too magical and complex for even for me. The NextJS influence is really making things worse, "use server" "use client" tags do not scale at all. The project clearly lacks mission, goal, leadership and direction. I'll use Preact in the next projects.
I feel embarrassed when some of the great back end / system programmers I work with have to go in the front end code base and write React. They can submit patches to linux source like it's nothing but understanding React is just too hard for them.
It's a different domain with a different skillset.
At this point people should already be looking to move away from react to something better like svelte, Vue, htmx. Why anyone would start a project with react in 2024 be beyond me.
Earlier quoted context omitted.
The problem is a library changing language semantics mostly as a consequence of their own earlier design decisions. So I can totally explain someone how there is no pass-by-reference in Go, and I can also explain why equal sets of different identity are not really equal in JS (following the records proposal, with my fingers crossed, and happy with it because it's a language change), but when libraries introduce diffe…
Evan You (Vue author) had a great quote about this: A mutable model that you can reliably understand is better than an immutable one that leaks. The pain and suffer of hooks all roots from the mismatch between a dogmatic belief in the superiority of immutability and the harsh reality of the host language that is JavaScript. React's render cycle is fundamentally mis-aligned with JavaScript since the re-render requires…
The key is to write your own hooks specialized for the project, then the complexity is isolated into one place where you are expecting it, instead of dispersed across your project. If you are trying to write everything using the built-in hooks then you’re going to have a bad time.
Earlier quoted context omitted.
I feel embarrassed when some of the great back end / system programmers I work with have to go in the front end code base and write React. They can submit patches to linux source like it's nothing but understanding React is just too hard for them.
I'm confused why you feel embarrassed? Do you think they feel embarrassed that you can write React yet don't know how to write patches for the Linux kernel? It's a different domain with a different skillset.