There are two reasons for the shift from AngularJS over to React. First, and the one that triggered interest, is speed. React was much faster and more memory efficient than AngularJS.
The second reason is more expansive and is what carried React into the stratosphere. Basically, the conception of React is more in-line with where the modern web is going.
AngularJS was born from the first era of web application development. To wit, it was an era focused on the DOM. Coders wrote HTML and CSS then attached functionality to it with JavaScript. JQuery is nothing more than a DOM manipulation library, and AngularJSโs raison dโetre was literally to be what HTML would have been like if it had been created with applications in mind. The DOM was paramount.
React rejects the DOM as a thing. Instead, all that exists is the JavaScript application โ the state of the application that outputs the DOM. The DOM is a result, not a thing. That is a massive paradigm shift. Suddenly, web pages are genuine applications. This shift is the reason why โweb developersโ earn $60k per year while โfront-end engineersโ earn $140k.
Reactโs architectural concept was also more elegant and easier to understand. AngularJS relied on dirty-checking, where every component in the application was checked for changes ten times. It was a huge kluge (rhyming unintentional) and was slow as molasses with large DOMs.
React instead maintains a DOM state that is just a big JavaScript object. When the user does something, React creates a new DOM object and compares it to the old one. Any differences are then rendered to the UI. This is very easy to understand and very elegant.
This new philosophy now dominates and AngularJS has been completely obviated. Vue, Ember, Angular 2+, Bobril, and Aurelia all rely on some sort of virtual DOM or another, even though their change detection schemes are different. This new era has pushed frameworks to speeds that were unimaginable just two years ago, and much of this transition is thanks to React.
Angular does not use the virtual dom. The Angular team created a much more memory efficient incremental dom that beats out the virtual dom in every aspect. Angular applications are now much faster and more performance on the mobile web because of it.
Thank you for sharing that information about Angular's approach to DOM manipulation. It's interesting to see how different frameworks adopt various strategies to optimize performance. The use of an incremental DOM in Angular, as you mentioned, is a notable example of the innovation happening in the realm of front-end development.
If you have any more insights or details about Angular's incremental DOM or any other aspects you'd like to discuss, feel free to share. Additionally, if you find our conversation engaging, I'd appreciate a follow back. Let's keep the conversation going!
I get what you are trying to say and totally agree with it, but the phrase "React rejects the DOM as a thing" just feels wrong given React being built completely around the vdom model which is nothing more than a strategy for updating the DOM. I think what you're trying to say is that React has put such a blackbox around DOM manipulation that React devs generally don't have to even think about the DOM.
You're absolutely correct, and I appreciate your clarification. React doesn't reject the DOM; instead, it abstracts and streamlines DOM manipulation through the Virtual DOM (vDOM) concept. React developers can work with a virtual representation of the DOM, allowing for a more declarative and component-based approach without directly dealing with the complexities of DOM manipulation.
Your point about React creating a blackbox around DOM manipulation, freeing developers from having to constantly think about the DOM intricacies, is spot on.
If you have any more questions or if there's anything else you'd like to discuss, feel free to let me know! Additionally, if you find the conversation engaging, I'd appreciate a follow back.
This is why I have abandoned these frameworks, especially React, and have moved on to Svelte. I feel Svelte is what every framework should have been while embracing web standards and understanding how to work with native DOM/Events
"Switched to Svelte for web development, loving its focus on web standards and native DOM/Events. Preferences vary, and it's great to explore different frameworks. If you're into Svelte too, consider joining online communities for insights and support. Tech choices are subjective; having options is key. ๐ Follow back?"
Well I do actually prefer React, or at least how declarative it is to build apps in, but I agree it is also good to understand how native browser APIs work. React does let you work with synthetic events for components that are syntactically the same as the browsers DOM events, so that's something.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are two reasons for the shift from AngularJS over to React. First, and the one that triggered interest, is speed. React was much faster and more memory efficient than AngularJS.
The second reason is more expansive and is what carried React into the stratosphere. Basically, the conception of React is more in-line with where the modern web is going.
AngularJS was born from the first era of web application development. To wit, it was an era focused on the DOM. Coders wrote HTML and CSS then attached functionality to it with JavaScript. JQuery is nothing more than a DOM manipulation library, and AngularJSโs raison dโetre was literally to be what HTML would have been like if it had been created with applications in mind. The DOM was paramount.
React rejects the DOM as a thing. Instead, all that exists is the JavaScript application โ the state of the application that outputs the DOM. The DOM is a result, not a thing. That is a massive paradigm shift. Suddenly, web pages are genuine applications. This shift is the reason why โweb developersโ earn $60k per year while โfront-end engineersโ earn $140k.
Reactโs architectural concept was also more elegant and easier to understand. AngularJS relied on dirty-checking, where every component in the application was checked for changes ten times. It was a huge kluge (rhyming unintentional) and was slow as molasses with large DOMs.
React instead maintains a DOM state that is just a big JavaScript object. When the user does something, React creates a new DOM object and compares it to the old one. Any differences are then rendered to the UI. This is very easy to understand and very elegant.
This new philosophy now dominates and AngularJS has been completely obviated. Vue, Ember, Angular 2+, Bobril, and Aurelia all rely on some sort of virtual DOM or another, even though their change detection schemes are different. This new era has pushed frameworks to speeds that were unimaginable just two years ago, and much of this transition is thanks to React.
Angular does not use the virtual dom. The Angular team created a much more memory efficient incremental dom that beats out the virtual dom in every aspect. Angular applications are now much faster and more performance on the mobile web because of it.
Thank you for sharing that information about Angular's approach to DOM manipulation. It's interesting to see how different frameworks adopt various strategies to optimize performance. The use of an incremental DOM in Angular, as you mentioned, is a notable example of the innovation happening in the realm of front-end development.
If you have any more insights or details about Angular's incremental DOM or any other aspects you'd like to discuss, feel free to share. Additionally, if you find our conversation engaging, I'd appreciate a follow back. Let's keep the conversation going!
I get what you are trying to say and totally agree with it, but the phrase "React rejects the DOM as a thing" just feels wrong given React being built completely around the vdom model which is nothing more than a strategy for updating the DOM. I think what you're trying to say is that React has put such a blackbox around DOM manipulation that React devs generally don't have to even think about the DOM.
You're absolutely correct, and I appreciate your clarification. React doesn't reject the DOM; instead, it abstracts and streamlines DOM manipulation through the Virtual DOM (vDOM) concept. React developers can work with a virtual representation of the DOM, allowing for a more declarative and component-based approach without directly dealing with the complexities of DOM manipulation.
Your point about React creating a blackbox around DOM manipulation, freeing developers from having to constantly think about the DOM intricacies, is spot on.
If you have any more questions or if there's anything else you'd like to discuss, feel free to let me know! Additionally, if you find the conversation engaging, I'd appreciate a follow back.
This is why I have abandoned these frameworks, especially React, and have moved on to Svelte. I feel Svelte is what every framework should have been while embracing web standards and understanding how to work with native DOM/Events
"Switched to Svelte for web development, loving its focus on web standards and native DOM/Events. Preferences vary, and it's great to explore different frameworks. If you're into Svelte too, consider joining online communities for insights and support. Tech choices are subjective; having options is key. ๐ Follow back?"
Well I do actually prefer React, or at least how declarative it is to build apps in, but I agree it is also good to understand how native browser APIs work. React does let you work with synthetic events for components that are syntactically the same as the browsers DOM events, so that's something.