I developed a rather complex SPA with Angular recently and I cannot go back to the ghetto that is jQuery when using server side rendering.
With React, you can basically store all you data (state) in the root component (which could be the root of your entire page), and replace that with new state without thinking too much about the DOM updates and view changes that result from this.
This is perfect for a server-side framework, because such a framework by definition already renders everything whenever something changes (page refresh). Without React, the framework does a bunch of things and finally craps out objects that are transformed to HTML by the view (where the views are as 'dumb' as possible). With React, instead of rendering the object to HTML, you just pass these objects, as JSON, to a React component (which could be the whole page), and it figures out what needs updating. You don't have to deal (as much) with client-side logic if you don't want to, and things will still be performant.
This also significantly simplifies server-side rendering, to the point where it might require only one extra call to render the component server side (the handy renderComponentToString).
Of course, in practice it's often not quite that simple, but because of how React operates, you can get pretty far with relying primarily on the server-side framework and little logic on the React-side of things (plus you can achieve the 'holy grail' of seamless server- and client-side rendering.
(apologies if I'm getting things wrong, by the way. I'm by no means an expert on these matters and only just diving into React.)
The data portion is the main reason I was looking at Angular.
Thank you.
Does that answer your question?
As your app grows, it might become inefficient to send down the now-huge JSON object, and you might want to add some client-side logic to deal with that. However, this might not even be necessary, as 1) even though you replace the entire state, React will only update what changed, and 2) by using optimistic updating on the client (or whatever the proper term is), the user might not notice that the actual data-syncing is a bit slower. Plus, it'll still be faster than a server-side-only approach.
The nice thing is that sending the total state (of the page or component) every time significantly simplifies matters, to the point where you might be able to keep relying on your server-side framework for most of the logic, at least until you need to start optimizing stuff.
The big weakness of Angular is server side rendering,which involves heavy solutions like phantomjs,while you can render react components on the server.
Angular is not very good at rendering/managing svg either,that's a fact.
I would argue maintaining pure html templates is not that hard.
But frankly Angular solves so many problems these are minor issues.Writing complex lob applications is so easy with Angular I wouldnt want to use anything else.
The only case i'd switch back to backbone+react/vue/ractive and jquery is when i'm writing interactive experiences that are not CRUD apps.
So no,dont switch to React for the sake of switching especially since AngularJS just works. I mean people dont even bother learning javascript,they learn AngularJS ...
It has been discussed on HN before : https://news.ycombinator.com/item?id=7719957
Some good comments there, worth checking out. Personally, I think the message loop architecture proved very good in Windows when processors were slow and had only 1 core and it is at least worth giving it a try in web development.
Hence my question. I feel like for some apps I don't need 60% of what Angular has to offer (routing, controllers, modules etc.) I would be satisfied with just directives. Which are probably the part of Angular I like the least.
For SPAs I see no other alternative to Angular currently. In instances where I need heavy JS only on some pages, I'm not sure.
You could then incrementally add logic client-side to improve performance, if that's necessary (if the state object becomes too large, for example).
<my-svg-shape my-directive-that-mutate-svg-props />