3 ms·

Being in the middle of a non-trivial SPA build, I can't agree that the technical difficulties are "solved", especially if you want to build on open source tech.

Being in the middle of a non-trivial SPA build, I can't agree that the technical difficulties are "solved", especially if you want to build on open source tech. Specifically, my project was prototyped in Firebase and for various reasons needs to be moved off. Now I'm left building a lot of plumbing that just isn't available outside of Firebase. In the end, our result will be less capable than the Firebase equivalent because we don't have time to engineer features like offline support and optimistic updates. There are a lot of tradeoffs to be made in order to avoid "hard problems" that are still very prevalent. I'll be happy to be proven wrong :)

dahauns 9y ago
But how is that a problem of SPAs in general? This sounds more like a problem of using Firebase for prototyping.
- bloudermilk 9y ago
  Firebase is a solution, not the problem. The problems are: * How do you allow users to continue using your SPA without a network connection? * How do you enable snappy and responsive UIs when the network is slow? * How do you synchronize state between client/server? These are just some of the "hard problems" that you'll face building an SPA. Firebase has its own solutions but many other tradeoffs. All I'm saying is that we don't have hardened open source solutions for these problems yet, in the same way that we have Rails/.Net Core MVC/Django for traditional websites.
  - mason55 9y ago
    > How do you allow users to continue using your SPA without a network connection? How do you do this with a traditional web site/app? > How do you enable snappy and responsive UIs when the network is slow? How do you do this with a traditional web site/app? > How do you synchronize state between client/server? At worst you do it just like a traditional web site/app True, these are all problems that you deal with when building a single-page app, but the worst case scenario is that you end up with some of the same problems as traditional web sites. None of these are new problems that are introduced by the fact that you're building an SPA. The new problems that SPAs introduce are things like history/back button breaking and how do you let users bookmark things or share deep links.
    - dceddia 9y ago
      I think user expectations (and/or product/UX expectations) have changed along with the rise of the SPA. In the days of server-rendered apps before SPA was a thing, the answer to all of those questions would've been some version of "You don't," followed by "Why would anyone expect a website to work offline, or be fast when the network is slow?" But SPAs are in a sort of "uncanny valley" where they sorta look and feel like native apps and users expect them to behave like native apps but doing that is much more work than building a simple webapp. There's a bit of cargo culting here too, I think. Not everything needs offline support and instant updates from Firebase. But $fancy_native_mobile_app has it, so our imitation SPA must too.
      - ggg9990 9y ago
        Also, the first rise of the Web was enabled by residential broadband adoption, so that most of your site’s users had a stable internet connection. Now that Mobile devices are the most common, flaky networks are back to being a problem.
  - thruflo22 9y ago
    This is true and these are the things to be asking when planning to develop a SPA. How do I manage state? How do I handle offline and intermittent? Btw, http://hood.ie http://hood.ie is one good option.
  - dbetteridge 9y ago
    serviceworkers for caching content to be available offline (can cache most recent result from an api call so you don't even need to change anything on the frontend) localstorage for offline state , if your serviceworker reports the app is offline then any changes of state go into localstorage and are queued for updating when the network is back online. Any changes to the server side state can be diffed against the localstorage changes and you deal with it according your priorities. i.e is the user always right or does the server take priority?

dahauns 9y ago

But how is that a problem of SPAs in general? This sounds more like a problem of using Firebase for prototyping.

bloudermilk 9y ago
Firebase is a solution, not the problem. The problems are: * How do you allow users to continue using your SPA without a network connection? * How do you enable snappy and responsive UIs when the network is slow? * How do you synchronize state between client/server? These are just some of the "hard problems" that you'll face building an SPA. Firebase has its own solutions but many other tradeoffs. All I'm saying is that we don't have hardened open source solutions for these problems yet, in the same way that we have Rails/.Net Core MVC/Django for traditional websites.
- mason55 9y ago
  > How do you allow users to continue using your SPA without a network connection? How do you do this with a traditional web site/app? > How do you enable snappy and responsive UIs when the network is slow? How do you do this with a traditional web site/app? > How do you synchronize state between client/server? At worst you do it just like a traditional web site/app True, these are all problems that you deal with when building a single-page app, but the worst case scenario is that you end up with some of the same problems as traditional web sites. None of these are new problems that are introduced by the fact that you're building an SPA. The new problems that SPAs introduce are things like history/back button breaking and how do you let users bookmark things or share deep links.
  - dceddia 9y ago
    I think user expectations (and/or product/UX expectations) have changed along with the rise of the SPA. In the days of server-rendered apps before SPA was a thing, the answer to all of those questions would've been some version of "You don't," followed by "Why would anyone expect a website to work offline, or be fast when the network is slow?" But SPAs are in a sort of "uncanny valley" where they sorta look and feel like native apps and users expect them to behave like native apps but doing that is much more work than building a simple webapp. There's a bit of cargo culting here too, I think. Not everything needs offline support and instant updates from Firebase. But $fancy_native_mobile_app has it, so our imitation SPA must too.
    - ggg9990 9y ago
      Also, the first rise of the Web was enabled by residential broadband adoption, so that most of your site’s users had a stable internet connection. Now that Mobile devices are the most common, flaky networks are back to being a problem.
- thruflo22 9y ago
  This is true and these are the things to be asking when planning to develop a SPA. How do I manage state? How do I handle offline and intermittent? Btw, http://hood.ie http://hood.ie is one good option.
- dbetteridge 9y ago
  serviceworkers for caching content to be available offline (can cache most recent result from an api call so you don't even need to change anything on the frontend) localstorage for offline state , if your serviceworker reports the app is offline then any changes of state go into localstorage and are queued for updating when the network is back online. Any changes to the server side state can be diffed against the localstorage changes and you deal with it according your priorities. i.e is the user always right or does the server take priority?