Just to add on here, I think you are exactly right. The author is pretty vague and doesn't provide any concrete examples. I always think, whenever working with

Just to add on here, I think you are exactly right. The author is pretty vague and doesn't provide any concrete examples. I always think, whenever working with JS/CSS/HTML to build a UI is just like any other UI system in terms of separating concerns and good programming practices. If the browser is what I have to work with then I am going to be writing JavaScript to manipulate HTML / CSS. No amount of CSS wizardy is going to really help. At the end of the day my logic is in JSS and I have to update a UI somehow. This is where and why design patterns like MVC are so popular. You can do all the ugly integrated JS/HTML/CSS in UI components just like in any native UI toolkit and then you update these thru your more pure "controller" logic that tries its best to just shove some data at the UI later and let it do its thing. Somewhere, if not MVC, but still with some separation between UI and your app logic you still have code that says "Okay, some state has changed, anyone that cares, here is the state that has changed." I think what the author laments is that is is extremely easy/tempting and common to just dig into those always available globals to solve design problems. This is why so many JS template and other frameworks exist, everyone is trying to find a nice way to do this that makes sense to them. So, I don't care what you do in your UI layer. If you want to make a rats nest of CSS in JS, go for it. If you want to create some beautiful HTML+CSS+JS design that minimizes JS and CSS weirdness, go for it. As long as you give me an API to deal with your thing and not some ass-ugly encapsulation breaking thing that makes me deal with the UI I can separate out the coding effort into better conceptual parts. This is where people get frustrated with modern JS. As an experienced programmer I can often get things done quickly in most environments and figure out the key parts pretty quickly, even when you are doing things like dependency injection or I have to go through your abstracted bi-bidirectionally dependent class hierarchy hell, I am okay with this. Drop me into a modern JS stack where in order to "do things right" I have to basically completely relearn CSS and figure out a dozen new esoteric and new JS micro frameworks and I just get annoyed. So far the only antidote I have found to this was Vue. It seems to support this more immediate dirty style of scribbling with DOM globals or the fancier modern things advanced JS/CSS UI folks know how to do that take days of `npm install` and packing and minifying and JSXing and whatever the heck else is going on in the JS world these days. Anyway, my point was, deal with it. CSS/HTML/DOM kind of suck as a UI layer, but they work. Hide it in your basement. Don't let it infect the rest of your code using well tread design and programming practices. Get on with your life. edit: Just to add, my one real criticism for the topic of discussion here is that it takes a LOT of esoteric, bleeding edge knowledge to "do the right thing" in JS/CSS these days. CSS is always adding new things and it creates a compatibility nightmare. As a casual occasional person that wants to write a UI using CSS/DOM I am never going to a.) reach the complexity where this matters and b.) have time to learn all that stuff to do it right. I am not convinced big teams with people dedicated to this chore can learn quick enough to keep up while still building a system that plays well with development teams and their speed of knowledge consumption/learning while trying to ship code. Old school things still work, are reliably, and solve the problem 80-90% of the time.