The Stack Overflow Podcast

The pros and cons of the SPA

Episode Summary

In this episode we discuss the rise of the Single Page Application, or SPA. From humble beginnings around 2003, it has come to be a dominant approach for many large tech companies and an alluring option for smaller startups. But for simpler web projects, are there better alternatives?

Episode Notes

Pawel Skolski wrote this definition of the SPA in 2016. "A single-page application is an app that works inside a browser and does not require page reloading during use. You are using these type of applications every day. These are, for instance: Gmail, Google Maps, Facebook or GitHub.
SPAs are all about serving an outstanding UX by trying to imitate a “natural” environment in the browser — no page reloads, no extra wait time. It is just one web page that you visit which then loads all other content using JavaScript — which they heavily depend on."

Tom McWright recently sparked some good discussion in the developer world with his article, If Not SPAs, What? He had written before about his belief that SPAs had done little to reduce the complexity of web development, but hadn't really given readers other options. In his latest post, he tried to offer some possible alternatives. 

Our lifeboat of the week of the week goes to Glortho for explaining how to add http:// to url if no protocol is defined in javascript?


 

 

 

Episode Transcription

Sara Chipps What's the most wrong with CSS? 


 

Paul Ford Mhmm. Mhmm.


 

SC All of it.


 

[INTRO MUSIC]


 

Ben Popper Are you struggling to deploy cloud native applications to a hybrid cloud? Do you want to become familiar with Kubernetes and Istio? IBM Cloud has a set of free, hands on training, ebooks, and an always on free tier of services to help you learn. Visit IBM.biz/StackOverflow to learn more. That's IBM.biz/StackOverflow.


 

BP Hello, and good morning, everybody! Welcome to the Stack Overflow podcast. I'm Ben Popper here with my lovely co hosts.


 

PF Hey Sara and Ben!


 

SC Hey Paul and Ben!


 

PF Here we are, we're gonna do this.


 

BP Three humans speaking into the microphones. 


 

PF Mhmm! Talking 'bout coooooode! [Sara chuckles]


 

BP Alright, so an interesting article came up in our feeds. I thought we'd start there. Paul, we've talked about SPAs before. This is a two part series, the one that came up, If Not SPAs, What? And this is a follow up to Second Guessing the Modern Web.


 

PF That's my favorite 10,000 Maniacs song. [Ben & Sara chuckles] That's a little inside joke. Oh, alright, single page applications. So, let me give a 30 second history lesson. Used to be you wanted to make something on the web, you would make a bunch of HTML pages, then you'd put them on a server and people could reach them and they could connect the pages through links, then people started automating the back end. So you can make more and more pages out of databases instead of having to make each page like a text editor, then people started to add JavaScript and make the pages do things, that got really exciting. Maybe we would have animated documents, but instead, they realized we can make actual whole applications like Word or Google Docs. And that's why. So they're single page applications. And now they own everything. Now they are the internet. Right. So Tom MacWright, on MacWright.com has asked, you know, If Not SPAs, What? And sort of like what, you know, there are limits to this approach and what are some of the other ways? And, you know, I'd say I want to get your opinion, Sara, you can build a full fledged application on the web. And if you want to go really deep and use all sorts of underlying technologies, you can start to approach native speed--browsers are amazing their operating systems now. So there's immense power in there. But you don't need all that power. And that power includes a lot of complexity, like React is complex compared to making an HTML page. The argument in this article is there are other ways to do this to still do some really interesting app style thinking, and you don't have to use a full SPA framework, you can use things like turbolinks and Alpine and HTMLx. And what they do is they enhance existing pages with interactive functions that might even turn back to a server. Where do you? Where does your brain go? As we're talking about SPAs?


 

03:01
 


 

SC Yeah, I think that one thing that really needs to come into the conversation when we're talking about SPAs is, who are we building for? And what is it? Like, every restaurant needs an SPA. That's it. Just like every restaurant, every family reunion, [Ben laughs] every website that is never going to have more than 10 people on it at the same time. And you know that. And also, I think, even though it's like adding a framework is sometimes a little bit overkill. And then when it comes to applications that need to scale, that's when you start thinking about stepping away from an SPA, or building something a little bit more complex. But I think that there was a time where everyone was doing the SPA and I see that it makes it difficult when you're scaling to kind of split up those responsibilities among a larger team.


 

04:01
 


 

PF So we're talking about React, view, angular apps for most cases, right? And yeah, there's a lot because they get big, you have to do things like code splitting so that they can load more quickly and so on. So in this article, the focus is more like, you know, do you need all that? Couldn't you just dress up your HTML and you know, go to the ball and have a fun time? As opposed to and your approach, you're thinking more like, man, as these things get big, it gets to be a real pain, and suddenly you're trying to jam the equivalent of like a, you know, install Microsoft Office and it's 12 gigs into one webpage. And that's not cool. Settle down everybody.


 

BP Yeah, I think there's some of that here in the article. He was saying like, this guy has worked on Mapbox Studio and Observable and he thought React was a great choice. The other side of the sweet spot was the high performance parts aren't react for Mapbox gL and observable runtime, vanilla JavaScript, you know, this level of stress. For React uses just too high the cost of using it, payload parse time so on is too much for it to be included as part of an SDK. So I think, Sara, what you're getting to like, hey, for a family reunion for a restaurant like this is great. It's simple and makes it more interactive and functional that way. As you get bigger, the optimization gets messy, right? 


 

SC Yeah. But the thing, though, about React and View and some of those other models is the way they use components does make it easier, I guess you can kind of call that the micro front end pattern. Paul, I know you've played with these what I actually haven't worked on a larger scale React or Angular app. So they've always been either hack projects or things like that. Have you seen these things scale with teams? 


 

05:46
 


 

PF Yeah, I mean, it's like, you know, it's like anything, if everybody works together well, and you you clearly separate. Everything's a cludge, right. But state management is really hard. It's gotten easier, I think, with hooks in newest React, but everybody has their own approach to it. Code splitting is a challenge. Load time is a challenge as you get into larger and larger platforms. So it's all the regular stuff, I think it's you know, this would be stuff that a desktop programmer, someone when you boot up Xcode, or you're using Microsoft's developer tools, like you're not thinking about that part, you're thinking about other parts, you know, you don't get distribution for free via the web with absolutely no clicking. But you definitely aren't thinking like, how am I going to make it possible for my app to load without annoying people, right? Like that's kind of built into desktop programming. And it's not built, I mean, we're bootstrapping something that was supposed to share a couple, some physics papers into an application delivery framework where there are billions of clients, some of which are on really kind of clunky phones on slow mobile connections, right. And so you're, you're solving that problem with App delivery. And that's hard. So I'll give you an example. Like you have a, if you're working on something for the Indian market, let's say, and you're trying to get reach millions and millions of people, we did this with an education platform, your entire approach to development changes, because people are going to be on Android, and it's going to load slowly, you have less control over the network and the environment. So you're going to think about application delivery in a very sort of piecemeal way. And you're gonna want to try to optimize a lot of different things. And then on the other side, if you're, you know, building essentially like a first world app for admining things where they're going to be working out of a control center, and and you know, you know, that people, if it takes 10 seconds to load, it's going to be on a desktop, you can really think about that problem in a different way.


 

BP I had some experience doing some reporting about this, Paul, and some of the interesting things that came up talking about the Indian market, which is huge. People would love to, you know, have customers there and bring their services there. Not only do you have to think about lower broadband speeds, generally, but that people often are on like, pretty tight data plans. 


 

08:02
 


 

PF That's right. 


 

BP And you get everything down to a really small package. And then also, that often, they're like times of day when they can use the internet and time to do when they can't. So can you make it easier for them to download stuff, and then you know, runs later as opposed to streaming it live? Those are things that they consider when building from there that Yeah, we don't think about in our first world American software experience.


 

PF It's hard like it like we had a client who was living in that market. And so they were able to really walk through all of those things with us, but it is, yeah, it's a tremendous amount you don't know. Which I mean, you know, we had Sophie Schmidt on to talk about Rest of World that's a website entirely about what we don't know about those markets when it comes to technology. And it's, it's when you go and look at it and you read it, it's a lot of news, you're like, ''Oh, this was worth a website.''


 

BP I mean, it's not new anymore. But like, I think five years ago, people were always astounded by WhatsApp and these rise of Asian apps, especially in China, where it was a chat app. But then it became an entire OS. And they just kept cramming, more and more like you could play games, you could read news, you could chat, you could do whatever. But it was all in this one tiny, you know, phone app. And and that market gobbled it up. They loved it. Like as US apps were unbundling and taking things apart, making everything simpler. Asian apps are going in the totally opposite direction, like the app is your OS.


 

PF Don't forget that Apple has a limit on App size. So giant mega apps like Facebook, like Facebook is a big app. Before that app can go out to the world, they have to take things out because there's always more that they'd like to put in. And I mean, they're like sticker packs or whatever. Right, like, and so, here's what I think. I think that software delivery in app form is overvalued. But it aligns really well with essentially capitalism, with like getting people to buy goods and services, you give them the app that give you the money, right.


 

SC So you're saying specifically like, mobile apps?


 

09:56
 


 

PF Mobile apps or desktop apps or whatever, and I think we're kind of we're still fighting that Battle like how do I make the web behave like that? And, I think that if you really it, what is the web truly great at it's stuff like those notebooks, you know, or if you go to Observable, Observable HQ, and you kind of poke around there, it's about sort of being able to have as many documents as you want, and as many pictures and now as much video, but also, it's all in this kind of dynamic environment, you could be manipulating and playing with it. And so, to me, I always think, you know, if you're going to tell me about the economy, can you give me a slider? If you're going to show me a picture? Can you let me kind of remix it or play with it in some way? And so I feel that notebooks are actually probably the more web appropriate application delivery platform. 


 

SC Wowww! That's a take.


 

PF It's a take, right? Like that is. And it is, like, but they're less revenue friendly. Right? There's no, no one has a business model around notebooks. Whereas they definitely have a business model or on Twitter, like it's not--what I'd love to see is like a pipeline, where instead of like giant IDE leading to impenetrable app, you had notebook environment, where you could kind of wrap the notebook up progressively into a more and more app like experience, right. 


 

SC I think what you're doing is just fixing HTML, and CSS. [Ben laughs]


 

PF Well remember the web was gonna be read, write. That was always the goal in the beginning, and they couldn't figure it out. It was too hard for version zero, and it never quite could get there. So notebooks really strike me as a read, write web, right? Like, I'm gonna have basically full access to the full server if I if I need it, as well as the ability to manipulate and show things in the front end. And it gets really tricky, because where's my state? It's my state and JavaScript on the front is my state on the back end. It's the great, great wrestling match of a client server based, you know, anything. This is the parallel history of computing that. The funny thing about our industry is, we always assume, either or, like it's either gonna be all app based or whatever. But Mathematica over on planet Stephen Wolfram has been publishing applications in this way in an academic environment, mostly, for essentially decades as Mathematica notebooks right? Everybody loves them.


 

12:09
 


 

SC Yeah, it works really well, in that use case. But what about the use case where it's like really UI heavy?


 

PF Well, then you're gonna do an app, then you're gonna do an app. Absolutely. Yeah, you might prototype and play around and share ideas for the app inside of the notebook, right, like be a great way to communicate your different widgets inside of a product team. You know, a certain point is like react storybook, which lets you browse through components, and it gives you the code in order to quickly build your own apps, right? Like, how far away is that from the notebook model if it had live data in it, and you could manipulate the widgets directly? Like I mean, I think we're starting to play with that space where you're gonna drag and drop widgets into live environments, and then mess around with them, which is very, you know, kind of 1980s Xerox PARC style computing.


 

SC Yeah, like the Yahoo News Feed.


 

PF Wait, what's that? Tell me about that.


 

SC Like when everyone's homepage was Yahoo, you had all your little widgets.


 

PF That's right. 


 

SC You could drag and drop
 


 

PF Make your own hub! That's where we're going.


 

SC Yeah, it was great! I always had the Met scores.


 

PF Ohhh, are you a Mets fan? We didn't know that, Sara. That never came up. 


 

SC Yeah, I come from a long line.


 

PF Right. That's good. That's good.


 

BP Yeah. As you were designing your own personal little geo city, it had widgets for weather, sports, stock ticker. [Ben laughs]


 

PF Well, that was always a fantasy. Really, people would want to make their own feeds in environments. Look, the things I'm describing are for people who are developers, or developer Jason, you know, that is a tiny percentage of a percentage. And then the rest of human beings are going to, like want to participate by reading and making decisions about their own life and or by watching. 


 

BP Maybe the reason this guy wrote this article is because he's worked on Observable. And so.


 

PF Yeah, no, I think that that, I didn't know that I didn't process that. That's totally, if you're thinking about notebooks, because what you realize is you can kind of log into your terminal and have the full all the state and all the environment that you were playing around with yesterday, or just kind of back up, rather than this sort of compile test experience loop. And that, that does feel really fun.


 

14:08
 


 

[MUSIC]


 

BP It's that time of the show, y'all, we're gonna shout out a life butter. This one goes to glortho: how to add HTTP to a URL if no protocol is defined in JavaScript. So thank you very much. That question was asked six years ago. Just got an answer. 


 

SC Wow!


 

BP Good to see. Appreciate that.


 

PF Oh, it's good. Everything's, everything's going


 

SC That seems like a RegEx.


 

PF Yeah, frankly, all questions are RegEx questions, as I've learned in my time with Pearl.


 

BP If you can make the memorization happen, you can make it work with RegEx.


 

PF Ouuff.


 

BP Alright, y'all. I'm Ben Popper, Director of content here at Stack Overflow. You find me on Twitter @BenPopper. 


 

SC And I'm Sara Chipps, Director of Community here at Stack Overflow.


 

PF This is Paul Ford, friend of Stack Overflow. Check out my company Postlight. Love you, love your show!


 

[OUTRO MUSIC]