> Javascript =/= the DOM My post was explicit in the fact that this was my frontend JavaScript path. I don't think they are DOM abstraction, rather they are "

> Javascript =/= the DOM My post was explicit in the fact that this was my frontend JavaScript path. I don't think they are DOM abstraction, rather they are "update abstractions", as all the data binding, two way bindings, (whatever way binding a future library might call it) is there to observe X, update piece of html fragment Y with X. The vanilla JavaScript idea is to debloat application and unlayer complexity where its possible. It doesn't offer the niceties, or feature parity of what frameworks do, but it allows me to be more explicit in the places where I'm going to use a framework. E.g. might have handrolled JavaScript code for light interactivity for a website for 90% of the time, and going to use something like VueJS only on the pages that require some highly integrated state associated page components. The people in my circles, didn't hate DOM manipulation. They just didn't understand it (or care to), and jQuery answers where all over stackoverflow (just use this library and this jQuery plugin call). And yes, without jQuery/frameworks DOM building is tedious. I've seen JSX praised before, but in an alternate timeline where IE didn't dominate the entire world with a legacy PoS, maybe the E4X standard would have been implemented in all browsers. Which would have been a pretty sweet deal, and another useful tool for the vanilla JavaScript camp.