4 ms·

Sorry, I don't have the complete context - SSR stack, app architecture, load times etc. So, I'm not in a position to comment on your SPA migration. But, I'd lik

Sorry, I don't have the complete context - SSR stack, app architecture, load times etc. So, I'm not in a position to comment on your SPA migration. But, I'd like to share thoughts from my current situation. We have a flagship product written in web forms (started in 2006). It's a big solution. Performance has always been a challenge with it. While I'm not proposing a complete rewrite into SPA, due to - migration requires a lot of effort, huge risk for missing functionality, errors etc. The biggest problem with the product is - app posts back the entire page, which most of the times is huge, even if we changed just one field. The viewstate is enormous. My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it. This approach is also described in MS's silk project - https://www.microsoft.com/en-us/download/details.aspx?id=27290 https://www.microsoft.com/en-us/download/details.aspx?id=272...

GordonS 8y ago
> My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then process the result and do something (update a table, display a message, redirect, whatever). I feel like this gives me the best of both worlds - the backend is very testable, and really straightforward for new developers to come up to speed on, while at the same time we remove a lot of full-page renders. You can find an example of this technique here[0] [0] https://github.com/jbogard/ContosoUniversityDotNetCore https://github.com/jbogard/ContosoUniversityDotNetCore
- hakfoo 8y ago
  I recall one of the more frustrating clients at my old firm. The client was hoping to build a competitor to a fancy all-AJAX industry-specific backoffice application (written by a team of dozens and with a coffee budget alone three times our dev budget) Since they were domain experts, but sort of scatterbrained (oh, we need undisclosed requirement xyz" 3 months into development), we were building it in phases to make sure we could cover their functional needs. It was a rule-based system for validating and analyzing user-provided data, where they'd be responsible for maintaining the rules via an admin backend. It was your typical PHP based request/response lifecycle. They. Could. Not. Get. Over. The. Fact. The. Pages. Reloaded. After. Each. Request. No matter how many times we said "can we focus on making sure the underlying math is right and then polish the UI?" So I finally snapped and implemented that exact same thing. That shut them up enough that they just started disappearing when they were asked for info. I suspect the project had enterred the phase where they were out of money and/or realized they were trying to swallow a bigger task than they could handle themselves. Recently, I saw Turbolinks [0] which looks like the same concept with way more panache. [0] https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
  - jimmcslim 8y ago
    See also Stimulus [0], from Basecamp. [0] https://stimulusjs.org/ https://stimulusjs.org/
- fiddlerwoaroof 8y ago
  I’ve occasionally thought of doing SSR but making it possible to server render only a small part of the page in response to an API request and then just use JavaScript to swap in the html from the backend.
  - fiddlerwoaroof 8y ago
    You could use `Accept: text/html` to indicate that an API should return html rather than Json.
  - purerandomness 8y ago
    This is elegantly implemented by [1]. I love this concept and use it in all my projects. [1] https://intercoolerjs.org/ https://intercoolerjs.org/
- mandeepj 8y ago
  You got my point right. Thanks for sharing your experience
- manigandham 8y ago
  This is exactly what the article points out. Github/Gitlab and many other projects do the same thing. Either small parts of the application are standalone SPAs (since they can be mounted to any single root element) or there are libraries like Turbolinks/Intercooler that just make the full-page request but in JS and then replace the DOM with the results so the browser doesn't actually experience a full page reload.

GordonS 8y ago

> My proposal is to switch to json objects for information exchange between server and client. We'll get the benefits similar to SPA without rewriting for it If I understand your approach correctly, I often do something similar, but with modern ASP.NET Core MVC apps. Basically, I have a tiny bit of JavaScript that 'intercepts' all form POSTs and submits them using AJAX instead. Another tiny bit of JavaScript can then process the result and do something (update a table, display a message, redirect, whatever). I feel like this gives me the best of both worlds - the backend is very testable, and really straightforward for new developers to come up to speed on, while at the same time we remove a lot of full-page renders. You can find an example of this technique here[0] [0] https://github.com/jbogard/ContosoUniversityDotNetCore https://github.com/jbogard/ContosoUniversityDotNetCore

hakfoo 8y ago
I recall one of the more frustrating clients at my old firm. The client was hoping to build a competitor to a fancy all-AJAX industry-specific backoffice application (written by a team of dozens and with a coffee budget alone three times our dev budget) Since they were domain experts, but sort of scatterbrained (oh, we need undisclosed requirement xyz" 3 months into development), we were building it in phases to make sure we could cover their functional needs. It was a rule-based system for validating and analyzing user-provided data, where they'd be responsible for maintaining the rules via an admin backend. It was your typical PHP based request/response lifecycle. They. Could. Not. Get. Over. The. Fact. The. Pages. Reloaded. After. Each. Request. No matter how many times we said "can we focus on making sure the underlying math is right and then polish the UI?" So I finally snapped and implemented that exact same thing. That shut them up enough that they just started disappearing when they were asked for info. I suspect the project had enterred the phase where they were out of money and/or realized they were trying to swallow a bigger task than they could handle themselves. Recently, I saw Turbolinks [0] which looks like the same concept with way more panache. [0] https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
- jimmcslim 8y ago
  See also Stimulus [0], from Basecamp. [0] https://stimulusjs.org/ https://stimulusjs.org/
fiddlerwoaroof 8y ago
I’ve occasionally thought of doing SSR but making it possible to server render only a small part of the page in response to an API request and then just use JavaScript to swap in the html from the backend.
- fiddlerwoaroof 8y ago
  You could use `Accept: text/html` to indicate that an API should return html rather than Json.
- purerandomness 8y ago
  This is elegantly implemented by [1]. I love this concept and use it in all my projects. [1] https://intercoolerjs.org/ https://intercoolerjs.org/
mandeepj 8y ago
You got my point right. Thanks for sharing your experience
manigandham 8y ago
This is exactly what the article points out. Github/Gitlab and many other projects do the same thing. Either small parts of the application are standalone SPAs (since they can be mounted to any single root element) or there are libraries like Turbolinks/Intercooler that just make the full-page request but in JS and then replace the DOM with the results so the browser doesn't actually experience a full page reload.