4 ms·
Most web developers are probably not particularly concerned about how fast their code is in relative terms. There’s a huge amount of room for UI library benchma
by baddox 6y ago
Most web developers are probably not particularly concerned about how fast their code is in relative terms. There’s a huge amount of room for UI library benchmark competitions that all lie easily within “good enough for the user.”
It’s also important to note that the virtual DOM isn’t just (or perhaps even primarily) about performance. It’s also about maintaining DOM state across updates, like focus, cursors in text inputs, etc. Modern browsers on modern devices are fast enough that for many web apps you probably actually could just document.write the entire DOM from scratch on every component state update if you didn’t care about that DOM state.
- jsf01 6y agoMost web developers should be more concerned with performance than they are. In the wild, on a fairly recent MacBook Pro, I frequently run into sites where I deal with 100ms+ input lag. And every time I check, it’s always React (sometimes Angular) under the hood. These are sites with great dev teams too. Stripe, Airbnb, Squarespace to name a few, suffer from severe performance problems on modern hardware. And those issues stem more from the diffing and reconciling stages than the actual DOM itself, whose updates are minimal for things like entering text into an input.
- onion2k 6y agoAnd every time I check, it’s always React (sometimes Angular) under the hood. What is it when the app is fast? It's probably React or Angular. Those are just the most popular frameworks, so when you look you'll probably see one of them. In good hands they can make fast apps. In poor hands they can make slow apps. Those frameworks aren't the problem.
- ng12 6y ago> And those issues stem more from the diffing and reconciling stages than the actual DOM itself I don't see how you could know that without reading the code.
- jsf01 6y agoBecause the only update occurring is the changing of text in an input. Yet due to how React works it’s diffing a much larger tree.
- ng12 6y agoThe diffing is very fast. It would take a ridiculously large tree to start running up against the limits of v8.
- baddox 6y agoAre you sure there isn’t a slow server request happening before the UI update? I would be very surprised that you’re regularly encountering web sites with noticeably slow React reconciliation. It’s difficult to make that slow.
- baddox 6y agoI agree with that, but I highly doubt that many web sites with performance problems can attribute those problems to React or whatever UI library they’re using. The reason that you see React or Angular when you check under the hood is that those are extremely popular UI libraries.
- ng12 6y ago> Most web developers are probably not particularly concerned about how fast their code is in relative terms. Absolutely. As long as our app performs without any input lag on IE11 I'm happy. Our users don't care and our higher-ups don't care either. They care that we built out new features quickly and have a better user experience than our competitors. If React lets us trade some minor rendering performance for better developer productivity it's doing it's job.