3 ms·
I thought this was well known years ago. A better description for VDOM should be 'It's not fast, and is not slow either'. But frankly, what I see in virtual DO
by namelosw 7y ago
I thought this was well known years ago. A better description for VDOM should be 'It's not fast, and is not slow either'.
But frankly, what I see in virtual DOM is not about speed. It's a declarative interface, an abstraction. It's more like a blueprint that's easier to interpret across different environments like React Native, WebGL. Even if you don't need any of these cross-platform benefits it's still good for testing -- without real DOM.
As for performance, it could be an aspect of advertising but I doubt it really matters anymore.
I saw many applications where AngularJS is too slow, and I even worked on one for quite a while -- it's just a fairly typical 'enterprise application'. But I still yet to see a real-world front-end project where React is too slow.
Users won't even care about if it is 10ms or 30ms.
- Rusky 7y agoThe point of the article is that you can get that same declarative interface at much lower cost, with a more efficient implementation.
- namelosw 7y agoI'm not sure if it's still an 'interface' since it's compiling another language to imperative code which operates DOM API. So it requires other platforms implements a similar imperative API surface as DOM.
- awesomepeter 7y agoWhich is the same thing that a virtual DOM does, it also has to have an adapter(react-dom in Reacts case) which applies the VDOM to the real DOM via it's imperative API.
- Bahamut 7y agoI work on one with React that is too slow in the browser with a team that only has senior devs, and users even filed bugs about the performance - we do heavy computations, and React's model of blocking rendering on having everything updated can freeze our UI for up to 10s while data comes in from various API requests. I believe our app would be performing much better for the end user if we were using Angular 2+ interestingly enough due to its built in incremental updating - there would be other tradeoffs though. Part of the problem is not having good enough APIs currently (we have to make too many API requests and data payloads are too fat, sometimes up to 2 MB per request), but imperfect APIs tend to be the case in a lot of apps early in their lifecycle. I've actually been a bit disappointed in React's performance from a UX perspective.
- charrondev 7y agoThis seems almost entirely unrelated yYou framework though. You are blocking rendering on IO. This can be greatly improved by offering - Good loading indicators that stay consistent for related IO. - Caching to speed up or remove the need for requests. - Fetching related data in parallel. - Prefetching data.
- jasonshaev 7y agoI don't understand what this has to do with React. You are sending 2MB of data to the frontend. Can you paginate it? Request a subset? If you are fetching data from multiple endpoints and waiting to render anything until ALL of them come back, that has nothing to do with React. You can start rendering the components that already have their data as soon as it comes back, not wait for all of the other components to have fetched.