Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes

[Music] there's an active debate happening in front end circles about the right way to build websites and like most front end debates both sides are really attacking a caricature of the other on the one hand we've got advocates for what is often referred to as modern web development on the other hand we have people who look at the state of modern mode development and argue that it's time for a bit of a come to jesus moment about the path that we're on for brevity i'm going to call these camps the modernists and the traditionalists but i don't want you to read any judgment into those terms my goal in this talk is to try and tease out some of the claims and counter claims and present what i think is going to become an increasingly popular approach to web development over the next few years the debate is often reduced to mpa or multi-page app versus spa or single page app that framing really doesn't either side justice but nevertheless it's a good place to start a multi-page app is really just a website when you go to that site after all the dns stuff happens you connect to a server or a cdn in front of the origin server and it sends you some html that html might have been dynamically generated for that specific request it might be a cached version of a response that was generated earlier that day or it might come from a static file server that was updated the last time the app was somewhere in that html perhaps there's a link if you click it the same thing happens again the browser connects to a server gets some more html and when it gets enough of a response the existing page is removed and the browser starts rendering the new page this is a pretty simple model that has worked well for a long time but as you all know things have changed a bit over the last couple of decades browsers have got a lot more capable user expectations have risen and we find that a lot of sites need client-side interactivity which means javascript the more complex the application the more javascript you're going to need and so if you're building a multi-page app you might find yourself in a bit of an opposition because the minute you have any client-side updates you're actually building two apps one for the initial render that might be php or rails or even handoff.html and another app for subsequent updates that happen in javascript two apps written in two languages possibly by two different teams that are nevertheless very tightly coupled to each other i could be wrong but i'm pretty sure the web is the only place where that's considered remotely normal and so a few years ago people started building single page apps instead of the content coming down the wire as html you'd get a blank page with a script tag that loaded the code that would render the app now if that rendered content included a link clicking on it wouldn't necessarily result in a round trip back to the server in some cases you might need to get a little bit more javascript or a little bit more data but either way it's going to update the page in place rather than nuking everything which means that navigation is going to feel instantaneous or dare i say app-like there's just one problem with single-page apps they're terrible here's a non-exhaustive list of things people will tell you are terrible about spas you will need to load a bloated javascript framework it's always bloated of course the performance is worse than a multi-page app it will probably be buggy accessibility will suffer your code base will sit up a teetering pile of duct tape tooling webpack apple all that other stuff and it's less resilient it won't work without javascript unfortunately these criticisms are largely valid this is one of the most popular single page apps in the world if javascript fails or is disabled this is all you get if it works then after you've downloaded a literal megabyte of javascript that's gzip by the way the amount of code the browser has to actually parse and evaluate is closer to five megabytes you can look at a profile page containing text and images if you click on one of those images it'll create a new history entry but if you then click the back button the app doesn't navigate now i don't want to overstep the mark here i'm not privy to the technical constraints and business requirements that led to these choices but at the same time come on people if the best front end engineers in the world can't make text and images work without five megabytes of javascript then maybe we should just give up on the web platform people sometimes look at you askew if you suggest that most websites should be functional without javascript but javascript failing is a fact of life i often send people to this website by stuart language to illustrate why and jslist users are systematically underrepresented in analytics because analytics tools use javascript also many single page apps violate your expectations of the browser's behavior in a way that's at best disorienting and at worst exclusionary to people with accessibility requirements normally on the web if you middle click or command click a link it will open in a new tab on this food delivery website that's ignored it will navigate in the current page instead if you then click the back button the layout will jump around for a bit before a nausea inducing scroll back to where you were there's lots of these little accessibility details that spas often get wrong focus management scroll management navigation announcements page titles command click behavior that collectively make the entire web a less predictable and less accessible medium we shouldn't accept that i pick real world examples albeit more or less at random because we need to reckon with the fact that single page apps have kind of ruined the web so the backlash to modern web development is understandable but it's important to remember that spas do in fact solve some real problems with the traditional approach they also give you new capabilities here's something you can't do in a traditional app you can't navigate from one page to another while continuing to play media in an spa that's extremely straightforward here's another you can't use client-side state management that persists across navigations in this app the first load contains a subset of my data if i scroll i load more if i then click into one of these items then click back i should be at the same place in the list even though a fresh page load would exclude everything except the first tranche of results this sort of thing is a little tricky to pull off in a single page app but it's essentially impossible in a multi-page app or consider transitions native app designers understand the importance of motion and object constancy in user interfaces but on the web we tend to teleport instantly from one place to another not because it's better but because that's all browsers are capable of in a single page app we can change that i should note that there's a proposal in the works to add navigation transitions to the platform and it often gets brought up in these conversations but look i'm glad that it's happening but don't imagine for a moment that it'll be as powerful as single page app transitions can be finally something that very often gets overlooked whenever we talk about performance and javascript load is that the main culprit isn't front end frameworks it's shitty ad tech and other third-party javascript in a single page app you only have to load those lousy scripts once in a multi-page app you have to load them for every single navigation even though the scripts are hopefully cached you still have to evaluate them on every page load which gives them plenty of opportunity to block the main thread and degrade the user experience so let's look at some of the pros and cons of these two approaches side by side in particular let's look at the mpa advantages you probably already know that most modern frameworks support server-side rendering if you're building everything by hand then you might have a bit of a hard time setting everything up but if you're using a so-called meta framework like next or nuxed or spell kit then you get that behavior out of the box so you don't need to sacrifice that fast initial load similarly if an app uses server-side rendering instead of delivering an empty shell it will have the same resilience as a traditional app your content will be universally available and as long as you're using links and forms correctly you can even have javascript free interactivity just the same as if you're using links and forms in hand authored html what about accessibility if you're manually implementing navigation logic and so on then you'll probably end up making mistakes here but again modern meta frameworks take this stuff pretty seriously the one big remaining thing is language choice if you're already part of the anti-javascript resistance then nothing i say in the rest of this talk is going to matter that much but i'm going to get into this later that ship might have sailed i do need to take a moment to shout out to projects like phoenix live view stimulus reflex and so on which are solving the two code bases problem from the other end by letting you write code that pushes dom updates from a server over websockets i'm a little skeptical about just how far you can push that model but it's a pretty cool field of experimentation so we can build apps that combine the best aspects of traditionalism and modernism fast initial load accessibility resilience instant navigation a cohesive code base and capabilities that used to be out of reach what should we call them well we already have a sea of acronyms that we use to describe all these various techniques so the risk of being all xkcd-927 maybe there's a new acronym that we could invent what's better than a spa html optimized through techniques users believe in super awesome usable neato apps better applications through html hyper-optimized using scripts etc javascript application centered on usability zippiness and zen inducement okay these are all terrible i'm sorry i really thought that inspiration would strike and i would be able to come up with something in time for the conference but that didn't happen so i started googling to see if there's a word for the synthesis of traditionalism and modernism and it turns out that the interior design community has thought about this they call it transitional design i'm going to read a paragraph from apartmenttherapy.com whereas traditional design can sometimes feel prim and stuffy and modern design can lean too heavily on the sleek and streamlined look transitional design samples elements from each aesthetic to form an equally classic and fresh feel think of transitional design as having the best of both worlds they could be talking about web development i actually really love this and not just because i'm a sucker for interior design porn there's an obvious linguistic connection to the kinds of transitions i was talking about earlier for too long we've modeled web apps as discrete pages that you jump to rather than cohesive spaces that you move around and it's not because one mode is universally more appropriate than the other it's because our thinking has been constrained by the medium i often recommend this website hudson is where motion design is for tv and film imagine what user interfaces could look like if we were afraid of our technological constraints i want a web with more design freedom and transitions are a big part of that but leaving all that aside this word transitional resonates with me it's a humble word that recognizes that we're in a constant state of evolution it doesn't pretend to have all the answers but it promises that we're going to keep seeking them it looks towards the future but it's respectful of the past in short it's everything we should aspire to be so jam stack conf let's coin a new term transitional apps let's see if we can get this hashtag trending in fact you know what i think i just figured out the title for this talk i want to talk a little bit about what transitional apps look like in practice particularly as it relates to sveltkit which is a meta framework we're currently building but first i need to talk to the eye rollers in the audience because i guarantee there's a few of you some people claim that you can get the benefits of single page apps without writing javascript the thing in rails circles at the moment is html over the wire or hotwire which is a truly fantastic name the idea is that the state and the rendering logic live on the server but you make the app more like an spa by sending partial chunks of html instead of complete pages whenever there's an update the marketing page says this makes you more productive without sacrificing any of the speed or responsiveness associated with the traditional single page application citation needed look i think this is a really cool idea but i'm not totally convinced it works in practice it turns out it's really hard to have things like optimistic updates when the rendering logic lives on the server so the responsiveness of your app is effectively dictated by network latency i don't want to be too critical of this idea because it's a good fit for a certain class of application but i do think we need to be honest about its limitations it's not hot wire but a rails app that often gets mentioned in these conversations and uses a similar technique is github i love github i rely on github and back in the day it was one of the first big applications that used the history api to do client-side navigation and it was a real wow moment but the front end is super buggy let's say you go to your issues list and click on one of the unreads you decide you don't want to deal with it right now so you back out hang on a minute it's still got the blue unread marker refresh the page and it's fixed fine actually let's close that issue hang on we still have an open issue or do we it turns out that when you send partial html updates instead of having the rendering logic in the state live in the same place you get inconsistencies everywhere i've seen prs that have both the green open lozenge and the purple merged lozenge on the same page it's incredibly disorienting to the extent that i obsessively refresh every github page after navigation almost as a nervous tick another example if you try and interact with the page while actions are running there's a good chance that it will go haywire why because we're sending partial html updates instead of data this kind of fragility is essentially baked into this development model you can fix it but you'll always be fighting an uphill battle another common objection is that documents and apps are fundamentally different and it's senseless to use app development tools to build document sites i definitely agree with the sentiment that you should use the right tool for the job but i want to question the underlying premise here look at this product page from an e-commerce site is it a document or an app clearly it's a little bit of both it's mostly text and images but it also has buttons that do stuff like add to cart my day job involves building interactive widgets that live on new york times article pages new sites are classic examples of the document-based web but this pretty clearly has at like characteristics we talk about documents versus apps zero dichotomy but it's not it's a spectrum when we erase the stuff in the middle we do the web a great disservice it's a medium that by its very nature resists definitional boundaries now of course you can point to the extremes on the spectrum and say they don't count but there's no reason your personal blog shouldn't have instant navigation for example and if you wanted to add a video player containing your conference talks that people could watch as they continue to navigate around your site then you shouldn't have to throw away your old stack and begin afresh with a new foundation a lot of people won't be persuaded by all this because the real reasons for the anti-modern web development backlash aren't technological they're cultural some folks just really don't want to use javascript or js adjacent technologies it's like i get it i don't agree with it i think javascript is actually pretty great but i do understand it but like it or not the trends are in javascript's favor and there's one in particular that i think is going to become especially relevant over the coming years that's edge computing we've already got things like cloudflare workers netflix net lift flight net lift by we've already got things like cloudflare workers net life edge handlers dino deploy and we're going to see more entrants in this space what these platforms let you do is run code cheaply close to where the user is with none of the cold start headaches that you associate with lambda and none of the maintenance or scaling concerns that come with running servers what they all have in common is that they're all built on v8 because of wasm you can theoretically run just about anything at the edge but realistically i think we can expect javascript to have a significant home team advantage transition on apps remember to use the hashtag a really well placed to take advantage of this trend because they have another really interesting characteristic they can transition between different environments depending on what's most appropriate whether that's on your server or in the cloud or at the edge or on the user's device be that on the main thread or in a service worker or web worker you might think this all sounds like too much javascript and that brings us to the final big objection which is that modern websites serve too much js to the browser as we talked about earlier the biggest culprit when it comes to javascript bloat is usually all the third-party script and modern web apps actually have a very significant advantage here because they can amortize the cost over the duration of the session rather than paying in full on every navigation but there is some real truth here if you have a server-ended page and you're hydrating it with an interactive client-side app then you will end up serving data and component code that isn't strictly necessary this is probably the least compelling part of the modern web story right now but it's a very active area of research and development the react team is working on server components which is sort of like html over the wire except vastly more sophisticated marco is doing something called partial hydration which means skipping the code and data for non-interactive subtrees quick is aggressively lazy loading everything so you don't load code until you need it for a specific interaction astro is tackling this problem with so-called islands architecture which is less granular than marco but gets you most of the way there svelt the framework i help maintain uses a compiler to make the cost of the framework as low as possible and though we don't yet do any kind of partial hydration you can easily turn off hydration at the page level and i guess that's as good a segue as any into a little demo of what we on the svelt team have been working on recently sveltkit our meta framework is essentially a toolkit for building transitional apps if you want to follow along at home please do first we do npm and it's felt at next once we hit a stable release soon it'll just be npm in its felt follow the prompts and your project gets scaffolded to the current directory or whichever directory you specify install dependencies then run npm npmrundev-open to start the development server and open the app in a new tab this is a simple demo app this page has a little dash of client-side interactivity just so you can check that the server-rendered html hydrated as expected if we follow this instruction and edit source slash root slash index.felt we can see what happens if we edit the source code it updates the page immediately using veet's hot module reloading in fact if we turn on vs code auto saving and turn the delay right down we can see that hot module reloading keeps up with our keystrokes though i don't necessarily recommend it if you're editing styles then component state will even be preserved which makes it super easy to tweak the design of your site if we do npm run build followed by npm run preview we can look at a production build of the site let's navigate to the about page unlike the home page there's no client side interactivity needed here so we're able to render this page without any javascript at all we can check that by viewing the page source all markup no script just as it should be and because this page is marked as pre-renderable in the source code when we actually deploy this app whether we deploy it as a node server or with netlify or the cell or aws or cloudflare workers or dino or whatever else requesting this page won't involve any server-side rendering it'll just serve a static file in most cases via cdn without you even needing to configure anything same is true for the home page in fact finally if we go over to our to-do's page we can start adding some reminders do this do that do more stuff if we hit this page directly it's dynamically server rendering with our data so we can't pre-render it importantly if we disable javascript this page still works because we're using progressively enhanced form submissions to send data back to the server this is the briefest possible overview of asphalt kit app but let's recap we have a mix of static pre-rendering with client-side interactivity a pre-rendered page with zero javascript a dynamically server-rendered page with interactivity that works without javascript but upgrades the user experience with javascript an api endpoint that powers that page and we can deploy all of this using a combination of edge functions and cdn static files without having to administer any of it all from a single code base with an unbelievable development experience powered by veet this is what transitional apps are all about and whether or not that name catches on hashtag the ideas are here to stay so the next time you hear people saying that multi-page apps are best or single page apps are best remember the truth is way more nuanced and it's way more exciting thank you for watching [Music] sit jam stack sit good boy

Channel: Jamstack TV

Views: 3,618

Rating: 4.9729729 out of 5

Keywords:

Id: 860d8usGC0o

Length: 19min 12sec (1152 seconds)

Published: Wed Oct 06 2021

Reddit Comments

[u/grich12]

If anyone prefers a written format (or wants something that's easier to reference), I transcribed the talk: https://geoffrich.net/posts/rich-harris-jamstack-conf-2021/

[u/DoomGoober]

Thanks for posting this. Since I am using Svelte to write a game, I have been totally out of the SvelteKit discussion. This video really explains what SvelteKit is and why you'd want to use it (it also talks about non-SvelteKit frameworks that solve the same or similar problems.)

[u/Gyfis]

Great talk! Glad Rick mentioned Hotwire, too - and it’s true it comes with its own issues

[u/buhrmi]

that instagram burn

[u/zarmin]

Really great talk!!

[u/trailrun80]

SPA is the only option sometimes. If we're talking apps, it's apps. Business apps, SaaS, games, chat apps, etc. Apps are not websites.

Rich knows that and he actually mentions it in podcast https://webrush.io/episodes/episode-153-single-page-application-vs-multi-page-application-with-rich-harris saying you can do everything you want with SPAs but not with MPAs.

[u/joakims]

Great talk! I like the name/hashtag.

My personal conclusion:
SPA is a horrible hack.
SvelteKit is also a hack, but a damned good one.

Edit: Don't be so touchy, downvoters. It was a compliment! As for Svelte I meant hack as in "An interesting technical achievement". After all, it does compile from non-standard files to standard web tech. And very cleverly so.