1. 13
  1.  

  2. [Comment removed by author]

    1. 1

      Just to drill down here; so there is no type of application you feel can benefit from spa approach? For example the “one page with many possible views” like an email client? You are saying the best way to view emails in such an app is on page per email, in your estimation?

      1. [Comment removed by author]

        1. 2

          And how do you back that claim?

          1. [Comment removed by author]

            1. 1

              If you see this solely from the performance or accessibility point of view, then yes, the web as it is today is bloated.

              On the other end, if you see this in term of evolution (what you can do nowadays on the web) then I don’t mind.

          2. 1

            I’m pretty sad to disagree with you on this one.

            The web solves distribution in a way that no other platform does. If it’s for-profit, the returns are much better when you ‘write a book with oil paint’ instead of trying to convince people to download and install software (see eg patio11’s writeup of doing SAAS vs a native app).

            It certainly sucks that there’s no better way.

      2. 3

        It’s hard to reason about this sort of thing in the dark. I like Alex Russell’s explanation of performance budgets for shining a bit of light on front-end behavior. Webpagetest has a “first interactive” measurement that seems to be a decent stand-in for Alex’s time-to-interactive metric, and it lets you specify network performance and location to boot.

        Overall, it’s much simpler to talk about tradeoffs when you have some initial objective numbers to kick around. I have at various points in my career been for and against doing everything client side: I delivered Flash applications for a few years, and more recently I commissioned a mostly-front-end project where we determined the performance budget upfront. The sad logjam of a silver bullet duel between opinionated developers can only be broken by agreeing on a goal and a way to measure it.

        1. 2

          bad performance on low-end devices (and I suspect higher battery consumption, but can’t really proof this one)

          I’d actually argue the opposite here. With a traditional web app you’re sending HTML across, and you’re doing a lot of parsing each time a page loads. Parsing HTML is an expensive operation. With SPA style apps, you load the page once and pass JSON around containing just the data that needs to be loaded. So, after initial load, you should expect to get better resource utilization.

          1. 6

            I’m not sure that parsing HTML is as expensive as parsing (and compiling) Javascript though. Of course you’d pay a high price at each request of an e-commerce web app, but if you want to read an article on some blog, it is faster when you don’t have to load all of Medium’s JS app.

            Browser vendors are trying really hard to fasten the startup time of their VM but the consensus is that to get to Interactive fast, you should ship less JS or at least less JS upfront.

            Obligatory pointer to Addy Osmani’s research on the topic https://medium.com/@addyosmani

            1. 1

              Parsing XML is notoriously expensive. In fact, it’s one of the rationales behind Google’s protocol buffers. Furthermore, even if the cost of parsing XML and JSON was comparable, you’d still be sending a lot more XML if you’re sending a whole page. Then that XML has to be rendered in the DOM, which is another extremely expensive operation.

              To sum up, only pulling the data you actually need, and being able to repaint just the elements that need repainting is much faster than sending the whole page over and repainting it on each update.

              1. 3

                The problem is that incremental rendering is often paired with a CPU intensive event listener and digest loops and other crud causing massive amounts of Javascript for every click and scroll.

                1. 1

                  That’s not an inherent problem with SPAs though, that’s just a matter of having a good architecture. My team has been building complex apps using this approach for a few years now, and it results in a much smoother user experience than anything we’ve done with traditional server-side rendering.

            2. 4

              This seems like the exact kind of thing we can empirically verify. Do you know of any good comparisons?

              1. 1

                I haven’t seen any serious comparisons of the approaches. It does seem like you could come up with some tests to compare different operations like rendering large lists, etc.

              2. 2

                I’m not so sure, a modern HTML parser is fairly efficient. On top of that, a lot of stuff is cached in a modern browser.

                My blog usually transfers in under 3 KB if you haven’t cached the page, around 800 B otherwise (which includes 800 bytes from Isso). My website uses less than 100KB, most of which is highly compressed pictures.

                Most visitors only view one page an leave so any SPA would have to match load performance with the 3 KB of HTML + CSS or the 4KB of HTML+CSS plus 100KB of images…

                A similar comparison would be required for any traditional server-side rendering application; if you want to do it in SPA, it should first match (or atleast come close to) the performance of the current server for the typical end user.

                SPAs are probably worth thinking about if the user spends more than a dozen pages on your website during a single visit and even then it could be argued that with proper caching and not bloating the pages, the caching would make up a lot of performance gains.

                Lastly, non-SPA websites have working hyperlink behaviour.

                1. 1

                  I think that if your site primarily has static content, then server side approach makes the most sense. Serving documents is what it was designed for after all. However, if you’re making an app, something like Slack or Gmail, then you have a lot of content that will be loaded dynamically in response to user actions. Reloading the whole page to accommodate that isn’t a practical approach in my opinion.

                  Also, note that you can have working hyperlink behavior just fine with SPAs. The server loads the page, and then you do routing client-side.

                  1. 1

                    Also, note that you can have working hyperlink behavior just fine with SPAs. The server loads the page, and then you do routing client-side.

                    That’s how it would work in theory, however, 9/10 SPAs I meet don’t do this. The URL of the page is always the same, reloading looses any progress and I can’t even open links in new tabs at all or even if I can, it just opens the app on whatever default page it has.

                    Even with user content being loaded dynamically, I would considering writing a server app unless there will be, as mentioned, a performance impact for the typical user.

                    1. 1

                      That’s a problem with the specific apps, and not with the SPA approach in general though. Moving this logic to the server doesn’t obviate the need for setting up sane routing.

                      1. 1

                        I’ve sadly seen SPA done correctly only rarely, it’s the exception rather than the rule in my experience.

                        So I’m not convinced it would be worth it, also again, I’m merely suggesting that if you write an SPA, it should be matching a server-side app’s performance for typical use cases.

                        1. 1

                          I agree that SPAs need to be written properly, but that’s just as true for traditional apps. Perhaps what you’re seeing is that people have a lot more experience writing traditional apps, and thus better results are more common. However, there’s absolutely nothing inherent about SPAs that prevents them from being performant.

                          I’ve certainly found that from development perspective it’s much easier to write and maintain complex UIs using the SPA style as opposed to server-side rendering. So, I definitely think it’s worth it in the long run.

                          1. 1

                            I’ve built enough apps both ways now to feel confident weighing in.

                            If you build a SPA, your best case first impression suffers (parsing stutters etc), but complex client side interaction becomes easy (and you can make it look fast because you know which parts of the page might change).

                            I no longer like that tradeoff much; I find too few sites really need the rich interactivity (simple interaction is better handled with jquery snippets), and it’s easier to make your site fast when there are fewer moving parts.

                            This might change as the tooling settles down; eg webpack is getting easier to configure right.

                            1. 2

                              The tooling for Js is absolutely crazy in my opinion. There are many different tools you need to juggle, and they’re continuously change from under you. I work with ClojureScript, and it’s a breath of fresh air in that regard. You have a single tool for managing dependencies, building, testing, minifying, and packaging the app. You also get hot code loading out of the box, so any changes you make in code are reflected on the page without having to reload it. I ran a workshop on building a simple SPA style app with ClojureScript. It illustrates the development process, and the tooling.

              3. 2

                A lot of the cons are actually design/implementation problems that are quite common and correlated in SPA’s but not truthfully caused by them.

                Back button not working ?

                Browsers and most common js frameworks have good solutions for that. Check your design/implementation.

                Open in a new tab not working ?

                The same. Check your design/implementation.

                Refresh not working ?

                The same. Check your design/implementation.

                …feels like blaming vcs’s for being bloat with binary trash everyone puts there; or blaming wordpress sites for having huge high-res images; or any other kind of “you are using it wrong” tech problems.

                The author is right, the current state is sad, SPA’s are a good approach to certain current problems but they are not a silver bullet.