Updating content in raw DOM methods is as direct as:
1. Get the desired node.
2. Write the content.
That is it. The corresponding code is two lines.
But but but... what about state? State is an entirely unrelated issue from writing content. State is also simple though. State is raw MVC plus storage. The way I do it is to have a single state object, the model. I update that model as necessary on user and/or network interaction, the view. When the page loads I read from the state object and then execute the corresponding changes using the same event handlers that would normally execute in response to the user interactions that wrote the state changes in the first place, which is the control.
That is simple, but many people find that simple is not easy.
It is simple, and it very quickly becomes un-simple when it comes into contact with increasing app size/complexity (for things which _need_ to be apps, and which have to deal tasks where the size/complexity is essential due to factors which _can't_ be avoided, e.g. an app which deals with Workers' Comp, with laws and requirements which differ by U.S. state in ways which cut across the entire app) and team size/mix of experience.
Framework people always complain that simplicity doesn't scale. In my nearly 20 years of experience doing this I can firmly say they are entirely wrong. If an application increases in complexity as its features increase the way to restore order is a minor refactor.
But really that isn't what this is about. Framework people were always falling back on this fail to scale argument even in the early days of jQuery. The real issue is that some people cannot architect and cannot refactor. That isn't a code or application limitation. Its a person limitation.
the tools are supposed to make u be able to make products faster and more efficiently and iterate faster on business requirements or whatever problem you are trying to solve. you are treating it like its some toy your supposed to fiddle with or something. there is a reason we aren't coding in binary and use functions to encapsulate and abstract away logic. these frameworks are supposed to provide boilerplate so that you don't have to go through the trouble yourself because somebody already solved it so you can be more productive and build on top.
getting a site up and running with vercel is like 20x faster and more simple than hardcoding .html files man.
1. Get the desired node.
2. Write the content.
That is it. The corresponding code is two lines.
But but but... what about state? State is an entirely unrelated issue from writing content. State is also simple though. State is raw MVC plus storage. The way I do it is to have a single state object, the model. I update that model as necessary on user and/or network interaction, the view. When the page loads I read from the state object and then execute the corresponding changes using the same event handlers that would normally execute in response to the user interactions that wrote the state changes in the first place, which is the control.
That is simple, but many people find that simple is not easy.