3 ms·

My reasons for SPAs has always been complex behaviors on the app and state persistence is a PITA if you don't end up with a nice MVVC on the front-end. Not say

My reasons for SPAs has always been complex behaviors on the app and state persistence is a PITA if you don't end up with a nice MVVC on the front-end. Not saying not possible to make complex pages without SPAs, but there are some things that are harder, and some that are easier. Personally I love writing SPAs, I find that I end up making less complex code which ends up being easier to maintain. Not counting by the number of lines of code, but counting by how easy developers find it to change the logic without breaking everything in a complex codebase. So idk, maybe I'm doing it wrong.

Quarrelsome 6y ago
The sort of garbage we ended up doing prior to SPAs justify SPAs. Writing a server to dynamically create a HTML page that also includes first pass content as well as potentially dynamic javascript to make the page interactive in "later passes" is just an ugly mix of client side execution and server side execution in one spot. The application just feels a lot more consistent when the client is just pulling data instead of being thrown away and recreated in the middle of a request made by a browser for a particular URL that is just one of a very long series of requests.
- Justsignedup 6y ago
  There are techniques for controlling complexity there, and often you can make a single-page react page which will encapsulate complex behaviors. Often a mix of the two helps. But you end up having one set of code managing the static page, and another for the api-based interactions. and then once you have api-based stuff product asks to add on a feature and a feature until you have mutliple SPAs. :P Code reuse is a big reason too, why write 10 different SPAs for one site, when you can write 1 SPA with a ton of code/tool re-use. I always end up taking 1 SPA and make 2-4 different SPAs out of it, each facing a different set of users, with different security/look requirements, but all underpinned by the exact same technology. So much headaches saved. Just to make it clear: - I agree that SPAs didn't come out of developers being idiots, but rather because the shit we had to do before SPAs was craaaaaaaaaaazy. Jesus I remember the old jquery things. And before jquery... shiver... - I think SPAs are definitely not a one-tool-for-all-problems kind of thing. - Interestingly enough, SPAs can be a one-tool-for-all-problems kind of thing with SSR, that's what linkedin does. LI is an SPA with the ability to behave like a non-SPA via isomorphism.
WillPostForFood 6y ago
These are good reasons, but notice they are all about improving the experience for the developer, not the user.
- debaserab2 6y ago
  If you have a messy codebase with logic mimicked on both the back and front end its not just the developer experience that suffers - the user experience will eventually suffer too.
- Justsignedup 6y ago
  I mean isn't that what ruby on rails is? RoR's minimum response time is WAY slower than most other frameworks. Getting a ruby on rails page rendering in under 100ms is work, while other frameworks getting it under 50ms isn't much effort at all. Tradeoffs everywhere. If I needed to serve my pages to an area where downloading 1mb would take a minute and that was my core demographic, I will be making very different choices in tech than what most people have to write for.
dougmany 6y ago
I am curious what tools you are using. I am trying to upgrade Angular 1.4 to 1.7 and it is a nightmare. Has your method had any sort of time test for upgradability?
- nawgz 6y ago
  Angular 1 is ancient and terrible. I've been developing React for the last 5 years, times change and "best practices" change with them, but my 3 year old model / graph editor seamlessly upgrades across React versions, even if my eyes don't love the code like they once might've.

Quarrelsome 6y ago

The sort of garbage we ended up doing prior to SPAs justify SPAs. Writing a server to dynamically create a HTML page that also includes first pass content as well as potentially dynamic javascript to make the page interactive in "later passes" is just an ugly mix of client side execution and server side execution in one spot. The application just feels a lot more consistent when the client is just pulling data instead of being thrown away and recreated in the middle of a request made by a browser for a particular URL that is just one of a very long series of requests.

Justsignedup 6y ago
There are techniques for controlling complexity there, and often you can make a single-page react page which will encapsulate complex behaviors. Often a mix of the two helps. But you end up having one set of code managing the static page, and another for the api-based interactions. and then once you have api-based stuff product asks to add on a feature and a feature until you have mutliple SPAs. :P Code reuse is a big reason too, why write 10 different SPAs for one site, when you can write 1 SPA with a ton of code/tool re-use. I always end up taking 1 SPA and make 2-4 different SPAs out of it, each facing a different set of users, with different security/look requirements, but all underpinned by the exact same technology. So much headaches saved. Just to make it clear: - I agree that SPAs didn't come out of developers being idiots, but rather because the shit we had to do before SPAs was craaaaaaaaaaazy. Jesus I remember the old jquery things. And before jquery... shiver... - I think SPAs are definitely not a one-tool-for-all-problems kind of thing. - Interestingly enough, SPAs can be a one-tool-for-all-problems kind of thing with SSR, that's what linkedin does. LI is an SPA with the ability to behave like a non-SPA via isomorphism.

WillPostForFood 6y ago

These are good reasons, but notice they are all about improving the experience for the developer, not the user.

debaserab2 6y ago
If you have a messy codebase with logic mimicked on both the back and front end its not just the developer experience that suffers - the user experience will eventually suffer too.
Justsignedup 6y ago
I mean isn't that what ruby on rails is? RoR's minimum response time is WAY slower than most other frameworks. Getting a ruby on rails page rendering in under 100ms is work, while other frameworks getting it under 50ms isn't much effort at all. Tradeoffs everywhere. If I needed to serve my pages to an area where downloading 1mb would take a minute and that was my core demographic, I will be making very different choices in tech than what most people have to write for.

dougmany 6y ago

I am curious what tools you are using. I am trying to upgrade Angular 1.4 to 1.7 and it is a nightmare. Has your method had any sort of time test for upgradability?

nawgz 6y ago
Angular 1 is ancient and terrible. I've been developing React for the last 5 years, times change and "best practices" change with them, but my 3 year old model / graph editor seamlessly upgrades across React versions, even if my eyes don't love the code like they once might've.