Posted on

Smashing Podcast Episode 63 With Chris Ferdinandi: What Is The Transitional Web?

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.

Show Notes

Weekly Update

Transcript

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.

Drew: We last talked about this concept of the lean web where we were seeing a bit of a swing back away from these big frameworks where everything is JavaScript and even our CSS was in JavaScript. And we were beginning to see at that time a launch of things like Petite Vue, Alpine.js, Preact, these smaller, more focused libraries that try and reduce the weight of JavaScript and be a little bit more targeted. Is that a trend that has continued?

Chris: Yeah, and it’s continued in a good way. So, you still see projects like that pop up, I’ve seen since then a few more tiny libraries. But I think one of the other big trends that I'm particularly both excited about and then maybe also a little bit disheartened about is the shift beyond smaller client side libraries into backend compiler tools. So, you have things like Svelte and SvelteKit and Astro which are designed to let people continue to author things with a state-based UI, JavaScripty approach but then compile all of that code that would normally have to exist in the browser and run at runtime into mostly HTML with just the sprinklings of JavaScript that you need to do the specific things you’re trying to do.

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.

Chris: If you were going to do JavaScript in the web, you were going to use jQuery.

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 [inaudible 00:09:57].

Drew: Yeah, I don’t want to gloss over the importance of jQuery as an example for this overall trend because, as you say, at the time, it was really difficult to just find things in the DOM to target something. You could give things an ID and then you had get element by ID and you could target it that way. But say you wanted to get everything with a certain class, that was incredibly difficult to do because there was no way of accessing the class list, you could just get the attribute value and then you would have to dissect that yourself. It’s incredibly inefficient to try and get something by class and what jQuery did was it took an API that we were already familiar with, the CSS selector API essentially, and implemented that in JavaScript.

Drew: And, all of a sudden, it was trivially easy to target things on the page which then made it ... It very quickly just became the defacto way that any JavaScript library was allowing you to address elements in the DOM. And because of that trend, because that’s how everybody was wanting to do it with quite a heavy JavaScript implementation, let’s not forget this was not a cheap thing to do, that the web platform adapted and we got querySelector which does the same thing on querySelectorAll. And of course, then what jQuery did or I think its selector engine was called Sizzle, I think, under the hood. Sizzle then adopted querySelectorAll as part of its implementation.

Drew: So, if a selector could be resolved using the native one, it would. So, actually, the web platform was inspired by jQuery and then improved jQuery in this whole cycle. So, I think the way the web has always progressed is observing what people are doing, looking at the problems that they’re trying to solve and the messes of JavaScript that we’re using to try and do it and then to provide a native way to do that which just makes everything so much easier. Is that the ultimate trend? Is that what we’re looking at here?

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: I think tools like Astro and Svelte are similarly showing a different way we can approach things that involves authoring and adding a compiled step. And they are, by no means, original there, static site generators have existed for a while, they just layer in this. And we’ll also spit out some reactive interacting bits and you don’t have to figure out how to do that or write your own JavaScript for it, just write the stuff, we’ll figure out the rest. So, yeah, I do think that’s the nature of the web platform is libraries are experiments that extend what the platform can already do or abstract away some of the tough stuff so that people can focus on building and then, eventually, hopefully, the best stuff gets absorbed back into the platform.

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: So, it’s one thing that jQuery got, really, is the API is very consistent in terms of how methods are authored and how they work. And just, as a counterpoint, in JavaScript proper, just native JavaScript, you could make a strong argument that querySelector and querySelectorAll shouldn’t be separate methods, it should just be one method that has a much shorter name that always returns ... Hell, I’d even argue an array, not a node list because there are so many more methods that you can use to loop over arrays and manipulate them to nodes or node lists.

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-

Drew: Well, that’s pretty up to date and an authoritative statement there, yeah. But we saw, it was Google IO recently, we saw loads of announcements from them back to things they’re working on. Things like the popover API, which is really interesting, which make use of this top layer concept where you don’t have to futz around with Z index to make sure, if something needs to be on the top, it can be on the top. It’s these sorts of solutions that you get from the web platform that are always going to be a bit of a hack if they’re implemented by a library in JavaScript.

Drew: It’s the fact that you can have a popover that you can always guarantee is going to be on top of everything else and has baked into its behavior so that it can be accessibly dismissed to all those really important subtleties that it’s so easy to get wrong with a JavaScript implementation that the web platform just gets right. And I guess that means that the web platform is always going to move more slowly than a big framework like React or what have you but it does it for a reason because every change is considered for, I don’t know, robustness and performance and accessibility and backward compatibility. So, you end up with, ultimately, a better solution even if it has weird method names.

Chris: For sure. Yeah, no, that’s totally fair.

Drew: I think-

Chris: Yeah.

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?

Chris: Yeah. So, things like transitions between pages and stuff, I'm going to be honest, those don’t excite me as much as I think they excite a lot of other people. I know that’s a big part of the reason why a lot of developers that I know really like SPAs and, I don’t know, markers, get really excited about that thing, I’ve just never really understood that. I am really holding out for a DOM diff method. I think the API I'm honestly most excited for is the Temporal API which is still in, I think, stage three so it’s not coming anytime soon. But working with dates in JavaScript sucks and the Temporal API is hopefully going to fix a lot of those issues, probably introduce some new ones but fix most of them.

Drew: This is new to me. Give us a top level explanation of what’s going on with that one.

Chris: Oh, yeah, sure. So, one of the big things that’s tough to do with the date object in JavaScript ... For me, there’s two big things that are really particularly painful. One of them is time zones. So, trying to specify a time in a particular time zone or get a time zone from a date object. So, based on when it was created or how it was created, no, this is the time zone. Figuring out the time zone the person is in is really difficult. And then the other aspect that’s difficult is relative time. So, if you’ve got two different dates and you want to just quickly figure out how much time is between them, you can do it but it involves doing a bunch of math and then making some assumptions especially once you get past days or, I guess, weeks.

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 [inaudible 00:27:24].

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.

Drew: You talk a lot about Vanilla JavaScript as a concept, I think it helps to give things names. I feel like this approach that we’re talking about here is being web platform native. Do you think that describes it accurately?

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 [inaudible 00:32:08]-

Chris: Yeah, probably more than I-

Drew: ... to paint.

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 [inaudible 00:32:33] 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. Now, to be fair, a lot of the reason why is Preact is newer and it benefits from a lot of modern JavaScript methods that didn’t exist when React was created. So, under the hood, there’s a lot more abstraction happening but it’d probably require a relatively big rewrite of React to fix that.

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: Oh, it depends. So, the easiest way, and I hate myself for saying this, but the easiest way, honestly, you got a few options. One of them, you rip out React, you drop in Preact, there’s a second smaller thing you need to smooth over some compatibility between the two but that’s going to give you just an instant performance boost, a reduce in file size and you can keep doing what you were doing. The way that I think is a little bit more future-proof and interesting, you grab a tool like Astro, which allows you to literally use React to author your code and then it’s going to compile that out ... Excuse me, into mostly HTML, some JavaScript, it’s going to strip out React proper and just add the little interactivy bits that you need.

Chris: I saw a tweet a year or two ago from Jason Lengstorf from the Netlify developer relations team about how he took a next app that he had built, kept 90% of the code, he just made a few changes to make it fit into the way Astro hooks into things, ran the Astro compiler and he ended up having the same exact site with almost all of the same code but the shipped JavaScript was 90% smaller than what he had put in. And you get all the performance and resilience wins that come with that just automatically, just by slapping a compiler on top of what you already have.

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: So, I mentioned some stuff has changed, I recently saw a talk from Rich Harris, who’s the creator of Svelte and SvelteKit, about this very thing and he’s very strongly of the belief that SPAs are better for users because you’re not fetching and rerunning all of the JavaScript every time the page loads. And I get that argument and SvelteKit does it in a really cool way where, rather than having a link element like you might get in Next.js or something like that, a React router or whatever, they just intercept traditional hyperlinks and do some checking to see if they point to your current page or an external site and behave accordingly.

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.

Chris: We’re not. I think it’s mostly we’re headed in a right direction, Drew. I'm a little less doom and gloom than I was a few years ago. And as much as I just ragged on tools like Astro and Svelte, I think they’re going to do a lot of good for the industry. I just love the move to mostly HTML, sprinkle in some JavaScript, progressively enhance some things, that’s a beautiful thing. And even though I was just ragging on the whole SPA thing that these tools are doing, one of the things they also do that’s great is, if that JavaScript to enhance it into an SPA doesn’t load or fails for some reason, Astro and SvelteKit fall back to a multi-page app with server side HTML. So, I think that promise of, what was it, isomorphic apps they used to call them a while ago, it may be closer to that vision being realized than we’ve ever gotten before. I still personally think that just building multi-page apps is often better but I'm probably in the minority here, I often feel like I'm the old man shouting at the cloud.

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: I’ve been trying to finally dig into ESBuild, the build tool/compiler I’ve been using, Rollup, and a separate NPM SaaS compiler thing and my own cobbled together build tool for years. And then Rollup V3 came out and broke a lot of my old stuff if I upgrade to it so I'm still on Rollup two and this was the motivation for me to finally start looking at ESBuild which also has the ability, I learned, to not just compile JavaScript but also CSS and will take nasty CSS imports and concatenate them all into one file for you just like ES modules would.

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.

Posted on

Smashing Podcast Episode 44 With Chris Ferdinandi: Is The Web Dead?

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.

Show Notes

Weekly Update

Transcript

Drew McLellan: He’s the author of the Vanilla JavaScript Pocket Guide series, creator of the Vanilla JavaScript Academy Training Program and host of the Vanilla JavaScript Podcast. We last talked to him in July 2020, where we asked if modern best practices about for the web. So we know he’s still an expert in Vanilla JS, but did you know he’s solely responsible for New Zealand being missing from 50% of world maps? My smashing friends, please welcome back, Chris Ferdinandi. Hi Chris, how are you?

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.

Chris: Indeed.

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.

Chris: And then the second trend I’ve seen that I think is personally more compelling is a shift from libraries to compilers. And so the one that kicked this whole trend off was felt by Rich Harris, which takes the idea of state based reactivity. But instead of having this be a thing that runs in real time in the client, you author your code with the same general pattern that you might with React or Vue, and then you run a build tool that compiles all that into plain old HTML and vanilla JavaScript, and that’s what gets shipped to the browser. And so you’ve stripped out almost all of the abstractions in the client and you deliver something that’s way closer to what you might hand write with old school DOM manipulation, but with the developer convenience of state based EI. So that was really interesting.

Chris: More recently there’s a new tool called ASTRO that builds on what Rich did with Svelt, and also allows you to pull in components from your favorite libraries so you can mix and match Vue, React, FELT, Vanilla, JavaScript, all in one package, compile it all out into Vanilla JavaScript and ship orders of magnitude, less code without the abstractions. And so it would run way faster in the browser as well. And those are, I think for me, really the two big things that are like standing on the shoulders of giants and producing a front end that will hopefully start to be a little bit faster. The compilers in particular are interesting because they take us away from rendering HTML in the browser as much as possible. You still render your HTML or you still author it with JavaScript if you want, but the outputted result is more static HTML and less JavaScript, which is always a good thing.

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: The third thing that I didn’t talk about that your question actually makes me think about though is, there is almost a natural cycle in the web where you start to throw a lot of JavaScript at solving problems as the web and the capabilities of it grow. And eventually those JavaScript libraries get absorbed by the platform itself, but it’s a much slower process than creating a new JavaScript library is, because it’s standard processes and how important those are. So we saw the same thing happen with jQuery, right, where the amount of JavaScript being used on the web swelled with jQuery and jQuery plugins.

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: It depends. So I, as the hair on my head has started to disappear and my beard has gotten whiter, I’ve started to talk in fewer absolutes than I did. And so five years ago, I would’ve said, "Absolutely yes." I don’t want to diminish the value of these tools in a team environment. And the other thing, I honestly think a lot of libraries really have the potential to at least patch fix in the interim is accessibility problems with the web around complex UI components. So in short, if I were to give this just a one sentence, yes, I do think in many ways we’re creating a really delicate house of cards that collapses very easily. And I think one of the nicest things about using mostly or almost entirely platform native to build for the web, so just authoring an HTML, CSS and JavaScript is, you cannot touch that code for five years and come back to it and you don’t have any dependencies to update. You don’t have any build tools to run, to start working with it again. It just works. And that’s really great.

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: I noticed a lot of focus on accessibility in the React community over the last year, building more accessible components, accessible routing, things of that nature. And for complex components, things like tabs and disclosure widgets, and sliders and things like that, it is really hard to do those accessibly with just HTML and Vanilla JavaScript. Trying to keep track of which ARIA attributes you need to add on, which elements and how to change them based on different behaviors and how to shift focus and announce different things is really complex. And I think these libraries as much as they can be a very delicate house of cards, I see a huge potential there to fill these gaps. Where I’d ultimately love to end up though, is in a place where the platform, the web, browsers offer native components that do those things so that you don’t need the libraries. And I think the details and summary elements provide a really nice model for what that could look like.

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: It can be styled with CSS. You can even change what the icons that display when it’s expanded and collapsed are, just with CSS. You don’t need to write any JS for it, but if you wanted to extend the behavior in some way you can, because it also exposes a JavaScript event that fires whenever it’s toggled open or closed. And I would love to see more stuff like that for tabs, for image sliders or carousels or photo galleries, which just... We have so many different interactive components now on the web that may or may not always be appropriate, but they’re in the designs and people are building them and having a way to do those things where you didn’t have to fumble through how to make them accessible or lean on a 30 kilobyte library would be awesome.

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: Yeah. And so for me, I almost break build steps into... Like for me, the gold standard is if I can ship it without any build step at all, that’s awesome. But even for myself, the vanilla jazz guy, that’s not how I do things a hundred percent today. And so I think the next step up is compilers that reduce your code to as much HTML and plain old JavaScript as possible, versus those that create even more JavaScript, like the ones that take a bunch of little files and make an even bigger file. So more of the former, less of the latter if possible is always a good thing, but not always possible.

Drew: I think getting off the dependency treadmill, as it were, it’s got to be a big draw to a Vanilla JavaScript approach, not having a million dependencies to be updating all the time, but I guess one of the advantages to some of these bigger frameworks is that they sometimes dictate and sometimes facilitate a uniform way of working, which is really important with larger teams. Is there a danger of a project going a bit off the rails without those standards and procedures in place that a framework imposes?

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.

Chris: Yeah, for sure. Where I think you sometimes get into trouble with that... And I agree. I absolutely like the ability to make a code base look consistent with a bunch of different people working on it is really, really important because the people writing the code today are not necessarily going to be the ones maintaining it later. And that can get messy fast. The flip side is, if you are someone who is not comfortable or really well versed in JavaScript, a lot of the modern tool set is really geared towards JavaScript. And there are a lot of people on teams who specialize primarily in HTML or CSS or accessibility. And for them, JavaScript is not a core competency nor do I think it’s fair to expect it to be. And just like you don’t expect all your JavaScript developers to be experts in CSS.

Chris: And so it can make their job a lot harder. And this is for me, always that like that give and take with these tools is they can do some really awesome things, but they can also gate keep a lot of people out of the process. And I feel like that balance is different from team to team, but for me, one of the big arguments for leaning more on browser native stuff, or ditching as many of those dependencies as possible is that you open up your development process to a lot of people who are not as JavaScript heavy.

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.

Drew: In your estimation does taking a Vanilla JavaScript approach enable you to swim free of all that is Vanilla JS like an evergreen approach that stands apart from those techniques.

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: Now the caveat here is, I learned JavaScript in the context of jQuery and then backed my way into Vanilla JavaScript, and then moved on to a bunch of other things too. The more I think about how that process went for me though, I think I was able to do that as easily as I did in large part because by the time I made that jump, ES5 had come out and had taken a bunch of its conventions from jQuery. And so there was a lot of these real one for one map. Mental map things I could do. I don’t know if we’re quite there yet with some of the state based UI libraries, but we’re definitely headed in that direction and I think that’s great. But the other thing here, there is this real pressure, as you mentioned in the industry to always keep up to date with all these new technologies, in large part because people who develop these technologies and people who work at the big companies are the ones who get invited to speak at conferences and talk about all the cool things they’ve built.

Chris: But the reality is that a lot of our web, like I’d say a majority of our web, runs on boring old technology that hasn’t been updated in a while, or has been updated, but in just a patch fix process. A lot of really important applications run on Python or PHP, or as a backend with just some sprinkling of lightweight HTML, CSS, and JavaScript on top. jQuery is still used on a lot of important stuff to the exclusion of other libraries. And it doesn’t always feel like it because I feel like most job descriptions that you see talk about wanting experience in React or Vue or something these days. But my experience from working in bigger technology companies or older product companies, is that there are a lot of jobs to be found working on old stable technology. And a lot of times it’s not always the most exciting work, but a lot of times they’re jobs that pay well and have really great hours and a lot of work life balance in a way that you won’t get in a really exciting tech company working on the latest stuff.

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: It depends. I’m a little biased here because I love the Jamstack personally, but I have also seen... Well, I shouldn’t say I have seen. I think what I’m trying to say here is the Jamstack is a term that can apply to a wide range of approaches up to and including a really large two megabyte of JavaScript single page app that has no server side rendering on one end. And then on the other end, flat HTML files that use absolutely no JavaScript at all, and instantly loading your browser and just happen to be shipped from a CDN or something like that. And technically speaking, both of those are Jamstack and are not the flat HTML thing. So Jamstack is not inherently better than server rendered, but in many cases it can be.

Chris: So for those of you who don’t know, Jamstack used to be an acronym that stood for JavaScript, APIs and markup, and they’ve since changed the spelling and changed the definition a little bit there. And it really encompasses an approach to building the web that doesn’t rely on server side rendering. So anything you’re serving, you’ve already compiled and put together and that’s what ships in the browser. And if there’s any other processing or scripting that happens, that happens in the client. Doesn’t have to, but often does. And so what I think is awesome about Jamstack if done a certain way, is it can dramatically improve the performance of the things that you’re building.

Chris: If you’re not just shipping like a metric ton of JavaScript to the client and having all the stuff that you used to do on the server happen in the browser instead, because the browser will always be less efficient at all that scripting than the server would be, but where this really comes to shine, and so I’ll use like WordPress as an example. I love WordPress. I built my career on WordPress. It’s the reason why I was able to become a developer, but every time someone visits a WordPress site out of the box, it has to make a call to a database, grabs some content, mash it into some templates, generate HTML and ship that back to the browser.

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.

Chris: So it’s like just in time Jamstack and he even jokes that he’s essentially recreated PHP in node and JavaScript, but it’s slightly different because there’s like a serverless build that happens that then instant deploys it to a CDN and it’s like a little weird. So it’s still a house of cards. You’re just shifting around where those cards live and who’s responsible for them, but yeah, yeah. Jamstack is cool. Jamstack is problematic. It’s also not. It’s awesome. It’s potentially overused both as a term and a technology. Yeah. It’s a whole lot of things and I love it in the same way that I love PHP. It’s great and it has problems and every technology and approach is a series of trade-offs.

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: Well, I mean, yes, to an extent, but we don’t have to. I mean, that analogy is appropriate in many ways, because a lot of the ways we do things today produce... I like to call them front end pollution in the over-reliance on JavaScript, but also in the very literal sense. We have so many heavy build processes now that they generate more actual literal pollution as well. But I think the counter argument here is with a... I will use farming, right? You could go out and hand mill your wheat with a scyther. I forget what you call those. The crescent shaped tool that you use to chop your wheat, or you could use an oxen drawn machine that will pull that off, or you can use a big tractor.

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.

Chris: One thing that the native web can’t do yet that would be really cool, is a way to handle DOM dipping so that if you want to build some HTML based on a JavaScript object and then update it as the object changes, it would be really cool if you didn’t have to rely on a library for that. And that there was maybe a performant out of the box way to do that in the browser. I think that would solve a lot of problems. As well as more accessible interactive components. I absolutely love when HTML and CSS can replace something I used to need JavaScript for. Doesn’t need to be as rigorously tested, way more fault tolerant, less likely to break, more performant all around. It’s a net win. And so I’d love to see more of those come to the platform.

Chris: So from a browser native thing there’s that. And then the other big thing I think we’re going to start to see more of is a shift away from client-side libraries and a shift to more pre-compiled stuff. Whether that’s static side generators, something like ASTRO that still uses JavaScript libraries, but pre renders them instead of making the browser do it. But those are the, I think, the big things I’m seeing start to happen and I think we’re going to see more and more of.

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: Yeah. Great question. So I have been going deep on service workers in part because I love their ability to both make the web faster, or even if you’re not building a progressive web app, they’re just really, really cool. One of the things I’ve absolutely loved them for though is they allow me to build a single page app like experience in terms of performance, without all the complexity of having to handle JavaScript routing and stuff. So I can have a multipage app, cache my API calls for a short period of time without having to cache them in memory. And so I’ve been able to do some really cool things with them. And then the other thing I’ve been learning a lot about lately is serverless, which allows me to get the benefits of having some server-side code without having to actually manage a server, which is great.

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.

Posted on

Choice Words about the Upcoming Deprecation of JavaScript Dialogs

It might be the very first thing a lot of people learn in JavaScript:

alert("Hello, World");

One day at CodePen, we woke up to a ton of customer support tickets about their Pens being broken, which ultimately boiled down to a version of Chrome that shipped where they ripped out alert() from functioning in cross-origin iframes. And all other native “JavaScript Dialogs” like confirm(), prompt() and I-don’t-know-what-else (onbeforeunload?, .htpasswd protected assets?).

Cross-origin iframes are essentially the heart of how CodePen works. You write code, and we execute it for you in an iframe that doesn’t share the same domain as CodePen itself, as the very first line of security defense. We didn’t hear any heads up or anything, but I’m sure the plans were on display.

I tweeted out of dismay. I get that there are potential security concerns here. JavaScript dialogs look the same whether they are triggered by an iframe or not, so apparently it’s confusing-at-best when they’re triggered by an iframe, particularly a cross-origin iframe where the parent page likely has little control. Well, outside of, ya know, a website like CodePen. Chrome cite performance concerns as well, as the nature of these JavaScript dialogs is that they block the main thread when open, which essentially halts everything.

There are all sorts of security and UX-annoyance issues that can come from iframes though. That’s why sandboxing is a thing. I can do this:

<iframe sandbox></iframe>

And that sucker is locked down. If some form tried to submit something in there: nope, won’t work. What if it tries to trigger a download? Nope. Ask for device access? No way. It can’t even load any JavaScript at all. That is unless I let it:

<iframe sandbox="allow-scripts allow-downloads ...etc"></iframe>

So why not an attribute for JavaScript dialogs? Ironically, there already is one: allow-modals. I’m not entirely sure why that isn’t good enough, but as I understand it, nuking JavaScript dialogs in cross-origin iframes is just a stepping stone on the ultimate goal: removing them from the web platform entirely.

Daaaaaang. Entirely? That’s the word. Imagine the number of programming tutorials that will just be outright broken.

For now, even the cross-origin removal is delayed until January 2022, but as far as we know this is going to proceed, and then subsequent steps will happen to remove them entirely. This is spearheaded by Chrome, but the status reports that both Firefox and Safari are on board with the change. Plus, this is a specced change, so I guess we can waggle our fingers literally everywhere here, if you, like me, feel like this wasn’t particularly well-handled.

What we’ve been told so far, the solution is to use postMessage if you really absolutely need to keep this functionality for cross-origin iframes. That sends the string the user uses in window.alert up to the parent page and triggers the alert from there. I’m not the biggest fan here, because:

  1. postMessage is not blocking like JavaScript dialogs are. This changes application flow.
  2. I have to inject code into users code for this. This is new technical debt and it can harm the expectations of expected user output (e.g. an extra <script> in their HTML has weird implications, like changing what :nth-child and friends select).
  3. I’m generally concerned about passing anything user-generated to a parent to execute. I’m sure there are theoretical ways to do it safely, but XSS attack vectors are always surprising in their ingenouity.

Even lower-key suggestions, like window.alert = console.log, have essentially the same issues.

Allow me to hand the mic over to others for their opinions.

Couldn’t the alert be contained to the iframe instead of showing up in the parent window?

Jaden Baptista, Twitter

Yes, please! Doesn’t that solve a big part of this? While making the UX of these dialogs more useful? Put the dang dialogs inside the <iframe>.

“Don’t break the web.” to “Don’t break 90% of the web.” and now “Don’t break the web whose content we agree with.”

Matthew Phillips, Twitter

I respect the desire to get rid of inelegant parts [of the HTML spec] that can be seen as historical mistakes and that cause implementation complexity, but I can’t shake the feeling that the existing use cases are treated with very little respect or curiosity.

Dan Abramov, Twitter

It’s weird to me this is part of the HTML spec, not the JavaScript spec. Right?!

I always thought there was a sort of “prime directive” not to break the web? I’ve literally seen web-based games that used alert as a “pause”, leveraging the blocking nature as a feature. Like: <button onclick="alert('paused')">Pause</button>[.] Funny, but true.

Ben Lesh, Twitter

A metric was cited that only 0.006% of all page views contain a cross-origin iframe that uses these functions, yet:

Seems like a misleading metric for something like confirm(). E.g. if account deletion flow is using confirm() and breaks because of a change to it, this doesn’t mean account deletion flow wasn’t important. It just means people don’t hit it on every session.

Dan Abramov, Twitter

That’s what’s extra concerning to me: alert() is one thing, but confirm() literally returns true or false, meaning it is a logical control structure in a program. Removing that breaks websites, no question. Chris Ferdinandi showed me this little obscure website that uses it:

Speaking of Chris:

The condescending “did you actually read it, it’s so clear” refrain is patronizing AF. It’s the equivalent of “just” or “simply” in developer documentation.

I read it. I didn’t understand it. That’s why I asked someone whose literal job is communicating with developers about changes Chrome makes to the platform.

This is not isolated to one developer at Chrome. The entire message thread where this change was surfaced is filled with folks begging Chrome not to move forward with this proposal because it will break all-the-things.

Chris Ferdinandi, “Google vs. the web”

And here’s Jeremy:

[…] breaking changes don’t happen often on the web. They are—and should be—rare. If that were to change, the web would suffer massively in terms of predictability.

Secondly, the onus is not on web developers to keep track of older features in danger of being deprecated. That’s on the browser makers. I sincerely hope we’re not expected to consult a site called canistilluse.com.

Jeremy Keith, “Foundations”

I’ve painted a pretty bleak picture here. To be fair, there were some tweets with the Yes!! Finally!! vibe, but they didn’t feel like critical assessments to me as much as random Google cheerleading.

Believe it or not, I generally am a fan of Google and think they do a good job of pushing the web forward. I also think it’s appropriate to waggle fingers when I see problems and request they do better. “Better” here means way more developer and user outreach to spell out the situation, way more conversation about the potential implications and transition ideas, and way more openness to bending the course ahead.

The post Choice Words about the Upcoming Deprecation of JavaScript Dialogs appeared first on CSS-Tricks. You can support CSS-Tricks by being an MVP Supporter.

Posted on

Collective #626

Why Tailwind CSS

Shawn Wang shares why he changed his mind on Tailwind CSS, and why he now considers it the “Goldilocks Styling Solution”.

Read it

Clamp

Trys Mudford dives into one of CSS’s exciting new features for fluid scaling, clamp() for Utopia.

Read it

The post Collective #626 appeared first on Codrops.

Posted on

Collective #540

C540_paint

Largest Contentful Paint

Philip Walton explains how to make it easier to know when a page’s important content has loaded using the Largest Contentful Paint (LCP) API.

Read it

C540_extracss

Extra.css

A CSS Houdini library giving some cool features to your site (turn on Experimental Web Platform features or use Chrome Canary to see the effects). By Una Kravets.

Check it out

C540_accessibilityamp

Amphora.

Ethan Marcotte discovers some accessibility issues with the AMP Story format.

Read it

C540_inter

The birth of Inter

Learn how the new open-source typeface used by GitHub and Mozilla came to be in this article by Carmel DeAmicis.

Read it

C540_dotnet

Uno Platform

In case you missed it: Uno let’s you build mobile, desktop and WebAssembly apps with C# and XAML.

Check it out

Collective #540 was written by Pedro Botelho and published on Codrops.

Posted on

What the Web Needs Now (and how ARTIFACT is here for it)

I recently had the pleasure of joining Dave Rupert, Chris Coyier, and Chris Ferdinandi on the Shop Talk Show to talk about the upcoming ARTIFACT Conference (Austin, TX on Sept. 30 – Oct. 1, 2019). ARTIFACT is an intimate gathering of web designers and developers where we discuss ways to build web sites that work for everyone.

This isn’t our first rodeo! I started ARTIFACT back in 2013 with Christopher Schmitt and Ari Stiles (the team behind the legendary In Control and CSS Dev conferences). At that time, the sudden avalanche of web-enabled mobile devices was throwing the web design community for a loop. How do we best leverage the recently-introduced Responsive Design techniques to adapt our designs to a spectrum of screen sizes?! What does that do to our workflows?! What happens to our beloved Photoshop comps?! How do we educate our clients and structure our billing cycles?! It was an exciting time when we needed to adjust our processes quickly to take on a radically new web viewing environment.

After four events in 2013 and 2014, ARTIFACT took a little hiatus, but we are back for a five-year reunion in 2019. We are returning to a landscape where a lot of the challenges we faced in 2013 have been figured out or, at the very least, have settled down (although there is always room for innovation and improvement).

Is our work making the web better done? Not by a long shot! Now that we’ve got a handle on the low-bar requirement of getting something readable on all those screens, we can focus our energy on higher-order challenges. How do we make our sites work easier for people of all abilities? How do we make our content, products, and services welcoming to everyone? Does our code need to be so bloated and complicated? How can we make our sites simpler and faster? How can I put new tools like CSS Grid, Progressive Web Apps, static sites, and animation to good use?

To that end, this time around ARTIFACT is expanding its focus from “designing for all the devices” to “designing for all the people.” Simply put, we want a web that doesn’t leave anyone out, and we’ve curated our program to address inclusivity, performance, and the ways that new possibilities on the web affect our workflow.

A web for everyone

Inclusive design—including accessibility, diversity, and internationalization—has been bubbling to the top of the collective consciousness of the web-crafting community. I’m incredibly encouraged to see articles, conference talks, and podcasts devoted to improving the reach of the web. At ARTIFACT, inclusivity is a major theme that winds its way throughout our program.

Photo by Jopwell from Pexels
Benjamin Evans will talk about his efforts as the Inclusive Design Lead at AirBnB to create a user experience that does not alienate minority communities.
Accessibility expert Elle Waters will share best practices for integrating accessibility measures into our workflows..
We’ll also hear from David Dylan Thomas on how to recognize and address cognitive bias that can affect content and the overall user experience.

Even better performance

Visitors may also be turned away from our sites if pages take too long to load or use too much data. We know performance matters, yet sites on the whole grow more bloated with every passing year. Tim Kadlec (who knows more about performance than just about anybody) will examine the intersection of performance and inclusion in his talk “Outside Looking In” with lots of practical code examples for how to do better.
We’ll also look at performance through the lens of Progressive Web Apps (presented by Jason Grigsby of Cloud Four). In fact, improving performance is a subtext to many of our developer-oriented talks.

Leveraging the modern browser

In the Good News Department, another big change since the first ARTIFACT is that browsers offer a lot more features out of the box, allowing us to leverage native browser behavior and simplify our code (Viva Performance!). Chris Ferdinandi will be demonstrating exactly that in his talk “Lean Web Development,” where he’ll point out ways that taking advantage of built-in browser functionality and writing JavaScript for just the interactivity you need may make a big framework unnecessary.
Better native browser features also means un-learning some of our old coping mechanisms. We’ll get to delight at all the polyfills and workarounds that have been kicked to the curb since 2012 in Dave Rupert’s tale of “The Greatest Redesign Ever Told,” and we’ll see what best practices make sense going forward.

Workflow and process

One thing that hasn’t changed—and likely never will—is that never-ending hamster wheel of trying to keep up with an ever-changing web development landscape. I’m guessing that if you are reading CSS-Tricks right now, you know that feeling. The methods we use to build the web are always evolving with new tools, approaches, and possibilities, which is why best practices for adapting our workflows and processes have always been a central focus at ARTIFACT. This year is no different. Jen Simmons will share her thinking process for designing a CSS grid-based layout by live-coding a site before our very eyes.
Design systems, which have become a cornerstone of large-scale site production, get the treatment in talks by Kim Williams, Dan Mall, and Brad Frost. (Dan and Brad are also running their acclaimed “Designer + Developer Collaboration Workflow” workshop on October 3.)
Divya Sasidharan will show off the possibilities and performance advantages of static sites in her “JAMstackin” presentation
We’ll get a glimpse of the future of web animation from Sarah Drasner. (She’s bringing her popular “Design for Developers” workshop on October 3 as well).

The web can always do better to serve the people who use it. We’re proud to provide an occasion for designers and developers who care about putting their users front and center to mingle and share ideas. And yes, there will be milkshakes! The very best milkshakes.

ARTIFACT takes place in Austin, TX from September 30 to October 2, 2019 with workshops on October 3. Group discounts are available.

The post What the Web Needs Now (and how ARTIFACT is here for it) appeared first on CSS-Tricks.

Posted on

Clever code

This week, Chris Ferdinandi examined a clever JavaScript snippet, one that's written creatively with new syntax features, but is perhaps less readable and performant. It's a quick read, but his callout of our industry's fixation on cleverness is worth... calling out:

...we’ve become obsessed as an industry with brevity and clever code, and it results in code that’s sometimes less performant, and typically harder to read and make sense of for most people.

He made a similar argument late last month when he wrote about code readability, noting that brevity might look cool but ultimately leads to all sorts of issues in a codebase:

Often, web developers are obsessed with brevity. There’s this thing were developers will try to write the same function in the fewest number of characters possible.

Personally, I think brevity is pointless. Readability is a lot more important.

I entirely agree with Chris on this point, however, I think there is one important distinction to make and that's the difference between code that's intended as a prototype and code that's intended for production. As Jeremy Keith argued a short while ago:

What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes.

I agree with Chris that we should be writing code that is easy to read when we’re in production. I also think experimenting with code in this way is a good thing when it comes to prototypes. We shouldn’t ever shy away from playing with code and pushing things a little bit – so long as we’re not doing that in a giant web app with a a team of other developers working alongside us.

I’ve noticed that there are some folks that are doing genuinely ingenious things with Sass. I consistently sit back and think, "Wow, I’ve never seen anything like this before." But when it comes to a production web app that has to be understood by hundreds of people at the same time, I don’t believe that this is the reaction we want when someone looks at the code.

As a result, I’ve been trying to write Sass code that is actually so simple that it almost looks dumb. One easy way to make code a lot simpler is to reduce the amount of nesting:

.element {
  .heading { ... }
}

This looks fine when there’s code inside — and it’s pretty easy to understand — but add a complex bit of design in the mix (say, using pseudo elements and media queries) and you suddenly have a rather complex set of rules in front of you. Creativity and cleverness can be harder to scan and identify one small part of the code that you’re looking for. Plus, in this example, we’ve unnecessarily made our .heading class a little bit more specific which might encourage us to override things in a hacky way elsewhere in the codebase.

We could write the following:

.element { ... }

.element-heading { ... }

I know this looks foolishly simple but the relationship between these two classes is easier to see and easier to extend in the future. Bundling all that code into a single nested class can get out of hand real fast. Even if it happens to look a lot cooler.

(As an aside, Andy Bell's post on using the ampersand in Sass — and the resulting comments — is a great example of the clash between creativity and practicality.)

Anyway, the point I’m trying to make here is that CSS (and JavaScript for that matter) is a strange language because there are no definite rules you can make about it. It all really depends on the codebase and the project. But I think we can safely say that our code ought to be a lot more boring than our prototypes when it moves to production.

Continue to make prototypes that are wild and experimental or impossibly weird! Code quality be damned.

The post Clever code appeared first on CSS-Tricks.