In this episode of The Smashing Podcast, we’re talking about The Transitional Web. What is it, and how does it describe the technologies we’re using? Drew McLellan talks to Chris Ferdinandi to find out.
- Connect with Chris Ferdinandi and read his posts on his website
- What’s The Perfect Design Process? written by Vitaly Friedman
- Sustainable Design Toolkits And Frameworks written by Cosima Mielke & Geoff Graham
- The UX Of Flight Searches: How We Challenged Industry Standards written by Robert Goesch
- Shines, Perspective, And Rotations: Fancy CSS 3D Effects For Images written by Temani Afif
- How To Become A Better Speaker At Conferences written by Andy Budd
Drew: He’s the author of the Vanilla JS Pocket Guide series, creator of the Vanilla JS Academy Training Program and host of the Vanilla JS Podcast. We last talked to him in late 2021 where we asked if the web is dead, and I know that because I looked it up on the web. So, we know he is still an expert in Vanilla JS but did you know he invented fish and chips? My smashing friends, please welcome back Chris Ferdinandi. Hi, Chris, how are you?
Chris: I’m smashing, thank you so much. How are you today, Drew?
Drew: I’m also smashing, thank you for asking. It’s always great to have you back on the podcast, the two of us like to chat about maybe some of the bigger picture issues surrounding the web. I think it’s easy to spend time thinking about the minutiae of techniques or day-to-day implementation or what type of CSS we should be using or these things but sometimes it is nice to take a bit of a step back and look at the wider landscape. Late last year, you wrote an article on your Go Make Things website called The Transitional Web. What you were talking about there is the idea that the web is always changing and always in flux. After, I don’t know how long I’ve been doing this, 25 years or so working on the web, I guess change is pretty much the only constant, isn’t it?
Chris: It sure is. Although, to be fair, it feels like a lot of what we do is cyclical and so we’ll learn something and then we’ll unlearn it to learn something new and then we’ll relearn it again just in maybe a slightly different package which is, in many ways, I think the core thesis of the article that you just mentioned.
Drew: And is that just human nature? Is that particular to the web? I always think of, when I was a kid in the ’80s, the 1980s, okay, so we’re talking a long while back-
Chris: It was a wild time.
Drew: One of the pinnacles that, if you had a bit of spending power, one of the things you’d have in your living room was a hi-fi separates. So, you’d have a tape deck, maybe a CD deck, an amplifier and I always remember as a kid, they’d all be silver starting off and those were the really cool ones. And then after a while, a manufacturer would come out with one that wasn’t silver, it was black and suddenly black looked really cool and all the silver stuff looked really old. And so, then you’d have five years of everything being in black and then somebody would say, “Oh, black’s so boring. Here’s our new model, it’s silver,” and everyone would get really excited about that again. I feel like somehow the web is slightly and, as I say, maybe it’s a human nature thing, perhaps we’re all just magpies and want to go to something that looks a bit different and a bit exciting and claim that’s the latest, greatest thing. Do you think there’s an element of that?
Chris: Yeah, I think that’s actually probably a really good analogy for what it’s like on what our industry has a tendency to do. I think it’s probably bigger than just that. I had a really, I don’t want to say a really good thought, that sounds arrogant. I had a thought, I don’t know if it was good or not, I forgot what it was.
Drew: Oh, it’ll come back.
Chris: So, I can’t tell you but it was related as you were talking.
Drew: I bamboozled you with talk of hi-fi separates.
Chris: Yeah, no, that’s great. It’s great.
Chris: And so, the output looks a lot more traditional DOM manipulation but the input looks a lot more like something you might write in Reactor view. So, I think that’s pretty cool. It’s not without, in my opinion, maybe some holes that people can fall into and I’m starting to see some of those tools do the, hey, we solved this cool thing in an innovative way so let’s go and repeat some of the mistakes of our past but differently traps and we can talk about that, that didn’t make it into the article that you referenced. I recently wrote an update looking back on how things are changing that talks about where they’re headed.
Chris: But I think one of the big things in my article, The Transitional Web, was this musing about whether these tools are the future or just a transitional thing that gets us from where we are to where we’re headed. So, for example, if you’ve been on the web for a while, you may remember that there was a time where jQuery was the client side library.
Drew: It absolutely was, yeah.
Drew: jQuery was everywhere.
Chris: Yeah. And not that you couldn’t get by without it but doing something like getting all of the elements that have a class was incredibly difficult back in the, i.e., six through eight era. And jQuery made it a lot easier, it smoothed things out across browsers, it was great. But eventually browsers caught up, we got things like querySelector and querySelectorAll, the classList API, cool methods for moving elements around like a pen and before and after and removed. And suddenly, a lot of the stuff that was jQuery’s bread and butter, you could just do across any browser with minimal effort. But not everything, there were still some gaps or some areas where you might need polyfills.
Chris: And so, you started to see these smaller tools that were … jQuery, they did some of the things but they didn’t do everything so the ones that immediately come to mind for me are tools like Umbrella JS or Shoestring from the folks over at Filament Labs. And the thing with those tools is they were really popular for a hot minute, everyone’s like, “You don’t need jQuery, use these,” and then the browsers really caught up and they went away entirely. And actually, even before that fully happened, you started to see tools like React and Vue and Angular start to dominate and just, really, people either use jQuery or these other tools, they don’t touch Umbrella or Shoestring at all.
Chris: So, I think the thing I often wonder is are tools like Preact and Solid and Svelte and Astro, are those more like what reacted for the industry or more like Umbrella and Shoestring where they’re just getting us to whatever’s next. At the time that I wrote the article, I suspected that they were transitional. Now, I think my thoughts have shifted a little bit and I feel like tools like Preact and Solid are probably a little bit more and Petite Vue who are … You called it something weird because you’re British, I forget, Petty Vue or something but-
Drew: Petite Vue, yeah.
Chris: No, I’m just teasing, I’m sorry. I love you, Drew.
Drew: I was attempting to go for the French so …
Chris: Right? Sorry, I have the way you guys say herb stuck in my head now instead of herb and I just can’t. So, yeah, I feel like those tools are potentially transitional and the what’s next just as an industry is, in my opinion, and a lot could change in the next year or three, the way I’m feeling now, it seems like tools like Astro and Svelte are going to be that next big wave at least until browsers catch up a lot. So, in my opinion, the things that browsers really need to have to make a lot of these tools not particularly necessary is some native DOM diffing method that works as easily as inner HTML does for replacing the DOM but in a way that doesn’t just destroy everything.
Chris: I want to be able to pass in an HTML string and say make the stuff in this element look like this with as little messing up of things as possible. And so, until we have that, I think there’s always going to be some tooling. There’s a lot of other things that these tools do like you can animate transitions between pages like you would in SPA. We’ve got a new API that will hopefully be hitting the browser in the near future, it works in Chrome Canary now but nowhere else, your transitions API. There’s an API in the works for sanitizing HTML strings so that you don’t do terrible cross-site scripting stuff, hasn’t really shipped anywhere yet but it’s in the works.
Chris: So, there’s a lot of library-like things in the works but DOM diffing, I think, is really the big thing. So much of how we build for the web now is grab some data from an API or a database and then dynamically update the UI based on things the user does. And you can do that with DOM manipulation, I absolutely have but, man, it is so much harder to do. So, really, I get the appeal of state-based UI. The flip side is we also use state-based UI for a lot of stuff where it’s not appropriate and it ends up being harder to manage and maintain in the long run. So, I’m rambling, I’m sorry. Drew, stop me, ask me—
Chris: Yeah, for sure. I often describe jQuery as paving the cow paths. So many of the methods that I love and use in the browser, I owe entirely to jQuery and I think recognizing that helped me get less angry at some of the damage that modern frameworks do or modern libraries because the reality is they are … I think the thing is a lot of them are experiments that show alternate ways to do things and then we have a tendency as an industry to be like, “If it’s good for this, it’s good for everything.” And so, React is very good at doing a specific set of things in a specific use case and, through some really good marketing from Facebook, it became the defacto library of the web.
Chris: The potential problem with that model is that, usually, by the time that happens, the tooling has both gotten incredibly heavy to the detriment of end users and has become really entrenched. So, even though the idea … Think of jQuery, we talk about it in the past tense but it’s still all over the web because these sites that were built with it aren’t just going to rip it out, it’s a lot of work to do that. And there’s a lot of developers even today who, when they start a new project, they reach for jQuery because that’s what they learned on and that’s what they know and it’s easiest for them.
Chris: So, these tools just really have persistence for better or for worse. It’s great if you invested a lot of time in learning them, it’s great job security, you’re not wasted time. But a lot of these tools are very heavy, very labor-intensive for the browser and ultimately result in a more fragile end user experience which is not always the best thing.
Drew: I remember, at one point, there was a movement calling for React to actually be shipped with the browser as a way of offsetting the penalty of downloading and pausing all that script. It is frustrating because it’s like, okay, you’re on the right path here, this functionality should be native to the browser but then, crucially, at the last moment, you swerve and miss and it’s like, no, we don’t want to embed React, what we want to do is look at the problems that React is helping people solve, look at the functionality that it’s providing and say, okay, how can we take the best version of that and work that into the web platform. Would you agree?
Chris: Yeah. Yeah, exactly. React will eventually be in the browser, just not the way everybody … I think a lot of people talk about it as in literally, the same way jQuery is in the browser now, too. We absorb the best bits, put some different names on them, arguably more verbose, clunky, difficult to use names in many cases and so I think that’s how it’ll eventually play out. The other thing that libraries do that I wish the web platform was better at, since we’re on this path, is just API consistency.
Chris: Why is the classList API a set of methods on a property instead of just a set of methods you call directly on the element? So, why is it classList add, classList remove instead of add class, remove class, toggle class, et cetera. It’s just lots of little things like that, this death by a thousand cuts, I think, exacerbates this problem that, even when native methods do the thing, you still get a lot of developers who reach for tooling just because it smooths over those rough edges, it often has good documentation. MDN fills the gap but it’s not perfect and, yeah.
Drew: Yes, using a well-designed framework, the methods tend to be guessable. If you’ve seen documentation that includes a remove method, you could probably guess that an add method is the opposite of that because that’s how anybody would logically name it. But it’s not always that way with native code, I guess, because of reasons, I don’t know, designed by committee, historical problems. I know that, at one point, there were, was it MooTools or prototype or some of these old frameworks that would add their own methods and basically meant that those names couldn’t be reused for compatibility reasons.
Chris: Yeah, I remember there was that whole SmooshGate thing that happened where they were trying to figure out how to … I think it was the flat method or whatever that originally was supposed to be called. MooTools had an array method of the same name attached to the array prototype. If the web standards committee implemented it the way they wanted to, it would break any website using MooTools, a whole thing.
Drew: In some ways, it seems laughable, any website using MooTools. If your website’s using MooTools, good luck at this point. But it is a fundamental attribute of the web that we try not to break things that, once it’s deployed, it should keep running and a browser update isn’t going to make your use of HTML or CSS or whatever invalid, we’re going to keep supporting it for as long as possible. Even if it’s been deprecated, the browsers will keep supporting it.
Chris: Yeah. I was just going to say, the marquee element was deprecated ages ago and it still works in every major browser just for legacy reasons. It’s that core ethos of the web which is the thing I love. I think it’s a good thing, yeah.
Drew: It is but, yes, it is not without its problems as we’ve seen. It’s, yeah, yeah, very difficult. You mentioned the View Transitions API which I think now may be more broadly supported. I don’t know if I saw from one of the web.dev posts that’s now, as of this month, has better support, which is transitional state but like an SPA style transition between one state and another but you can do it with multipage apps.
Chris: Yeah. A discord I’m in, just quick shout out to the Frontend Horse Discord, Adam Argyle was in there today talking about how, because he built this slide demo thing where every slide is its own HTML file and it uses U transitions to make it look like it’s just one single page app. He was saying that it still does require Chrome Canary with a flag turned on but things change quickly, very slowly and then all at once, that’s the-
Chris: For sure. Yeah, no, that’s totally fair.
Drew: I think-
Drew: … we had-
Chris: Oh, sorry. Go ahead, Rich. Drew rather.
Drew: I was about to mention Rachel, we had Rachel Andrew on the show a few episodes ago talking about Google Baseline which is their initiative to say which features are supported to replace a browser support matrix idea. And if you look at the posts that Rachel writes what’s new on the web on web.dev every month, she does a roundup of what’s now stable, what you can use and there’s just a vast amount being added to the web platform all the time. It could be a change log from a major framework because it is a major framework, it’s the native web platform but there’s just things being added all the time. Is there anything in particular that you’ve seen that you think would make a big difference or are you just hanging out for that DOM diffing after all those things that are yet to come?
Drew: This is new to me. Give us a top level explanation of what’s going on with that one.
Chris: So, I could easily look at two date objects, grab timestamps from them and be like, “Okay, this was two weeks ago or several days.” But then, once you start getting into months, the amount of days in a month varies. So, if I don’t want to say 37 weeks, I want to say, however many months that ends up being, it’s going to vary based on how long the months were. And so, the Temporal API addresses a lot of those issues. It’s going to have first class support for time zones, it’s going to have specific methods for getting relative time between two temporal objects and, in particular, one where you hopefully won’t have to …
Chris: It’s been a while since I’ve read the spec but I’m pretty sure it allows you to not have to worry about, if it’s more than seven days, show in weeks, if it’s more than four weeks, use months. You can just get a time string that says this was X amount of time ago or is happening N amount of time in the future or whatever. So, there’s certain things the Date API can do relatively or the date object can do relatively well but then there’s a couple of you’re trying to do appy stuff with it.
Chris: For example, I once tried to build a time zone calculator so I could quickly figure out when some of my colleagues in other parts of the world, when it was for them. And it was just really hard to account for things like, oh, most of Australia shifted daylight savings time this month but this one state there doesn’t, they actually do it a different month or not at all and so it was a huge pain.
Drew: Yeah, anything involving time zones is difficult.
Chris: Yeah. It’s one of the biggest problems in computer science. That and, obviously, naming things. But yeah, it will smooth over a lot of those issues with a nicer, more modern API. If you go over to tc39.es/proposaltemporal, they have the docs of the work in progress or the spec in progress. It’s authored a lot more nicely than what you might normally see on, say, the W3C website in terms of just human readability but you can tell they borrowed a lot of the way the API works from libraries like Moment.js and date-fns and things like that. Which again gets back to this idea that libraries really pave those cow paths and show what a good API might look like and then the best ones usually win out and eventually become part of the browser.
Drew: And again, back to my point about the web platform getting the important details right, if you’ve got native data objects, you’re going to be able to represent those as localized strings which is a whole other headache. I’ve used libraries that will tell you, “Oh, this blog post was posted two weeks ago,” but it’ll give you the string two weeks ago and there’s no way to translate that or, yeah. So, all those details, having it baked into the platform, that’s going to be super good.
Chris: Smashing, one might even say.
Drew: Smashing, yeah. It raises a question because the standards process takes time and paving the cow paths, there has to be a cow path before you pave it. So, does that approach always leave us a step behind what can be done in big frameworks?
Chris: Yeah, theoretically. I think we can look at an example where this didn’t work with the Toast API that Google tried to make happen a few years back. That was done relatively quickly, it was done without consensus across browsers, I don’t think it really leaned heavily on … I think it was just doing what you described, the paving before the cow paths were there and so it was just met with a lot of resistance. But yeah, I think the platform will always be a bit behind, I think libraries are always going to be a part of the web. Even as the Vanilla JS guy, I use libraries all the time for certain things that are particularly difficult.
Chris: For me, that tends to be media stuff. So, if I need to display really nice photo galleries that expand and shrink back down and you can slide through them, I always grab a library for that, I’m not coding that myself. I probably could, I just don’t want to, it’s a lot of little details to manage.
Drew: It’s a lot of work, yeah.
Chris: Yeah. So, I do, I think the platform will always be behind, I don’t think that’s necessarily a bad thing. I think, for me, the big thing I’ve wished for years is that we run through this cycle as an industry where a little tool comes out, does a thing well, throws in more and more features, gets bigger and bigger, becomes a black hole and just sucks up the whole industry. I keep picking on React but React is the library right now. And then eventually people are like, “Oh, this is big, maybe we should not use something as big,” and then you start to see little alternatives pop up. And I really wish that we stopped doing that whole bigger black hole thing and the tools just stayed little and people got okay with the idea that you would pull together a bunch of little tools instead of just always grabbing the behemoth that does all the things. I often liken it to people always go for the Swiss Army knife when they really just need a toothpick or a spoon or a pair of scissors. Just grab the tool you need, not the giant multi-tool that has all this stuff you don’t.
Drew: It almost comes back to the classic Unix philosophy of lots of small tools that do specific things that have a common interface between them so that you can change stuff together.
Chris: And that’s probably where … Now that you’re saying it, I hadn’t really considered this but that’s probably where the behavior or the tendency arises is, if you have a bunch of small libraries from the same author, they often play together very nicely. If you don’t, they don’t always, yeah, it’s tougher to chain them together or connect those dots. And I really wish there was some mechanism in place that incentivized that a little bit more, I don’t know. I got nothing but I hadn’t really considered that until you just said it.
Drew: Maybe it needs to be a web platform feature to be able to plug in functionality.
Chris: Yeah. Remember the jQuery, I think it was called the extend method or they had some hook that, if you were writing a plugin, basically you would attach to the jQuery prototype and add your own things in a non-destructive way. I wish there was some really lightweight core that we could bolt a bunch of stuff into, that would be nice.
Drew: Yes, and I think that would need to come from the platform rather than from any third party because done the interface would never be agreed upon.
Chris: Very true.
Chris: Yes. Yeah, definitely.
Drew: Yeah. So, you’ve talked about still reaching for libraries and things where necessary. Would you say that, if it is our approach to pave the cow paths that, really, the ecosystem needs these frameworks to be innovating and pushing the boundaries and finding the requirements that are going to stick, are they just an essential part of the ecosystem and maybe not so—
Chris: Yeah, probably more than I—
Chris: Yeah. I think, more than I’d like to admit, they are an essential part of the ecosystem. And I think what it comes back to for me is I wish that they did the one thing well and stayed a relatively manageable size. Preact, for example, has done a really great job of adding more features and still keeping themselves around three kilobytes or so, minified Gzipped, which is pretty impressive considering how much like React the API is and they have fewer abstractions internally so a lot of the dynamic updates, you, user Drew, interact with the page, some state changes and a render happened, that ended up happening orders of magnitude faster than it does in React as well.
Drew: And we know those are always popular.
Chris: Yeah. They are dangerous, I understand why people don’t like to do them. I’ve done it multiple times, I always end up shooting myself on the foot, it’s not great.
Drew: So, say that I’m a React developer and I’m currently, day-to-day, building client side SPAs but I really like the sound of this more platform native approach and I want to give it a try for my next project. Where should I start? How do I dip a toe into this world?
Chris: So, I’m really excited about a tool like Astro for that reason. I’m also a little bit worried that a tool like Astro becomes a band-aid that stops us from addressing some of the real systemic issues of always reaching for these tools. Because you can just keep doing what you’re doing and not really make any meaningful changes and temporarily reduce the impact of them, I don’t know that it really puts us in a better place as an industry in the long run. Especially since tools like Svelte and Astro are now working towards this idea that, rather than shipping multi-page apps, they’re going to ship multi-page apps that just progressively enhance themselves into single page apps with hydration and now we’re right back to we’ve got an SPA.
Chris: The thing that nobody ever talks about when they talk about SPAs are better is all of the accessibility stuff that they tend to break that you then need to bolt back in. So, even if you’re like, “Okay, this library is going to handle intercepting the links and finding the page and doing all the rendering and figuring out what needs to change and what stays the same,” there’s this often missed piece around how do you let someone who’s using a screen reader know that the UI has changed and how do you do it in a way that’s not absolutely obnoxious. You don’t want to read the entire contents of the page so you can’t just slap an ARIA live attribute on there.
Chris: Do you shift focus to the H1 element on the page? What happens if the user didn’t put an H1 element on the page? Do you have some visually hidden element that you drop some text in saying page loaded so that they know? Do you make sure you shift focus back to the top so they’re not stranded halfway down the page if they’re a keyboard user? It’s one of those things where how you handle is very it depends, contextual. And I think it’s really tough for a library to implement a solution that works for all use cases. I think it’s optimistic to assume the developers will always do the right thing.
Chris: I mentioned at the very start that I’m excited about these tools but I also see them doing that let’s repeat the same mistakes all over again and this feels like that to me. I absolutely understand why, on certain very heavy sites, you might want to shift to an SPA model but there are also just so many places you can really do real harm to yourself or your users when going down that path. And so, I worry that these tools came up to solve a bunch of UI or UX and performance related issues with state-based UI just to then re-implement them in a different way eventually. That’s my soapbox on that. If you have any questions or comments, I’m happy to hear them.
Drew: So, as often happens when we talk, we get all the way to the end and conclude that we’re doomed.
Drew: And yes, as often happens, it all comes round to progressive enhancement being a really great solution to all of our problems. Maybe not all of our problems but some of them around the web.
Chris: It’s going to cure global hunger, you watch.
Drew: So, I’ve been learning all about being web platform native. What have you been learning about lately, Chris?
Chris: So, now I’m over here thinking like, “Oh, is it finally time to drop SaaS for native CSS?” and, “Oh, all these old SaaS variables I have, I should probably convert those over to CSS variables.” And so, it’s created this whole daisy chain of rabbit hole for me in a very good way because this is the kind of thing that keeps what we do professionally interesting is learning new things.
Drew: You’ll be the Vanilla CSS guy before we know it.
Chris: That’s Steph Eckles. She is much better at that than I am. I reach for her stuff all the time but, yeah, maybe a little bit.
Drew: If you, dear Listener, would like to hear more from Chris, you can find his social links, blog posts, developer tips newsletter and more at gomakethings.com. And you can check out his podcast at vanillajspodcast.com or wherever you’re listening to this. Thanks for joining us today, Chris. Did you have any parting words?
Chris: No, Drew, just thank you so much for having me. I always enjoy our chat so it was great to be here.