I've been coding for over 20 years now! (WOAH, do I feel old)
I've touched just about every resource imaginable under the Sun (too bad they were bought out by Oracle)
I still prefer to do everything on the back end. It is significantly faster to push raw HTML to a client and have it simply insert or replace part of the DOM, than to dynamically generate DOM client side from sever data. This still enables single page applications, allows for Http caching, plenty of extensibility on the back end. There are so many tools, tried and true utilities that exist well before these Frameworks that can still can be used with this approach. Additionally, if no JS is available, or is broken, or if you need SEO, or screen readers, these ALL still work, since the entire HTML (not just the replaced content in the container) can be pushed from the server. Everything existing still works beautifully, accessibility is maintained, tools don't need overhauled, and it's significantly easier to program. It's an all out win.
Depends on the scope of the application and the target audience. If your bread and butter is intranet apps for the corporate crowd then there is no such thing as offline: if a pc is offline then there is a problem with it or the network infrastructure, essentially you can depend on the clients always be in contact with your server. In these cases all that matters is raw speed of delivery and ssr really shines there.
These are my big reasons for switching to Server side rendering. As well as improved productivity. At least to me, it's much easier to have one monolith with a small team rather than wrangling and deploying 30 different projects.
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.
I still prefer to do everything on the back end. It is significantly faster to push raw HTML to a client and have it simply insert or replace part of the DOM, than to dynamically generate DOM client side from sever data. This still enables single page applications, allows for Http caching, plenty of extensibility on the back end. There are so many tools, tried and true utilities that exist well before these Frameworks that can still can be used with this approach. Additionally, if no JS is available, or is broken, or if you need SEO, or screen readers, these ALL still work, since the entire HTML (not just the replaced content in the container) can be pushed from the server. Everything existing still works beautifully, accessibility is maintained, tools don't need overhauled, and it's significantly easier to program. It's an all out win.
All great, unless you want to be able to provide an offline experience.
Depends on the scope of the application and the target audience. If your bread and butter is intranet apps for the corporate crowd then there is no such thing as offline: if a pc is offline then there is a problem with it or the network infrastructure, essentially you can depend on the clients always be in contact with your server. In these cases all that matters is raw speed of delivery and ssr really shines there.
These are my big reasons for switching to Server side rendering. As well as improved productivity. At least to me, it's much easier to have one monolith with a small team rather than wrangling and deploying 30 different projects.