3 ms·
Am I the only one who couldn't connect this to "making things move in a web browser" for a minute? It wasn't until I saw the pseudo-HTML (JSX) code that it clic
by daliwali 11y ago
Am I the only one who couldn't connect this to "making things move in a web browser" for a minute? It wasn't until I saw the pseudo-HTML (JSX) code that it clicked. Even the headline is full of jargon.
Seems that everyone is busy coming up with convoluted ways to do the same old thing (manipulating the DOM). When I look at early jQuery era front-end code, it's quite easy to follow what's going on. The language (ES3) was simpler, and the competing libraries at the time provided thin abstractions on top of the DOM API.
The DOM was more or less complete when DOM Level 3 was specified in 2004. How much of the front-end code being written now, will be able to be easily understood and maintained in ten years time, after the trendy fads have come and gone? Maybe that question is irrelevant since most business fail within that timeframe, but for posterity's sake, I'd like to look back and learn what went well and what went horribly wrong.
- _pmf_ 11y ago> How much of the front-end code being written now, will be able to be easily understood and maintained in ten years time, after the trendy fads have come and gone? Eventually, the kind of virtual DOM will move to either some standard API (via a way of committing changes in a transactional manner) or into the next iteration of the DOM API itself, so yes, none of the VDOM libraries will survive the next 5 years. For now, VDOM libraries are a necessary evil, not some revolutionary concept like many people seem to try to make us believe.
- daliwali 11y agoActually it's quite faster to call the DOM API directly, even if the VDOM abstraction is very sophisticated it's still overhead. Facebook has convinced people that it's a necessary evil when it's not. It doesn't even make sense to standardize VDOM since it's just an implementation detail.