371–380 of 574 posts
React's concurrency features should have been broken off into a separate, opt-in library, not packaged into React core, and they sealed their own coffin with this release. That said, suspense is awesome once it's fully understood. Give the public a few more years to get it, though.
I was using React earlier for many years, but nowadays Svelte and SvelteKit (file based routing). I feel I am more productive (might be an illusion), but at least I am less frustrated. More here: https://kit.svelte.dev/
Is Svelte still overly dependent on Rich Harris? He's great but that reliance put me off Svelte.
I must be the only person in the world who likes class components in React. Sure, it's often overkill and a functional component does the same thing with less code. Use a functional component in these cases. But if you're doing something more complicated then stop treating class components like the fucking devil. They have their place.
I think the problem is ES6 classes just aren't very flexible or expressive, compared to systems like Ruby, Smalltalk, or CLOS. For a lot of programmers, half-assed classes are worse than no classes, even when they can help with organizing state and behavior.
Earlier quoted context omitted.
Yeah, this feels like a weird oversight.
A bit weird, although it’s not clear how they would do it without class components. I guess it would probably look something like React.forwardRef.
It may be due to the codebase I'm working on, but I doubt it since I assume I have decent colleagues (I'm in a FAANG), but I just fucking hate React. I spent years working on Angular before changing team, and there everything makes sense instantly. It's just normal programming, normal MVC, normal everything, and you basically only need to learn about the syntaxic sugar for data-binding and stuff like this. In React i…
A lot of people really hated it but it's opinions and structure helped promote a more maintainable codebase. I don't miss tuning watchers and the digest cycle though.
All the React projects I've inherited are nightmares. I'm comfortable working on them but they are harder for junior and mid-levels to hop into.
The number of ways to do things in React is a benefit and a curse.
We had so much prop drilling early on. The idea that components should only have what they need is nice, but you need some data to flow to children. And when the UI needs to change on a prop drilled codebase, holy shit, refactoring is a major PITA.
Luckily we have some alternatives to avoid the prop drilling but it's so fragmented.
If something like Mobx was just part of React from the beginning, the ecosystem would be in better shape IMO.
I identify with a lot of the issues the author stated.
React is just at that place where you need a TON more discipline to produce quality code in a team environment.
And because of that, there will be a mountain of shitty codebases in React to inherit, cleanup and maintain over the next 5 years.
That being said, I'm still a big fan of React and Vue though.
How has nobody mentioned the insane complexity monster that is React 18 / Suspense?! I mean, it makes sense once you understand it, but who is going to understand it? React's concurrency features should have been broken off into a separate, opt-in library, not packaged into React core, and they sealed their own coffin with this release. That said, suspense is awesome once it's fully understood. Give the public a few…
Earlier quoted context omitted.
Step 1: The existing tooling is too clunky, big and a major PITA to work with, Developers spend most of their time fighting their framework and tooling to do simple things. Step 2: Someone gets fed up with this writes a framework that "does things right" and is designed for "simplicity" Step 3: People start loving the new tool because it is so much easier to work with. Step 4: People start to do things the tool wasn'…
I don't agree with you. I have been doing Rails development for past 10 years now and I never faced a dilemma where the framework took a direction which isn't aligned with its core vision. I have been just trying to find a similar tool for frontend where I don't have to keep rewriting the entire codebase.
Earlier quoted context omitted.
Could you say more about this? I'm not a React user, but to me one of the OO fundamentals is "object = behavior + state". What you're saying sounds so obviously correct to me that I guess there's something pretty weird going on in React-land?
React added "hooks" which are basically methods and properties implemented as FIFO queues instead of lookup tables, with terrible syntax that requires you to declare them inside their constructor (the "functional" component's... well, function). No, I'm not kidding. Unless something's fundamentally changed about the code since release, they even end up attached to an object representing the UI component, by the time…
When pressed about it, be ready to be hit with, "You don't understand hooks".
We tried to use other frameworks but finally came back to React for only one reason. It's easier to hire for React. The talent pool for React is almost 10 times that of other frameworks. And for now, this reason is good enough for us.
Vue is learnable in a single day. React is almost as easy to learn. Just hire React devs and give them a couple of days with Vue, no problem
In general Vue holds high conceptual similarity to React so React devs just "get it" straight away. However nearly everything is simpler / easier than it would be in React, so they learn it extremely fast.
Earlier quoted context omitted.
Eh, to some degree you do get a starting point in uni for various things. You’ll learn basic models for systems or databases as part of core requirements. If a web course exists, it’s most likely optional and out of date. Web is certainly a different context, and some people struggle to pick it up. There’s no authoritative book like the C Programming Language, and the web is full of wrong information that sometimes c…
> Web is certainly a different context I mean it's a thin or fat client talking to a fat or thin data source over a network. "We" have been building systems like that since the 1950's.
As a general example, part of why accessibility on the web is so poor is because we don't teach anything about it. It's become this mythical scary thing, when in reality a lot of the pain is avoidable with a little bit of thinking. We just don't teach any of it.