In this episode, we’re asking if changes to best practises over the last year have negatively impacted the web. Is it all downhill from here? Drew McLellan talks to expert Chris Ferdinandi to find out.
- Next.js Wildcard Subdomains written by Sam Poder
- Improving The Performance Of Wix Websites written by Dan Shappir
- Adding A Dyslexia-Friendly Mode To A Website written by John C Barstow
- How To Maintain A Large Next.js Application written by Nirmalya Ghosh
- 3D CSS Flippy Snaps With React And GreenSock written by Jhey Tompkins
Chris Ferdinandi: Oh, I’m smashing. Thanks for having me Drew. Interesting thing. I actually make sure New Zealand is not on maps because it’s probably my favorite country in the whole world and I don’t want too many people to know about it.
Drew: You want it to remain unspoiled.
Drew: So welcome back to the podcast. Last time we talked, we posed this question of if modern best practices, the use of reactive frameworks and these sorts of things were actually bad for the progress of the web. And I don’t know whether it was a controversial episode or it just struck a chord with a lot of listeners, but that conversation has been one of the most shared and listened to episodes that we’ve put out that smashing.
Chris: Oh, that’s awesome.
Drew: It’s actually been more than a year now, 15 months since we recorded that, which at the pace the web moves is like literally forever. So I wanted to ask, has anything changed? Is the web still in a terminal decline? Has the needle shifted at all?
Chris: Yeah, quite a bit has changed quite a bit has not. So I think, it’s so weird. The web technology changes so fast, but the web itself tends to move a little bit slower just in terms of developer trends and habits. And so you see these slightly longer arcs where you’ll have a bunch of technology pile up around one approach and then it’ll slowly start to swing the other way and then change all at once. And so last time we talked, I think one of the big kind of… Well, I had two big points related to the modern web. The first was, we’re using a lot of tools that give developers convenience, but we’re using those tools at the expense of the user. So we’re throwing a ton of client-side JS at people, and that introduces a ton of agility and performance issues.
Chris: The other big point that I was really hammering on was that these tools don’t necessarily improve the developer experience as much as I think people think they do. They do for some people. And I think for another segment of the front end professionals it actually can make things a little bit worse. But what I’m starting to see happen now, and one of the things I’d love to dig into a little bit more is I think we’re seeing a new, it’s almost like a second generation of tools that take a lot of the developer benefits that these client-side frameworks bring and strip away the punishing effects that we put on our users as a result. So it’s taking those same concepts and tools and packaging them a little bit differently in a way that’s actually better for the front end.
Chris: So one of the things I’ve been talking about with people lately is this idea that modern development has broken the web, but it’s also starting to fix it. And so we can definitely dig into that in a bunch of different angles, depending on where you want to take this conversation.
Drew: Sure. What sort of things have you seen in the last year that really stand out from that point of view?
Chris: Yeah, so the two biggest trends I’ve noticed are the rise of microframeworks. So where we saw a lot of really big all encompassing libraries for a while React, Vue before that angular, which is just a massive beast at this point, we’ve started to see smaller libraries that do the same thing come into their own. So for example, I think the king of this hill is probably Preact, which is a three kilobyte alternative to React that uses the same API, ships way less code and actually runs orders of magnitude faster on safe updates than React does too. So you’ve got things like that.
Chris: For a while you had… Well, it’s still out there, but Alpine JS, which was inspired by VJS and then actually inspired Evan You who built Vue to release Petite Vue, which is a 5.5 kilobyte subset of Vue that’s optimized around progressive enhancement. So these are still client-side libraries, but the intent behind them is that they ship less code, include fewer abstractions and ultimately work faster and put less of that cost on the front end user. So that’s been one angle.
Drew: Do you think this is the ecosystem’s response to this quiet developer dissatisfaction about the weight of modern frameworks? Is it just a natural heave and ho?
Chris: Yeah, it is. Although to be honest, I’m not entirely sure how much of this was driven by… Well, there’s some definitely some performance minded developers out there who have been very vocal about how these tools are bad for the user. I don’t know that that’s necessarily representative of the general population though. I mean, certainly a subset of it given how the last time we talked that episode did, but I think one of the things that none of these tools for me get at is… Or the thing that I’m most bothered by by the modern web that I don’t think these tools address is that I personally feel like just the development process in general is over complicated.
Chris: This is where I get into the whole like, I don’t think the developer experience is actually better with these tools, but I think for a lot of developers in maybe a team environment, it can be. For me as a largely solo developer, I find these tools more trouble than they’re worth, but I know a lot of folks disagree with me there, so I don’t want to dismiss that as invalid. If you find these tools useful great, but yeah, I think this is maybe a natural pendulum swing back in the other direction.
Chris: And then eventually the web platform realized that these ways of doing things are really smart and we started to get native ways to do it. And then there was this really long, slow petering off of the shift away from jQuery. So I think these libraries, as much as they’ve done a lot of… That’ll be a little controversial here and say, they’ve done a lot of damage to the web. They’ve also served an important function in paving cow path for what native APIs could look like it could do. So I don’t want to completely dismiss them as terrible.
Drew: It’s interesting that you mentioned ASTRO just a little bit earlier. I’ve actually recorded an interview with Matthew Phillips. I’m not sure if it goes out before or after this one. He’s one of the core developers on ASTRO. And it certainly is a very creative and an interesting approach to the problem. I do wonder as you saying how much this is. We’ve created a set of problems for ourselves and so now we’ve created a new solution, which patches over those problems and gives us something even better. But are we just stacking the bricks on top of each other and still ending up with a very wobbly tower because of it? Are we just going down the wrong path?
Chris: But I think the thing I see with libraries is a lot of them come into creation to fill gaps in what the platform can do. And what I’ve noticed happens is after the platform catches up, the libraries stick around for a really long time. And so the thing I always try to do is be a little bit deliberate about what I add to the things I build, because it’s really easy to add stuff and really hard to take it away once it’s there. And just, I think to ground these heady abstract concepts, I’m talking about for a sec, every year, web aim, Web Accessibility consultancy firm does a survey of the top million sites on the web. And they run an audit, just automated audits. They’re not doing a detailed inspection of all these sites. So just stuff that, simple like robot tasks and pickup. And historically, one of the things they’ve always found is that sites that use UI rendering libraries have more accessibility issues than sites that don’t.
Chris: This year they found the same trend with one exception. Sites that use React actually have fewer accessibility issues than sites that don’t. And that is a notable trend or noticeable departure, rather from the year before when React sites had more accessibility issues.
Chris: So if you’re listening to this and you don’t know what those are, the details element is an HTML element that you wrap around some content, and then inside it you nest a summary element with like a little description of what’s in that content. And by default, this element will be a collapsed bit of content. And when you click on the stuff in the summary, it expands and then when you click it again, it collapses and it shows a little arrow when it’s open or closed to indicate what’s happening here. It’s accessible out of the box. If the browser doesn’t support it, it shows all the content by default. So it’s just automatically progressively enhanced. You don’t need to do anything special there.
Chris: And so for me, that’s, I think, the next evolution of the web. That’s where I really want to see things start to go. And I think that’s the big need that these libraries address today in addition to some other stuff like changing the UI based on state changes and interesting use cases like that.
Drew: Yeah. Modern browsers are just so capable now and they automatically update themselves and they include many of the features natively that we’ve previously relied on, on big frameworks and build tools for. Is the requirement of a build process to deploy a project a red flag in 2021? Should HTML and CSS and JS just be deployable as it is?
Chris: So technically they are. I don’t think for most build processes that’s real or for most apps or sites or companies that’s necessarily realistic today. I don’t know that I’d call it a red flag as much as a resigned I wish it wasn’t like this, but I understand why it is, for me. Even for myself, my site has several thousand pages on it now. I think I’m up to three or four thousand pages and there’s no way I am just hand coding all those. I use a static site generator and I think tools like that can be really great.
Chris: I think there’s some challenge there in that they become things that have to be kept updated and maintained. And so I like to keep mine as lean as possible, but I think build tools that put more of the run time on you, the developer, and thus allow you to ship less to the browser are a good thing, especially as the things we build become more complex. So I don’t know that I would necessarily say it’s just by default a red flag. I think a lot of it depends on how you’re using it. If you need to run a build to ship a one or two page marketing site or brochure site, yeah, that’s a red flag. But if you’re building some complex applications and these allow you to author in a way that’s more sensical for you and then ship less stuff to the browser, that’s not a bad thing. And that’s why I find tools like ASTRO really, really interesting because there is still a build step there, but it’s a build step in the service of providing a better end user experience.
Drew: Yes. It’s shifting all that computation onto the server to build time or pre deferred time and not on page request time.
Chris: Yes. Yeah. I think that’s fair. I used to downplay, I think, the significance of this for a while. And I think that is valid. That is a fair benefit of these tools. I think that maybe the small counter argument here is if you Google, “How to do X with React,” you’re going to get half a dozen different approaches to doing that thing. So there are conventions, but there’s not necessarily hard and fast, like if you don’t do it this way, everything breaks kind of rules. One of the appeals of these tools is that they have a lot of flexibility. Certainly they do enforce more standard approaches though than just green fields, browser native things do. And so I think there’s maybe a bit of a balance, even if you don’t have a strong team lead who’s driving internal code standards.
Chris: I have seen even framework based projects go off the rails with hodgepodge approaches before. So it’s not like these tools automatically give you that, but they definitely give you some guidelines, maybe some rails that nudge you in the right direction. And I know some people need that. If that is something you need, this is where I really like that we’re seeing more of these smaller libraries that use the same conventions, like Petite Vue or Preact and compilers that also… Like FELT has some very rigid rails around it, certainly more so than you would see with ASTRO and so if you really need that, I think you have some options that don’t punish users for that need as much as what we had been doing a few years ago.
Drew: In the work that I do, we use Vue and the Vue single file components are a really compelling case for this in that we have engineers writing front-end code, who aren’t necessarily front-end specialists who say here’s a way to create a skeleton single file component. Your template goes here, your Java script goes here, your CSS goes here. And just naturally as a result of that, we end up with a very consistent code base, even though it’s been created by a very diverse set of people. And so the conventions like that can really have a big benefit to teams who aren’t necessarily all headed in the same direction because the engineering department’s so massive or whatever.
Drew: There’s always this undercurrent within the industry that suggests there’s the current way of doing things, the latest and there’s the outdated way. And if you’re not up to date with whatever the latest is, you’re somehow not as good an engineer or whatever.
Chris: Yeah. Yeah. There’s a few threads in what you just mentioned, Drew. So one of them is, if you understand the fundamentals of the web, I have found that it’s a lot easier to like a bee, just bounce from different technology to different technology and understand it enough to like… Even if you don’t use it, look at it and be like, “Okay, I can see some benefits to this or not, and evaluate whether it’s the right choice.” If you need to dive into a new technology based on client needs or shifting direction in the company, you can. I think it’s a lot harder to do that if you only know a library and you’ve only learned the web in the context of that library.
Chris: And so there’s these trade offs there. It’s not always a bad thing. Yeah, I think it’s one of those, like the new, new, new thing is potentially a very vocal minority of the web that’s not representative of as the web as a whole.
Drew: And there seems to be along with this idea that you should be adopting everything new and immediately casting away everything that you’ve been using for the last 12 months. There’s also this idea that you should be engineering things that are enterprise grade of engineering, but you ought to be doing every small project the way that an enormous company with 400 engineers is building things. And those two ideas actually aren’t compatible at all. It’s the big companies with all these hundreds of engineers who are using the old crusty technology, because it’s reliable and they’ve got far too much momentum. They hate to be dropping it and picking up something new. So those two ideas are indirect conflict, I think.
Chris: Yeah. It’s funny. You always see the whole like, “Well, will it scale, will it scale,” kind of thing all the time. And does it need to? Are you building things for a Facebook sized audience? I’m sure you’ll get there at… Well, you’ll get there, but it would be wonderful if you got there at some point, but like, if you’re not there today, maybe that’s not necessarily how you need to start out. Like those aren’t your needs today. You’re pre-engineering for a problem that you don’t have to the detriment of some problems that you do.
Chris: I think the other thing here is there’s this presumption that because Facebook or Google or Twitter do things, it’s a good idea, or it’s a good idea for everybody. And that’s not necessarily the case. Those companies do a lot of things right. But they also do a lot of things poorly and they do them that way because of engineering trade offs they’ve had to make because of how their teams are structured or very specific internal problems they had at the time that they made this decision or because some executive somewhere felt really strongly about something and made the internal team do it, even though it wasn’t necessarily best at the time. And then these things stick around. And so, yeah, I think one of the biggest things I see happen in our industry to our own detriment is looking at those few really big visible technology companies and thinking, “If they do it this way, I have to too,” or “That’s the right call for everybody.”
Chris: It’s that old, like no one got fired for hiring IBM kind of thing, but applied to if it’s good enough for Google or if it’s good enough for Twitter or whatever, so yeah. I agree. I think we do a lot of that and maybe that we shouldn’t.
Drew: I asked on Twitter earlier on that what frustrated people about modern web development best practices and from the responses I got, there’s certainly a lot of dissatisfaction with the current state of things. One trend, which over the last few years is getting momentum is like the Jamstack approach to building sites. And it seems on the surface that this going back to just client-side apps and nothing complex on the server, it sounds like it’s going back to basics, but is it doing that? Is it or is it just masking the complexity of the stack in a different way?
Chris: And there are some plugins you can use to do some of that ahead of time, but it is a very slow process, especially on a shared inexpensive web host. A Jamstack approach would be to have that HTML file already built, and you cut… You don’t cut the server out, but you cut all of that server processing completely out. So the HTML file already exists and gets shipped. And in an ideal world, you would even push that out to a bunch of CDNs so it sits as close to the person accessing it as possible. And what that can do is take a load time from a couple of seconds on an inexpensive host to less than half a second, because of how little computing time it takes to actually just request a file, get the file back and load it, if it’s mostly HTML.
Chris: And so, yeah, I really like rambling in long winded response to your question, Drew, but I think the answer is, if you’re using it with something like a static site generator, it can be amazingly more performant than some of the other things we’ve done in the past. And it allows you to get that same WordPress experience where I’m authoring content and I have some templates and I don’t have to hardcode HTML, but the performance is way better on one end.
Chris: And then on the other end, you could theoretically define a React app as Jamstack as well and it can be really slow and buggy and terrible. And so it depends. The other thing I’m seeing happen that’s really, really funny and interesting is we just keep reinventing PHP over and over and over again as an industry in various ways. So-
Drew: We still have PHP as well. It’s not gone.
Chris: Right? And yet PHP still exists and still works great. And so we’ve got… Like I remember when Next.js came out. There was all these kind of, “And here’s all the things you can do with it.” And I was like, “Oh, that’s like PHP,” but a decade later. And then my friend Zach Leatherman who built Eleventy which is an amazing static site generator has been experimenting with some compiling in real time on the server stuff with Eleventy.
Drew: Do you think we’re going through some industrial revolution in web development? What used to be skilled painstaking work from individual arts and is now high volume, high production factory output. All the machines have been brought in and the frameworks and the build tools and have we lost that hand rolled touch?
Chris: And I think there’s a clear argument that at some point, factory farming is this big industrial complex that has lost a little bit of that close to the Earth touch, but I don’t think I necessarily need my farmers to be hand chopping their wheat. That is wildly inefficient for very little benefit. And there’s probably a balance there. And I feel the same thing with what we’re doing here. Some of these tools allow us to do more artisan work faster and more efficiently. And sometimes they just turn it into generating a bunch of garbage and turn it out as fast as possible. And there’s not necessarily a clear cut delineation for where that crossover happens. I think it’s a little fuzzy and gray and like a you know it when you see it kind of thing. Sometimes not always. But yeah, I think it’s a little bit of both. The commercialization of the web is both a really terrible thing and also a really great thing that has allowed folks like myself to have a living working on the platform that I love full time.
Chris: That’s awesome. But it’s also produced a lot of problems and I think that’s true for any technology. There’s good and bad that comes with all of it.
Drew: And maybe sometimes we’re just producing really fat pigs.
Chris: Yeah. I’ve gotten a lot more like, it depends as I’ve gotten older. This stuff used to really, really upset me from a purist standpoint. And I still really hate the fact that we’ve forced our users to endorse such a fragile and easily broken web. The web in general has gotten four to five times faster in the last decade. And the average website has only gotten a hundred milliseconds faster in terms of load time, because we just keep throwing more and more stuff at our users. And we could have a really fast resilient web right now if we wanted one, but we don’t. And part of that is a natural trade off for pushing the capabilities of the web further and further and that’s awesome, but I feel like sometimes we do things just because it’s shiny and new and not because it adds real benefit to folks. So I’d love to see a little bit more balance there.
Drew: Is part of the problem that we’re expecting the web to do too much? I mean, for many years we didn’t really have any great alternatives. So we enhanced and maybe over-stretched the high tech document system to behave like a software application. And now we’ve all got really powerful phones in our pockets, running a range of network connected apps. Is that the appropriate outlook for this functionality that we’re trying to build into websites? Should we just all be building apps for that case and leaving the document based stuff to be on the web?
Chris: I would argue the other direction. I think the bigger problem is… So maybe there are certain things for which I even personally I prefer like a native app over something in the web. But I think having the web do more frees you from app ecosystems and allows you as a team to build a thing and be able to reach more people with it, not have to download an app before you can access the thing you want. That’s a really cool thing. And I would argue that potentially the bigger problem is that browsers can’t keep up with the pace of the thing that we want the web to do. And that’s not a knock on the people behind the standards processes. I would not want to go back to every browser just does their own thing and the hell with it. That was awful to develop for.
Drew: It was, yeah.
Chris: We do have some of those similar problems though, just based on how the standards process works. So sometimes you’ll see Google get frustrated because they have so much in-house development power, get frustrated with other browsers that are part of that process not wanting to go along with something or not moving fast enough. And so they just… Leeroy Jenkins it and just run off and go do whatever they want to do. On the flip side you sometimes see Apple moving very, very slow because they don’t put as much investment into the web as they do other parts of their business, which is hopefully, maybe starting to change a little bit with some of the more recent hires they’ve made. But I think one of the things you run into is just the web tends to move a little slowly sometimes.
Chris: Technology moves fast, but the browsers themselves and the technologies they implement don’t always keep up. And so I don’t believe we demand too much of our browsers. I just think you get this natural ebb and flow where we demand a lot. We build a bunch of libraries to polyfill the things that we want and then when the browser eventually catches up, there’s this really slow, petering off as library usage for that particular stuff drops off.
Chris: Yeah. But I don’t know that I would say we demand too much of the web. Yeah, I don’t know. I actually, I love all the things the web can do. I think it’s really, for me, it’s what’s so exciting about the web. I think my frustration is more just with how slow some of these technologies are to come out, particularly on iOS devices. And I say this as someone who, I love my iPhone, but progressive web apps continue to be a second… They just don’t get as much priority as native apps do on that platform, which is disappointing.
Drew: So looking to the future on that note, what should we, as a development community be working on to fix some of these issues? Where should we be placing our efforts?
Chris: Yeah. So I think there are a few different things. And I think some of the tools we’ve talked about, I don’t think they’ll ever necessarily go away. They might change in form a little bit, but so I already see some cool things on the horizon. One of the things people love about single page apps that we’ve never been able to do with, I call them multistage apps, but they’re really just plain old webpages is like the nice transitions that happen between views where you might like fade in, fade out, or something like that.
Chris: There’s a native API in the works that’s going to make that a lot easier. That’s awesome. There’s also a native API in the works for HTML sanitization. So one of the big things that libraries do for you is they, when you’re rendering HTML from third party data, they have some libraries baked in that will help reduce your risk of cross-site scripting attacks.
Chris: There’s not really a good, just native way to do that, but there’s one in the works that will make that a lot easier. And even if you continue to use state based libraries, that should allow them to strip a bunch of code out and that would be an awesome thing.
Drew: So you saying maybe it’s not all doom and gloom and perhaps we can fix this? There’s a way out?
Chris: No, yeah, I see us emerging from the dark ages slowly. And what I think is going to happen is we’re going to hit a point where much like where today people are like, “Why does everybody still use React?” I can imagine in 7 to 10 years time, we’re going to be like, “Why does anybody…” I’m sorry. Not React. jQuery. “Why does everybody still use jQuery?” We’re going to see the same thing with React and Vue. Like, “Why does everybody still start a project with those?” And there’s going to be some new libraries that are starting to emerge to solve a whole new set of problems that we haven’t even dreamed of today.
Drew: One comment from Twitter that I really identified with was from Amy Pellegrini, who said, “Every time I update something, everything gets broken.” Yep. I just think we’ve all been there, haven’t we?
Chris: Yeah. I unfortunately don’t think that will ever fully go away because even in the non-build tool era of jQuery, we used to just load it with a script element. You would run into situations where different versions would be incompatible with each other. And so you’d drop a plug in into your site and it would be like, “Sorry, you’re running jQuery 1.83, and this requires 1.89 or higher because it added this new…” And so there’s always been some version of that. I think it’s a lot more pronounced now because so much of it happens in the command line and spits out all these terrible errors that don’t make sense. But yeah, that unfortunately I don’t think will ever go away. I feel the pain though. That one, it’s a big part of the reason why I try and use as few dependencies as possible.
Drew: Me too. Me too. So I’ve been learning all about the lean web or learning more about the lean web than our conversation. What have you been learning about lately, Chris?
Chris: And so I went really, really deep on those, put together a couple of courses on both of those topics as well, but they have benefited me immensely in my own work, in particular service workers, which has been amazing. I’m obsessed with them. Recommend them for everybody.
Drew: That’s amazing. And where can people find those courses that you put together on?
Chris: So if you go to vanillajsguides.com, you can dig into those and a whole bunch of other courses as well.
Drew: Amazing. If you dear listener would like to hear more from Chris, you can find his book on the web at leanweb.dev and his developer tips newsletter, which I believe now gets over 12,000 subscribers-
Chris: Yeah. Up a little bit from the last time we chatted.
Drew: Yeah. That’s at gomakethings.com. Chris is on twitter @chrisferdinandi. And you can check out his podcast at podcast.com or wherever you usually get your podcasts from. Thanks for joining us today, Chris. Do you have any parting words?
Chris: No, that was a really great summary, Drew. Thank you so much. You hit all the key links. So thanks so much for having me. This was great.