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

You can divide your page into multiple components, then to update the screen replace the components that contain stale data. You do not have to deal with elements--you only have to deal with components.

Regardless of which library you use there is nothing preventing you from injecting DOM elements from everywhere. Only discipline can prevent that.




I guess I fail to see the value of this. If you don't want the component lifecycle, event system, or DOM diffing that React gives you, you might as well just write your own declarative wrapper around `document.createElement(...)` and be done with it. You can achieve this for templating alone in < 10 lines of code, and if you want to add some event delegating on top of it you can include that for another ~30.


Right - DOM diffing is the key selling point of React. But the fine-grained screen updates possible via DOM diffing is not super important for most applications.

Event system is already supported by DOM. React doesn't add anything there. Component lifecycle is also not compelling.


That's kind of what I'm saying. If you don't value those things, why introduce a library at all? What you're describing can be implemented in < 10 lines.


More like 200 lines, so it is useful to have a library. BTW it is rare to hear component lifecycle and event system described as key selling points of React. Most people would say DOM diffing and perf are the key selling points.


The point of React is to make it practical to structure view logic as a function (projection) of the application state. Virtual DOM is just an implementation detail.


By the way, for the most minimal diffing implementation see https://github.com/patrick-steele-idem/morphdom.


I lied. More like 5 lines. http://codepen.io/anon/pen/MbjLMB


Right, but the point is that React is disciplined for you. You never do any manual HTML manipulation so you don't have to worry about injection issues.


You don't do manual HTML manipulation with this lib either. You can just see your page as being composed of components and replace components in order to update screen.


So, you're still controlling what is updated and when, with the same potential for making mistakes that you'd get in direct DOM manipulation.

React doesn't require you to ever manually replace a component - that's why the two are not comparable.


I am not familiar with the type of mistakes you are talking about. I have used both React and UIBuilder and find them to be comparable. Would you be willing to share an example of the type of mistake that developers frequently make?




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: