5 ms·
If your web-app has even a modicum of complexity on the client side, the vanilla DOM based solution is going to get unwieldy real fast. Consider a simple list
by jasim 10y ago
If your web-app has even a modicum of complexity on the client side, the vanilla DOM based solution is going to get unwieldy real fast.
Consider a simple list of elements to which you can add or delete items. With vanilla DOM, you’ll have to write handlers that will `$.find` the particular element, and then run a `$.remove` to remove it. To insert something, you’ll have to do a manual `$.appendHTML`. And when you have to send the data over to the server, you have to iterate over the elements, collect it into an array and send it across. But if you used something that had an explicit notion of the application state, and allowed you to express your view as a simple function of your state, all you would have to write is an `array.push` and another `_.remove(array)`. The view will update automatically because we’ve already told the 'over-engineered' framework what to render for any given state.
But you could avoid framework and still not fall prey to spaghetti DOM manipulation. All you need is to keep an explicit state variable and have a single `render` function to deal with the DOM. This method will be invoked everytime you change your state, and it'll recreates the necessary DOM from scratch. It is a simple straight-forward implementation, but now you're going to lose cursor position, and with large enough DOM trees, the lag will be noticeable.
To fix this, you can add a virtual-dom implementation that'll maintain the DOM tree in memory and avoid re-rendering things that haven't changed.. and then you can have some sort of immutability checker to skip even the virtual-dom rendering part. And by now you have a home-brewed over-engineered React-like framework, but without any of its documentation or robustness or community.
We definitely need to be conservative in our choice of tools, but React today is a conservative choice to build rich front-end web applications. More than a framework, it is an approach to user interfaces, and it is a damn good one too.
- DenisM 10y agoTo be fair diffing virtual dom is not the only way - you could also be diffing the model and only update the parts which need it. Knowing the model well allows you write an efficient diff. The problem of course is that dom diff is universal while model diff is specific to application.
- lukaszkups 10y agoor operate on document fragments
- olavgg 10y agoNo adding/removing/modifying elements in a list is very simple and fast, even with thousands of elements. Example: https://pastebin.com/Fu39i47z https://pastebin.com/Fu39i47z
- csallen 10y agojasim isn't complaining about performance, but about the complexity of the code.
- valarauca1 10y agoParent's paste bin is ~40 lines of code (with white space) consisting of 4 functions, with what? 4 loops. If you consider 40LOC complex I don't understand why you work as a dev.
- jasim 10y ago> If you consider 40LOC complex I don't understand why you work as a dev. Goodness, your snark that questions the parent's competence is not only unwarranted, it is based on an incomplete understanding of the value of abstractions in programming. It is not about 40 lines of code, it is about a basic programming model that allows us to understand and create user interfaces irrespective of how complex or large it is. It lets you compose your UI based on a tree of state and pure functions. If you don't have this abstraction, you do not have a coherent programming model to build UIs.
- drdaeman 10y agoActually, I wonder if there's something out there that has all the declarative state-to-DOM manipulation goodness, but does this at build time. React is a runtime that works on the client, and its compile-time stuff is just syntax sugar (JSX) and some minor optimizations. As I understand, this runtime is the complexity that some complain about. At least I perceive this as a downside. If there's something that can, given a component definition, generate those sets of add/update/remove functions and appropriate calls on state updates (preferably, as human-readable as possible) - I think that would be interesting to see and compare. (I hope no one normally dynamically mutates their components at runtime?)