The problem with UI/DOM is the mental model of working with it. For me I think SPA frameworks need to provide an abstraction layer that makes it easy to work with.
Thus React. I can think of it in a functional pattern and let it abstract the DOM/UI for me, ofc I understand there's a cost to it but that cost will greatly be overshadowed development & maintenance costs.
Whatever happened to the "think of the user experience first".
I am sad this shift to "it's easier for me to develop, who cares about the users" happened.
This is because Front-end web developement has been taken over by back-end developers.
Few developers complained about JavaScript until Back-end developers became 'Fullstack' and had to start working with it and tried to apply the same mental model they had used with Java or Python etc.
CSS was always something you had to dedicate time to, to master and learn the quirks of the current and past browsers, until Back-end developers decided it was 'terrible' and a race to the bottom of CSS frameworks was created and nobody remembered proper selection or specicifity as BEM was adopted.
HTML was a tool for layout which developers made good choices for thoughtful semantic code, so that it was easily readable, for both man and machine, yet it was a manual process. Then Back-end developers didn't have the time to learn something new and everything is a div and if you're lucky it will have a role.
This is the "if all you have is a hammer, everything looks like a nail" kind of view.
What i believe is, the complexity of developing software has been increasing and we have a lot of pressure specially due to time constraints that we are always reinventing the wheel in order to meet deadlines and try to make things easier.
I'm not convinced that software has been increasing in complexity, I just think that more complex sites are being created now than in the past, and there are less capable developers having to work on these sites.
I agree that pressure is high and time constraints are tight and this forces people to look for an answer outside of themselves.
Complains and jokes about JavaScript have been here from the first time JavaScript was released. Many of them fully rightful. There are even
years old memes about it like thousands of variants for this https://img.devrant.com/devrant/rant/r_1585_DY1Kk.jpg
The complains about CSS being something that is hard to learn and remember and about its shortcomings and hard maintenance have been here also for years. The thing people acknowledged was that it was improvement over writing it all into html.
Original HTML contained everything that CSS contains now - unseparated. And for that matter, everything is DIV because CSS people and designers like it so. It has nothing to do with backend people who would happily use table everywhere if only they were allowed to. Then again, css people and designers did not pushed for divs out of whim - they want it that way because it is practical for them.
Yes people acknowledged that CSS was an improvement, but most of the shortcomings were not because CSS was at fault but that browser vendor implementation was slow and inconsistent.
CSS has always been relatively simple, the complexity came about by having to juggle workarounds and hacks to support all the different browsers.
I completeley disagree with your last statement, divs had been around for a long time before they became a one-hit wonder for all elements, nobody needed or wanted them.
Once CSS 2.1 was adopted and table layout was no longer required semantic html ruled.
Divs have only become ubiquitous since CSS and front-end frameworks have become so popular
Pure css is not comfortably maintennable. It lacks variables for example. That is massive shortcoming - inability to say that this color is same as that color. Or alternatively that this selector here is same as the one over there.
Also, even things like making stuff same height were absurdly difficult with css even absent browser differences. It is oddly inconsistent language with hard to remember rules.
And it often ends with house of card constructions that break the moment anything changes.
Actually, pure CSS can be comfortably maintained--if you're willing to limit your project to specific parameters or, simply, use a well-defined methodology (i.e. BEM, OOCSS, ITCSS, etc).
I've read some developers limit their CSS file(s) to 50 lines (max.) while other developers build their CSS on a page-by-page basis dependent on a primary global style sheet (ex: content-sidebar.css is loaded on every static page and post while content-page.css is only loaded on static pages).
Where I currently work at, every static page gets its own CSS if it meets the following two parameters: (1) accessible from the root and (2) not part of a larger (or "nested") set of pages--two rules becomes necessary when you have a team who hates nested pages and prefers an internal taxonomy system. The styles are encapsulated by adding an additional HTML class (usually a sanitized version of the page title and its ID) to the body tag.
For pure CSS websites, OOCSS will be your best friend as it forces serious thought into how you define your style rules. Additional rules also include limiting the use of CSS vars only to elements that have an ID attribute (which is also limited as well).
Sorry that is a crazy thing to say. With node (front end tech at heart made by front end people) programmability invaded the frontend. Which gave myriads of new ways to solve problems and given that all the front end problems are new and the community is fairly young the whole thing is pretty wild currently. No backend dev would care about SPA madness is he had the choice.
a developer who doesn't think of that is going to do that with react or without react. freeing up development time to focus on better user experience is more possible by using a framework such as react.
Thus React. I can think of it in a functional pattern and let it abstract the DOM/UI for me, ofc I understand there's a cost to it but that cost will greatly be overshadowed development & maintenance costs.