| Verbosity is hardly the problem these UI libraries/frameworks solve. They establish idioms for data flow and composition. The UI component model’s data flow might vary between libraries, but they’re all generally opinionated and fairly consistent internally. The equivalent in “vanilla JS” can easily become unwieldy even with a lot of discipline, because the underlying APIs are designed with the view as the source of truth. That’s almost always the opposite of how you’d want to design a system with more than a very small amount of complexity. But that’s where inertia will guide you because there isn’t even a notion of state that doesn’t reference the DOM etc. Once you’ve succumbed to this even partially, composition becomes incredibly difficult because the underlying model leaks implementation details. Tangling them is not just easy, it’s the default. Avoiding tangling them means basically developing a UI library with its own opinions and idioms. Which maybe you want that, but most people are building something else. Untangling them is an enormous task. I’m maintaining an application that began in the era when this was common, and picked up some notion of components along the way. Even just understanding how things get invoked can take hours or days tracing app code and its interaction with implicit state in the view, and that’s with two years of familiarity with the code. I don’t even like React or several of its idioms. But stuff that takes me hours or days would take minutes to understand with just the basic assumptions React or any other component library would afford. I can’t speak for any specific commenter, but I think this is the kind of “scale” most UI devs mean when they discuss it in those terms. And granted, the critique that many things don’t need the scale they take on—that they add incidental complexity to fit a library/framework’s model. That can certainly be true, but I think the “vanilla JS” camp really underestimates how steep that cliff is and how quickly many projects can run off it. |