User experience, well specifically interactivity. The user can keep interacting with the application with SPA's. Imagine if a service like Trello was server rendered. The entire page would have to refresh every time a user moved a card, edited a card, etc.
Not to mention the decoupling of frontend and backend technology stacks.
Of course, if it was a page that doesn't require much interactivity and needs extremely fast load times(a blog for example), then SSR trumps SPA without a doubt.
I think there's some confusion here. I am not advocating only using SSR like a traditional monolithic app.
I am, however, advocating having a SPA experience that is also utilizing SSR. The initial render is from the server, and then the client side JavaScript takes over to provide a SPA experience. This means that web crawlers are able to view content on that initial render of any page.
This is probably my fault in not making that clear in the article, so I will probably add that to the "Universal JavaScript" section.
Update: I added a new section to the article to hopefully clear up this confusion.
Depends, I meant handling the initial render in the server then handle the interactivity in the browser the way it was for years. By SPA, I assume that the server will return a page with an empty content as you mentioned and the JavaScript will handle the rendering, which is not what I meant by saying "handling it with AJAX". Generally, using AJAX doesn't imply it's a SPA.
Oh right, sorry I didn't realise that's what you were referring to.
However, I've seen a few websites trying that approach and the code was a mess. Probably poor planning. Have you worked with that pattern? How was your experience with it?
yeah it can be messy very quickly, but using a solid architecture and a suitable design pattern will make a huge difference. For the example of Trello, i would create an independent API in the backend and for the front-end part i would use a Pub-Sub design pattern as the application is heavily events driven. Hence, the code will become more readble and extendible.
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.
User experience, well specifically interactivity. The user can keep interacting with the application with SPA's. Imagine if a service like Trello was server rendered. The entire page would have to refresh every time a user moved a card, edited a card, etc.
Not to mention the decoupling of frontend and backend technology stacks.
Of course, if it was a page that doesn't require much interactivity and needs extremely fast load times(a blog for example), then SSR trumps SPA without a doubt.
I think there's some confusion here. I am not advocating only using SSR like a traditional monolithic app.
I am, however, advocating having a SPA experience that is also utilizing SSR. The initial render is from the server, and then the client side JavaScript takes over to provide a SPA experience. This means that web crawlers are able to view content on that initial render of any page.
This is probably my fault in not making that clear in the article, so I will probably add that to the "Universal JavaScript" section.
Update: I added a new section to the article to hopefully clear up this confusion.
but you can avoid that using AJAX, are there any drawbacks ?
But using AJAX would mean that it isn't SSR, wouldn't it?
Depends, I meant handling the initial render in the server then handle the interactivity in the browser the way it was for years. By SPA, I assume that the server will return a page with an empty content as you mentioned and the JavaScript will handle the rendering, which is not what I meant by saying "handling it with AJAX". Generally, using AJAX doesn't imply it's a SPA.
Oh right, sorry I didn't realise that's what you were referring to.
However, I've seen a few websites trying that approach and the code was a mess. Probably poor planning. Have you worked with that pattern? How was your experience with it?
yeah it can be messy very quickly, but using a solid architecture and a suitable design pattern will make a huge difference. For the example of Trello, i would create an independent API in the backend and for the front-end part i would use a Pub-Sub design pattern as the application is heavily events driven. Hence, the code will become more readble and extendible.