This isn't true. The biggest cause of spaghetti code in "traditional" JS is due to having multiple conflicting sources of truth for the same pieces of state information (usually split between JS variables and DOM) and subsequent multi-directional synchronization.
Having a model that drives all DOM is one way to solve this. However, having "canonical" representation of your state in DOM works as well.
Having the DOM as your canonical representation of state is only suitable for apps with limited state IMO, because your state effectively has to be turned into text (CSS class names and element attributes) whenever it is mutated, which becomes a liability as the complexity of your app state grows.
Personally, I feel the components approach keeps it sane. Just let your v-dom layer do all the work. Use a state management library if needed.
Just my 2 cents.
Keeping the model as a single source of truth was still up to the developer though. As was rendering the template after every change. (You controlled how often you wanted to render it.
Backbone tried to organize this via a simple convention. All your Models were backbone models, basically the same as regular arrays/objects but they emitted event. Your Views listened to these events and called render accordingly.
The boilerplate switched from maintaining the models and rendering to setting up what was basically a simple pub/sub.
Still, this boilerplate was too much to actually have to think about for most people. Many from jquery backgrounds, being forced to use Backbone figured out they could just cram all the logic into the render functions. Everything was wrapped as a Model or View despite those features not being used.
Even today there are many Backbone legacy apps written in this shitty way. The existence of backbone just flails around the logic rather than organize it. They are wrappers for the sake for saying "this app is modern because it uses backbone".
What React did with the virtual DOM was eliminate the boilerplate and responsibility of DOM updates. It even combined logic and templating into one thing. With this reduction of concepts, many people or just now getting what MVC actually is.
Keeping a single source of truth is the MAIN thing and it has a long history. For web development with heavy user interaction state management is massively complex.
It would be great if everybody slowed down to truly get what MVC at its core was about. And for the "older" deriders or modern web development to realize that the real-time interactivity exploding the complexity of state DOES necessitate new tools. In fact, more traditional web development is becoming more and more commoditized with less technical skills needed. There is however a large market for JS developers to develop tools (heavy interaction) to replace what traditionally were JVM crud apps. Developing for the web is easier than the JVM. JVM was easier than developing for every OS.
Python? C++? Do these languages have strong support for web stuff?
There are two ways to change a webpage:
- reload a new page with the changes applied
To put some concrete examples to that...
There are a few solutions for Ruby, PHP and Python although I have no experience with them and how well they perform/work.
React is implemented in JS and uses JS to declare components, and it would be fun if there is some working JS-to-Python (-to-PHP/-to-Ruby) translator that is good enough to translate React code to run "natively".
You can see an example of the various controls here:
The code for the example is here:
Most of the code is either a) auto-generated by the IDE (all non-private/public interface code, and all event handlers), or b) part of the "particles" canvas drawing code.
Saying one is slower than the other doesn't really make sense, since they solve problems in different ways. You can argue that in many scenarios with complex front end applications, it's easier to avoid performance or spaghetti issues when using React instead of jQuery, but there are also cases where jQuery is more convenient and leaves you with more control.