When Does a Project Need React?
css-tricks.com
css-tricks.com
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.
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.
Sadly, the popularity of Java means there was a lot of bad code, poisoning its popularity. The same may happen to javascript with people years from now (or even currently) looking at old backbone, angular, react, node code and deriding shitty "javascript shop culture"
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.
Python? C++? Do these languages have strong support for web stuff?
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".
Other languages like C, C++, and Rust can also run on the Web thanks to WebAssembly, a new compiler target for the web that's on by default in Firefox, Chrome, and Safari Technical Preview, and available behind a flag in Edge: http://caniuse.com/#feat=wasm However, interaction between the DOM and WebAssembly is still pretty rough, so it's currently best at numeric / computationasl tasks, not replacing JavaScript entirely.
For example, if you inspect this page, you'll see that it has about 150 lines of Javascript.
There are two ways to change a webpage:
- manipulate it with Javascript
- reload a new page with the changes applied
If your page loads quickly and not all that often, you can get pretty far without Javascript. If you are willing to tolerate a pageload on each interaction, you don't need any Javascript.
To put some concrete examples to that...
The HN page uses javascript[1] for the upvote/downvote buttons and also to collapse/expand comments. It would be very disruptive and jarring to reload an entire page after someone clicks a vote button. Also, mobile phone users would be doubly punished since a page reload is slower than desktop highspeed internet.
A good example of a website not requiring javascript without penalizing user-interface usability is Wikipedia text pages.
You can see an example of the various controls here:
http://www.elevatesoft.com:8081/controlsdemo/controlsdemo.ht...
The code for the example is here:
http://www.elevatesoft.com/controlsdemo_code.txt
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.