Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

there's other reasons for the vdom though.

vdom is necessary in react to abstract the view from the platform so it can be represented by react-dom and react-native[-x] bridges.




That has very little bearing on the web platform. I personally don't care for meta-platforms that abstract away the web.


It does have an impact on app development. I personally don't care for web-only libraries / frameworks.


I mean that's fine, but when mixed into a conversation on web standards and APIs it leads to a place where you don't care about any web-specific evolution including most progress on the DOM. You end up only caring about a future of WASM + WebGPU, etc. This is exactly where some of the original React core team said they wanted to go - they just wanted a network connected framebuffer.

Again, fine, but I personally prefer a vibrant web platform that evolves to meet the needs of web developers.


Don't get me wrong, I'm happy for the change. It will improve things overall, and more power to web-only implementations.

My only intent was to point out another function of the vdom being discussed.

For WASM+WebGPU, I doubt it will ever be up to the same accessibility and feel that react-native-web gives. Just look at Flutter.


I'm a web developer and the web api is bloated and ugly. React API is, or at least was, acceptable to work with.


You can still have a framework-specific render tree that maps to the DOM that tracks changes with signals instead of diffing. We’re just saying that there’s no requirement for diffing algorithms anymore to performantly and correctly reconcile state to the DOM. Keyed children was the last place it was needed.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: