Tag: Podcast

stefan-baumgartner-200x200-opt
04 Dec

Smashing Podcast Episode 27 With Stefan Baumgartner: What Is TypeScript?

by TBSCategories: News

We’re talking about TypeScript. What is it, and how can it help us write better JavaScript? I spoke to expert Stefan Baumgartner to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: He’s a web developer and web lover based in Linz, Austria. Currently working at web performance company Dynatrace, he writes, speaks and organizes events all about software development and web technologies. Lately he’s the author of the book TypeScript in 50 Lessons, published this autumn by Smashing. So we know he’s an expert in TypeScript, but did you know he can juggle up to eight fiery weasels whilst blindfolded on a unicycle? My Smashing friends, please welcome Stefan Baumgartner. Hi, Stefan. How are you?

Stefan Baumgartner: Hi. I’m smashing. I didn’t that about me, so that’s very interesting.

Drew: It’s amazing what people find out about themselves on this podcast.

Stefan: Absolutely.

Drew: So, I wanted to talk to you today about TypeScript.

Stefan: Yes.

Drew: It’s the subject of your new book, so clearly it’s something you’ve spent a lot of time getting to really know in depth.

Stefan: Yes, absolutely.

Drew: For those who have not used TypeScript before, so might not be familiar with what it is, how would you describe TypeScript, and what problem is it actually solving for us?

Stefan: It’s a very good question. So, there are many ways of approaching TypeScript and one way that I like most, and also the way that I like to describe in my book, is as a tooling layer on top of JavaScript. JavaScript is a wonderful language, but it has its quirks. There’s some parts that can have multiple meanings. You have dynamic typing, which means that while you can have different types like number or string or an object based on the position where they are in your code, and there’s lots of implicit knowledge when you work, especially with the technologies or with Node.js, That you have to know about some interfaces that you use from APIs, function signatures, etc.

Stefan: And TypeScript tries to give you a type system around all that, to give you this information. So, it tries to figure out which types you set when assigning variable. It tells you which function signatures expect which well use at which position, and which return objects that you get that you can then access and modify and work with.

Stefan: And this was, back in the day when TypeScript was created, that’s now about 80 years ago, the prime goal of the TypeScript team to create this tooling layer, in form of an additional language. So, to take all the risk from JavaScript and then on top they create their own kind of meta language that allows you to define types for your functions, your objects, whatever there is. And this also means that every JavaScript code is TypeScript code, which also means that you can get started right away. If you know JavaScript, you’re basically a TypeScript developer as well. And you just take what you need to get more and more information about your code.

Drew: So, TypeScript is almost like imposing a sort of bunch of more strict rules about how we write JavaScript in order to make code more reliable? Is that…

Stefan: Yes, yes, this is exactly what it is. So, the strictness is totally up to you. So you can tell TypeScript how strict you want to have it. But their goal is to catch as much errors, or as much possible errors, that there can be. Like oh well this value could be null, so better do a check if this value you exists or it can be undefined. Or, at this position I don’t exactly know if it’s a string or a number so check if it’s type of string, check if it’s type of number.

Stefan: So TypeScript knows more, or can give you more information about the class of failures that you’re dealing with. And right now, the main goals of TypeScript are to catch as many errors as there are. So they spent a lot of time in providing more tools for you to declare your types and to declare the strict rules for you to figure out if there’s any error in your code that you might have a problem with in the long run.

Drew: So, I mean, really to get back to basics when we talk about types in a programing language, which obviously TypeScript is all about types, we have strictly type languages and weakly type languages and JavaScript is weakly typed, isn’t it? What do we actually mean when we say something is weakly typed?

Stefan: There’s weakly typed, and another word for that is also dynamically typed, which means that you don’t always have to know which type your variables or your constants have. So, the moment you assign a variable, let’s say var fu or let fu with a number once you forget something, the cross-credentials say fu is now of type number, it’s a number and I can’t do number operations on top of it, like addition, multiplication, subtractions and all those kinds of things. If you assign it a string then it’s a string.

Stefan: And, in JavaScript, you have the possibility to override it with the value of an entirely different class, entirely different type. So, you can, say at one point in time it’s 1, 2, 3, 4, at another point in time it’s a string like, “Hello world, Stefan,” or “fussy cat” or something like that. And this can cause for couple of errors because what if you expect your variable fu at some point in time to be a string and then you do string operation on top of it like two uppercase, two lowercase. Or if you expect a number and you want to edit to something, then you could do result, which you don’t expect.

Stefan: And, with TypeScript, you can explicitly set the types or you can tell TypeScript to infer a type from an assignment. So the moment you assign one to free, TypeScript knows, Hey, this is number, and throughout your whole code, throughout every user through, it will think it’s a number and it will tell you if you do something that is not allowed with numbers. So, yeah. And this is the difference between a statically or strongly typed language, where you say, okay, once it has the type it has to be of the type and the type can’t change afterwards. In the weakly or dynamically typed language where the type just depends on where you are in your code and it can change, especially at run times or during the execution of the code, which can cause a ton of problems if you don’t pay attention.

Drew: So, yes, there’s that whole class of error, isn’t there, where you, as a developer, think that a variable contains a certain type of value and actually when it comes to that point in the code and that’s executed, for whatever reason it’s something different. And TypeScript is adding that enforcement of types on top of JavaScript to sort of give us that extra level of checks and reliability to it, to get rid of that type of bug.

Stefan: Exactly. The best example is for, for example, at the string two, with the number two, and you get 22 as a string, at the number two vice-versa and you get the number four. So, it’s apparently the same operation, but just if you swap the number in the string you get two totally different results. And TypeScript pays attention that it don’t have errors like that. And the one biggest rule that it sets like, so once you do an assignment, it has to be of that type, and the type can’t change.

Drew: So, TypeScript doesn’t actually get run by the browser, does it? Or by node or whatever run time you’re using, it presumably gets compiled down somehow to JavaScript?

Stefan: Yes. So you, there are two ways of working with TypeScript. One way is just exactly what you said, you write the TypeScript code, especially with this typing meta language that you use, and then you have a compile step where TypeScript erases all the types and spits out regular JavaScript code. And TypeScript is also transpiled so you can, say if you write more than the JavaScript, you can compile it down to something that I-11, if you have to support it, can work with. That’s one way.

Stefan: The other way is, and this is an interesting way which I like a lot and which people are using actually, you write regular JavaScript and then you add type declarations in a separate file, and refer to it by adding JSDoc comments in your code. And TypeScript can read this comment information, this documentation information, maps it to the types you created in separate file, and can give you the same tooling, the same information that you would get if you write in this transpiled, compiled way.

Drew: Okay, so then, that way you just keep your standard JavaScript, but the tooling that you’re using around it knows to reference the sort of side car file that has all the definitions of what the types are.

Stefan: Exactly.

Drew: Type checking is one thing, but surely that’s the sort of thing we can, we don’t need a new language to do. That sort of analysis we could just have running in a code editor in a VS Code or whatever for example. Does TypeScript add things that take us beyond just what you could do in a code editor?

Stefan: The biggest advantage that you get is actually from code editors. One funny thing is that if you work with Virtual Studio Code and you write regular JavaScript, what you’re really doing is writing TypeScript because Virtual Studio Code has built in TypeScript a checker and analyser that gives you, that tries to figure out as much information as possible and gives this information back to the editor and has a close relationship to the editor into TypeScript. In particular, especially since you mentioned VS Code. VS code was their first project to work with TypeScript. Back in the day, where it was called Strada or Project Strada, where all the developers figured out how to actually create a language like that.

Stefan: So, editors and language are very, very much connected and you get the best benefit if you’re working with modern day editor. And thanks to the TypeScript team this doesn’t have to be VS Code. It can be basically any editor. So the proactive blankets for almost any editor out there that supports a so-called language protocol. There also getting it for all the other programming language, feedback and editor feedback, and analyzing information.

Stefan: So, yeah. This is actually the main use-case for that. And, of course, if you have bigger projects and you used to compile stepped version of TypeScript, having some sort of continuous integration, continuous delivery, where you constantly check if your project makes sense, you’re creating bundles that you should begin, this is also a part of TypeScript plays a huge role because with every commit to a GitHub repo or something you can do type checks and see if there might be an error slipped in that should be taken care of.

Drew: So, I guess there’s a level that your code editor can do automatically. Like you said that Visual Studio Code does by just analyzing it as your writing JavaScript, but then when you’re using these, when you’re declaring types specifically or adding these JSDoc comments that’s what takes it a step beyond that. That’s where you’re actually, it’s defined as more of a language on top of JavaScript.

Stefan: Yep. The cool thing is TypeScript is, in the way it’s designed, that it tries to get as much information out of your JavaScript as possible without you doing anything. So, if it sees a number in the wild it knows that this type is going to be number. Or if you have a function signature and you say you have a default value like the way you add a tax to a price and you see it as standard way you add a tax is 0.2. So if you add this in the function signature TypeScript already knows at this point I expect you to pass number and not something else.

Stefan: Also, if you return an object or if you write a JavaScript class, TypeScript can figure out what the well use are, what the types of your fields should be. And this works for actually quite a lot of use cases. So you have lots of scenarios where this is totally sufficient and you don’t need anything else. But when you do, this is now your part to strengthen TypeScript with additional type information that you provide. So, let’s say you want to create a type article which should have a number, a description, a price. You have different types for that. And then you create a compound or object type and once you declare this type and you know that your object should be of this type, TypeScript knows which values and which fields to expect.

Stefan: And one thing that’s particularly interesting here is that TypeScript is one of the few and certainly the most popular type system that works with structural typing, which means that as long as the shape properties and types of those properties is the same as the object that you pass along or the object that you get from somebody else, it will say it’s okay. You don’t have to have the exact name, it just needs to have the exact structure. So if you have a type called book which happens to have name, description, and price and you have a type called video which happens to have name, description, and price, those types are compatible with each other.

Drew: Okay, so that means we can sort of define customer types that make sense in terms of the project and the objects that our project is trying to model and then use TypeScript to enforce the shape of those.

Stefan: Yep.

Drew: So if we’ve got a product that has a price property that’s an integer in sense or what have you, then TypeScript will enforce that for us and if we pass in something that’s not a product or doesn’t have a price or whatever, that’s when we start getting our errors. Can you then go sort of step beyond that if you had like a cart type that had an array of products inside it? Can you enforce all the way that level?

Stefan: Yep. Yeah, exactly. You can enforce that as well. There you enter also a class of types which is already goes into very advanced topics which is generic types. So, the array type is a generic type. It tells you an array has certain interest so you can index them. It has a certain properties like length or map or for each, but the well use inside this array are defined by a so called generic. So you can say you have an array of number, you have an array of string, you have an array of articles.

Stefan: And then if you do array.map then you get, inside this map function, you get the type again like a string, number, article, whatever you pass along. And with generics you can do a lot of things. So this is where the type system really tries to make sense out of all the possible cases people encounter in JavaScript frameworks. So you have, especially in JavaScript you have so many functions that can mean so much. Like, okay the first argument is now a string, the second argument has to be an object, or if the first argument is a number, the second argument has to be a string. You’ve seen that in the wild in countless, countless libraries that you use.

Stefan: And, for this kind of scenario TypeScript also has structures in generic types and conditional types where you can have checks if this is one class of types do this, if this is another class of types do that, which really tries to figure out most of the scenarios that you find in day to day JavaScript code.

Stefan: So, and this is actually where the fun starts. The thing like creating object types, creating regular types like number, string, etc., or creating function types that’s one thing. But if you try to model a very complex behavior just within the type system, this can get very, how do I say it, mind boggling. Yeah, I guess mind boggling is the right word. This can be very mind boggling, but also a lot of fun.

Stefan: And this is where I kind of got my, found my call to work more with TypeScript because I just found out that I could do so many that I see in, not only in my code but in the code for my colleagues and code that I find online, to make more sense out of it and to be prepared for future scenarios. So, I mostly write types in TypeScript because I know that at some point in time I have to revisit code and I want to know what I’ve been thinking back when I originally wrote it.

Drew: Where is in your project that you would define these types? Because presumably you want them to be reusable all around your project. Where do you define them?

Stefan: So, I usually define them very close to the code that I actually write. So, when I write TypeScript I write in TypeScript first. So I transpile, I usually have a compile slip anyway of, maybe because I’m doing React and I need to transpile JSX, or because the project is so big that I want to do extra checks. So there’s a built chain anyway. Either I need to bundle or I need to transpile, so I’m writing regular TypeScript, not JavaScript with this JSDoc extensions. And there I try to keep the types very close to the objects that I declare.

Stefan: If there’s a type that is used throughout the whole project, I’m not only expecting the type, but also the objects or the functions for that objects. So this is some way of splitting and moving files and types around. There’s a very rare case where I also have one of those global type finishing files next to me, which is if my app has to deal with something that’s in the environment where I run it, be it either node or browser or whatever, where some global ideas or global concepts are that I want to carry in my program and hold. And this is actually a pretty standard set up.

Stefan: So you have your TypeScript files on one side, you have couple of type definition files on the other side, and then TypeScript tries to figure out everything, if it makes sense and if it’s possible to do and hopefully that’s the case.

Drew: Yes, I think we’re all very sort of used to having a build step, combilation step, in our work flows these days, aren’t we? With whether it’s running Babble or dealing with JSX and React or Web Pack and what have you so…

Stefan: Absolutely.

Drew: I guess adding TypeScript into there is just another small step in the process and quite easy to do.

Stefan: Yeah. So it’s, on one side TypeScript is a great extension, especially if you have a Babble set up running. So they provide an interface where you can do TypeScript type checks, even though your whole application is transpiled with Babble. TypeScript also has a lot of tools so it can be the only transpiler that you need. So it can transpile JSX, it can transpile down to Equiscript 5, Equiscript 3. The only thing that it doesn’t do anymore is bundling. So if you want to have bundled up application you need to take another tool like Roll Up or Web Pack or whatnot.

Drew: One of the features that I liked in newer versions of PHP, back when I was writing a lot of PHP, they brought in the ability to declare the types of each argument that a function was expecting. TypeScript does the same thing, right? You can say the first argument should be a number, the second argument should be a string-

Stefan: Yes.

Drew: … and then the tool sets going to catch that if you try and pass the wrong thing in.

Stefan: Exactly.

Drew: In a lot of sort of real world cases I find that I have function arguments or variables that would be of a given type, but there might also be null. Is that something that TypeScript allows for?

Stefan: Yep, yep. So, this is where you enter the wonderful world of Union types and this is the big chapter in my book in the middle where we go from beginner concepts to advanced concepts. Where we realize that you don’t, not only have different classed of types like numbers, string, or several object types, but you can combine them. So you can say, this argument can be of type of string, of type number, or of type null or of type undefined, or for some object type. And with that your arguments, especially function arguments become much, much more varied.

Stefan: So if you can for one thing say, if this function argument does not have null in its unit type, then you’re not allowed to pass null. And you can make sure that inside this function, this way you is never null. If it can happen that it’s null, you add pipe to pipe operator null to it, and suddenly you have to check if it’s null or if it isn’t. Which makes it very, very interesting. So, especially the case of null checks and having undefined values. This is something that you happened to have in TypeScript all the time, or in JavaScript all the time.

Stefan: And with this one little addition, like make sure you check for your null-ish values and if you don’t allow null-ish values they can’t be null. This erases a whole clause of errors that you would otherwise encounter. And this is also one lesson in my book where I just talk about this one compile of next trick null checks and what it means for your work and what you suddenly have to do. And at some point you realize, okay it’s much more tedious to add pipe null to every possible case where it could be null, instead of just for one time in one place of your code, check if it’s actually null and then just continue with what you did. So, that’s a very nice way of working with null and undefined values.

Drew: A lot of sort of more formal languages, OO type languages, have classes and give you the ability to define a class interface to be able to say if it’s a class that uses this interface it needs to have these methods, it needs to behave like this. Is that something that TypeScript gives us?

Stefan: Yeah, absolutely. So this is very much related to the history of TypeScript. TypeScript, when it got first released, you know it was eight years ago we weren’t talking about Equiscript 6 there, we weren’t talking about native Equiscript classes, we spoke mostly about objects and functions. There was no modern system so it was a very different type of JavaScript eight years ago than we have today. And eight years ago, the TypeScript team introduced lot of features from other program languages like Java, C#, like classes, interfaces, extra classes, name spaces, to create some sort of structural or structured programming tools that make it possible for you to lay out your code entirely different than you’re used to.

Stefan: But over the years, lots of those concepts found there way into JavaScript, especially classes. So, they had to revisit lots of that concepts again and made it much, much more aligned to the way JavaScript is right now. So you still have classes, you still have interfaces, but TypeScript classes are just the same JavaScript classes. And TypeScript interfaces are like compound type or composite types where you have just list of properties. They can be function properties or string properties or mass object properties, and interfaces and type declarations are, in the most parts, just the same.

Stefan: You also can implement, you know the implements keep it exist, you can implement an interface, you can implement a type. There are, just in some rare cases, effective to some rare cases there are totally the same. So, yes they exist, but they mean something different than your used to from other programming languages. And this is also something where I’d say people who come from other programming languages have to look out for things like that because they can be false friends. Where you, they think, Okay, oh this just works just like in Java or this works just like NC Sharp, where in turn it’s just borrowed language or it’s just the same names for concepts that are nuanced and somewhat different than to what you would expect.

Drew: It can be a real sort of mental hurdle to jump over, isn’t it?

Stefan: Absolutely.

Drew: If you’re familiar with a name meaning one sort of thing and now it means something else.

Stefan: Yep.

Drew: It can be quite difficult to reset how you think about those things. So, it sounds like TypeScript has some sort of really advanced features that help us who are working really hard in JavaScript all day. Is it just for us super nerds or can people who less familiar with JavaScript, is it useful for the more, the beginner or the intermediate as well?

Stefan: Yeah, I’d say both. So one of the nice things about TypeScript is it’s creditable. So you just use as much of TypeScript as you want to use. So if you learn JavaScript, you get some additional tooling that gently tells you, Hey, there might be some properties that you want to select. Like if you call document .queries elect it already tells you, no queries elect exists and it gives you some hint on what to expect as an argument without throwing a single error and without you needing to do anything with those red streak lines that you get in your editor.

Stefan: And for that already TypeScript can do a lot of things. So this basic tool aspect of it can help beginners just as much as people who are more familiar with JavaScript and then have been in JavaScript for a very, very long time. But as you progress you can buy into more and more and more concepts as long as it’s reasonable for you to do. So I’m always a strong proponent of not having to use every feature a programing language gives you, but just the features that you actually need and TypeScript is perfect for that because it has a ton of features from the history that we spoke about where it tried to introduce concepts that haven’t been in JavaScript. And now from all those concepts that try to make the most sense out of all the JavaScript code that there is outside, you can take whatever you need and whatever you like from that.

Stefan: And this is, I guess, what makes TypeScript so special. When I started working with TypeScript, like seriously working working with TypeScript, the things that it most was like having a react component and being super happy that if I press control space that I get all the name of the properties my function component would expect. So this alone helped me a lot and it did nothing else but using this feature for a very, very, very long time. And then I started, in some sort of library code that I created for my colleagues or for people who I work with, creating a type core set around my function so people who use my code know better what I meant when I wrote those particular functions. And there I go all in. I’m very deep, deep down the type system rabbit hole.

Drew: Yeah, I mean that’s interesting. In the last episode of this podcast I talked to Natalia from Vue JS all about Vue 3 and one of the big changes they’d made in Vue 3 was that it was rewritten using TypeScript. How important is it for libraries and frameworks to adopt TypeScript? What benefit is that actually providing those who are working with the library and not on the library code itself?

Stefan: So, I think for one part you get a lot of implicit documentation. Especially if you import Vue or React, React is kind of a mixed bag, but if you import Vue or Preact for that matter, Preact is also written in TypeScript. People who use your framework immediately have some information about all the functions and all the objects that they get without you needing to look up anything and you get some extra checks if what you’re doing is the right thing to do.

Stefan: So that’s a lot of implicit documentation for all the users of those libraries that you get, basically for free, if you start writing in TypeScript anyway. So every project that is written in TypeScript gets, produces all this extra information for free. I guess as a team, as a library author, it makes contributions a lot, lot easier for the same documenting reasons. It also makes checks a lot easier because there’s a whole class of errors that you can catch in the type system that you, that would take ages to catch in tests. That’s why nobody writes test for that, especially if this is of a certain type, kind of tests.

Stefan: And yeah, and then you of course get all the benefits that you would get if you used TypeScript in any other project are catching errors before they happen. And one thing that I have to mention here is, especially Preact because Preact tries to do the kind of thing that write JavaScript code, and add additional types on the side, which gives them a low barrier of entry for people who want to contribute because they don’t have to figure out how the type system works or how type script works because they’re just like JavaScript code. But they, as library authors, get the additional benefits of having type checks, of seeing if this works the way it is intended, and I think this is for lots of projects. Especially Open Source projects really the best way to go.So, I strongly advocate for the idea of having JavaScript types on the sides because it can help people so, so much for basically not a lot of investment on your part.

Drew: Increasingly, we’re seeing sort of whole organizations moving to JavaScript as their sort of language of choice, both in the front end where it’s an obvious choice, but in the back end of their products and systems. Would you consider TypeScript something that sort of larger teams and larger organizations would really benefit from? More than individuals?

Stefan: So, I’m currently in the same transition. So we have lots of Java NC Plus developers who are going to write a lot of JavaScript in the future and you know what, TypeScript can be some sort of guide for those carry areas of new program languages. JavaScript has a lot of quirks, a lot of history and a lot of prejudices if you come from a different programing language. So TypeScript can be a guide because there’s some concepts that you’re familiar with it in the type system.

Stefan: But also, I think, especially when you have lots of people working in the same hole base or lots of people who need to work with each other, this can be an additional layer of guidance in your project where you don’t have any bad surprises in the end. So, of course technology doesn’t solve any communication problems. This is not what TypeScript is intended for, but it can lower, it can make lot more room for the right discussion then, if you don’t have to talk about what do you expect from me in your code, but rather what should your code do or what should your library do.

Stefan: And, I always say that if you ever write code for other people or if you write code with lots of people or if you just write code for yourself, you have to revisit the next day, consider TypeScript because it might help you in the long run. And this is not just an investment for the next project of next week, but more for one who say, Okay, especially if long lasting projects for month, two, or years. Definitely offer that. You’re never going to know what you’ve been thinking of when you wrote the little piece of code one year ago, but types can give you a hint of what you meant.

Drew: One thing I think that stopped me looking too closely at TypeScript in the past is I sort of remember things like Coffee Script that were a sort of new Syntacs that sort of transpired down and I kind of thought that TypeScript was another one of those, but it’s really not, is it? It’s plain JavaScript with some extra things layered on top.

Stefan: Yeah, so this is something that the team also strengths a lot. It’s fundamentally not a new language. So, it could look like that if you look at examples from 80 years ago, this was also part, just like you too. I was avoiding for such long time, firstly because of Coffee Script, second because of tons of JavaScript developers telling me that this is Java 4 or this is JavaScript for child developers, like and now finally get all those tools that I know from years and years of writing Java and I don’t want to change the ways I write, I just want to have the same tools but drawing in a different environment and this scared me and I didn’t want to have to do anything with it. And it took me, I guess about six years or so until I tried it again.

Stefan: Especially after watching some videos of TypeScript’s creator Anders Hejlsberg who spoke exclusively about the tooling aspects and about this is JavaScript. So, I met him twice in Seattle and when he went into interview sessions where we all were, he said from himself that he was writing JavaScript for the better part of the last decade. And if the creator of TypeScript has this idea that he’s writing JavaScript, perhaps you know with this extra type annotations, this takes the whole language and the whole tool into totally different light.

Stefan: And that’s why they’re stretching the fact so much that everything that you have, especially if it’s a new language feature, this is JavaScript. So they are very closely aligned to the ECMAScript standard. They are also championing a couple of proposals in the ECMAScript standard. They are involved, they know what’s happening, and if there’s a new feature that reaches a certain stage, they’re adopting it in TypeScript, but they’re not creating any new language features on their own.

Stefan: Where they innovate is in the type system. And you can really separate the type system from the actual JavaScript code. Of course there’s some mingling of JavaScript code and types group, especially when you do type annotations, but other than that it’s JavaScript with benefits. And those benefits are what makes it worth in my opinion.

Drew: And I guess we could go through all sorts of those benefits, all sorts of features that are in TypeScript, we could go through them blow by blow, but it doesn’t necessarily make sense to do that in a podcast. It’s difficult to describe code, isn’t it?

Stefan: Oh, you an write an entire book about that.

Drew: Are there any particular features of TypeScript that you’re most excited about or think provide the most value to users?

Stefan: I guess one of the features from the type system that I like most, which is again advanced but not super advanced so that it’s easily graspable, are union and section types. Where you can say, Okay, this argument or this variable can be not only of this type, but also of another type. Or it needs to have features from this type and this other type. And if you, once you realize that you can make use of that, you suddenly can model your application a lot, lot better.

Stefan: So, I adopted a work for where I tried to think about the object and the functions that I have, like what do they expect, what is the data, how are the properties designed. And then I tried to work with them as much within functions and if you use an intersection types you can, you have so many tools of modeling your data that if you spend a little time doing that you catch a ton of errors and a ton of problems up front without spending too much time into, in TypeScript land.

Stefan: And that’s why I guess they would be my most favorite feature. And also the fact that TypeScript transpires everything. I don’t need any Babble or any other transpile and I’m pretty tired of having too many tools that I need to use. So if I just can rely on one tool and maybe another one for bundling, that takes a lot of noise off my mind. So, that’s what I’m also very thankful for. It can just do a lot.

Drew: You’ve written about what it can do in a new book for Smashing. Loads of great information for people who are wanting to learn TypeScript. So, what sort of developer is the book aimed at?

Stefan: Yeah, so if you read TypeScript in 50 Lessons, we assume that you are already a JavaScript developer. You don’t have to be a seasoned JavaScript developer, so just enough that you, you’ve written application with it, you know some quirks, you know what an object is, you know what an error is, you know what a function is, you know what an assignment is. So stuff like that.

Stefan: And we take you from there, from just enough JavaScript that you know how to be dangerous, and guide you through the TypeScript layer. So, you could write books about TypeScript that you just speak about every feature that there is and explain just a little and let the reader figure out whatever to do with it, and we take a total different approach. We focus on one particular part, which is the type system, we leave out a lot of other things that, they are, neither the team nor seasoned TypeScript developers would recommend that you do, and focus just on the part that is long lasting.

Stefan: So, this was one thing that I really cared about when writing this book that once it’s out it should have some relevance in years to come. Especially with TypeScript getting four releases a year, you never know all the features and you can’t express all the features. But you can express, or explain, how the type system works. And from that on you figure out the things on your own. And this is what we do, so we give a very in depth introduction into the type system.

Stefan: First, in the first four chapters we guide you to the point where Okay, yeah, you know how to assign types, now you know how to work with types. Then there’s this water sheds chapter where we go into unit intersection types and from then on you learn about type modeling and about moving into types system. And after you read the last few chapters, we had seven chapters in total, you should know everything, to be prepared for every single TypeScript that there is. And for every new class of types they introduce and for every new class of errors they try to solve.

Stefan: And it took me quite a while to write this book to be honest, so me knowing that it didn’t have to change the table of contents and it didn’t have to introduce any new concepts over the last 1 1/2 years to me is proof enough that we succeeded in that. So, maybe we snuck in one or two features from TypeScript 4.0 but not all. So all the learnings that you have are still well it even though we, I designed them 1 1/2 years ago. So, yeah this is the main goal of the book. And it’s kind of what we see in the tag line. We want to take you from a beginner to an expert. And I hope we succeed with that. Yeah.

Drew: I certainly found reading the book though because it is broken down in, you know it’s 50 lessons so it’s all in sort of fairly bite size chunks, and I found that I was able to start using all of that straight away. You’d read about something and then you could start using it. It’s not one of those books where you have to make it all the way through to the end before you can start being productive.

Stefan: Yeah. Yep. Absolutely.

Drew: Very easy to just sort of drop in and drop out of which with many of us being so busy and under so much pressure in our jobs and things at the moment, it’s great just to be able to read a little bit and then forget about it for a while and then come back and read a bit more.

Stefan: Yep. This is also something that we take a lot of care, that we really cared about to achieve. It can be really overwhelming to learn a new language. Especially a new programming language. And so those bite sized chunks, you know you just spend about five or maybe ten minutes with one of those lessons. And you can immediately apply the learnings of those lessons to some actual code and we provide you with all the code examples online. So if you go to TypeScript-Book.com you see a list of all the code examples that there are.

Stefan: And this helps you just getting in as much as you need and as much as you like and it gives you also a lot of room to breathe and to take a break and to get your mind off of it and then revisit back later. This is also by the edit some interludes in between chapters which are mostly non-technical. They give you little bit of TypeScript culture, little bit of ideas how the TypeScript team thinks, how the community thinks, and how writing good TypeScript code because you without actually focusing on the coding aspect. And we also added those to give you a little break, a little room to breathe, to digest what you just learned because we know that this can be a lot of stuff. And, yeah, so if you just take one lesson a day, you are through with it in 50 days and are an expert in TypeScript, so.

Drew: I often find that when I’m writing about something I’ve been putting together a presentation or an article or something like that, I find that I learn new things that I didn’t appreciate before because having to explain something, you have to make sure you really understand all the details. Was there anything that you found about TypeScript in writing the book that you realized you were learning for the first time?

Stefan: Yes. There were two kind of things that I learned while writing the book that really surprised me. And one thing is how the type definitions TypeScript brings along are structured and created and declared. So they have written a parcel that goes over all the web standards on top of your 3C and there’s this web interface definition language which is it’s own language created by W3C to declare JavaScript interfaces and to take this code slip, it’s refracted them into TypeScript types. And then have some way of structuring them to be ready from ECMAScript 5 standards up to ECMAScript 2020, 2021 standards and if you browse through those alter generated file and read how good they are and how well documented they are and how the structure types that you can learn a lot.

Stefan: So this was one thing there. I kind of lost track at some point while writing it because it was just spending two or three days within, in those lib.d.ts files and soaking up everything that they created. I even have one lesson dedicated to lib.d.ts because it was so, so surprising. And the other thing is, I guess, realizing how generics and conditional types really work under the hood.

Stefan: Because when you apply them and you work with them you just use them as much so you get the right results, but you never question what’s actually making them work and by explaining them in chapters five and six in my book I really found out there are very delicate mechanics underneath and if you understand those mechanics it gets a lot, lot easier creating conditional types, creating generic types, than it would be without just by trying to figure out things. That’s why I also have some flows of code in my book where we start with the conditional type that you write and then we go step by step evaluating what it means until we get to the result type.

Stefan: And this is something where I found some joy in it because it really made me understand what my book should be actually about. That I spend a lot of time and cared a lot about getting those examples right, so. I hope readers will find the same joy out of it because it can be very, very interesting. And, yeah, it gets a little bit nerdy, but that’s part of the fun.

Drew: For anyone wanting to actually get started with JavaScript it sounds like your book is a really great place to begin. Are there any other resources that you’d recommend?

Stefan: So, one thing that I also mention very early in the book is the TypeScript Playground. So, TypeScript offers an interactive editor online with lots and lots and lots of examples to give you good feeling of how it is to work with TypeScript, how TypeScript in the JavaScript only scenario looks like and works like or which language features there and what they mean for your types and especially in the recent year, the TypeScript team hired a person, Orta, just to work on documentation and Playground and website and all those learning resources. And you can see that the process immensely.

Stefan: So, he spend so much time into refactoring every bit and piece of the whole website that it’s now a great learning resource and Otta also, has also written the forward to my book and were chatting about how a book on TypeScript can or should be different compared to what they provide as a learning resource. And I think they work really well together. The book gives you a very tailored and opinionated view and the learning resource that guides you step by step whereas the handbook is this big knowledge base where you get all the additional information and can dig deep into one specific scenario that wouldn’t have enough room in a book.

Drew: Stefan’s book TypeScript in 50 Lessons is available digitally from Smashing right now and it’ll be available in print from November 2020. You can find it at TypeScript-Book.com. So, I’ve been learning all about TypeScript. What have you been learning about lately Stefan?

Stefan: I’m digging into different programing languages again. I’ve been learning a little bit of Go and a little bit of Thrust and what scenarios there are for using them and it’s fun learning something entirely new. It gives you a new perspective on what you already learned so far. So, this is what I enjoy a lot at the moment.

Drew: It’s always exciting, isn’t it? Learning a new language and getting a new perspective on how other languages are structured.

Stefan: Absolutely.

Drew: If you, dear listener, would like to hear more from Stefan, you can follow him on Twitter where he’s DDPRRT and you can find his personal site at fetblog.edu. TypeScript in 50 Lessons is available now from Smashing and you can read all about it at TypeScript-Book.com. Thanks for joining us today, Stefan. Do you have any parting words?

Stefan: Thank you very much. No, well, DDPRRT is the worst Twitter handle in the entire world and if you say it very fast it’s dead parrot, and if you know Monty Python, you might know about the dead parrot. So, that’s all I can say about the worst twitter handle that there is.

Drew: He’s pining for the fjords.

Stefan: Yeah. But, seriously, I hope people enjoy working with TypeScript. I hope they enjoy my book. I’m really, really excited about feedback, so if you have any feedback hit me up on Twitter. I’m here to chat with you about all that stuff. And I’m also very happy to work with you on type programs. If you have something that you can’t quite make sense out of it just drop me a line or a Twitter direct message. I really take the time to see if we can solve the problem.

Articles on Smashing Magazine — For Web Designers And Developers

natalia-tepluhina-200x200-1
19 Nov

Smashing Podcast Episode 26 With Natalia Tepluhina: What’s New In Vue 3.0?

by TBSCategories: News

In this podcast episode, we’re talking all about VueJS. What’s new in the 3.0 release, and how hard will it be to migrate? Drew McLellan talks to core team member Natalia Tepluhina to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: She’s a passionate web developer, a Google Developer expert, and a conference speaker and author. Currently she’s a Staff Front Engineer at GitLab, but you may know her best as a Vue JS Core Team member. So clearly she knows her way around Vue better than almost anyone. But did you know she once taught a kangaroo to sing. My Smashing friends, please welcome Natalia Tepluhina.

Drew: Hi Natalia, how are you?

Natalia Tepluhina: Hi Drew, this was a really nice attempt on my last name. I need to give you credits. It was one of the best things that I ever heard from English speaker when they try to pronounce my last name. I guess it’s not possible if you’re not Russian speaking. It’s correct pronunciation is Tepluhina, but it’s like, that’s why I’m usually just asking people to call me Natalia and let’s stop at that.

Drew: Okay, well I made an effort. But the important question is, are you Smashing?

Natalia: Of course I am.

Drew: That’s good. So I wanted to talk to you today about some really exciting news that we have in September with the release of Vue 3.0. It’s been a major release in terms of version number but it really is a big release for Vue, and has been in the works for quite some time, hasn’t time it?

Natalia: It is. I think we first announced version three in 2018. I think it was announced in Spring, and the real work started in, I mean ideas was in Spring, the real work started in 2018 Autumn. And I think it was officially announced at the London Conference, which happened in October, 2018. Active work took two years. And it’s a lot if you think about, previous version was released in 2016. So half of these four years were also dedicated to Vue 3 work.

Drew: What was the sort of motivation factor in deciding that a new major version was called for? Was it a sort of conscious decision that, okay we’re going work on a major version, we’re going to work on Vue 3, or was it just sort of an accumulation of changes that simply required a version bump?

Natalia: No, I think it was an idea to create a new version due to a few very important things. So first of all, there was a motivation to change the reactivity. Previous one was built upon Object.defineProperty. And it had a few caveats, they’re all documented but still. You know, even if you document something that people shouldn’t do, they will do it anyway. And you would need to point them to the documentation. Nobody reads documentation by the way. For some reason it just happens. Until you point people out it doesn’t exist in docs it does. But okay. We will teach you anyway. So reactivity was one of the things.

Natalia: Performance was the next. Vue 2 still had and has not the worst performance, but we had a few ideas about how to make Vue faster. And also there was one pain point for a particular part of our, let’s say audience, people that use Vue. It was TypeScript. Vue 2 internally was written in Flow, which is still strongly typed one, but typing with TypeScript were a real nightmare especially if you are working with our state management Vuex. This was again a huge part. And the last one was, we kind of missed the functionality to abstract logic, in terms of not components but compossible logic parts. Like functions helpers and so on, but they should be able to include viewer activity as well. A nice example here could be React Hooks, right they allow you abstract the parts of the functionality and this was clearly missing in Vue. And I know that right now it sounds like, “You stole the feature from React.” Not in fact. I believe that ideas cross-pollination is a big and nice part in our ecosystem and also it helps developers to switch between favorites, right?

Natalia: So we were working on these main features to create the Vue 3 as major version.

Drew: Now I think it’s one of the great things about existing in an open source ecosystem is that there’s a wealth of ideas and experience all out there from all sorts of different projects, and the ability to borrow those ideas and borrow the experience from other projects is really beneficial and makes everything stronger, doesn’t it?

Natalia: It is. I think it, it works the way we call an iteration value in GitLab. When you come up with an idea, it’s never perfect. It’s mostly like some very raw, very hard coded thing. Maybe change something, but it’s like definitely not perfect. And you need a few iterations over this idea to make it really good, not even perfect, just good. And happens with ideas in the ecosystem. Someone comes up with a good idea, and you just take it and make it better and better. And I bet that well, there will be something that will take some ideas from Vue, maybe they already taken some ideas from Vue, and make it better, and there is nothing bad here.

Natalia: I’m strongly against, like, “You are stealing ideas”. This is not stealing, this is just cross-pollination.

Drew: Exactly, yeah. You mentioned that the migration to TypeScript, so Vue 3 itself is written using TypeScript now, is that correct?

Natalia: Yes, yes it does. And trust me, Drew, I was writing the documentation, the small document about how to use Vue with TypeScript. And I was like, okay, probably somehow like Vue 2. And I overcomplicated the document so hard, I was like typing everything explicitly. Looks good everything is typed. I can see types, so my ts-link is happy, so far so good. And then one of our developers who was working with TypeScript, “You don’t need to do this”. Like how, how? “You don’t need to do explicit types to data. You just give it an initial value and ts-link knows its number. It’s already typed.” Like, how come? “I removed 90% of explicit types from the document. There are only two things you will really need to type is proxy of the component, and computed properties will have. They still require return types. But the rest is like, typed automatically, just write a component with a method we call define component. And that’s it. It’s typed.”

Natalia: It was like, it just works. And for me, and I was working with Angular in my past experience a lot, I have Stockholm Syndrome for TypeScript. Everything should be typed explicitly. I mean, if you have complex types, of course you will need to write interfaces, but this is how TypeScript works. Still, it’s so much easier to work with TypeScript right now with Vue 3.

Drew: So that’s great, so it’s a benefit both to the Vue Core Project, and to developers who are building applications using Vue because they can use TypeScript in their applications nicely with Vue now, where they couldn’t with 2.0, well any version of 2.0 so easily. Those who are familiar with the Vue community will be aware that Vue’s creator Evan You is still leading the project very actively. How does the Core Team function? How is it structured when it comes to the development process? It’s not all Evan is it?

Natalia: That’s such a great question Drew, because for years, literally, people were speaking about Vue as, I quote this and I will sound harsh, but sorry, it’s like, “A framework of one Chinese person, like Chinese framework even”. And I mean even with Vue 1.X, there was already a team and there was a big team behind Vue 2 and even bigger team behind Vue 3. The thing is we all have different responsibilities when we speak about Vue.

Natalia: There are people who are working on Core, and this is not just Evan himself, he is doing most of work on Vue Core, definitely, and he’s leading the project as well. But there are people who works in Vue Core, and their contributions are absolutely invaluable. And there are a few new people, joining Vue team as well, that work in Core. And there are also smaller teams working on ecosystem, there are people that work on the Pure Router, like Eduardo, there are people working on Vue CLI, on Vuex, on documentation as well.

Natalia: There is a whole team that works on documentation because we believe that documentation is important. And currently on our website there is, I think 21, 20 or 21 person, always miss the count, that belong to the Core team, but this is not a static list. Because we, we’re not hiring obviously, we are an open source team, this is not paid job. But we believe that if someone contributes a lot to any of parts of the Vue ecosystem, when people already do the job of the Core team member, it’s just, giving them recognition with just access to the repositories and formal title.

Drew: That’s great because it’s a case where contributing to an open source project can really sort of pay back to an individual. They get some recognition and that can have an impact in your professional career and what have you.

Drew: For listeners who may not be used to Vue but perhaps they’re familiar with other reactive frameworks, such as you know React, Angular and so on. What are the big, sort of, headline changes with Vue 3 and specifically what problems are they trying to solve? You mentioned composition earlier as one of those things, is that on of the big changes?

Natalia: Yes, this is one of the biggest changes, and it’s actually one of the things that are, first of all, like let me make clear statement here. Composition API is purely additive. It’s not that you need to rewrite your components, you can add TypeScript to them. Or you might prefer, to use all syntax, now we call it Options API, and nothing will change for you in these terms. It’s like, when we’re speaking about new API, this is not a breaking change. I just want to emphasize this really, it’s really important to say because when it first announced the Composition API it was an awful moment.

Natalia: I think we didn’t really describe the changes nicely and we made it seem that standard build will be Composition API. It’s our bad completely and options were like, maybe we will deprecate it in future builds, not in Vue 3, clearly. And if there are any chances that people will read what you said wrong they will read it wrong.

Natalia: Immediately after this statement, it was RFC where we just proposed the change, Reddit exploded. Reddit was filled full of like, “Oh, my god. I will need to write everything. Oh, my god. Vue is new Angular. They are going to break all the things.” And there was a guy who created an article on dev.to called, Vue’s Darkest Day. It was a darkest day, honestly. We felt so but I was like trying to kind of fight this on my own Twitter like, “People we are not really… They were saying that we started to change the RFC, I think Evan started to change the RFC without announcing changes. So he was like, “I will just quickly re-write this. Let’s like push into master”. People were mad about this. Because they were arguing about certain points then you just refresh a page and those points not exist anymore. You feel like, am I a fool or just… What the hell? I mean, it was right there. I remember this. And I believe that our communication strategy could be better and this isn’t us.

Natalia: Right now, every single time I speak about composition, this is purely additive, people. This is just a nice feature. You can use it, you can not use it, you ar not obliged to. Just… It exists.

Drew: What is the sort of problem that somebody might get themselves into where the Composition API is a new thing that helps them get out of that problem? What problem is it solving?

Natalia: Imagine the component that has a few features inside of it. Let’s say it’s search and sorting. Let’s say we search for a certain list and we try to sort it. This is already two different features and the thing with Vue components is, they are split, based on the options, not based on the logic. Imagine your search has probably a query, because you need to make a query to search and array of results. And these are two reactive properties. In terms of your component, you put them to the option that is called data. And obviously you need some method to perform the sort. Maybe a button click, maybe something else, something that runs the search. You create the method. And for sorting you need to build something upon sorting options, another reactive property. Then you perform some calculation to sort the results.

Natalia: In Vue, for this, you also have computed properties, which is another option. At the end, your component became really fragmented. And imagine I’m a developer and I have a task to work only on searching part. I cannot split the component right now, because these two features are kind of cross in their ways. I search for some results and sorting them. And I need to jump from data to method, from method to computed and at the end it’s really hard to just switch the context. Especially if the component grows really big.

Natalia: What options did we have in Vue 2.0? First option was called mixins and mixin is just an object that can contain the same properties component can have and we are mixing them in with a component. Sounds good, I can just move all my search in there and what is the problem? There are a few. First, this is completely not flexible. If I want to search for a certain end point and I move this to mixin, this will be the only end point I can search for. Mixins don’t accept parameters. I created a mixin, it’s completely static. Second issue is mixin is mixed in, which means for certain properties it happens like a merge. For example if you have created hooks it will be merged. All the logic in the lifecycle hook from the mixin component are merged together. But if you have a data property, a cold query in the mixin and by any chance you have the same in the component, the component has a priority. It will be overridden. You will have no warnings. Absolutely. It will just happen and you will have no idea this happened.

Drew: All the scope is completely mixed?

Natalia: Yep, completely. There is no chance you will see and also, mixins are very unclear source. You just import the mixin with name and put it to view component property mixin, that’s it. It’s very implicit and I’m speaking about this from the point of my own experience. We have a logic in GitLab where a component contains two mixins and every of these two mixins contains another mixin. And here it goes, here is a property you need to check and it’s not in the component. Let’s go deeper, first level mixin. This one does not contain it and this one does not contain it as well. Where it is? You’re diving deep, just deeper down the rabbit hole, just to find this property and testing becomes a nightmare as well.

Natalia: Mixins are very, let me say, dumb ways of extracting the logic. It’s plain, it’s clear, it’s very easy to get. It brings you so many problems if you want to work with this on advanced level. Next way of abstracting logic in Vue 2.0 was renderless components. In Vue, component can contain a slot. Basically a piece where you can put anything from the parent component. A small window, a slot actually. And there is an idea of scoped slots. Imagine the child component that can expose its own scope back to parent and slot content will have an access to this. Imagine I have a component with a slot and component performs all the logic regarding searching, let’s say searching which has an end point with past parameters. Our child component, like searching and then it exposes this part of its scope back to parent. These are search results. Enjoy. Sounds good. Sounds definitely better than mixins. We can test parameters. The logic is explicit here, we are returning something. Issues? There are a few.

Natalia: First of all, you’ve created your component instance. This is not the cheapest operation in the world. Second part, it’s runtime. The component only works in runtime and this means that exposed property from this component will be only able in the slot you exposed it as a scope of slots, so your search results are only available in the small part of your template. If you want to play with the discrete part of the component, you don’t have access there. It’s runtime. There was no to action this logic if you needed a reactive state somewhere else. Of course it can create helper like a pure function and return results but, what if I need to operate for the reactive properties? That’s how Composition API was created. With the Composition API you can have standalone reactive state. Reactive state is not just part of the component anymore. You can make any object or primitive, reactive. And you can expose it back to parent, it’s very explicit.

Natalia: Every property you want to return to parent is exposed. It’s explicit, you can click on this, you can see where it is, what it is, and so on. And the best part, if you include the part of Composition API to old good component that has data methods, computer properties, whatever, it just works. It just works perfectly, you just add a few reactive properties and methods to your component and you can use them with old options API as well.

Drew: This sounds like it’s really going to help developers clean up their code bases when it comes to very complex components or even mildly complex combination of components. And you mentioned the testability of mixins and things, does the Composition API allow for better testability?

Natalia: Yes, definitely because Composition API, if we exclude lifecycle hooks from this, because you also can run another lifecycle hook in the composeable. It’s actually pure function. You have S-parameters, you’re doing something and outside of lifecycle hooks there are still side-effects. And testing pure functions, as you know, is probably the easiest thing. It’s just a black box, you have S-parameters, you have something to return.

Drew: That sounds a very comprehensive solution to a problem that I’m sure a lot of people building more complex apps with Vue will appreciate. And it certainly sounds like a really great way to eliminate the sort of bugs that I know can creep in with mixins, where it’s very easy to introduce bugs, like you mentioned, with the scope being merged and all those sorts of things.

Drew: I always think a massive consideration when choosing to build on top of a framework is its API stability over time. Maybe stability isn’t the right word, but I think many of us have been stung by building on top of a framework then undergoes a big reworking and leaves us with apps that either require a massive investment to migrate or they just end up being bound to an old version of a framework which then is no longer supported. It’s a horrible situation to be in. How much sleep am I going to lose moving a big project from Vue 2 to Vue 3?

Natalia: First of all, API surface is 90% the same that it was. We didn’t have that many deprecated things or deprecated filters which are replaceable with deprecated event hubs. If you want to use an EventEmitter you would need to replace a view based one with some external library as well. These are big changes, but speaking about migration… Let me make it clear, I’m really torn right now, because on the one hand I’m Vue JS Core Team member. On the other hand, I’m a Staff Engineer in the big project that uses Vue. If you are about to start migration right now, I would not recommend doing so. First of all, the ecosystem is not released, I mean if we speak about core libraries like Pure Router, PUX, Vue CLI, these are in the good shape but they are still release candidates, not releases. And if we speak about other ecosystems like not core libraries maybe, UI component libraries, maybe some form validation libraries, they are not ready, mostly, for Vue 3. And if you have a big project, you have so many dependencies you need to care. So this wold be a complicated thing.

Natalia: What are options? You have a big project, you want to use all this Composition API goodness. How to achieve this? First of all we plan to release an LTS build of Vue 2.0, Vue 2.7. That will include lots of deprecation warnings, so you will be able to see what is going to be deprecated, how to refactor it not to break it with Vue 3. So you will be still technically using Vue 2 but you will be preparing Vue 3 anyway because you have all the warnings.

Natalia: Second, we’ll use a migration tool that will be able to just run it and it will work as a codemod, replacing things that relate to Vue 2 with Vue 3 alternatives. Of course, no codemods are perfect. We aim to, first of all, make replacements whenever possible but also show warnings whenever deprecation is not easily handled. Codemod will be able to recognize a thing and throw a warning but not replace it by itself. This is like a big plan and by the moment Vue 2.7 is released and I think right now their estimation time arrival is December if I remember correctly, I would need to check the road map, but I think it’s December.

Natalia: The ecosystem will be also more or less ready. If you have a large project with Vue 2.0, just wait a bit more until Core is stabilized because even if you produce a perfect library it still needs some time to stabilize because people start using this, people start reporting bugs. If you’re about to use it for pet project and report bugs, please, you are very welcome to do so. And after this there will be a good smooth way of migrating to Vue 3.

Drew: So the migration tool that you mentioned sounds quite interesting. Is that basically a static analysis tool that looks through your code and…

Natalia: Yes, yes, yes, it’s a code or a tool. Right now it’s available in a very limited way. It’s available as a plug in of Vue CLI. If you have Vue CLI based project you can run Vue upgrade and see how the tool works. It’s not in the shape we want it to be so far. Unfortunately, I don’t work on a project built on Vue CLI. I would need to wait and check what is going on but, for example GitHub, we’ve already taken a few steps even without migration tool to prepare, because we know what is deprecated. It’s actually stated on the Vue 3 documentation.

Natalia: There is migration guide. You can see all the breaking changes and things that have deprecated and you can already work on part of them even on Vue 2.0 code base. For example, in Vue 2.6 we changed the syntax for slots. Syntax for scope slots was deprecated but not denied, it still exists. It gives a warning but you can run it. And of course, with a codebase that was seven years old, nobody cares about replacing all the deprecated syntax if it just works. There are no warning in production. Slots work. In development like, “Oh, I see some warning in the console. Maybe 20 of them, fine. It’s yellow not red. I don’t care”.

Natalia: You know it happens to everyone. We created a huge epic to work on this. Find all the current sets of old syntax. We make an effort to replace our EventEmitters, again, seven years old project, don’t judge us. We have EventEmitters. GitLab was working on EventHubs. We replaced Vue based fun with external libraries. I would recommend doing the same. Go through migration guide checking what can be replaced already and what changes you can already make to prepare and start working on this.

Drew: With the current state of the migration tool be a good way of just testing the waters with your codebase. Just running it and having a look to see what it flags up already, to see if it looks okay or if there are some big things or is it still to immature for that? Is it better to wait till December when it might actually be able to fix things.

Natalia: If I had a big project, I wouldn’t recommend doing so. If you have small bad project or maybe some personal project but it’s not that large I would recommend running it and checking issues like whatever you have because for two mid-sized projects I’ve been running it. I think one or two issues. I can’t say it’s immature. It’s already in a good shape. But for big projects again, it’s legacy, it’s some exotic stuff. Don’t do this in production, people.

Natalia: Also if you would like to play with the scaffolding of your project, right now Vue CLI supports two modes. You can create Vue 2 project, you can create Vue 3 project. And definitely give it a try at least. This is a good way for us as well because as you play, you discover bugs, you report bugs, we try to fix them and so on.

Drew: In the docs and on the development roadmap I see mention of a migration build. Is that something different to what we’ve talked about or is that what we’re talking about?

Natalia: No, no, it’s the same. It’s the same one and it should be ready but for now, if you plan migration, the main path is just read docs and follow whatever is said there because we definitely make an effort whenever we don’t have migration tool, documentation team went ahead and created a detailed guide of what is the change, why it has been made and what is actually a replacement here.

Drew: Yes, in the docs is quite a comprehensive migration guide as part of the Vue 3 docs and it mentions an awful lot of changes that need migrating. I guess some of those won’t impact every project. A lot of them were essentially edge cases for a lot of people. Is that fair?

Natalia: Yes, a good chunk of them for example, filters, definitely are some edge case because even at GitLab with, for the third time, seven years old codebase and a big one. We had one or two occurrences of filters and they were not used anymore. It was a good thing that we searched for them and removed them completely because like, “Oh, unused code” and again, who cares it just exists.

Natalia: I would say that totally breaking changes are the model changes. Take a look at this because every single project I know contains at least one Vue model, for sure. This should be checked and maybe attributes changes as well because currently we are including class and style, tubulars and ethers. And if you ever worked with Vue, previously it was not included. Right now, the way you pass class and style to a child components is slightly different and they’re definitely worth an attention.

Drew: That’s good to know. The 3.0 releases that come released with Vue, I mean you mentioned the ecosystem and everything around it, Vuex and all these other parts of the ecosystem that need to get forward to that level. Is that why, currently, the website, the big “Getting Started” button still all goes to Vue 2? It kind of feels like Vue 3 has been released but not with full confidence. But is it because of that ecosystem issue that it’s like that still?

Natalia: No, I think you just found a bug, let me just quickly check. No, get started is pointing to Vue 3, it’s fine. I mean if you go to vuejs.org it points to version two. This is intentional because we planned to replace it with sub-domain like Vue 2, which is work in progress, but so far we decide to leave vuejs.org where it is and create Vue 3 and that’s why there is a banner on vuejs.org. If you go to any doc-

Drew: There’s a very tiny banner at the top, yeah.

Natalia: Yes, like small.

Drew: Yeah.

Natalia: We should make it bigger, I guess. Bigger and with a better color contrast. My accessibility feelings stays like, “Oh, there is nothing of contrast there”.

Drew: That’s good news. If somebody is starting, maybe not a big project, but if somebody is starting a personal project or wanting to learn Vue, certainly, Vue 3 is the place to start?

Natalia: I would say so. The learning curve is not that different by the way. Because it was an intention of the documentation team to have the old syntax options, I shouldn’t say old, it’s actually the current syntax. The familiar syntax as a default one. Because if you go through Vue 3 documentation you will see with the Composition API only in advanced topics and the learning path you have with Vue 3 is kind of similar to what you had in Vue 2. There is no big deal to start with a newer version if you just learning Vue and try to experiment with it and I believe it would be a better investment if we speak about career. Start learning the newer version because it will be overtaking all the projects. Eventually, maybe half of a year, a year, even for big sized projects there will be migration.

Drew: I seem to have in my personal career, a real talent of coming to platforms just as they’re in the process of a big migration. I mean even as far back as, do you remember, Macromedia Director, going back that far and Shockwave, Flash and all that kind of stuff. I came to that as they were transitioning to dot syntax and I had to learn both. And here I am, I find myself in the last month, working on a project in Vue for the first time, which is a Vue 2 project and learning as I go and looking forward to all the things that are coming in Vue 3. It’s certainly an interesting time to be learning something as it migrates but it sounds like it’s not too difficult with Vue and once the ecosystem has caught up with the Core then we should be in a good place.

Natalia: Oh, Drew, I just want to make a point about whatever you said about big project immigration. You can imagine me like, 2018 and I’m joining GitLab. I wasn’t Core Team members, I’m just a contributor at this moment.

Natalia: Immediately the same time Evan is like, “Oh,we are going to make Vue 3”. Everyone like, “Yeah, cool”. Spring of 2019 you are the Core Teeam. I mean the whole GitLab is like, “Oh, this is cute. We all having migration and you know who is kind of responsible for this?” And you can only imagine how it happens when you write documentation for Vue 3, everybody will be reading and your own company is like, “Oh, I want to learn something about Vue 3, I can’t understand your docs.” So you’re like, “Oh, damn this is so painful” because you’re a developer there and tech writer, kind of here.

Natalia: You’re in the middle of this but, I have to say it’s really beneficial for framework as well because any big product created with a framework is a great, absolutely great battlefield to find bugs and bring them back to the library, to the ecosystem. I can say that tests, and GitLab is open sourced, Vue Test Utils, which is a testing tool for Vue. A team was using our testing code based around tests, which makes a lot of sense, right. Because you can find some edge cases and so on. But still, when I think about migrating GitLab to Vue 3, I feel like a personal responsibility for this. I’m not only in the middle of migration, I’m personally responsible for every single bug we will find.

Drew: Looking back at the previous generation of JavaScript frameworks, I think one of the most successful of those was jQuery, back in the day, and I think it gained traction because it had an extremely well designed API. Just this concept of taking a CSS selector and using it to query the DOM in your JavaScript was something that jQuery popularized. And I think that really resonated with hardworking developers who didn’t need to learn a new way to work with JavaScript. I see Vue almost being I that same sort of camp. I mentioned I was previously working with React and moved to Vue in the last few weeks, and I found that almost everything to be more intuitive in the most genuine sense, as in I can look at something unfamiliar and pretty much understand what it’s doing. And if I need to do something I’ve not done before I can sort of guess at how it would be implemented and usually I’m right or close to it.

Drew: Is the API of Vue something that the Core Team think about very closely or has it just turned out well almost as a happy accident because of the personalities involved?

Natalia: I think, at the times of Vue 2 we had a concept. It’s changed slightly but we had a concept that was called Documentation Driven Design. And it’s a really great concept because if something is really hard to explain, really hard to get and really hard to write down, maybe the API is wrong there. Maybe something is not developed as it should be because non-intuitive solutions, something that is like very cryptic, and you need to put a lot of work to explain, usually is not right. The API was shaped the way that is the easiest to explain and that’s why it’s intuitive. If it’s easy to explain, people probably will get it on themselves. That’s why the older directives like v-if and v-for look very familiar for any JavaScript developer. You don’t need to explain what v-if is doing because it’s clear, right.

Drew: It really is.

Natalia: It’s kind of insulting and same with v-else. V-if, v-else-if, v-else and that’s it. And we intuitively built v-for with syntax that looks like for loop in JavaScript and same for the biggest part of the API. I think the main intention since Vue 1.x and I think Evan also stated this in his docs was to create something that you have pleasure to work with as a tool. It’s all about developer experience as well and I think this is what attracted me in Vue back in time as well. I started with Vue when it was already in beta for version 2. I didn’t work that much with Vue .1. I think were not that many people familiar with Vue from the first version but I was like, “It’s so nice to use”. I’m just building the same stuff and it’s just been a pleasure. I don’t need to think about the tool, I’m thinking about what I’m going to build. And tool is not preventing me from doing this.

Natalia: And again, I need to state this next one will be totally personal opinion, not as a Vue Core Team member. I’ve been working with Angular from version two to version six on a commercial project and it’s a great framework. There are many different terms, it has lots of abstractions, the dependency injection is amazing, TypeScript support is absolutely incredible but I constantly had the feel I am building a wall with huge heavy bricks. And I need to just make an effort to move every single brick. I mean, the wall is amazing. Bricks are still heavy and it’s just hard being a developer. And after this, working with Vue is like, “Oh, it’s just like a walk in the park”.

Drew: There can be a danger with software that when it’s so well designed, it makes everything feel really easy, that it sort of gets branded as a toy, as not being as powerful as the things that are really complex. Do you think that’s a risk with Vue, do you think it might be regarded as less serious as some of the other reactive frameworks simply because it’s better designed?

Natalia: Oh, it was. It was for this reason and for a few more reasons as well. And honestly, for a good amount of time, I think I had this question, every single conference I’d been speaking at, “Would you recommend Vue for big sized project, for enterprise project, for like serious project.” And every single time I was like, “Yes, you can use it for small project, it’s easy to scaffold something, you can use it for the big size project and honestly if we speak about enterprise size project, framework is the least of the issues you need to solve.

Natalia: You can take any framework on the market, be it old one, be it Amber, be it whatever else, be it Angular One and create a good and stable architecture. You can take any of the newest framework, like latest release Vue 3, Svelte, latest React and build absolutely, incredibly awful stuff. It depends on how build it and how your team is working on this, whatever you have there, how you planned all the architectural decisions because I think, none of the framework, maybe Angular a bit, is dictating an architecture. Angular kind of does this thing rest of them are like, “You’re free. Build it.” And yes, also I think the issue with Vue, not an issue, but issue in minds of people and especially in minds of company management was it’s not backed by a big company.

Natalia: You have an Angular and there is Google standing behind Angular. There is React and there is Facebook supporting React. There is Vue and who is the small Chinese guy, again this is like a stigma, there is a framework of one guy, what if Evan You is hit by a bus? There was an article, “What if Evan You is hit by a bus”, I swear on dev.to. I’m like, “What are they so scared” and big companies are probably like, “What if they drop support, what if they decide, maybe even he decides, if we speak about Evan, what if he decides he does not want to work on this.” And as we can see over years it’s good and stable and it’s developing and it’s not an issue and honestly, I think when framework is completely open sourced and built with a team of people that are not engaged, that are not subjective, that are not under one big company it’s actually better for the framework.

Natalia: Last year we introduced the RFC process. It’s actually just a request for comments. We have an idea, we drop it, people come there and people argue there and if we create an RFC for anything, this means that it’s not decided, it’s not set in stone. We just have an idea and we want to hear what community thinks. I believe it’s great because Vue is shaped by developers community. This is not just loud words. No, this is not a production slogan, by the community for the community, I remember we used this but it’s true. It’s actually shaped by community. It’s not shaped for the needs of a certain company. Even for big companies, even for companies that are sponsoring Vue. They’re not shaping the framework and I believe this is great.

Drew: It’s quite telling when you mentioned the list of active Core Team members is 20ish people and they’re all listed on the site and next to everyone it says what thy work on in the project and also where they work professionally. And just looking down the list of where people work professionally, I mean you’re at GitLab and there are other people who are just independent consultants and it’s not like 18 of the 20 people work at Big Corp. Everybody is just contributing from all over the place which, as you say, is a real point of strength.

Natalia: Yeah.

Drew: That there is no one big body controlling it that could, for their own business purposes, just say, “We’re changing direction, we’re not going to do this anymore” and pull away all that support and leave the project in a mess. It is just lots of individuals contributing and doing their best to make something good, which I think is a really strong foundation for something as important as a framework that people are building on top of.

Drew: You know I’ve spent the first half of this year learning React and then changing jobs and now learning Vue. Personally it feels to me like a breath of fresh air. And I really want to commend the work that you and your colleagues are doing on that. For those who are wanting to find out more about Vue, the 3.0 release or just generally about Vue, you can go to vuejs.org currently the version three specific version as we mentioned is linked to the little banner at the top. Maybe by the time you’re listening to this, the site will have changed and will just be Vue, but that’s also where you find the docs and in the docs is that really good migration guide that we mentioned. I’ve been learning all about Vue 3.0, what have you been learning about lately, Natalia?

Natalia: I’ve been learning about Apollo Client version three. It’s funny, because if you look at versions and I’ve been watching both of them, they are going completely the same way. Apollo Client was 2.6 and Vue was 2.6. And Apollo promised a release for a year and they were delaying and delaying it. It was for a long time in beta then release candidate. Same was for Vue, we announced a release and then we were delaying it again and again and moved to beta a bit late and then moved to release candidate. And they released not the same time but not with a big time difference. Apollo I think was released in Summer, beginning of Summer.

Natalia: And we use Apollo as well. I use it professionally and now I kind of try to build something with Vue 3 and Apollo 3, which is not an easy task because Apollo did a good number of changes. Again, we’re adjusting them at work but, for example, removing local resolvers, is like, “What do I do now? What do I do with my local queries?” If you’re curious about Apollo Client version three definitely give it a try. It’s interesting to see how it’s evolving.

Drew: I’m definitely going to give that a try. I’ve used Apollo on a couple of projects and it’s really great to see that pushing ahead as well. If you as a listener would like to hear more from Natalia, you can follow her on Twitter where she is N_Tepluhina and you can find collections of her articles and videos of her public speaking events, much of which is about Vue on her website, nataliatepluhina.com

Drew: Thanks for joining us today, Natalia. Do you have any parting words for us?

Natalia: Not really, but thank you for having me, it was a lot of fun to speak there.

Articles on Smashing Magazine — For Web Designers And Developers

anthony-campolo-200x200-1
04 Nov

Smashing Podcast Episode 25 With Anthony Campolo: What Is RedwoodJS?

by TBSCategories: News

We’re talking about RedwoodJS. What exactly does it mean to be a full-stack Jamstack framework? I spoke to community champion Anthony Campolo to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: He’s a Lambda School student, studying full stack web development, as well as being a contributor to RedwoodJS. Something of a community champion, he’s recently written a 12 part article series called A First Look at RedwoodJS that helps to explain the origins and motivations of Redwood, along with many of the different concepts that the framework introduces. So, we know he’s an expert at RedwoodJS, but did you know he’s never seen a dog? My smashing friends, please welcome Anthony Campolo.

Drew: Hi, Anthony. How are you?

Anthony Campolo: Hello. I am smashing, thank you so much for having me.

Drew: I wanted to talk to you today, and it’s probably obvious from the introduction, about RedwoodJS. For those who haven’t heard of RedwoodJS before, at a high level, what is it?

Anthony: I think there’s a couple ways that you can describe it depending on where people are coming from, but the canonical definition is it’s a full stack serverless framework for the Jamstack. So, it combines full stack web development with serverless AWS Lambda type stuff and the Jamstack, which is a big thing these days.

Drew: So, it’s a full stack framework that tries to put together a lot of the ideas around a Jamstack development ecosystem? Is that right?

Anthony: Yeah, it’s pushing the boundaries of what a Jamstack application can be, so by calling it full stack, Jamstack, it’s about how do we go beyond just the front end to having the same sort of deployment paradigm of just get pushed, getting your whole code deployed. How do we get that but also with our back end, and have it all connected?

Drew: Now, before we delve too deeply into it, I think it’s quite interesting to hear that it’s from quite a seasoned team, isn’t it? The people behind Redwood, they’re not spring chickens. Not to say they’re old, but they’ve been around the block, haven’t they, in terms of web development?

Anthony: They’re seasoned. Yes, I’ve actually put a decent amount of time into writing about the history of the framework and the ideas that have led to it, and Tom Preston-Werner is the creator, and so he’s also known as the creator of Jekyll, which is a really influential static site generator. He also did TOML, the configuration file language. And he was the CEO of GitHub originally. So, his work with Jekyll and GitHub pages and that sort of thing I think has really led to what we now think of as the Jamstack. A lot of people would say, “Oh, the Jamstack’s new. They’ve been doing this forever.” That’s how we’ve been talking about how it’s an extension of these older ideas, the static site generations, but with GraphQL and serverless and these ideas of how to use glue code and APIs to make your app work.

Drew: So, this is definitely from people who are very embedded in that community? I mean, the CEO of GitHub, you really don’t get more embedded in the sort of open source community than that. So, Redwood is a full stack framework and I guess that means you’ve got Redwood code running in the front end and in the back end. Is that right?

Anthony: Yeah, this is the first thing I like to explain to people when I’m showing them a Redwood project, is that it’s a monorepo. So, you have your front end and your backend in the same repo, and then each of those live in their own folders. You have a web folder, which is your front end, and it’s fairly similar to what you’d get from a Create React app. Then, you have API folder, which is your back end, and this is where all of your functions get essentially shoved into one big GraphQL handler that gets deployed to AWS Lambda through Netlify.

Drew: Okay, so starting at the front, as you mention, it’s based around React. Is that React plus a bunch of Redwood code, or is it just plain React? What’s the balance there?

Anthony: It’s a lot of things. It’s definitely just React in the sense of you’re not bringing in a lot of state management libraries, you’re not even bringing in a router actually. They have their own router that they wrote, and they use a lot of GraphQL stuff. So, when people talk about React and GraphQL and friends, that’s a bit of what’s going on here, is that it gives you a lot of default integrations to get React talking to your GraphQL. Because we have a lot of conventions now over how to use React, but the data fetching is still a huge hassle.

Drew: So, it’s React configured with a bunch of other tools that work nicely with React to give you a functioning ecosystem for doing this particular style of task. Is that a fair description?

Anthony: Yeah, no, yeah, that’s a great way to put it. The way Tom has put it is that there’s all these best of breed solutions that exist, and really sophisticated tools and technology we can use, but it’s really hard to actually leverage them because you have such a huge startup cost, and having to learn them, having to figure out how to integrate them. So, they put the tagline as, “We do your webpack config for you.”

Drew: I think it’s a common pain point that you hear from lots of people when they’re trying to get started in the modern development framework with client side JavaScript apps and configuring web pack, configuring all the different things, the build processes, the build steps. It can be quite a minefield, can’t it, to get everything hooked together and working? And it’s a long way before you get to “Hello, World!”. So, Redwood is giving us all that preconfigured?

Anthony: Yeah, it’s very much a convention over configuration type idea, because you have… Tom was, like he built GitHub with Ruby on Rails and Rob, one of the other core contributors, he’s been a Rails developer forever. They have a lot of ideas that philosophically they align with in terms of Rails, but they want to take those convention over configuration ideas, the full stack framework ideas, and implement that with all the modern technology we have now.

Drew: So, you mentioned that Redwood gives you a router or a router, as we say over on this side of the pond, does it come with things like default components and any of that sort of stuff in React, or are you just then to implement all that yourself?

Anthony: Yeah, the router is, it’s very sophisticated. It does most of the stuff that you would get just from React router, it has just kind of different ideas in terms of how these should be implemented, because Next they also have their own router, and it’s still not really entirely figured out how we want to get our single page app routing to work. Because of Suspense, you have a lot of these kind of questions over where is the async stuff going to come in? We have with Redwood, this idea of a cell, and this is what really does your data fetching for you.

Drew: So, maybe we could go into that a little bit? What is a cell in terms of Redwood?

Anthony: Yeah, so a cell is a default way to write a GraphQL query and then have your page basically tell whether you’re getting the data back, whether you’re getting an error back, whether you’re in a loading state, or whether… There’s one more state, I forget. But yeah, so it gives you the different states that basically you can be in based on whether you are getting your data or not. It’s setup with Apollo under the covers. So, if you’re using Redwood, you’re using Apollo as your GraphQL client, but you don’t ever have to think about it. You never have to write any Apollo or even think about it, it’s all baked in. It lets you just write GraphQL queries, which was really the dream of why people wanted GraphQL, is that it was this really simple query language that front end devs could use. But then, you had to figure out how to set up a GraphQL server, you had to figure out all this other stuff, and how do you get that all wired up. So, it does all of the GraphQL integration for you so you can just write GraphQL, you don’t have to think about how do I even implement GraphQL.

Drew: So, I guess one of the classic jobs of a framework is to take all the boiler plate code that you could write yourself and implement it for you, and tidy the way behind the scenes so you never have to look at that boiler plate ever again, and you can just write the code that’s unique to your circumstance. I guess that’s what’s going on with a cell is it? There’s nothing revolutionary here, it’s something that you could set up a React component to have all this different states and you could hook in Apollo and you could do all this yourself, but that’s actually quite a lot of work and it’s a common pattern. So, Redwood has tidied up into a nice, reusable pattern that you can just start using without having to think about it. Is that a good description?

Anthony: Yeah, they came up with the name but they definitely acknowledge that this was a practice they saw frequently and that they saw a lot of people just coding it themselves, and they decided that they wanted a declarative way to do your data fetching. So, that’s why you have this setup, because it lets you just have your different states and you don’t have to do if/then logic to figure out, need to do this if this happens. So, it’s about just having a single way to declare all the different states your data could be in as you’re loading it.

Drew: It’s one of the characteristics of React, isn’t it, that React doesn’t try and give you an architecture for your project, it lets you decide how you’re going to structure things. That, of course, has pros and cons. But, it seems like Redwood is imposing some of that structure for you so that you don’t have to think about it and so that it can put the plumbing in for you and sort of pick up where React left off in terms of giving you that sort of structure.

Anthony: Yeah, and I think it’s really interesting that we’ve seen multiple different attempts at this solution to this problem, because I mean you’ve had people who’ve been saying it forever, “Why isn’t there a Rails for JavaScript or a Rails for React?” There’s a great Full Stack Radio interview between Michael Chan and Adam Wathan called React is Not a Rails competitor. This is one of the different frameworks.

Anthony: The other ones are BlitzJS which has gotten a decent amount of buzz, and then Bison is kind of a new up and coming one. They all have a similar stack, but they use different pieces. You’ll have React query instead of Apollo, or you’ll have Chakra instead of Tailwind. The people who are putting together all these pieces into their stacks, all these stacks are kind of, they’re battling it out, it’s all very friendly competition. Actually, that’s one thing that I really appreciate, is that we actually all collaborate between the frameworks as well. There’s no animosity there.

Drew: So, we’ve mentioned Apollo and GraphQL, Redwood uses GraphQL quite heavily as one of the core pieces, isn’t it, of the framework? We can probably dedicate an entire podcast episode to just GraphQL, but for those who aren’t familiar, what piece is GraphQL doing here, what problem is it solving in this context?

Anthony: Yeah, this is a great question. When I am telling people what they should know to have a good start with Redwood, I’d say that you should have used Create React app, just if you’ve made a Create React app, and you’ve deployed it to Netlify or Vercel, that’ll get you a good start. Then, know at least a little bit of GraphQL because it is very central. So, the GraphQL is how your front end will talk to your back end. They say it’s a query language for APIs, the idea being that it’s meant to be an alternative to RESTful API methods, and that instead of doing that RESTful thing, you are sending queries which specify exactly the hierarchical data structure you want to receive back from the database. So, it requires a little more startup time to get your GraphQL server to talk to the two pieces. Then, once you have it there, the front end developers have the ability to get data in much more flexible way. You don’t need all these different API endpoints that your back end guys need to keep making.

Drew: So, if there are changes in requirements in the front end, presumably you can then just tweak your GraphQL query and you don’t need the help of somebody who works on the back end to make that change for you?

Anthony: I mean, the real dream is you can throw on a mobile client to it, that it would be that flexible ultimately that it becomes, you can have multiple clients all talking to your one API. Your GraphQL API becomes your source of truth, that’s where all your logic is centralized. Then, you can build all these different view layers on top.

Drew: So, we’ve got GraphQL there giving us the ability to query some sort of back end. In Redwood, what is the back end?

Anthony: Yeah. There’s a couple different ways to create your back end. There’s the way you’ll get out of the box with the tutorial, which is you use Postgres database deployed on Heroku, super easy, super simple. Then, your Redwood app talks to it with Prisma. I don’t know if you’re familiar at all with Prisma, but it’s like an O/RM. They specifically say it’s not an O/RM, it’s a query builder, which is a little more lower level. But, for the sake of just explaining it to people, Prisma is the thing that lets you talk to your database. It does your migrations and sets up your tables. It does all the SQL stuff so you don’t have to write SQL. To me, that sounds like an O/RM. You don’t necessarily need to use Prisma though to use Redwood.

Anthony: I actually built a just proof of concept app where we used FaunaDB instead. FaunaDB, they have their own GraphQL API, so you can just send GraphQL API straight to Fauna, and then do your database mutations that way. You lose a lot of the functionality of Prisma’s CLI, but Prisma really it’s a convenience factor to work really easily with your relational database. But really, anything you could think of, you could figure out how to hook it up with Redwood is what I found out just because it’s built around GraphQL and the whole point is to be able to talk to all these different pieces.

Drew: So, Prisma is essentially a sort of abstraction layer between your code and whatever data store that you’re using presumably that Prisma supports, is that… or is it doing more intelligent things than that?

Anthony: Yeah, so you write a schema, so you create a schema.Prisma file, and it would have model post, and then it would have id and integer and auto increment, like title sting, body string, created at date, time. So, you’d create basically what you want to be in your database with the types, and then it does the database stuff for you so you don’t have to interact with the database.

Drew: So, you use Prisma to define I guess what sort of database or what sort of data store that you’re talking to. Then, in there you lay out your different mvc models to use that parlance. So then, when your application is talking to the data stores, it’s kind of using an instance of a Prisma client, is it? Is that what’s going on?

Anthony: Yes. Yeah, that’s exactly it. So, in your back end’s API folder, you have a lib folder with a db.js, and just by default that has your Prisma client set up. So, that’s all the stuff you get out of the box, and like you said, Prisma can work with different databases. It can switch between SQLite for development and then Postgres for production, that kind of thing. It’s mostly relational ones right now, but the roadmap has things like Mongo and Fauna on it.

Drew: So, that’s quite useful then if you can set up and use SQLite in your local development environment as you’re getting things up and running, and then go into production with something like MySQL.

Anthony: That’s exactly how the tutorial is set up, that’s the workflow it shows you.

Drew: It’s quite interesting, isn’t it, to see a very modern approach to a framework then falling back on some of these more traditional databases like MySQL. I’m very familiar with MySQL. I love it for its stability and I love the relational way of storing data. I think it works so well for so many things. Often you see the baby thrown out which was the bath water when it comes to the newer types of data store, so it’s quite interesting to see Redwood by default supporting these good, old relational databases.

Anthony: Yeah, no, that’s such a good point, because I say that for all the new stuff Redwood combines together, there’s some things that actually says the old, tried and true way is actually the best. So, they are really big on relational databases. That comes from Tom’s experience with using Rails and having a relational back end. Active Record was the O/RM layer that Prisma’s meant to approximate.

Drew: I guess, we’re talking about a serverless architecture here with Redwood, and we talked to Chris Coyier I think two or three episodes back, all about serverless using APIs and cloud function and things. So, taking a step back, if you were to think in terms of a server based framework, like we mentioned Ruby on Rails or something like Laravel in the PHP world. Even with a React front end, your API request would be running code that is Rails code or Laravel code plus then your user code and configuration. Is that the same with Redwood? Is there actual Redwood server code that runs, or is it just more tools and structure and glue that enables you to implement your own?

Anthony: Yeah, so in the back end, there’s a file specifically that is a way to take your SDL, so you have your schema definition language, and then you have what are called your services, which are like your methods for talking to your back end. Then, all of this gets stitched together into a GraphQL handler that is deployed to a single Lambda function. So, it’s optimized for Lambda specifically. We actually just recently had someone do it with the serverless framework, and we’ve got some people working on Azure and Google Cloud something. It’s not Google Cloud function, it’s the one built on top of that. But yeah, so it’s right now basically optimized for deploying your back end as a GraphQL function in an AWS Lambda. This is the stuff that’s all magic happening in the code I don’t understand, but that’s the high level explanation.

Drew: So, there are deployment tools are there, that take all the code that you’ve written, squash it all together into some sort of magic ball of code that can be executed in the cloud and puts it up onto AWS or do you still have to manage that process yourself?

Anthony: Yeah, so it’s all done through Netlify if you follow along with the tutorial. You don’t really have to mess with any sort of serverless functions yourself. The stuff that wires your back end together to shove it into the AWS Lambda, that’s all handled, you don’t have to touch any of that code. That’s all generated out of the box as your conventions over your configurations so you don’t really have to think too much about how to make it serverless. It’s serverless by default. It’s really a hard thing to wrap your head around. It took a while for me to wrap my head around it.

Drew: Yeah, because it’s an important point isn’t because there are actually now a few different areas we’re keeping track of here. We’ve got I think three different areas. We’ve got our front end React app, that’s running in the browser, and then we’ve got an API that is GraphQL based, running as a cloud function, and that’s responding to our queries, but that’s then interacting with a data store which uses Prisma. And that data store is what and where in this, because you can’t run a MySQL server on Netlify, can you?

Anthony: Yes, that’s where Heroku comes in. So, in the very last part of the tutorial, you deploy your front end to Netlify and then you deploy your back end to Heroku Postgres and you just grab your config variables from Heroku, plug it into Netlify. Getting your Netlify front end to talk to your Postgres back end is a really, really simple thing. They wanted to go with the thing that was going to be the easiest for anyone to get spun up, but still have good stable, battle tested tech. At the end, what you get out of the box just by following the instructions, is really incredible.

Drew: Jamstack enthusiasts will be familiar with services like FaunaDB that you mentioned that provides a data store as an API, AWS has DynamoDB, Google has got Cloud SQL, and so on. So, you mentioned that Redwood is looking at integrating, or I guess Prisma is the component here that’s looking at integrating with those sorts of services further down the line?

Anthony: Yeah, this is a good question. This is something I’m actually talking with Ryan Chenkie at Prisma about kind of helping out with, is what is the kind of database story for Redwood for things that don’t necessarily work with Prisma? Would it be better to figure out a way to get Redwood to work with it directly like I did with Fauna or would it make more sense to implement a driver for Prisma? So, there’s different ways to approach it. There’s obviously a million different databases now that everyone wants to use, so it’s how motivated are you to get your data store onto it. There’s a lot of community contributions going in there.

Drew: So, because Prisma understands your model and it knows how to query them, is it able to generate some kind of migrations or things like that to help you get that database set up?

Anthony: That’s exactly the thing that you lose out when you have to take Prisma out and get your data, is that you lose all the migration functions. It has a really advanced CLI that does a ton of stuff for you, so you can go through the whole Redwood tutorial and enter the Prisma commands and you don’t have to have any idea what it’s doing, it just works. It’s a really great tool for doing all that kind of database type stuff that you want to make sure you get right and you want to make sure it’s done correctly.

Drew: It seems like having a really good tooling around frameworks is quite a modern trend, isn’t it? To not just say, “Here’s all the things that this framework can do, but here’s perhaps some CLI tools that are going to do a whole bunch of it for you.” Does Redwood have tools for things like CLI generators and stuff to get you up and running quickly?

Anthony: This is probably the biggest key feature that you get from Redwood, is you get a whole set of very sophisticated generators. For anyone who’s ever seen the original Ruby on Rails demo, that DHH gave, he builds a blog in like 15 minutes and he does it all with Rails, and people are like, “Whoa, this is amazing.” That’s the effect Redwood is going with. They want you to be able to get everything spun up really quickly so you can generate pages, you can generate layouts, you can generate your cells, which I was talking about, and you can do a scaffold command that is going to create your entire CRUD interface. I have a whole section, part four of the blog series, just explains all the code that the scaffold gives you. It gives you so much code. There’s an off generator, there’s even a Tailwind generator that configures your tailwind for you.

Drew: That’s amazing. I remember seeing DHH’s demo of Rails. I mean, it was probably, what, 15 years ago now when he first did that scaffolding and showed you, and you get a fairly rudimentary but functional control panel essentially to enable you to create new items, edit them, delete them, et cetera. That can be invaluable in a project, especially working in a sort of dynamic environment where, okay maybe you’re going to implement better tools in the future for editing that content, but it means being able to spin something up quickly, you can get test data in, or you can even hand that over to a content team who could start working whilst you’re working on the front end, so that’s really useful.

Drew: If you wanted to just deploy that and have that in production, presumably you can just deploy it along with your front end code, but you’d need some way to secure that aspect, those roots in your application.

Anthony: Yeah, there’s a couple different options for authentication. You can use Netlify identity. That’s the default if you go into the tutorial, and then you can also use Auth0, and then one I’m not familiar with called Magic.Link, and there’ll probably be a couple of extra ones added in the future. But yeah, so there’s a couple built in solutions there already, and that’s the very last thing you do so that’s the very last part of my whole 12 part blog series is the Auth one. I don’t think I’d ever figured out Auth before I used Redwood. It’s hard and they’ve definitely done a good job with it.

Drew: Does that integrate at a route level, or a route level, sorry, how do you secure things?

Anthony: Yeah, so part of how they have their own router, they also have… You can do private routes, so they have a private route component. Then, your actual login form, that’s what you get from Netlify identity so you don’t have to actually create a form and do your state management with that, that is where a lot of problems come into play. Taking away the really key parts and then you can just implement role based access. We have role based access control add on that was been done over the last couple weeks be David T. So, there’s a lot of work happening to create other ways to do it, but what they got now is already… it works, it’ll get you functional.

Drew: People always say about security algorithm hashing cryptography, that you should never write your own because it’s never going to be as good as the things that are out there. Increasingly, I think that’s also true of authentication at a higher level; that authentication is such a complex area these days that people want to not just log into your site with unique credentials, but they might want to authenticate using Google, or they might want to authenticate using an Apple device, or they might want two factor authentication, or they might want to integrate it with a single sign on service that they’re using from an enterprise. All these things are such a headache if you try and implement it yourself and so much opportunity for getting something wrong and exposing security holes in your application, that using an authentication service seems almost like a no brainer at this point to me. So, just being able to drop something in with essentially a few lines of code and be up and running sounds like a really productive way to work and to keep things secure.

Drew: It sounds like the deploying both the front end and the server aspects, the serverless function things, is a naturally fit for deploying to Netlify. Are you tied into that with Redwood? I mean, we mentioned that Tom Preston-Werner is one of the main proponents of this framework, he’s also on the board at Netlify. Do you think there’s potential for too tight a coupling there if you were to choose Redwood as the basis for a project?

Anthony: Yeah, this is something that Tom’s definitely conscious of. He’s invested in a lot of companies that float around. He invested in Prisma and Fauna. He wants to just make the tools he wants to use. It’s not about we want to lock you into this thing so much as what Netlify has built he thinks is the best option, so that’s why they built around it. But, they don’t want it to be locked in to any one deploy target, and that’s why we have work being done on things like the serverless framework and some people have talked about Begin. We want to be pragmatic, we want it to work for whatever someone’s use case is. So, we get you 90% of the way and then you just have to wire up the last couple things to get it to work with whatever your servers of choice is.

Drew: I guess even Netlify is using AWS Lambda for the servers functions so it’s really the deploy part that’s taken care of by Redwood there, and actually you could deploy that to Lambda yourself. Posting your front end is just files, isn’t it, it’s CDN based the rest of it? So, there’s quite a lot of flexibility there without being too tied in.

Anthony: Yeah, there’s a actually a term that Tom talks about as the core philosophical idea behind Redwood, which is that we want to get to a universal deployment machine. That’s kind of t idea, is that you can just deploy things and you don’t have to think about it at all. He’s been talking about this idea for years and years and years, and this is what Jekyll was even about back in the day. When you hear that now, you’re like, “Oh, you mean like Netlify?” That’s basically what Netlify is to most people who are working on the front end. They don’t even think about deploying anymore, it’s not even a thought.

Drew: Here’s my application in a Git Repo, this directory is the front end, this directory is the back end, here’s my database, and that’s about as much configuration as perhaps you would need for then whatever service to take it and to build it and host it.

Anthony: Yes, and one thing I should also point out, we just very recently got Vercel Redwood default deploy set up, so when you’re deploying on a server side app you can say, “Oh, I have Gatsby app,” and it knows exactly how to build a Gatsby app versus a NextApp. We have that for Vercel now. So, there are really, really good non-Netlify options as well, if you’re more into that.

Drew: So, if I wanted to get started and build an app and take it into production this week, is Redwood ready for that? Is it mature?

Anthony: Yeah, we’ve got about a half dozen apps that are in production right now. The first one was called Predict COVID, which came out back in March, and it’s like a realtime data visualization application. Then, we’ve got repeater.dev is done by Rob, it’s like a cron job like thing for Jamstack. Then, there’s Tape.sh, Duoflag I think is another one. So, there’s at least a handful. If you go awesome Redwood repo, you can see a list of all of them. If you go to the community forums, you can find write ups of these as well, because people have put these into production and kind of said how it went. So far, they’ve all been successful and no one’s said, “I’m never using this again.”

Drew: But, it is very new. I guess there’s no escaping that, but in terms of maturity, Redwood’s pretty new, it’s getting a good following.

Anthony: Well, it’s funny, it is and it isn’t. It was announced in March. At that point, it had been worked on for about a year by Tom and Peter. So, they’d already put a ton of upfront work into this, so it wasn’t like I’m going to announce this project with a Read Me and then start building it. By the time they announced it, it wasn’t… It’s not a 1.0 now, but it’s pretty dang close in terms of what people would expect out of a 1.0. But, Tom is very against what we call type driven development so he always errs on the say it’s not ready. So, we say it’s not ready for production even though it’s in production.

Drew: I think one thing that people sometimes get burned on using frameworks is that they’ll build a project around the framework and then that framework will very quickly go to another major version that had backwards incompatibilities, and they’re then left with a big project to update everything onto the new version of the framework. Is that something that’s likely to happen with Redwood? I mean, none of us has got a crystal ball, but just with the technologies that are involved and the way it’s structured, do you think that’s a big danger or a little danger?

Anthony: Yeah, it’s a super valid concern and definitely something the team has thought about. The CLI has an upgrade command, so you can basically every time there’s a version bump, you just do a command and it bumps you up the version. I’ve been dealing with this a little bit just because of the series I wrote, I started it when it was on version 11 or 0.11, it’s like 0.17 or something now. So, I’ve been slowly iterating on it as it’s gone but nothing breaks. It’s all, you get slowly things, or like “Oh, this is kind of a nice little touch you’ve got here,” but it’s pretty much set in stone architecturally. Redwood as it’s structured, the front or the back end is not going to change at all. It was very well thought out in terms of what they want architecturally. That’s why they built it, so they could get something that’s structured like this thing.

Drew: I guess with modern web development, there is a certain point where you’re just never going to get away from being reliant on dependencies updating themselves and changing. I mean, even using React, React goes through as many different changes as anything else.

Anthony: That’s exactly why Tom inventing semantic versioning.

Drew: I guess from the other side of that coin, if Redwood did happen to go away, which is always something we consider when picking a framework, if development stopped somehow, I guess the impact on a particular app might not be too great because it is just so heavily built on existing other projects around. Is that-

Anthony: Well, some would say that a Redwood tree can survive a lot, it survives for a very long time. That may have been why it’s called that, is that you can just make a site and deploy it and it’s not going to break, it’s just going to work. So yeah, maintainability, sustainability, all that kind of stuff, that’s huge. Being built by people who tried to scale Rails apps, I imagine they’ve thought a lot about that. But in terms of the going away part, that’s always going to be a danger with any open source project, so I think what you have to look for is how enthusiastic is the community to continue it without the team if that ever happens. I don’t think you even need to worry about that because Tom’s a billionaire and he has a venture funding thing that is funding some of the development. It is an open source project that is well funded actually. It has four full time members, Tom, Rob, David, and Peter. You just go to the forums, you can see the activity that’s going on, so I wouldn’t worry about that too much-

Drew: Of course.

Anthony: Beyond normal open source worries that come along with that stuff.

Drew: What is the community like? You mentioned the community, are there lots of people using it and contributing to the code base or is it mainly the core team who are doing the development?

Anthony: Yeah, it’s very much structured to be a community thing. They want to get as much buy in from the community as possible, and this comes from the lineage like you said. There’s few people with more open source cred than Tom, so he’s done a really great job of bringing people into the fold. I think just my story in general is a big win for the community because I came in, I’m a boot camp student, I’m learning all this stuff as I go. I’m not pushing code to the repo, I’m making doc fixes and writing blog articles and stuff, but they still invited me to the core contributors meeting because they saw what I was doing and they thought it was adding value. Yeah, there’s really a lot of things about how they approach community building that I have a lot of respect for, and that is why I’ve been so invested in it and putting so much of myself into it.

Drew: Some frameworks have got this sort of natural bent for certain types of projects. For example. The Python framework, Django came out of online news publishing, and so it’s a really good fit if you want to rapidly publish content like you would in a news organization. Does Redwood lean in any particular direction when it comes to the type of projects? Is it suited for content publishing or building web applications or-

Anthony: It’s made to be fairly agnostic to that. It wants to be a tool that you use for a lot of stuff. First, before it was called Redwood, it was called Hammer, the idea being that you do a lot of stuff with a hammer. But, there definitely is a kind of sweet spot, which I think is the multi client type applications. So, if you know that you’re starting with a web front end but you’re pretty sure you’re going to end up with a mobile client as well, then it’s a really good fit for that because it starts you off in a way that you’re going to be able to extend into having multiple clients with GraphQL, which we kind of talked about a little bit. So, I’d say that’d probably be the first thing that I would say is its sweet spot. But, it’s meant to work for as many things as possible.

Drew: Does Redwood have a published roadmap of where it’s going? What can we expect to be coming in the near future?

Anthony: Glad you asked. We just put out a roadmap to 1.0 less than a month ago, it was probably like two or three weeks ago. It kind of itemizes things that we’re working on, things we think we’re kind of close on, things we think we still have a long ways to go on. That kind of helps the community see where can I help contribute. That’s one of the things we’re really great about is showing here are the things that still need to be worked on. They’re aiming for 1.0 by the end of the year. We’ll see where we get with that, but that’s the trajectory we’re currently on.

Drew: One of the beauties of a Jamstack and a serverless approach I always think is that it’s this idea of lots of pieces loosely joined that has served us so well in computer science up until this point. It should be really easy to scale up a Jamstack and serverless project because you can add multiple front ends or you could put more resources behind running your functions, and you can scale up a big engineering team by having people work on different small pieces. Is there a danger that adopting a framework around all of that, that you might be taking a distributed architecture and creating a tighter binding than you might otherwise have? Could Redwood become the monolith that acts as a bottleneck in your engineering efforts?

Anthony: Yeah, this is something I think about a lot because as I learned web development, I was taking… I’m in a boot camp that supposedly is full stack development, but you learn each piece in isolation. We’re essentially learning the PERN stack, but you learn React, and then we learned Express. We never talked about how it actually works together. So, I do think that there is definitely a danger of not being able to comprehend in your project because of how it’s all wired up. So, what I really liked about Redwood is that it just made sense. It was a mental model of how to think about my entire app and all the pieces and how they fit together in a way that really made sense to me. But, what I was surprised to find doing the Fauna project is that it’s much more modular than you would think based on… You talk about it, and like you said, it sounds like it’s a monolith thing, but you can rip pieces out and replace them with other pieces and they can still work. So, it’s made to be a fully integrated solution, but not a solution that is tightly coupled just because this is a good way to integrate all these technologies doesn’t mean you need to tightly couple them to integrate them well.

Drew: Yeah, that sounds a very promising way of structuring things, and it’s going to be really exciting to see what happens with Redwood as it gets to version 1.0. Is there anything else we should know about it that we haven’t talked about?

Anthony: No. I mean, I would say if you’re interested, just check out the tutorial on YouTube, the RedwoodJS tutorial. They have what they call tutorial driven development, which is kind of a play on Read Me driven development, which is another thing Tom coined, that you should start with a Read Me, and then create your code to make sense with what your Read Me was. This is the idea of you create a tutorial and then you write your framework to make the tutorial work. So, that’s why it’s a really easy way to get spun up with it because it was made to make sense of going through the process of learning it. They’ve really thought about how to actually get onboarded into a massive framework with all these different pieces and all this different new tech. They progressively reveal it to you as you go. The series that I wrote is very heavily influenced by it. I essentially built the same project, but I write my own stuff as I go, and reference the docs. So, if you’re interested in just learning Redwood, start with the actual tutorial and then check out my series.

Drew: So, I’ve been learning all about Redwood, what have you been learning about?

Anthony: Yeah, so I’ve been learning about CMSs, and I was actually really curious to get your thoughts on this because I imagine you’ve been around the block, you know a lot of CMSs. Obviously, you know you’ve got your WordPress’s, your Drupal, but what’s really interesting with something like Redwood is since you have this GraphQL stuff baked in, it has the CMS, it’s just such a natural fit. So, I’m trying to figure out, what are interesting headless CMSs to check out? Which ones have GraphQL integration? Which ones have different sweet spots? If I wanted to take a CMS to build an app with RedwoodJS, what would you recommend?

Drew: That is a good question, and I’m not sure I have an immediate answer. I have looked at lots of different CMSs, not particularly with a view to GraphQL. I’ve not worked with GraphQL myself yet, and so that was not-

Anthony: Oh man, you’ve got to join the club, dude.

Drew: Yeah, no, I’m definitely getting onboard. But yes, I have a requirement at work that may be coming up to know a bit more about GraphQL, so it’s certainly one of the things that I need to be learning.

Anthony: I actually learned GraphQL through Redwood. I didn’t really know GraphQL, and I’d say you should know a little bit before going into it, and I had a very, very tiny basic knowledge. You can actually learn what a schema definition language is, and that GraphQL kind of jargon. You’ll learn a lot and you’ll pick it up as you go with Redwood.

Drew: Yeah, I should definitely get onboard and maybe doing some Redwood is the way to do it. Perhaps I need to pick up a project and start going with Redwood and see where it takes me.

Anthony: Yeah, at the very least I would say just check it out, just because it’s interesting. I find it to be just a really fascinating thought experiment of how do we do modern web application development differently and more coherently.

Drew: If you, dear listener, would like to hear more from Anthony, you can find him on Twitter at ajcwebdev. His comprehensive series of articles about getting started with Redwood are on the Redwood community site, which we’ll link to from the show notes. Of course, you can find all about Redwood and get started at RedwoodJS.com. Thanks for joining us today, Anthony. Do you have any parting words?

Anthony: Just if you’re interested in any of this stuff, feel free to reach out. My DMs are always open. The community is very open in general. I’ll be happy to explain or walkthrough or get you set up with anything you need to know to get going.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
cassie-evans-200x200-1
21 Oct

Smashing Podcast Episode 24 With Cassie Evans: What Is SVG Animation?

by TBSCategories: News

Today we’re talking about SVG Animation. How can vector images, JavaScript and CSS all work together to provide engaging motion graphics? I spoke to SVG expert Cassie Evans to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: She is a front end developer and speaker with a background in graphic design and motion design. She got started with coding back in the days of MySpace and Neopets and is on a mission to make the web more whimsical again. She currently works at Clearleft in Brighton UK, and can usually be found tinkering with SVGs on CodePen. So we know she’s a skilled developer and SVG expert, but did you know she was National Junior Wing Walking Champion for three years in a row? My smashing friends, please welcome Cassie Evans. Hello Cassie. How are you?

Cassie Evans: I’m smashing, thank you.

Drew: I wanted to talk to you today about one of your passions, which is SVG, and in particular the animation side of things. I think most people listening to this podcast will have heard of Scalable Vector Graphics in some shape or form. I know I’ve used them heavily with things like logos and icons in recent years, but let’s not assume. So for anyone who isn’t really up to speed with SVG, what makes it different from other ways of adding graphics to a webpage?

Cassie: So, a lot of the clue’s in the name, of course. So, SVG stands for Scalable Vector Graphic. So, these are first the images that can be any size. You can make them really, really small or really, really big, and they’ll retain image quality and won’t get pixelated like JPEGs or PNGs.

Cassie: You can also make them really, really small, so small in file size. So, everyone’s kind of added a PNG to their site that’s a million megabytes and seen what that does to page load. So, you can add all sorts of cool illustrations and stuff to your site without impacting on performance too badly, and also you can animate them so that’s the most exciting bit. With JPEGs or PNGs, if you wanted to animate them or move bits of them around, you’d have to cut them out into little pieces or kind of layer them on top of each other, whereas with SVGs you’ve got actual elements in the SVG. It’s got a DOM structure just like HTML does.

Drew: So, I guess in a world of mobile devices with different screen sizes and different pixel densities and sort of constrained data connections, SVG really is a format that’s more suited to the modern web than the old graphic styles. Is that fair?

Cassie: Yes, definitely.

Drew: Most images are of course sort of binary based, but SVG is totally view sourcable, isn’t it?

Cassie: Yeah. So, that’s really exciting because you can actually right click and view source on an SVG and you can traverse around the DOM and kind of see what you’ve got and kind of get to learn it that way, which I find that really great. It feels a lot like the old web, like being able to go to a website and view source on it and see how it’s put together.

Drew: SVG kind of feels more sort of native and integrated into the web than things like maybe Canvas or even back in the day Flash, which of course flash was scalable vector graphics, wasn’t it? In its own way. And those technologies feel very much like a black box that’s encased on the page that you can’t sort of get in or out of. SVG is a lot more integrated isn’t it?

Cassie: Yeah. It’s funny that you’d say that because I always refer to Canvas as a black box when people are asking whether they should use Canvas or SVG for something. I think a lot of the time, obviously it depends on the use case, but one of the things with Canvas is if you don’t have JavaScript for some reason, if your code fails, you end up with a little black box with nothing in it. So you could create this crazy infographic, all sorts of things going on inside this Canvas element, and then you just lose it all. Whereas SVG, it’s a lot more aligned with progressive enhancement, so you can have an animated SVG, maybe that’s animating using JavaScript, but then without JavaScript you will still have the illustration. You’ll still have the SVG there.

Drew: And SVG isn’t new to the web, is it? It’s been around for quite a while.

Cassie: It has, yes. It’s been around for longer than I’ve been doing stuff on the web.

Drew: And it certainly seems to be coming into its own a lot more with things like animation, like you’ve been saying, but also as we were mentioning, the way that it scales just makes it perfectly suited when we’re designing sites that might be viewed on a retina display with double the pixel density, or need to be delivered over a mobile connection where you want things to be as performant as possible. So we know SVG has got a DOM, you mentioned that. Does that mean that the things in it can be manipulated with code?

Cassie: Yes, so that’s the most exciting thing. You can get at SVG elements and you can animate them and move them around just like you can with HTML DOM elements, and it also means from an accessibility perspective, SVG has a DOM so you can traverse that DOM if you’re using a screen reader or something, so you can make SVG graphics very accessible to screen readers.

Drew: Yes, so I was going to ask about the situation with accessibility because classically, graphical stuff on a page is one of the most difficult things to make accessible. So are there sort of attributes that you can add to hint? Can you use the ARIA stuff in SVG or how does that work?

Cassie: Yeah. You can use ARIA labelledby, but you also have title and description tags that you can put inside an SVG.

Drew: That’s incredible and in terms of sort of motion preferences, because that’s something that we’ve seen recently with a media query in CSS to see that the user prefers reduced motion and you can change your animations and things based on that, is that something you can do in SVG or does it have to be implemented a little bit more manually?

Cassie: Well with SVG people often talk about SVG animation like it’s its own separate kind of special thing and of course we used to have SMIL. We still do have SMIL technically. It was getting deprecated, but it’s actually not being deprecated anymore. It’s just not really as widely used and not worked on anymore, but we used to have SMIL and that was what most people refer to as SVG animation. Whereas now, SVG animation could mean any of those things. It could mean SMIL, it could mean CSS animation, or it could mean animating using JavaScript or a JavaScript animation library. So, there’s lots of different options but with CSS animation and JavaScript animation the option to use prefers reduced motion is there and should definitely be used.

Drew: So you mentioned CSS animation and of course there’s a certain amount that we can do, like with HTML elements and CSS animation, to create graphics and motion on a page. SVG just like blows that out of the water in terms of flexibility doesn’t it?

Cassie: Yeah, definitely. I think people make amazing things with just CSS, like Lynn Fisher makes really amazing things. There’s all sorts of people making crazy CSS only illustrations, but it takes a lot of time and the handover for that is pretty impossible. Like if you imagine a designer giving you an illustration and asking you to recreate that in a CSS, that would be a large ticket. So SVG kind of makes it a lot more feasible to have these interdisciplinary teams and pass things over from one person to another. So you can have an illustrator or a designer create an illustration in a vector graphics program like Illustrator, and then they can pass that SVG over to a developer who can animate it.

Drew: And I suppose that would fit quite well into people’s established workflows. We’re using things like Git, because SVG is text-based, isn’t it? So presumably, committing SVGs into Git you get all that ability to diff and merge and all those sort of powerful features that you get with other text-based stuff. Is that right?

Cassie: Yeah, exactly.

Drew: So it’s kind of like, well I say kind of like, it absolutely is graphics expressed as code.

Cassie: Yes.

Drew: Isn’t it? SVG?

Cassie: It is.

Drew: And it’s quite a lot like HTML in its syntax. It’s another XML based language, isn’t it?

Cassie: Yep.

Drew: So it has tags and attributes and nested children and all that sort of stuff that your average web developer is going to be used to.

Cassie: I think that that’s what I love the most about SVG is I’m really into creative coding and also teaching people, and I found that teaching people who are more of a creative leaning, they sometimes get a little thrown off when you immediately jump in with JavaScript or Python or something like that for creative coding, but without fail I’ve managed to get anyone that I taught on board with SVG because it’s got this really approachable entry points because it does look like HTML. So, you can give someone with an understanding of HTML and how to build websites SVG, and it looks the same, but it’s the graphics instead of documents and then you can animate that with CSS to start off with which is also a little bit more comfortable, and then you can kind of progress to animating it with JavaScript. So it’s a really good learning curve.

Drew: And of course it can be dynamic. It’s not just a case of creating motion. You can actually make the properties of it dynamic. So, one of the interesting things I’ve seen SVG used for, and it’s a grand term, but like data visualization, DataViz, and drawing graphs and charts and of course things like dashboards that we seem to have everywhere these days. SVG is sort of perfect for that isn’t it?

Cassie: Yes, definitely. SVG is great for DataViz. All the way from kind of small DataViz up to D3 which is very well known DataViz library that uses SVG under the hood. But you could also just, if you’ve got a little bit of data that you wanted to show on a web page, you could create a chart in a graphics editing program and then you could just use JavaScript to change those values and kind of change how your graph looks. So you don’t have to go all in with a massive database library. You can kind of just start off small.

Drew: Obviously sort of traditional graphs and charts and things are just sort of the tip of the iceberg when it comes to ways that SVG can help with data visualization. I saw you had an interesting project that you did at Clearleft with your solar panels on the roof. Can you tell us a little bit about that?

Cassie: That project was actually meant to be me learning D3 and then I got very distracted. We have some solar panels on the roof of our office, which I miss thoroughly actually it’s been so long, but yeah we’ve got some solar panels on the roof and I found out shortly after starting working at Clearleft that we had an API that was attached to the solar panels that you could hook into. So I was like…

Drew: Amazing.

Cassie: Right. I need this to be my side project, and I had a little look at what we got back from the API and amongst the data there was the amount of CO2 saved and they measured the amount of CO2 in trees.

Drew: Okay.

Cassie: So I was immediately like, wow, well we’re going to have to plot this somehow, but I want to measure it in trees because that’s such an interesting way of plotting this. So, all of my D3 aspirations went out of the window and I sat down in illustrator and recreated an illustration of our office building and created a jungle of trees and plants and stuff, and then I’m looking at how much CO2 we have saved and then kind of growing in these plants and vines and stuff. Yeah, it’s great. It’s really good to check back occasionally as well and just see how much the jungle’s grown.

Drew: It’s an amazingly creative way of visualizing that data, whereas if you were relying on traditional software for creating graphs and charts and things, there’s never going to be a function to create an office building with trees on top. That that just doesn’t exist, but then using JavaScript and using SVG to be able to generate those graphics and using the JavaScript to manipulate them to adjust the values that are being shown, you can come up with something completely new in a completely novel way of communicating an idea to the person using the site. So, we know we can hand codes the markup for SVGs, which me as a developer, I think that sounds great because I can go in and I can be very precise, but that is probably a technical skill that isn’t going to suit everybody, particularly those whose strengths being more visually creative than actual coding. So are there other ways to author SVGs or do you have to just do it by hand and in a text editor?

Cassie: I think I wrote a hamburger icon once just from the top of my head and I was super proud of myself, but the rest of the time I create SVGs in Illustrator or other alternatives. Affinity designer is really good. Illustrator has obviously the Adobe pricing structure, which can be a little bit out of people’s budgets, but Affinity Designer is like a once off purchase and it’s pretty good actually, and the SVG markup that you get out of it is good which is the most important thing. But yeah, I don’t think there’s anyone apart from, it’s a guy called Blake Bowen on the GreenSock forums, and I think that he could probably hand write SVG path data, but I don’t think it’s a thing that everyone can do. I don’t think that it’s a thing that we should be aspiring to do. It’s quite verbose.

Drew: So being a lightweight by using a dedicated graphics tool to author SVGs, it’s a perfectly valid route.

Cassie: It’s fine. Choose your battles.

Drew: Are there any tools out there that are free for filtering SVGs or is it all commercial?

Cassie: I think Inkscape is free, but yeah, I would really recommend Affinity Designer. I think for the kind of cheaper tier, I think it’s worth paying a little bit of money towards these tools because it can be quite frustrating working with clunky vector graphics tooling.

Drew: In terms of the output, the SVG output that you get from these tools, is it all the same? Do they all just basically generate the same SVG or some better than others?

Cassie: Yeah, that’s a very good question. I find Illustrator is a lot better than other tools, but it’s not something that should hold you back or make you feel like you need to spend that money. So at the end of the day you’ll get some markup out, some editors you might need to do a little more tweaking than others but most of them you will get workable SVG code out of it.

Drew: I’ve found personally when I’ve tried to create SVGs, and I’m not graphically skilled, that I get varying results depending on how I actually draw something in say Illustrator. Presumably when it comes to thinking about how something’s going to be animated, it matters more how you construct your shapes in the editors. Is that fair?

Cassie: Yeah, definitely. Also SVG has an implicit drawing order, so it’s not like HTML. So with HTML, you can use that index to kind of move things around and put things underneath or on top of other things, whereas with SVG the order that it is in the code will be the order that it is displayed on the web page. So that’s something to kind of keep in mind when you’re drawing out an SVG is getting your layers in the right order and then anything that you want to move as one unit you should wrap in a group and anything that you want to move separately from something else you need to make sure that it’s actually a separate shape.

Drew: Yeah, so I mean by getting your layers in order there you’re literally talking about the layers palette in Illustrator and dragging the things around before you export, is that right? Just getting them in the correct order and then exporting.

Cassie: Yes.

Drew: And once you have exported it are there tools that will help sort of optimize or, because I know with PNGs, there’s a whole load of things I use to cut all the craft out of the file and reduce the file size. Are there’s similar things for SVG?

Cassie: Yeah. There’s a tool called SVGOMG, which I use a lot, which is great and you can use that for batch processing. There’s terminal commands for it, but you can also, there’s a Gooey in the browser, which I really like for large illustrative SVGs because I think it’s nice to build it into, say your build process, if you’re dealing with a huge load of icons that you all want processed in the same way, but if you’re dealing with an illustrative SVG, it’s nice to be able to use the gooey because you can flip between the code view and the visual view and you can just make sure that the things that you’re changing in the settings aren’t visually affecting your SVG in a negative way and aren’t affecting the code in a way that you don’t want it to.

Drew: Presumably these tools, things like Illustrator, are great for creating graphics, but they’re not going to help us at all with animation are they? That all happens once we get the SVG and put it into a webpage.

Cassie: Yeah.

Drew: So what does that process look like? I mean, obviously it’s difficult to talk about animation too much on an audio podcast, but in terms of just the sort of process you’d go through. You put your SVG into a page, what happens then? How do you address parts of it or what do you do to start working with it?

Cassie: So it’s very similar to animating HTML DOM elements in that you need to be able to target the elements themselves. So that would involve putting classes or IDs on them so that you can target them, and then you can either use CSS for animation. There are some issues with transforms with CSS that are still kind of being ironed out a little bit. So I tend to recommend CSS for experimenting and playing with SVG animation. When it comes to SVG animation and production I will usually recommend GreenSock, which is a JavaScript animation library, and yeah, well with GreenSock and with CSS you basically just get the SVG elements and then do stuff to them.

Drew: So do you have full access to interacting with the complete range of JavaScript APIs and things like scroll events and mouse events and resizing and intersection and that whole browser environment presumably you’ve got at your disposal, to then have your animation interact with and respond to.

Cassie: Yeah. So anything that you would use in normal JavaScript, so like mouse events or scrolling, that kind of thing, you can look for that and then do things to your SVG on those events. You’ve also got SVG specific methods and stuff, like get PATHlink I think is one, stuff like that so there’s specific SVG methods that you can kind of play around with.

Drew: So you could do things for example, like start an animation as an SVG comes into view on the page if it’s scrolled out of place and stop it when it gets scrolled away and restart it if it comes back into view and that sort of thing.

Cassie: Yeah. There’s actually a new GreenSock plugin called ScrollTrigger and previously I think a lot of people have used ScrollMagic for scroll animations, but that was a different library to GreenSocks, so they had no kind of affiliation with each other so you were just mashing together two different libraries, one that did animation and one that did scroll events. Whereas GreenSock have now just made a scrolling plugin that works with GreenSock and it has one event listener. One scroll listener. Yeah. So it’s very, very performance and I’ve played around with it recently and it’s great. It’s really easy to use.

Drew: Is that automatically buffered so you’re not completely overrun with scroll events being fired at your code and all those sorts of traditional problems?

Cassie: Yeah all of the traditional problems, they’re kind of doing all the heavy lifting in the background for you, which is good.

Drew: Fantastic. Would GreenSock be the tool then, the sort of library, that you’d recommend people to start using if they were looking at SVG animation?

Cassie: Yes, definitely. Mostly because GreenSock, it’s the only animation library out there that handles SVG transforms consistently cross-browser and that isn’t just something that they do that they’re not focusing on anymore. It’s a constant effort from their part so they’re constantly kind of looking for SVG bugs and fixing things. So it’s very reliable. Definitely.

Drew: What is the sort of cross-browser situation like with SVG? Is it fairly reliable or are you constantly having to deal with inconsistencies across different browsers and platforms?

Cassie: If you are animating with GreenSock then you don’t. If you are animating with CSS, yeah there’s quite a few inconsistencies. It’s mostly to do with how transforms are handled. So with HTML DOM elements transforms are measured from the center of them, and with SVG transforms are measured from the top left hand corner, but in some browsers it’s the top left hand corner of the element itself, and in other browsers it’s the top left hand corner of the SVG view box parent. So you can end up, if you’re rotating things around in some browsers, they might end up going in a different trajectory than others.

Drew: That sounds like most of the animation I’ve ever tried to script. Things going in unexpected directions. We’re used to sort of traditional animation tools, having things like easing options, ease in ease out and that sort of stuff. Presumably that’s something that GreenSock then brings to the table.

Cassie: Yeah. GreenSocks got a lot of really good easing equations that you can use. Yeah, and they’ve got a great ease visualizer so you can have a little look at how will the eases work.

Drew: That’s really useful, and again that’s something I always struggle with. It’s like, I know I should do something. It shouldn’t just move linearly from A to B, but what do I do? So yeah, being able to visualize stuff is really handy.

Cassie: When I started making animations I made a lot of space animations because I hadn’t quite figured out how easing worked yet, so in space everything does move linearly because it’s just floating around. It doesn’t have gravity to contend with, so I made lots of rockets, planets bobbing around and it was fine.

Drew: I mean I guess you, being such an SVG enthusiast, you probably see people they’re putting SVG to all sorts of creative uses. What sort of things, just to get the juices flowing, what sort of things have you seen people do with SVGs that has been particularly impressive or creative?

Cassie: I think one of the things that I love with SVG is the fact that you don’t just have to use it for illustrative SVG animations by themselves because it is XML based markup, just like HTML. You can kind of mix it in with the HTML DOM. So, I think it’s a bit of a nerdy thing, but my favorite examples of SVG animation are when people mix SVG animation with semantic DOM elements, so when you have a button that is a proper button but it’s got some SVG icon illustration in it so that when you click that button something joyful happens, and I love that because it’s this perfect marriage of kind of whimsical joyfulness and proper semantic DOM elements.

Drew: You’ve said in the past that front end development has become very serious in recent times. Has all the fun gone out of the web Cassie?

Cassie: That’s a very serious question. Has all the fun gone out of the way.

Drew: Because things used to be a lot more fun, but maybe not as efficient and have we got too serious with it?

Cassie: Yeah. I think efficiency is a real killer when it comes to adding these little enhancements on. I find that in my day job at Clearleft, I quickly realized that if I wanted to have animations as an extra thing, as like another ticket or something, it was very hard to get sign off on that. It was always the thing that if the project starts being a little bit cramped on time, it’s the first thing to go. But I think that once you’ve got a good understanding of animation and SVG you can just sneak things in to start off with. So when you’re building a component and you see an opportunity for a little bit of animation and you can just add it in and it gets easier because then people start seeing the possibilities and people start realizing that the clients really like that kind of thing, and then you can kind of get a little bit more time to work on it.

Drew: It is the sort of thing that can just really elevate an experience beyond unsatisfactory or unsatisfying sort of boring transaction to something that gives the user just a little bit of joy and gives her a whole sort of perception of quality and some brand personality as well, I think with animation. There’s a…

Cassie: Yeah.

Drew: There’s a lot in terms of brand personality that can be put across with those sort of little touches.

Cassie: But I think this is something that a lot more people are realizing now as well, not just with SVG and animation, but personality in general, and I think that there’s a lot more weight that’s being given to copy that’s written well and has a bit of personality and illustrations that aren’t just from a stock library that are unique to that company or that person and animations are a big part of that. And I think that I personally feel like we’re seeing more of these websites nowadays and I think that we went through, and are probably still going through a little bit of efficiency first period, but I think as with anything people start getting bored of that and it does seem like a lot of websites suggest being churned out by some corporate mega machine and people are starting to push back, I think. Max Bock made a site recently called the whimsical web and it’s got a lot of personal sites on there that are really joyful for various different reasons and I think we’re starting to see a lot more of that.

Drew: Is it possible to go too far with adding animation and sort of too much personality perhaps to a site?

Cassie: Yes. Definitely. I’m not a huge fan of websites that are very, very, whizbang. Like websites that are animation first. You get to the page and everything’s moving and you’re trying to read text as you’re scrolling, but it’s moving while you’re trying to read it. I’m not a fan of that. I really like looking at animation as an enhancement and I think that’s why SVG, I think is so great because you can kind of build an otherwise quite sensible website, but you can have these little whimsical touches throughout it.

Drew: And it’s crucial, isn’t it, as we mentioned before, the accessibility sort of aspect of things that it is possible to create a nicely accessible SVG, even if it has sort of content, if you’re locked in there, it’s not locked. It’s accessible to screen readers and then hopefully to everyone who visits the site. As I say, it’s hard on a podcast to really get into the practicalities of, well, we can’t show animation or anything, but you’re running an online workshop with Smashing Conference all about SVG, aren’t you?

Cassie: Yes, I am.

Drew: It’s the SVG animation MasterClass and that starting on October the eighth and it’s quite an unusual format. It’s two hours on Thursdays and Fridays. That’s an unusual way to do things, isn’t it?

Cassie: Yeah. I’m actually really happy about that because I’ve done a version of this workshop before. I spent a large part of 2019 putting it together. It was my baby, my passion project, and then I had quite a few workshops booked in and then the situation happened and all of them got canceled. So I got the opportunity to run it twice before the situation, and it was really great but it was a lot of content and it was a full day workshop. About eight hours and you could tell by the end of it people’s brains are just switching off because you’re sitting in a room trying to absorb information for eight hours. So I’m quite excited about this format because it means that I could divide it up into sections that kind of work by themselves and it gives people a chance to learn that and process it a little bit and let it sink in before they get the next load of information. So I think we’re going to get some really interesting things at the end of it just because people have had more time to absorb.

Drew: So it’s a Thursday and a Friday, a Thursday and a Friday, and then a Thursday to finish it off with two hours on each of those days followed by Q and A. I think that’s right, isn’t it?

Cassie: Yes.

Drew: Q and A on each session. What would those attending expect to learn? What should their expectations be in terms of what skills they might pick up?

Cassie: So it’s more angled towards the animation coding side of SVG animation. So we’ll cover a little bit of getting SVGs out of a graphics editor, and then the whole process from getting the code out through to starting to work with it. So optimizing and adding the right classes and structuring it properly, and then we’ll work on animating SVGs. So we’ll be using CSS. We’ll also be using GreenSock, which is the animation library that I mentioned, and we’ll be covering what I kind of refer to as SVG super powers. So this is stuff that it’s, aside from the animation, it’s the things that you can do with SVG.

Cassie: So that’s like clipping, and masking, and stroke animation, and filters, and all of that stuff is just so important to understand with SVG because it unlocks all of these kinds of super powers that you can play with. And we’ll also look at performance and accessibility, and also a bunch of the kind of little tips that I’ve picked up and learned along the way. So, little handy tips that I find useful for my workflow, handy tips that help with flashes of unstyled content before you start animating. Little tips like that.

Drew: That sounds really useful. I looked just before we started our interview and there are still some early bird places available, which is great. So if people are quick they might still catch those and you can register at smashingconf.com. There’s actually a number of different master classes that are being run at the moment and there are early bird deals and bundled deals on some of them as well. So there’s things like JAMstack, CSS layout with Rachel Andrew, Vue.js, web performance, GraphQL, loads of different Masterclasses and you can find all those at smashingconf.com. So I’ve been learning all about SVG. What have you been learning about lately Cassie?

Cassie: Oh, I’ve been recently learning quite a lot about Eleventy. I did a little site redesign recently using Eleventy and I’ve also been doing Andy Bell’s Eleventy from scratch course. So I’m getting quite into static site generators in general at the moment.

Drew: That’s great. I think we’re all getting into static site generators more as time goes on.

Cassie: It’s the future.

Drew: If you dear listener, would like to hear more from Cassie you can of course sign up for this animation Masterclass with Smashing Conf, but also you can find her on Twitter where she’s @Cassiecodes and her personal website is cassie.codes and that links to her CodePen, which is a great place to explore. Thanks for joining us today Cassie. Do you have any parting words?

Cassie: I would like to say that Smashing and I are offering for free tickets to my workshop. So they are diversity tickets that are going out to anyone that’s underrepresented in tec or going through a tough financial time at the moment. So you can apply for that on the webpage about my workshop and I hope to see you there.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
guillermo-rauch-200x200-1
06 Oct

Smashing Podcast Episode 23 With Guillermo Rauch: What Is Next.js?

by TBSCategories: News

Today, we’re talking about Next.js. What is it, and where might it fit into our web development workflow? I spoke to co-creator Guillermo Rauch to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: He’s the founder and CEO of Vercel, a cloud platform for static sites that fits around a Jamstack workflow. He’s also the co-creator of Next.js. He previously founded LearnBoost and CloudUp, and is well-known as the creator of several popular node open source libraries like Socket.io, Mongoose, and SlackIn. Prior to that, he was a core developer on MooTools, so we know he knows his way around JavaScript like the back of his hand. Did you know he once received a royal commission from the King of Spain to create an ice sculpture out of iceberg lettuce? My smashing friends, please welcome Guillermo Rauch. Hi Guillermo, how are you?

Guillermo Rauch: I’m smashing freaking good, thanks for having me.

Drew: I wanted to talk to you today about the whole world of Next.js, as it’s something that obviously you’re personally very knowledgeable about, having been involved as a co-creator right from the start. Next.js is one of those project names that has been on my radar while working in the Jamstack space, but it isn’t something that I’ve actually personally looked at or worked with too closely before. For people who are like me, who perhaps aren’t aware of what Next.js is, perhaps you could give us a bit of background into what it is and what problems it tries to solve.

Guillermo: Next.js is a very interesting member of the Jamstack universe, because Next.js actually started being a fully SSR-focused framework. It started getting a lot of adoption outside the Jamstack space where people were building very large things specifically when they wanted to have user generated content or dynamic content or social networks or e-commerce, and they knew that they wanted SSR because their data set was very large or very dynamic. It fell under the radar I think for a lot of people in the Jamstack world, but later on Next.js gained the capabilities for static optimization.

Guillermo: On one hand, for example, if you wouldn’t do data fetching at the top level of your page with Next.js, your React page would be … Also by the way, for those who are not fully in the know, Next.js is simply React framework for production, but has this capability of doing some rendering. Then when you get in static optimization capabilities, if you wouldn’t define data fetching at the top level of your page, it automatically exported as HTML instead of trying to do anything with server rendering.

Guillermo: Then later on, it also gained the capability for static site generation, meaning that you can define a special data hook, but that data hook gets data at build time. Next.js became a hybrid, very powerful dynamic and static framework, and now it’s been growing a lot in the Jamstack space as well.

Drew: People might say that React is already a framework, you certainly hear it described that way. What does it actually mean to be a framework for React?

Guillermo: That’s a great observation, because I always point out to people that React at Facebook and React outside of Facebook are completely different beasts. React at Facebook actually is used together with server rendering, but even their server rendering, for example, doesn’t use Node.js, it uses a highly specialized virtual machine called Hermes which communicates to their sort of production hack and PHP stack and answers all this advanced and exotic Facebook needs.

Guillermo: When they open source React, it’s almost like open sourcing a component. I always call it like open sourcing the engine, but not giving you the car. What happened is people really wanted to go and drive with it, they wanted to get to places with React. In the community, people started creating cars, and they would embed React as the engine, which was what the driver, the developer was after in the first place, make React the fundamental part of the car. Things like Next.js and Gatsby and React Static and many other frameworks started appearing that were solving the need for like, “I actually want to create fully loaded pages and applications.”

Guillermo: Whereas React was kind of more like the component and the engine for specific widgets within the page, this was certainly the case for Facebook. They will broadly and publicly admit that they invented it for things like the notification batch, the chat widget, the newsfeed component, and those components were React routes that were embedded into the contents of the production existing app with lots and lots of lines of code and even other JS libraries and frameworks.

Guillermo: What it means to create a framework for React, it means you make React the fundamental part of the story, hopefully and this is something we’ll try to do with Next.js, the learning curve is primarily about React with some added surface for Next.js, particularly around data fetching and routing. We also do a lot of production optimizations, so when you get React, when you get Create React app, which is sort of like, I like to call it a bootstrapped car that Facebook gives you, maybe the needs for production are not really met. Or if you try to do it yourself by configuring Webpack and configuring Babel and configuring server rendering and static generation, it’s also hard to put together a car from scratch. Next.js will give you this zero config and also production optimized set of defaults around building entire big things with React.

Drew: So it’s like it almost puts a sort of ecosystem around your React app with a collection of pre-configured tools to enable you to-

Guillermo: Correct.

Drew: Hit the ground running and do static site generation or server rendering or routing.

Guillermo: Correct, and you used a word there that is very, very key to all this, which is pre-configured. We’re fortunate enough to draw the attention of Google Chrome as a contributor to Next.js. One of the leaders of this project, her thing is that when they were working on frameworks internally at Google, they faced a lot of the same problems that the community and open source are facing today. There were many different competing initiatives at Google on how to scale and make really performant web apps out of the box.

Guillermo: You would join as a Googler and you would be given a framework with which you would create really big production ready, very high performance applications. Shubie was part of a lot of those initiatives, and what she found is that there’s two key ingredients to making a framework succeed at scale. One is pre-configuration, meaning that you come to work, you’re going to start a brand new app, you should be given something that is already ready to go and meets a lot of the production demands that are known at that given point in time.

Guillermo: On the other hand, the other really important step that we’re working towards is conformance. You can be given the most highly optimized production ready pre-configured framework, but if you go ahead and, for example, start introducing lots of heavy dependencies or third party scripts or use very inefficient layouts that take a long time to paint and so on and so forth, then you’re going to make that pre-configuration sort of go to waste. By mixing pre-configuration with conformance over time, the developer is not only having a great starting point, but it’s also guided to success over time.

Drew: It seems that a characteristic of Next.js, that it’s quite opinionated, the UI layer is React, it uses type script, uses Webpack, and those are all choices that the project has made and that’s what you get. Correct me if I’m wrong, but you couldn’t swap out React for Vue, for example, within Next.js.

Guillermo: That’s a good point, where technical decision making meets sort of an art. On one hand, I’d really like to claim that Next is very unopinionated, and the reason for this is that if you specifically go to github.com/vercel/nextjs and the examples directory, you’ll see that there’s almost like a combinatoric explosion of technologies that you can use together with Next.js. You’ll see fire-based, you’ll see Graphic UL, you’ll see Apollo, you’ll see Redux, you’ll see MobX, in the CSS space there’s even more options.

Guillermo: We have a default CSS port that’s embedded, but then you can use two flavors of it, one with import, one with style tags which we call Style JSX, which resembles very much like the web platform approach to Shadow CSS. The reason I mean unopinionated is we want Next.js to stay very close to the “bare metal” of the web, and not introduce lots of primitives that if the web from 10 years from today would be incompatible with. Then if you look at the examples, you’ll see that there’s all these other technologies that you can plug in.

Guillermo: The base level of opinionation is that there is React and you’re not going to be able to replace it, at least anytime soon. Then there is the concept of you should be able to create pages, and this was kind of like a new thing when we first launched it, which was everyone is trying to create single-page applications. What we realized is like the internet is made up of websites with lots of pages that create distinct entry points via search engines, via Twitter, via Facebook, via social networks, via email companions, like you always guide the person toward an entry point, and that person that comes through that entry point shouldn’t have to download the burden of the entirety of the application.

Guillermo: Then that path led us to implementing server rendering, then static generation for multiple pages, et cetera, et cetera. That other base level of opinionation is Next should be a framework that works for the web, not against the web. Then on top of that, React was missing data fetching and routing primitives, and we added those. There’s a level of opinionation that has to deal with like everybody needs a router, so might as well have a router built in by default.

Drew: The big advantage of having those defaults is it takes away a lot of the complexity of choice, that it’s just there, it’s configured, and you can just start using it without needing to think too much, because I think we’ve all-

Guillermo: Exactly.

Drew: Been in situations where there are far too many choices of what components to use, and it can be overwhelming and get in the way of being productive.

Guillermo: Exactly.

Drew: What sort of projects do you see people using Next.js for? Is it for basically any situation where you might build a production React app, or is it more suited to particular types of content heavy sites? Does it matter in that sense?

Guillermo: Yeah, so this has been an age old debate of the web, is the web for apps, is the web for sites, is it a hybrid? What is the role of JavaScript, et cetera, et cetera? It’s kind of hard to give a straight up answer, but my take on this is the web was evolved always to be a hybrid of content that is evolving to be more and more dynamic and personal to the user. Even when you say like a content website, the high end content websites of the world have code bases that are very much comparable to apps.

Guillermo: A great example here is like New York Times, they’ll give you embedded widgets with data analysis tools and interactive animation, and they’ll recommend what story to read next, and they have a subscription model built in which sometimes gives you part of the content and sometimes counts how many articles you’ve read. Like if I told you this when the web was invented, like Tim Berners-Lee would be like, “No, that’s crazy, that’s not possible on the web,” but that’s the web we have today.

Guillermo: Next.js is answering a lot of these complex modern needs, which means you’ll see lots of e-commerce usage, you’ll see lots of content with that. E-commerce meaning, by the way, not just like buy items, but experiences like the largest real estate websites on the web, realtor.com, zillow.com, trulio.com, that entire category is all Next.js, then content sites. We just onboarded washingtonpost.com as a customer of Vercel and Next.js, we have then a third category that is more emergent but very interesting, which is full apps and user-generated content, like tiktok.com, and kind of like you would think the original single-page application use case as well being quite represented there.

Guillermo: Next.js sort of shines when you need to have lots of content that has to be served very, very quickly, has to be SEO optimized, and at the end of the day, it’s a mix of dynamic and static.

Drew: I’ve previously spoken to Marcy Sutton about Gatsby, which seems to be in a similar sort of space. It’s always great to see more than one solution to a problem and having choice for one project to the next. Would you say that Next.js and Gatsby are operating in the same sort of problem space, and how similar or dissimilar are they?

Guillermo: I think there’s an overlap for some use cases. For example, my personal blog rauchg.com runs on Next.js, it could’ve just been a great Gatsby blog as well. There is that overlap in the smaller static website sort of space, and by small I don’t mean not relevant. A lot of dotcoms that are super, super important run on basically static web, so that’s the beauty of Jamstack in my opinion. Because Next.js can statically optimize your pages and then you can get great Lighthouse scores through that, you can use it for overlapping use cases.

Guillermo: I think the line gets drawn when you start going into more dynamic needs and you have lots of pages, you have the need to update them at one time. Although Gatsby is creating solutions for those, Next.js already has production ready live solutions that work with any sort of database, any sort of data backend for basically “generating” or “printing” lots and lots of pages. That’s where today customers are going to Next.js instead of Gatsby.

Drew: One of the problems that everyone seems to run into as their JavaScript-based solution gets bigger is performance and how things can start getting pretty slow, you have big bundle sizes. Traditionally, things like code splitting can be fairly complex to get configured correctly. I see that’s one of the features that jumped out at me of Next.js, that it claims that the code splitting is automatic. What does Next.js do in terms of code splitting to make that work?

Guillermo: Your observation is 100% right. One of the biggest things with the web and one of the biggest weights on the web is JavaScript, and just like different materials have different densities and weights irrespective of the actual physical volume, JavaScript tends to be a very dense, heavy element. Even small amounts of JavaScript compared to, like for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.

Guillermo: Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. The first one that was my first intuition when I first came up with the idea for Next.js was you’re going to define, for example, 10 routes. In the Next.js world you create a pages directory and you drop your files in there Index.js, About.js, Settings.js, Dashboard.js, Termsofservice.js, Signup.js, Login.js. Those become entry points to your application that you can share through all kinds of media.

Guillermo: When you enter those, we want to give you JS that is relevant for that page first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Next.js also, which is very, very nice, automatically pre-fetches the rest of the pages that are connected to that entry point, such that it feels like a single-page application. A lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Look, you can find those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it’s better optimized with regards to that initial paint, that initial entry point.”

Guillermo: That was the initial code splitting approach, but then it became a lot more sophisticated over time. Google contributed a very nice optimization called Module and No Module, which will give differential JS to modern browsers, and legacy JS that’s heavy with polyfields to other browsers, and this optimization 100% automated and produces massive savings. We gave it to one of our customers that we host on Vercel called Parnaby’s, I believe if I’m not mistaken, it was something very, very significant. It was maybe like 30% savings in code sizes, and that was just because they upgraded Next.js to a version that optimized JS bundles better.

Guillermo: That was kind of the point that we were going over earlier, which is you choose Next.js and it only gets better and more optimal over time, it’ll continue to optimize things on your behalf. Those are, again, pre-configurations that you would never have to deal with or be bothered with, and the research of which you don’t ever even want to do, to be honest. Like I wasn’t obviously very involved with this, but I look at some of the internal discussions and they were discussing all these polyfields that only mattered to Internet Explorer X and Soho, I was like, “I don’t even want to know, let’s just upgrade Next.js and get all these benefits.”

Drew: There is sometimes great benefits on there with sticking with the defaults and sticking with the most common configuration of things, which seems to be really the Next.js approach. I remember when I started writing PHP back in the early 2000s, and everybody was using PHP and MySQL, and at the time I’d just come from Windows so I wanted to use PHP and Microsoft Sequel Server. You can do it, but you’re swimming against the tide the whole way. Then as soon as I just switched over to MySQL, the whole ecosystem just started working for me and I didn’t need to think about it.

Guillermo: Yeah, everything just clicks, that is such a great observation. We see that all the time, like the Babel ecosystem is so powerful now that you could become, for example, a little bit faster by swapping Babel for something else, but then you trade off that incredible ecosystem compatibility. This is something you touched on performance earlier, and like for a lot of people, build performance and static generation performance is a big bottleneck, and this is something that we are very diligent in improving the performance of our tools incrementally.

Guillermo: For example, one of the things that Next.js is doing now is that it’s upgrading its default from Webpack 4 to Webpack 5, which has some breaking things, and that’s why we’re first offering it to people as an opt-in flag, but later on it’ll become the default. Webpack 5 makes incredible performance improvements, but we’re not sacrificing the Webpack ecosystem, we incrementally improved. Sure, there were some very small things that needed to be sacrificed, but that’s an incredible benefit of the JS ecosystem today that a lot of people are glossing over, I think, because maybe they see, “Oh, we could’ve done X in Soho, maybe it was a little faster, or maybe MPM in Soho would take less time.” They pick up some details and they miss the bigger picture, which is the ecosystem value is enormous.

Drew: The value of having all the configuration and the maintenance and that side of it done by a project like Next.js rather than taking that on yourself by swapping to using something else is incredible, because as soon as you move away from those defaults, you’re taking on the burden of keeping all the compatibilities going and doing it yourself. One of the things that I’ve been really interested in with Next.js is there are options available for either doing static site generation or server-side rendering, or maybe a hybrid of the two perhaps. I think there’s been some recent changes to this in a recent update, can you tell us a little bit about that and when you might choose one or the other?

Guillermo: Yeah, for sure. One of the key components of this hybrid approach combined with the page system that I described earlier is that you can have pages that are fully static or pages that server rendered. A page that’s fully static has the incredible benefit of what I call static hoisting, which is you can take that asset and automatically put it at the edge. By putting it at the edge, I mean you can cache it, you can preemptively cache it, you can replicate it, you can make it so that when a request comes in, it never touches the server because we know ahead of time, “Hey, Slash Index is a static.”

Guillermo: That’s a very, very interesting benefit when it comes down to serving global audiences. You basically get an automatic CDN out of the box, especially when you deploy the modern edge networks like Vercel or AWS Amplify or Netlify and so on. Next.js has this premise of if it can be made static, it should be static. When you’re first starting a project and you’re working on your first page or you’re kicking the tires of the framework, might as well make everything static.

Guillermo: Even for high end needs, so for example, vercel.com, our own usage of Next.js is fully static. It’s a combination of fully static and static site generation, so all our marketing pages are static, our blog is statically generated from a dynamic data source, and then our dashboard which has lots of dynamic data, but we can deliver it as shells or skeletons, all the pages associated with viewing your deployments, viewing your projects, viewing your logs, et cetera, et cetera, are all basically static pages with client-side JavaScript.

Guillermo: That serves us incredibly well because everything where we need a very fast first-pane performance is already pre-rendered, everything that needs SEO, already pre-rendered, and everything that’s extremely dynamic, we only have to worry about security, for example, from the perspective of the client side which uses the same API calls that, for example, our CLI used or our integrations use, et cetera, et cetera. A fully static website, very cheap to operate, incredibly scalable and so on and so forth.

Guillermo: Now, one particular thing that we needed with our blog was we wanted to update the data very quickly. We wanted to fix a typo very quickly and not wait for an entire build to happen, and this is a very significant benefit of Next.js, that as you straddle from a static to a dynamic, it gives you these in between solutions as well. For our blog we used incremental static generation, so essentially we can rebuild one page at a time when the underlying content changes.

Guillermo: Imagine that we had not just a couple hundred blog posts and we had lots of blog posts being generated all the time and being updated all the time, like I mentioned one of our customers, Washington Post, in that case you need to go more toward full SSR, especially as you start customizing the content for each user. That journey of complexity that I just described started from I have one marketing page, to I have a blog that has a couple thousand pages, to I have tens of thousands or millions of pages. That’s the Next.js journey that you can traverse with your own business.

Guillermo: Then you start as a developer to choose between perhaps less responsibility to more responsibility, because when you opt in to using SSR, you’re now executing code on the server, you’re executing code on the cloud, there’s more responsibility with more power. The fact that you can decide where you use each kind of tool is I think a very, very interesting benefit of Next.

Drew: Just in practicalities of combining the static site generation and the server-side rendering, how does that work in terms of the server element? Are you needing a dedicated platform like Vercel to be able to achieve that, or is that something that can be done more straightforwardly and more simply?

Guillermo: Next.js gives you a dev server, so you download Next and you run your Next Dev, and that’s the dev server. The dev server is obviously incredibly optimized for development, like it has the latest fast refresh technology that Facebook released, where … Actually, Facebook didn’t release it, Facebook uses it internally to get the best and most performant and most reliable hot module replacement, such that you’re basically typing and it changes are reflecting on the screen, so that’s the dev server.

Guillermo: Then Next gives you a production server called Next Start, and Next Start has all the capabilities of the framework for self-hosting. The interesting thing about Vercel is that when you deploy Next to it, it gets automatically optimized and it’s 100% serverless, meaning there’s no responsibility whatsoever of administration, scaling, cashing and cashing validation, purging, replication, global fail over and so on and so forth that you would have to take on when you run Next Start yourself.

Guillermo: That’s also the great benefit of Next.js, so for example, apple.com has several different properties, subdomains and pages on dotcom on Next.js they self-host, due to very, very advanced and stringent security and privacy needs. On the other hand, washingtonpost.com uses Vercel, so we have this sort of wide range of users, and we’re extremely happy to support all of them. The nice thing about where serverless is headed in my opinion is it can give you best of both worlds in terms of the most optimal performance that only gets better over time, with the best developer experience of like, “Hey, I don’t have to worry about any sort of infrastructure.”

Drew: The Next.js is an open source project that’s being developed by the team at Vercel. Are there other contributors outside of Vercel?

Guillermo: Yeah, so Google Chrome being the main one that actively submit server PRs, help us with optimizations and testing it with partners, like very large Next.js users that are already part of the Google ecosystem, for example, due to using lots and lots of apps, so they need to be involved closely as partners. Facebook, we maintain a great relationship with the Facebook team. For example, fast refresh, we were the first React framework to land that, and they helped guide us through all the things that they learned of using React and fast refresh at Facebook.

Guillermo: We work with lots of partners that have very large deployments of Next.js apps in the wild from all kinds of different sort of use cases, like imagine e-commerce and content. Then there’s just lots and lots of independent contributors, people that use Next.js personally, but also educators and members of front infrastructure teams at large companies. It’s a very, very wide community effort.

Drew: It sounds like the concern that somebody might have, that this is being developed in a significant part by Vercel, that they might have the concern that they’re going to get sort of locked into deploying on that particular platform, but it sounds very much like that’s not the case at all, and they could develop a site and deploy it on Firebase or Netlify or…

Guillermo: Yeah, absolutely. I like to compare it a lot for like the Kubernetes of the Front End age in a way, because at the end of the day I am a firm believer that … Kubernetes is something that pretty much almost everyone needs when they need to run Linux processes, like you were talking about opinionation and you’re saying it’s a good technology, it’s very much not opinionated, but there is some opinionation that we kind of forget about. It’s like at the end of the day, it grew out of running a specific demons of Linux programs packaged as containers.

Guillermo: Next is in a similar position, because what we take for being the universal primitive of the world as a React component, obviously it’s opinionated, but we do think that for lots of enterprises, just like they all gravitate towards Linux, we are seeing the same thing towards React and Vue, but Vue luckily has Nuxt too, which is a very awesome solution, it’s equivalent in ideation and principles as Next. We’re gravitating towards these platforms like Next.js, like Nuxt, like Sapper for the Svelte ecosystem.

Guillermo: I think these should be open platforms, because again, if everybody’s going to need this, might as well not reinvent the wheel across the entire industry, right? We very much welcome that position, we welcome people to deploy it and reconfigure it and rebuild it and redistribute it and so on.

Drew: Just recently a new version of Next.js was released, I think version 9.5. What significant changes were there in that release?

Guillermo: The most awesome one is, as I was saying earlier, a lot of things start static and then become more dynamic as things grow. This was the venture for WordPress, by the way. WordPress in the beginning was based on a static file database approach, and then grew into needing a database, kind of like what you described with how PHP evolved to be more and more MySQL. What’s nice about Next.js 9.5 is that it makes incremental static generation a production ready feature, so we took it out of the unstable flag.

Guillermo: This feature allows you to make that journey from static to dynamic without giving up on all the static benefits, and without having to go full for server-rendered dynamic, so it stretches the useful lifetime of your sort of static. The way we use it at Vercel, for example, as I mentioned, it’s like our blog gets fully pre-rendered at build time, but then for example, we’re actually in a couple minutes about to make a major announcement, and when we blog about it we want to be able to tweak it, fix it, preview it, et cetera without having to issue a five to 10-minute build every time we change one letter of one blog post.

Guillermo: With incremental static generation, you can rebuild one page at a time. What could take minutes or even seconds, depending on how big your site is, now takes milliseconds. Again, you didn’t have to give up on any of the benefits of static. That’s perhaps the thing I’m most excited about that went stable on Next.js 9.5, and specifically because the JS community and the React community and the framework community and static site generated community have been talking about this unicorn of making a static incremental for a long time, so the fact that Next.js did it, it’s being used in production and it’s there for everybody to use, I think it’s a major, major, major milestone.

Guillermo: There’s lots of little DX benefits. One that’s really nice in my opinion is Next.js, as I said, has a page system. You would argue, “Okay, so let’s say that I’m uber.com and I’ve decided to migrate on Next.js, do I need to migrate every URL inside over to Next.js in order to go live?” This has become a pretty important concern for us, because lots of people choose Next.js, but they already are running big things, so how do you reconcile the two?

Guillermo: One of the things that Next.js allows you to do in 9.5 is you can say, “I want to handle all new pages that I created with Next.js with Next.js, and the rest I want to hand off to a legacy system.” That allows you incremental, incremental is the keyword here today, incremental adoption of Next.js. You can sort of begin to strangle your legacy application with your Next.js optimized application one page at a time, when you deploy and you introduce in your Next.js page, it gets handled by Next. If it doesn’t match the Next.js routing system, it goes to the legacy system.

Drew: That sounds incredibly powerful, and the incremental rendering piece of that, I can think of several projects immediately that would really benefit that have maybe 30-minute build times for fixing a typo, as you say. That sort of technology is a big change.

Guillermo: We talked to one of the largest, I believe, use cases in Jamstack in the wild, and it was basically a documentation website and their build times were 40 minutes. We’re doing a lot in this space, by the way, like we’re making pre-rendering a lot faster as well. One of my intuitions for years to come is that as platforms get better, as the primitives get better, as the build pipelines get better we’re going to continue to extend the useful lifetime of statics. Like what ended up taking 40 minutes is going to take four.

Guillermo: A great example is we’re rolling out an incremental build cache, as well, system. I sort of pre-announced it on Twitter the other day, we’re already seeing 5.5 times faster incremental builds. One of the things that I like about Jamstack is that the core tenet is pre-render as much as possible. I do think that’s extremely valuable, because when you’re pre-rendering you’re not rendering just in time at runtime. Like what otherwise the visitor would incur in in terms of rendering costs on the server gets transferred to build time.

Guillermo: One of the most exciting things that’s coming to Next is that without you doing anything as well, the build process is also getting faster. On the Vercel side, we’re also taking advantage of some new cloud technology to make pre-rendering a lot faster as well. I think we’re always going to live in this hybrid world, but as technology gets better, build times will get better, pre-rendering will get better and faster, and then you’ll have more and more opportunities to do kind of a mix of the two.

Drew: Sounds like there’s some really exciting things coming in the future for Next.js. Is there anything else we should know before we sort of go away and get started working with Next.js?

Guillermo: Yeah. I think for a lot of people for whom this is new, you can go to nextjs.org/learn, it’ll walk you through building your first small static site with Next.js, and then it’ll walk you through the journey of adding more and more complexity over time, so it’s a really fun tutorial. I recommend also staying tuned for our announcement that I was just starting to share on twitter.com/vercel, where we share a lot of Next.js news. Specifically we highlight a lot of the work that’s being done on our open source projects and our community projects and so on. For myself as well, twitter.com/rauchg if you want to stay on top of our thoughts on the ecosystem.

Drew: I’ve been learning all about Next.js today, what have you been learning about lately, Guillermo?

Guillermo: As a random tangent that I’ve been learning about, I decided to study more economics, so I’ve been really concerned with like what is the next big thing that’s coming in terms of enabling people at scale to live better lives. I think we’re going through a transition period, especially in the US, of noticing that a lot of the institutions that people were “banking on”, like the education system, like the healthcare system, a lot of those, like where you live and whether you’re going to own a house or rent and things like that, a lot of these things are changing, they have changed rapidly, and people have lost their compass.

Guillermo: Things like, “Oh, should I go to college? Should I get a student loan?” and things like that, and there is a case to be made for capitalism 3.0, and there is a case to be made for next level of evolution in social and economic systems. I’ve been just trying to expand my horizons in learning a lot more about what could be next, no pun intended. I’ve found there’s lots of great materials and lots of great books. A lot of people have been thinking about this problem, and there is lots of interesting solutions in the making.

Drew: That’s fascinating. If you, dear listener, would like to hear more from Guillermo, you can find him on Twitter at @RauchG, and you can find more about Next.js and keep up to date with everything that goes on in that space at nextjs.org. Thanks for joining us today, Guillermo. Do you have any parting words?

Guillermo: No, thank you for having me.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
chris-coyier-200x200-opt
22 Sep

Smashing Podcast Episode 22 With Chris Coyier: What Is Serverless?

by TBSCategories: News

Today, we’re talking about Serverless architectures. What does that mean, and how does it differ from how we might build sites currently? I spoke to Chris Coyier to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: He’s a web designer and developer who you may know from CSS-Tricks, a website he started more than 10 years ago and that remains a fantastic learning resource for those building websites. He’s the co-founder of CodePen, the browser based coding playground and community used by front-enders all around the world to share what they make and find inspiration from those they follow. Alongside Dave Rupert is the co-host of ShopTalk Show, a podcast all about making websites. So we know he knows a lot about web development, but did you know he once won a hot dog eating competition using only his charm? My smashing friends, please welcome Chris Coyier. Hello Chris, how are you?

Chris Coyier: Hey, I’m smashing.

Drew: I wanted to talk to you today not about CodePen, and I don’t necessarily want to talk to you about CSS-Tricks, which is one of those amazing resources that I’m sure everyone knows appears right at the top of Google Search results when looking for answers about any web dev question. Up pops your face and there’s a useful blog post written by you or one of your guest contributors.

Chris: Oh, I used to actually do that. There was a… I don’t know, it probably was during the time of when Google had that weird social network. What was that? Google Plus?

Drew: Oh, Plus, yeah.

Chris: Yeah, where they would associate a website with a Plus account, and so my Plus account had an avatar, and the avatar was me, so it would show up in search results. I think those days are gone. I think if you…

Drew: I think so, yeah-

Chris: Yeah.

Drew: But I kind of wanted to talk to you about something that has been a little bit more of a sort of side interest of yours, and that’s this concept of serverless architectures.

Chris: Mm (affirmative).

Drew: This is something you’ve been learning sort of more about for a little while. Is that right?

Chris: Yeah, yeah. I’m just a fan. It seems like a natural fit to the evolution of front-end development, which is where I feel like I have, at least, some expertise. I consider myself much more of a… much more useful on the front-end than the back-end, not that I… I do it all these days. I’ve been around long enough that I’m not afraid of looking at a little Ruby code, that’s for sure. But I prefer the front-end. I’ve studied it more. I’ve participated in projects more at that level, and then along comes this little kind of a new paradigm that says, “You can use your JavaScript skills on the server,” and it’s interesting. You know? That’s how I think of it. There’s a lot more to it than that, but that’s why I care, is because I feel it’s like front-end developers have dug so deep into JavaScript. And now we can use that same skill set elsewhere. Mm, pretty cool.

Drew: Seems like a whole new world has opened up, whereas if you were just a front-end coder… I say, just a front-end coder, I shouldn’t. If you’re a front-end coder, and you’re used to working with a colleague or a friend to help you with the back-end implementation, suddenly that’s opened up. And it’s something that you can manage more of the whole stack yourself.

Chris: Yeah, yeah. That’s it.

Drew: Addressing the elephant in the room, right at the top. We’re talking about serverless, and obviously, naming things is hard. We all know that. Serverless architecture doesn’t mean there are no servers, does it?

Chris: I think it’s mandatory, like if this is the first podcast you’re hearing of it, or in the first… you’re only hearing the word “serverless” in the first dozen times you ever heard it, it’s mandatory that you have a visceral reaction and have this kind of, “Oh, but there are still servers.” That’s okay. If that’s happening to you right now, just know that, that’s a required step in this. It’s just like anything else in life. There’s stages to understanding. The first time you hear something, you’re required to kind of reject it a little bit, and then only after a dozen times or so, or after it’s proven its worth a little bit to you, do you get to enter the further stages of understanding here. But the word has won, so if you’re still fighting against the word “serverless”, I hate to tell you, that the train has left the station there. The word is already successful. You’re not going to win this one. So, sorry.

Chris: But I do think it’s interesting that… it’s starting to be like, maybe there actually aren’t servers involved sometimes. I would think one of the things that locked serverless in as a concept was AWS Lambda. They were kind of the first on the scene. A lambda is like a function that you give to AWS and it puts it in the magical sky and then… it has a URL, and you can hit it and it will run that function and return something if you want it to. You know? That’s just HTTP or whatever. That’s how it works, which… the first time you hear that, you’re like, “Why? I don’t care.” But then, there’s some obvious things to it. It could know my API keys that nobody else has access to. That’s why you run back-end to begin with, is that it knows secret stuff that doesn’t have to be in the JavaScript on the client side. So if it needs to talk to a database, it can do that. It can do that securely without having to expose API keys elsewhere. Or even where that data is or how it gets it, it’s…

Chris: So that’s pretty cool. I can write a function that talks to a database, get some data, returns that. Cool. So, Lambda is that, but AWS works. You have to pick a region. You’re like, “I don’t know. Where it should be, Virginia? Oregon? Should I pick the Australia one? I don’t know.” They have 20, 30. I don’t even know how many they have these days, but even lambdas had regions. They, I think, these days have Lambda@Edge, which means it’s all of the regions, which is kind of cool. But they were first, and now everybody’s got something like Lambda. All the cloud services. They want some kind of service in this world. One of them is CloudFlare. CloudFlare has workers. They have way more locations than AWS has, but they executed it kind of at a different time too… the way a CloudFlare worker… it’s similar to a lambda in that you can run Node. You can run JavaScript. You can run a number of other languages too, but… I think of this stuff largely, the most interesting language is JavaScript, just because of the prevalence of it.

Chris: It happens just at the CDN level, which I guess is a server, but I tend to not think of CDNs as a server. Not as obviously as something else. It’s starting to feel even more serverless-y lately. Is a CDN a server? I mean, I guess it’s a computer somewhere, but it feels like even less server-y.

Drew: It feels like, yes, a CDN may be a server, but it’s the most sort of minimal version of a server. It’s like a thin server, if you like.

Chris: Yeah. Sure.

Drew: All right. I’ve heard it said… I can’t remember the source to credit, unfortunately, but I’ve heard serverless described as being “like using a ride-sharing service like Uber or Lyft” or whatever. You can be carless and not own a car, but that doesn’t mean you never use a car.

Chris: Yeah, it doesn’t mean cars don’t exist. Mm, that’s nice.

Drew: You just summon one when you need it, but at the same time, you’re not paying the upfront purchase cost of a car. You’re not paying maintenance or fuel or-

Chris: Right, and the pricing makes sense, too, right? That’s nice. That’s a nice analogy, I think. And then, because it’s at the CDN level too, it just intercepts HTTP requests that are already happening, which means you don’t ask it… you don’t send a request to it and it sends a request back. It’s just happening during the request naturally, which also makes it feel less server-y. I don’t know, it’s interesting. It’s interesting for sure. So that’s a big deal, though, that you brought up the pricing thing. That you only pay for what you use. That’s significant too, because… let’s say, you’re a back-end dev, who’s used to spinning up servers their whole life. And they run the costs, “I need this kind of server with this kind of memory and this kind of CPU and these kind of specs. And this is how much it’s going to cost.” Serverless comes along and chops the head off of that pricing.

Chris: So, even if you’re a back-end dev who just doesn’t like this that much, that they’re just not into it, like your skill set is just what it is over the years, you compare the price and you’re like, “What? I could be paying 1% of what I was paying before?” You are not allowed to not care about that, right? If you’re this back-end dev that’s paying a hundred times more for their service than they need to be paying, you’re just kind of bad at your job then. Sorry to say. This has come along and this has shattered pricing in a lot of ways. You have to care about that. And it’s kind of cool that somebody else is… It’s not like you don’t have to worry about security at all, but it’s not your server. You don’t have… your lambda or cloud function, or your worker, or whatever, isn’t sitting on a server that’s right next to some really sensitive data on your own network. It’s not right next to your database.

Chris: If somebody writes code that somehow tries to eject itself from the worker or the lambda, or whatever, and try to get access to other things in their way, there’s nothing there to get. So the security’s a big deal too, so again, if that’s your job as the server admin, is to deal with the security of this thing. Running it, running certain things in Lambda, you just get some natural security from it, which is great. So, it’s way cheaper. It’s way more secure. It encourages these small modular architecture, which can be a good idea. It seems to be domino after domino of good ideas here. That’s why it’s notable. You know?

Drew: Yeah, I mean, traditionally with a server based architecture that we’ve been running for decades on the web, you have a web server that you run yourself. It holds your front-end code, your back-end code, your database and everything. Then you need to maintain that and keep it running and pay the bills, and even if it’s not being used, it’s there clocking up bills. The user would make a request and it would build all that HTML query stuff from the database, send it all down the line to the browser. That process works. It’s how loads of things are built. It’s probably the majority of how the web is built. It’s how things like WordPress work. Is this really a problem that we need to solve? I mean, we’ve talked about costs a little bit. What are the other sort of problems with that, that we’re… that we need to address, and that serverless might help us with?

Chris: Yeah, the problems with the old school approach. Yeah, I don’t know, maybe there isn’t any. I mean, I’m not saying the whole web needs to change their whole… the whole thing overnight. I don’t know. Maybe it doesn’t really, but I think it opens up doors. It just seems like, when good ideas arrive like this, they just slowly change how the web operates at all. So, if there’s some CMS that is built in some way that expects a database to be there, it means that maybe the hosts of the future will start leveraging this in interesting ways. Maybe it feels to you like it’s still just a traditional server, but the hosts themselves have farmed it out, how they operate, to serverless architectures. So you don’t even really know that that’s happening, but they’ve found a way to slash their costs by hosting the stuff that you need in serverless ways. Maybe yeah don’t even need to care as a developer, but at a meta level, that’s what’s happening. Maybe. I don’t know.

Chris: It also doesn’t mean that… Databases are still there. If it turns out that architecturally having a relational database is the correct way to store that data, great. I mention that because this world of Serverless is kind of growing up at the same time that JAMstack is. And JAMstack is this architecture that’s, “You should be serving your website off of static hosts, that run nothing at all except for…” They’re like little CDNs. They’re like, “I can do nothing. I don’t run PHP. I don’t run Ruby. I run nothing. I run on a tiny little web server that’s just designed to serve static files only.”

Chris: “And then, if you need to do more than that, if you need to pull data from a relational database, then please do it at some other time, not at the server time. You can either do it in a build process ahead of time, and pull that stuff out of the database, pre-build static files and I’ll serve those, or do it at runtime.” Meaning you get this shell of a document, and then it makes a JavaScript request to get some data and prefills it then. So you do it ahead of time or after time, but it doesn’t mean, “Don’t use a relational database.” It just means, “Don’t have the server generate it at the time of the request of the document,” which is a… I don’t know, it’s a little bit of a paradigm shift.

Chris: It’s not just JAMstack either. We’re also living in the time of JavaScript frameworks. We’re living in a time where it’s starting to be a little more expected that the way that a JavaScript application boots up, is that it mounts some components, and as those components mount, it asks for the data that it needs. And so, it can be kind of a natural fit for something like a React website to be like, “Well, I’ll just hit a serverless function to cough up the data that it needs. It hits some JSON API essentially. I get the JSON data that I need and I construct myself out of that data, and then I render onto the page.” Now, whether that’s good or bad for the web, it’s like, “I don’t know. Too bad. Ship has sailed. That’s how a lot of people are building sites.” It’s just client rendered things. So, serverless and modern JavaScript kind of go hand in hand.

Drew: I suppose you don’t have to wholesale… be looking at one architecture or another. There’s an area in the middle where parts of an infrastructure might be more traditional and parts could be serverless, I’m guessing?

Chris: Yeah. Well, they’re trying to tell you that anyway. Anybody that wants to sell you any part of their architecture is like, “You don’t have to buy in all right now. Just do it a little bit.” Because of course, they want you to dip your toe into whatever they’re selling, because once you dip the toe, the chances that you splash yourself into the pool is a lot higher. So, I think that… it’s not a lie, though, necessarily, although I find a little less luck in… I don’t want my stack to be a little bit of everything. I think there’s some technical death there that I don’t always want to swallow.

Drew: Mm (affirmative).

Chris: But it’s possible to do. I think the most quoted one is… let’s say I have a site that has an eCommerce element to it, which means… and let’s say large scale eCommerce, so 10,000 products or something, that this JAMstack architecture hasn’t gotten to the point where that’s always particularly efficient to rebuild that statically. So, the thinking goes, “Then don’t.” Let that part kind of hydrate naturally with… hit serverless functions and get the data that it needs, and do all that. But the rest of the site, which isn’t… there’s not as many pages, there’s not as much data, you could kind of pre-render or whatever. So a little bit of both.

Drew: Of course, plenty of people are dealing with legacy systems that… some old database thing that was built in the 2000s that they may be able to stick a sort of JSON API layer on top of…

Chris: Yeah.

Drew: … and build something more modern, and perhaps serverless, and then still interact with those legacy systems by sort of gluing it altogether in a weird way.

Chris: Yeah. I like that though, isn’t it? Aren’t… most websites already exist. How many of us are totally green-fielding websites? Most of us work on some crap that already exists that needs to be dragged into the future for some reason, because I don’t know, developers want to work faster, or you can’t hire anybody in COBOL anymore, or whatever the story is. You know?

Drew: So terminology wise, we’re talking about JAMstack which is this methodology of running a code pretty much in the browser, serving it from a CDN. So, not having anything dynamic on the server. And then when we talk about serverless, we’re talking about those small bits of functionality that run on their server somewhere else. Is that right? That we were talking about these cloud function kind of-

Chris: Yeah, I mean, they just happen to be both kind of hot ideas right now. So it’s kind of easy to talk about one and talk about the other. But they don’t necessarily need to be together. You could run a JAMstack site that has nothing to do with serverless anything. You’re just doing it, you just pre-build the site and run it, and you can use serverless without having to care about JAMstack. In fact, CodePen does nothing JAMstack at all. Not that we want to talk about CodePen necessarily, but it’s a Ruby on Rails app. It runs on a whole bunch of AWS EC2 instances and a variety of other architecture to make it happen. But we use serverless stuff whenever we can for whatever we can, because it’s cheap and secure, and just a nice way to work. So, no JAMstack in use at all but serverless all over the place.

Drew: That’s quite interesting. What sort of tasks are you putting serverless to on CodePen?

Chris: Well, there’s a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… the point of CodePen is that you write each HTML, CSS and JavaScript in the browser and it renders it in front of you, right? But you can pick pre-processor languages as well. Let’s say you like Sass. You turn Sass on in the CSS, and you write Sass. Well, something has to process the Sass. These days, Sass is written in Dart or something.

Chris: Theoretically, you could do that in the client. But these libraries that do pre-processing are pretty big. I don’t think I want to ship the entire Sass library to you, just to run that thing. I don’t want to… it’s just not, that’s not the right architecture for this necessarily. Maybe it is down the road, I mean, we could talk about offline crap, yada, yada, Web Workers. There’s a million architectural things we could do. But here’s how it does work now, is there’s a lambda. It processes Sass. It has one tiny, tiny, tiny, little job.

Chris: You send it this blob of Sass and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job and we probably pay for that lambda, like four cents or something. Because lambdas are just incredibly cheap and you can hammer it too. You don’t have to worry about scale. You just hit that thing as much as you want and your bill will be astonishingly cheap. There is moments where serverless starts to cross that line of being too expensive. I don’t know what that is, I’m not that master of stuff like that. But generally, any serverless stuff we do, we basically… all nearly count as free, because it’s that cheap. But there’s one for Sass. There’s one for Less. There’s one for Babbel. There’s one for TypeScript. There’s one for… All those are individual lambdas that we run. Here’s some code, give it to the lambda, it comes back, and we do whatever we’re going to do with it. But we use it for a lot more than that, even recently.

Chris: Here’s an example. Every single Pen on CodePen has a screenshot. That’s kind of cool, right? So, the people make a thing and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. If you share it in Slack, you get the little preview of it. We use it on the website itself to render… instead of an iframe, if we could detect that the Pen isn’t animated, because an iframe’s image is much lighter, so why not use the image? It’s not animated anyway. Just performance gains like that. So each of those screenshots has a URL to it, obviously. And we’ve architected it so that that URL is actually a serverless function. It’s a worker. And so, if that URL gets hit, we can really quickly check if we’ve already taken that screenshot or not.

Chris: That’s actually enabled by CloudFlare Workers, because CloudFlare Workers are not just a serverless function, but they have a data store too. They have this thing called key-value store, so the ID of that, we can just check really quick and it’ll be, “True or false, do you have it or not?” If it’s got it, it serves it. And it serves it over CloudFlare, which is super fast to begin with. And then gives you all this ability too. Because it’s an image CDN, you can say, “Well, serve it in the optimal format. Serve it as these dimensions.” I don’t have to make the image in those dimensions. You just put the dimensions in the URL and it comes back as that size, magically. So that’s really nice. If it doesn’t have it, it asks another serverless function to make it really quick. So it’ll make it and then it’ll put it in a bucket somewhere… because you have to have a origin for the image, right? You have to actually host it somewhere usually. So we put it in an S3 bucket real quick and then serve it.

Chris: So there’s no queuing server, there’s no nothing. It’s like serverless functions manage the creation, storage and serving of these images. And there’s like 50 million or 80 million of them or something. It’s a lot, so it handles that as scale pretty nicely. We just don’t even touch it. It just happens. It all happens super fast. Super nice.

Drew: I guess it… well, a serverless function is ideally going to suit a task that needs very little knowledge of state of things. I mean, you mentioned CloudFlare’s ability to store key-value pairs to see if you’ve got something cached already or not.

Chris: Yeah. That’s what they’re trying to solve, though, with those. Those key-value pairs, is that… I think that traditionally was true. They’re like, “Avoid state in the thing,” because you just can’t count on it. And CloudFlare Workers are being like, “Yeah, actually, you can deal with state, to some degree.” It’s not as fancy as a… I don’t know, it’s key values, so it’s a key in a value. It’s not like a nested, relational fancy thing. So there’s probably some limits to that. But this is baby days for this. I think that stuff’s going to evolve to be more powerful, so you do have some ability to do some state-like stuff.

Drew: And sometimes the limitation, that sort of limited ability to maintain state, or the fact that you have no… you want to maintain no state at all, kind of pushes you into an architecture that gives you this sort of… Well, when we talk about the software philosophy of “Small Pieces Loosely Joined”, don’t we?

Chris: Mm (affirmative).

Drew: Where each little component does one thing and does it well. And doesn’t really know about the rest of the ecosystem around it. And it seems that really applies to this concept of serverless functions. Do you agree?

Chris: Yeah. I think you could have a philosophical debate whether that’s a good idea or not. You know? I think some people like the monolith, as it were. I think there’s possible… there’s ways to overdo this and to make too many small parts that are too hard to test altogether. It’s nice to have a test that’s like, “Oh, I wonder if my Sass function is working. Well, let’s just write a little test for it and make sure that it is.” But let’s say, what matters to the user is some string of seven of those. How do you test all seven of them together? I think that story gets a little more complicated. I don’t know how to speak super intelligently to all that stuff, but I know that it’s not necessarily that, if you roll with all serverless functions that’s automatically a better architecture than any other architecture. I like it. It reasons out to me nicely, but I don’t know that it’s the end-all be-all of all architectures. You know?

Drew: To me, it feels extremely web-like, in that… this is exactly how HTML works, isn’t it? You deliver some HTML and the browser will then go and fetch your images and fetch your JavaScript and fetch your CSS. It seems like it’s an expansion of that –

Chris: It’s nice.

Drew: … sort of idea. But, one thing we know about the web, is it’s designed to be resilient because network’s fragile.

Chris: Mm (affirmative).

Drew: How robust is the sort of serverless approach? What happens if something… if one of those small pieces goes away?

Chris: That would be very bad. You know? It would be a disaster. Your site would go down just like any other server, if it happens to go down, I guess.

Drew: Are there ways to mitigate that, that are particularly –

Chris: I don’t know.

Drew: … suited to this sort of approach, that you’ve come across?

Chris: Maybe. I mean, like I said, a really super fancy robust thing might be like… let’s say you visit CodePen and let’s say that there’s a JavaScript implementation of Sass and we noticed that you’re on a fairly fast network and that you’re idle right now. Maybe we’ll go grab that JavaScript and we’ll throw it in a service worker. Then, if we detect that the lambda fails, or something, or that you have this thing installed already, then we’ll hit the service worker instead of the lambda, and service workers are able to work offline. So, that’s kind of nice too. That’s interesting. I mean, they are the same language-ish. Service workers are JavaScript and a lot of Cloud functions are JavaScript, so there’s some… I think that’s a possibility, although that… it’s just, that’s some serious technical that… It just scares me to have this chunk of JavaScript that you’ve delivered to how many thousands of user, that you don’t necessarily know what they have, and what version of it they have. Eww, but that’s just my own scarediness. I’m sure some people have done a good job with that type of thing.

Chris: I actually don’t know. Maybe you know some strategies that I don’t, on resiliency of serverless.

Drew: I guess there’s a failure mode, a style of failure, that could happen with serverless functions, where you run a function once and it fails, and you can run it a second time immediately afterwards and it would succeed, because it might hit a completely different server. Or whatever the problem was, when that run may not exist on a second request. The issues of an entire host being down is one thing, but maybe there are… you have individual problems with the machine. You have a particular server where its memory has gone bad, and it’s throwing a load of errors, and the first time you hit it, it’s going to fail. Second time, that problem might have been rooted around.

Chris: Companies that tend to offer this technology, you have to trust them, but they also happen to be the type of companies that… this is their pride. This is the reason why people use them is because they’re reliable. I’m sure people could point to some AWS outages of the past, but they tend to be a little rare, and not super common. If you were hosting your own crap, I bet they got you beat from an SLA percentage kind of level. You know? So it’s not like, “Don’t build in a resilient way,” but generally the type of companies that offer these things are pretty damn reliable. The chances of you going down because you screwed up that function are a lot higher than because their architecture is failing.

Drew: I suppose, I mean, just like anything where you’re using an API or something that can fail, is just making sure you structure your code to cope with that failure mode, and to know what happens next, rather than just throwing up an error to the user, or just dying, or what have you. It’s being aware of that and asking the user to try again. Or trying again yourself, or something.

Chris: Yeah, I like that idea of trying more than once, rather than just being, “Oh no. Fail. Abort.” “I don’t know, why don’t you try again there, buddy?”

Drew: So I mean, when it comes to testing and development of serverless functions, sort of cloud functions, is that something that can be done locally? Does it have to be done in the cloud? Are there ways to manage that?

Chris: I think there are some ways. I don’t know if the story is as awesome. It’s still a relatively new concept, so I think that that gets better and better. But from what I know, for one thing, you’re writing a fairly normal Node function. Assuming you’re using JavaScript to do this, and I know that on Lambda specifically, they support all kinds of stuff. You can write a fricking PHP Cloud Function. You can write a Ruby Cloud Function. So, I know I’m specifically talking about JavaScript, because I have a feeling that most of these things are JavaScript. Even no matter what language it is, I mean, you can go to your command line locally and execute the thing. Some of that testing is… you just test it like you would any other code. You just call the function locally and see if it works.

Chris: It’s a little different story when you’re talking about an HTTP request to it, that’s the thing that you’re trying to test. Does it respond to the request properly? And does it return the stuff properly? I don’t know. The network might get involved there. So you might want to write tests at that level. That’s fine. I don’t know. What is the normal story there? You spin up some kind of local server or something that serves it. Use Postman, I don’t know. But there’s… Frameworks try to help too. I know that the serverless “.com”, which is just terribly confusing, but there’s literally a company called Serverless and they make a framework for writing the serverless functions that helps you deploy them.

Chris: So if you like NPM install serverless, you get their framework. And it’s widely regarded as very good, because it’s just very helpful, but they don’t have their own cloud or whatever. You write these and then it helps you get them to a real lambda. Or it might work with multiple cloud providers. I don’t even know these days, but their purpose of existing is to make the deployment story easier. I don’t know what… AWS is not renowned for their simplicity. You know? There’s all this world of tooling to help you use AWS and they’re one of them.

Chris: They have some kind of paid product. I don’t even know what it is exactly. I think one of the things they do is… the purpose of using them is for testing, is to have a dev environment that’s for testing your serverless function.

Drew: Yeah, because I guess, that is quite a big part of the workflow, isn’t it? If you’ve written your JavaScript function, you’ve tested it locally, you know it’s going to do the job. How do you actually pick which provider it’s going to go into and how do you get it onto that service? Now, I mean, that’s a minefield, isn’t it?

Chris: Yeah. I mean, if you want to use no tooling at all, I think they have a really… like AWS, specifically, has a really rudimentary GUI for the thing. You can paste the code in there and hit save and be like, “Okay, I guess it’s live now.” That’s not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don’t hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.

Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that’s like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you’re using their little Wrangler tool thing to do that. Also, I think the way we did it was… it’s also a little dangerous. The second you put it live, it’s affecting all your web traffic. It’s kind of a big deal. You don’t want to screw up a worker. You know? You can spin up a dev worker that’s at a fake subdomain, and because it’s CloudFlare, you can… CloudFlare can just make a subdomain anyway. I don’t know. It’s just kind of a nice way to do a… as you’re only affecting sub-domain traffic, not your main traffic yet. But the subdomain’s just a mirror of a production anyway, so that’s kind of a… that’s a testing story there.

Chris: It brings up an interesting thing, though, to me. It’s like… imagine you have two websites. One of them is… for us it’s like a Ruby on Rails app. Whatever. It’s a thing. But we don’t have a CMS for that. That’s just like… it’s not a CMS, really. I think there’s probably Ruby CMSs, but there’s not any renowned ones. You know? It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you’ve lived in the CMS market for a long time –

Drew: Absolutely.

Chris: … so you know how this goes. Let’s say you want to manage your sites in Perch or whatever, because it’s a good CMS and that’s the proper thing to use to build the kind of pages you want to build. But you don’t want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don’t know, there’s any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There’s an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That’s fine, I guess, but now you’re in a client side rendered page. It’s going to be slow. It’s going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It’s just a bad story for SEO. It’s not very resilient, because who knows what’s going to happen in the network. It’s not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.

Chris: You could also do it on the server side, though. Let’s say you had… Ruby is capable of granting a network request too, but that’s even scarier because then if something fails on the network, the whole page could die or something. It’s like a nervous thing. I don’t love doing that either. But we did this just recently with a worker, in that we… because the worker’s JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn’t. It all happened at the… on the edge, at the worker level, at the serverless level.

Chris: So it’s kind of cool. I think you can imagine a fetch request on the browser probably takes, I don’t know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. They do. Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It’s not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it’s kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there’s a cool future to that.

Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I’m sort of thinking about how to architect things. Say I’ve got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who’s going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?

Chris: Mm (affirmative). That’s a fascinating question. I’d probably have an architect function or something. One function would be the one that’s in charge of orchestrating the rest of them. It doesn’t have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that’s somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that’s probably generally a good idea-

Drew: Yeah, that sounds smart. Yep.

Chris: But I think that’s the ultimate thing. You get a bunch of server nerds talking, they’ll talk about the different approaches to that exact idea in 10 different ways.

Drew: Yeah. No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you’re using APIs where you’ve got secret information. You’ve got API keys or something that you don’t want to live in the client. Because I don’t know, maybe this florist API charges you $ 100 dollars every time flower bomb someone.

Chris: Easily.

Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That’s a viable way to work?

Chris: Yeah, yeah. I think so. I mean, secrets are, I don’t know, they’re interesting. They’re a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It’s kind of like, you could just put your API key right in the serverless function, because it’s just going to a server, right? You don’t even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there’s probably a source control along the way. It’s probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can’t put your API key in there, because then it’s in the repo, and you don’t put your API keys in repos. That’s good advice. Now there’s stuff. We’ve just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it’s encrypted by the time anybody’s looking at that file.

Chris: But only locally they’re decrypted, so they’re useful. So it’s just kind of an interesting idea. I don’t know if that helps in this case, but usually, cloud providers of these things have a web interface that’s, “Put your API keys here, and we’ll make them available at runtime of that function.” Then it kind of locks… it doesn’t lock you in forever but it kind of is… it’s not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.

Drew: Yeah, I think that’s the way that Netlify manage it.

Chris: They all do, you know?

Drew: Yeah. You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.

Chris: Yeah, right. But then you got to leave… I don’t know, it’s not that big of a deal. I’m not saying they’re doing anything nefarious or anything. How do you deal with those secrets? Well, it’s a hard problem. So they kind of booted it to, I don’t know, “Just put them in this input field and we’ll take care of it for you, don’t worry about it.”

Drew: Is there anything that you’ve seen that stands out as an obvious case for things that you can do with serverless, that you just couldn’t do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?

Chris: It’s probably mostly that. I don’t know that it unlocks any possibility that you just absolutely couldn’t run it any other way. Yeah, I think that’s a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don’t know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That’s the one I want to use. I think that’s kind of cool. You know? That you can kind of benefit from other people’s experience in that way. I think that will happen more and more.

Drew: I guess it’s the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.

Chris: Yeah, yeah. I think so, I think that’s… because there’s moments like… you don’t have to be tremendously skilled to know what’s appropriate and what’s not for a website. Like, I did a little tutorial the other week, where there was this glitch uses these… when you save a glitch, they give you a slug for your thing that you built, that’s, “Whiskey, tango, foxtrot. 1,000.” It’s like a clever little thing. The chances of it being unique are super high, because I think they even append a number to it or something too. But they end up being these fun little things. They open source their library that has all those words in it, but it’s like a hundred, thousands of words. The file is huge. You know? It’s megabytes large of just a dictionary of words. You probably learn in your first year of development, “Don’t ship a JavaScript file that’s megabytes of a dictionary.” That’s not a good thing to ship. You know? But Node doesn’t care. You can ship hundreds of them. It’s irrelevant to the speed on a server.

Drew: Yeah.

Chris: It doesn’t matter on a server. So, I could be like, “Hmm, well, I’ll just do it in Node then.” I’ll have a statement that says, “Words equal require words,” or whatever, and a note at the top, “Have it randomize a number. Pull it out of the array and return it.” So that serverless function is eight lines of code with a packaged@JSON that pulls in this open source library. And then my front-end code, there’s a URL to the serverless function. It hits that URL. The URL returns one word or a group of words or whatever. You build your own little API for it. And now, I have a really kind of nice, efficient thing. What was nice about that is, it’s so simple. I’m not worried about the security of it. I don’t… you know?

Chris: It’s just… a very average or beginner JavaScript developer, I think, can pull that off, which is cool. That’s an enabling thing that they didn’t have before. Before, they were like, “Well, here’s a 2MB array of words.” “Oh, I can’t ship that to the client.” “Oh, you’ll just shut down then.” You might hit this wall that’s like, “I just can’t do that part then. I need to ask somebody else to help me with that or just not do it or pick more boring slugs or some…” It’s just, you have to go some other way that is a wall to you, because you couldn’t do it. And now, you’re, “Oh, well, I’ll just…” Instead of having that in my script slash, or in my source slash scripts folder, I’ll put it in my functions folder instead.

Chris: You kind of like moved the script from one folder to the other. And that one happens to get deployed as a serverless function instead. How cool is that? You know? You’re using the same exact skill set, almost. There’s still some rough edges to it, but it’s pretty close.

Drew: It’s super cool. You’ve put together a sort of little micro site all about these ideas, haven’t you?

Chris: Yeah. I was a little early to the game. I was just working on it today, though, because… it gets pull requests. The idea… well, it’s at serverless.css-tricks.com and… there’s a dash in CSS-Tricks, by the way. So it’s a subdomain of CSS-Tricks, and I built it serverlessly too, so this is… CSS-Tricks is like a WordPress site, but this is a static site generator site. All the content of it is in the GitHub repo, which is open-source. So if you want to change the content of the site, you can just submit a poll request, which is nice because there’s been a hundred or so of those over time. But I built all the original content.

Drew: It’s a super useful place, because it lists… If you’re thinking, “Right, I want to get started with serverless functions,” it lists all the providers who you could try it and…

Chris: That’s all it is, pretty much, is lists of technology. Yeah.

Drew: Which is great, because otherwise, you’re just Googling for whatever and you don’t know what you’re finding. Yeah, it’s lists of API providers that help you do these sorts of things.

Chris: Forms is one example of that, because… so the minute that you choose to… let’s say, you’re going to go JAMstack, which I know that’s not necessarily the point of this, but you see how hand in hand they are. All of a sudden, you don’t have a PHP file or whatever to process that form with. How do you do forms on a JAMstack site? Well, there’s any number of ways to do it. Everybody and their sister wants to help you solve that problem, apparently. So I think if I was the inventor of the word JAMstack, so they try to help you naturally, but you don’t have to use them.

Chris: In fact, I was so surprised putting this site together. Let’s see. There’s six, nine, twelve, fifteen, eighteen, twenty one, twenty two services out there, that want to help you serverlessly process your forms on this site right now. If you want to be the 23rd, you’re welcome to it, but you have some competition out there. So the idea behind this is that you write a form in HTML, like literally a form element. And then the action attribute of the form, it can’t point anywhere internally, because there’s nothing to point to. You can’t process, so it points externally. It points to whatever they want you to point it to. They’ll process the form and then they tend to do things that you’d expect them to, like send an email notification. Or send a Slack thing. Or then send it to Zapier and Zapier will send it somewhere else. They all have slightly different feature sets and pricing and things, but they’re all trying to solve that problem for you, like, “You don’t want to process your own forms? No problem. We’ll process it for you.”

Drew: Yeah, it’s a super useful resource. I’d really recommend everyone check it out. It’s serverless.css-tricks.com. So, I’ve been learning all about serverless. What have you been learning about lately, Chris?

Chris: Well, I’m still very much in this world too and learning about serverless stuff. I had an idea to… I used to play this online role playing game ages ago. I just recently discovered that it’s still alive. It’s a text based medieval fantasy kind of game. I played it when AOL was a thing, because AOL wanted to have these games that you had to be logged on to play it, because they wanted you to spend hours and hours on AOL, so they could send you these huge bills, which was, I’m sure, why they did so well at some point.

Drew: So billing by the second. Yeah.

Chris: Yeah. So games was big for them. If they could get you playing games with other people on there. So this game kind of… it didn’t debut there, but it moved to AOL, because I’m sure they got a juicy deal for it, but it was so… I mean, it’s just, couldn’t possibly be nerdier. You’re a dwarven mage and you get rune staff from your leather sheath. And you type commands into it like a terminal. Then the game responds to you. I played that game for a very long time. I was very into it. I got into the community of it and the spirit of it. It was kind of a… it was like I was just alone by myself at my computer, but yet I look back on that time in my life, and be like, “That was a wonderful time in my life.” I was really… I just liked the people and the game and all that. But then I grew up and stopped playing it, because life happens to you.

Chris: I only found out recently, because somebody started doing a podcast about it again… I don’t know how I came across it, but I just did. I was like, “This game is alive and well in today’s world, are you kidding me? This text based thing.” And I was more than happy to reactivate and get my old characters back and play it. But only to find out that the clients that they have you download for this game, haven’t evolved at all. They are awful. They almost assume that you’re using Windows. There’s just these terribly cheesy poorly rendering… and it’s text based, you think it’d at least have nice typography. No. So I’m like, “I could be involved. I could write a client for this game. Put beautiful typography in it.” Just modernize the thing, and I think the players of the game would appreciate it, but it felt overwhelming to me. “How can I do it?” But I find some open source projects. One of them is like… you can play the game through an actual terminal window, and it uses some open source libs to kind of make a GUI out of a terminal window.

Drew: Really?

Chris: I don’t know. So that was kind of cool. I was like, “If they wrote that, there must be code in there to how to connect to the game and get it all going and stuff. So at least I have some starter code.” I was trying to go along the app, “Maybe I’ll do it in Flutter or something,” so the final product app would work on mobile phones and, “I could really modernize this thing.” But then I got overwhelmed. I was like, “Ah, this is too big a… I can’t. I’m busy.” But I found another person who had the same idea and they were way further along with it, so I could just contribute on a design level. And it’s been really fun to work on, but I’ve been learning a lot too, because it’s rare for me to jump into a project that’s somebody else’s baby, and I’m just contributing to a little bit, and that has totally different technology choices than I would have ever picked.

Chris: It’s an Electron app. They picked that, which is also kind of a cool way to go too, because it’s my web skills… so I’m not learning anything too weird, and it’s cross-platform, which is great. So, I’ve been learning a lot about Electron. I think it’s fun.

Drew: That’s fascinating. It’s always amazing how little side projects and things that we do for fun, end up being the place where we sometimes learn the most. And learn skills that can then feed back into our sort of daily work.

Chris: That’s the only way I learn things. I’m dragged into something that… I was like, “They’re not…” It’s rendered with a JavaScript library called Mithril, which is… I don’t know if you’ve ever heard of it, but it’s weird. It’s not… it’s almost like writing React without JSX. You have to “create element” and do all these… but it’s supposed to benchmark way better than it… And it actually kind of matters because in this text based game, the text is just flying. There’s a lot of data manipulation, which is like… you’d think this text based game would be so easy for a browser window to run, but it’s actually kind of not. There’s so much data manipulation happening, that you really have to be really… we have to be conscientious about the speed of the rendering. You know?

Drew: That’s fascinating-

Chris: Pretty cool.

Drew: Yeah. If you, dear listener, would like to hear more from Chris, you can find him on Twitter, where he’s @chriscoyier. Of course, CSS-Tricks can be found at css-tricks.com and CodePen at codepen.io. But most of all, I recommend that you subscribe to the ShopTalk Show podcast if you haven’t already done so, at shoptalkshow.com. Thanks for joining us today, Chris. Do you have any parting words?

Chris: Smashingpodcast.com. I hope that’s the real URL.

Articles on Smashing Magazine — For Web Designers And Developers

chris-ferdinandi-200x200-opt
08 Sep

Smashing Podcast Episode 21 With Chris Ferdinandi: Are Modern Best Practices Bad For The Web?

by TBSCategories: News

Today, we’re asking if modern best practices are bad for the web? Are modern frameworks taking us down the wrong path? I speak to Lean Web expert Chris Ferdinandi to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: He’s the author of Vanilla JS Pocket Guide Series, creator of the Vanilla JS Academy Training Program, and host of the Vanilla JS Podcast. He’s developed a Tips newsletter, it’s read by nearly 10,000 developers each weekday. He’s taught developers at organizations like Chobani and The Boston Globe. And his JavaScript plugins have been used by organizations like Apple and Harvard Business School. Most of all, he loves to help people learn Vanilla JavaScript. So we know he’d rather pick Vanilla JavaScript over a framework, but did you know he was once picked out in a police lineup as being the person least likely to have committed the crime? My Smashing friends, please welcome Chris Ferdinandi. Hello, Chris. How are you?

Chris Ferdinandi: Oh, I’m smashing. Thanks for having me.

Drew: I wanted to talk to you today about this concept of a Lean Web, which something of a passion for you, isn’t it?

Chris: Yes, very much so.

Drew: Why don’t you set the scene for us? When we talk about a Lean Web, what is the problem we are trying to solve?

Chris: Yeah, great question. Just as a caveat for all the listeners, this episode might get a little old man yells at cloud. I’m going to try to avoid that. When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. I’ve come to believe that a lot of what we think of as best practices today might actually be making the web worse.

Chris: The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I’m sorry, not the developer experience. The user experience rather, over the developer experience, and the ease of building things from a team perspective, which is what I think where we put a lot of focus today and as we’ll probably get into in our conversation.

Chris: I’ve actually come to find that a lot of these things we think of as improving the developer experience do so for a subset of developers, but not necessarily everybody who’s working on the thing you’re building. So there’s a whole bunch of issues with that too, that we can dig into. But really, the Lean Web is about focusing on simplicity and performance for the user and really prioritizing or putting the focus on the people who use the things we make rather than us, the people who are making it.

Drew: As the web matures as a development platform, there seems to be this ever increasing drive towards specialization.

Chris: Yes.

Drew: People who used to cover Full Stack, and then we split into front-end and back-end. And then that front-end split into people who do CSS or JavaScript development. And then increasingly within JavaScript, it becomes more specialized. Somebody might consider themselves and market themselves as a React developer or an Angular developer, and their entire identity and outlook is based around a particular framework that they are highly skilled in. Is this dependency on frameworks, the core of our work on the web, a bad thing?

Chris: It’s nuanced. I used to be very strongly in the yes, always camp. I think broadly, I still feel like yes, our obsession as an industry with frameworks and tools in general really, is potentially a little bit to our detriment. I don’t think frameworks are inherently bad. I think they’re useful for a very narrow subset of use cases. And we end up using them for almost everything, including lots of situations where they’re really not necessarily the best choice for you or for the project.

Chris: When I think about a lot of the issues that we have on the web today, the core of those issues really starts with our over-reliance on frameworks. Everything else that comes after that is in many ways, because we throw so much not just frameworks which is JavaScript in general, at the web. I say that as someone who professionally teaches people how to write and use JavaScript. That’s how I make my money. And I’m here saying that I think we use too much JavaScript, which is sometimes a little bit of an odd thing.

Drew: In the time before the big frameworks sprouted up, we used to build user interfaces and things with jQuery or whatever. And then frameworks came along and they gave us more of this concept of a state-based UI.

Chris: Yes.

Drew: Now, that’s a fairly complex bit of engineering that you’re required to get in place. Does working with less JavaScript exclude using something like that, or do you have to re-implement it yourself? Are you just creating a loaded boilerplate?

Chris: A lot of it depends on what you’re doing. If you have a non-changing interface, you can build a state-based UI with… I don’t know, maybe a dozen or so lines of code. If you have a non-changing interface, I would honestly probably say state-based UI. It’s not necessarily the right approach. There’s probably other things you can do instead. Think of static site generators, some pre-rendered markup, even an old-school WordPress or PHP driven site.

Chris: But where this starts to get interesting is when you get into more dynamic and interactive interfaces. Not just apps. I know people love to draw this line between websites and apps, and I think there’s this weird blend between the two of them and the line is not always as clear. When you start to get into more the user does stuff, something changes. State-based UI becomes a little bit more important. But you still don’t need tons of code to make that happen.

Chris: I look at something like React or Vue, which are absolutely amazing pieces of engineering. I don’t want to take away from the people who work on those. I ended up as a learning exercise, building my own mini-framework just to get a better sense for how these things work under the hood. It is really hard to account for all of the different moving pieces. So I have tremendous respect for the people who build and work on these tools. But React and Vue are both about 30 kilobytes after minifying and gzipping. So once you unpack them, they’re substantially bigger than that.

Chris: Not all of it, but a good chunk of that weight is devoted to this thing called the virtual DOM. There are alternatives that use similar APIs or approaches. For React, you have Preact, which is 2.5 kilobytes or about 3 kilobytes instead of 30. It’s a tenth of the size. For Vue, you have Alpine JS instead, which is about 7 kilobytes. Still, substantially smaller. The big difference between those and their big brother counterparts, is that they’ve shed the virtual DOM. They may drop a method or two. But generally, it’s the same approach and the same kind of API in the way of working with code, and they’re substantially smaller.

Chris: I think a lot of the tools we use are potentially overpowered for the things we’re trying to do. If you need a state-based UI and you need reactive data and these dynamic interfaces, that’s great. I think one of the big things I try and talk about today is not… never use tools. For me, Vanilla JS is not you’re handwriting every single line of code and every single project you do. That’s madness. I couldn’t do that, I don’t do that. But it’s being more selective about the tools we use. We always go for the multi-tool, the Swiss Army knife that has all these things in it. And sometimes, all you really need is a pair of scissors. You don’t need all the other stuff, but we have it anyways.

Chris: Which is a really long way to… I’m sorry, of answering your question. Which is sometimes it’s more code than you could or would want to write yourself, but it’s not nearly as much code as I think we think it requires. When I say you don’t need a framework, I get a lot of push-back around this idea that, “Well, if you don’t use a framework, you’re basically writing your own.” Then that comes with its own problems. I think there’s a place in between using React or Vue and writing your own framework, and it’s maybe picking something that’s a little bit smaller. There are sometimes reasons where writing your own framework might actually be the right call, depending on what you’re trying to do. It’s all very fluid and subjective.

Drew: It’s quite interesting that as a learning exercise, you implemented your own state-based framework. I remember in the past, I used to think that every time I reached for a library or something, I liked to think that I could implement it myself.

Chris: Sure, sure.

Drew: But reaching for the library saved me the hassle of doing that. I knew if I had to write this code myself, I knew what approach I’d take to do it. And that was true all the way up to using things like jQuery and things. These days, I think if I had to write my own version of Vue or React, I have almost no idea what’s happening now in that library, in all that code.

Drew: For those of us who are not familiar, when you say something like Preact drops the virtual DOM and makes everything a lot smaller, what’s that virtual DOM giving us?

Chris: To answer that question, I want to take just a slight step back. One of the nicest things that frameworks and other state-based libraries give you is DOM diffing. If you’re not really updating the UI that much, you could get by with saying, “Here’s a string of what the markup is supposed to look like. In HTML, I’ll just put all this markup in this element.” When you need to change something, you do it again. That is a little expensive for browsers, because it triggers a repaint.

Chris: But I think potentially more importantly than that, one of the issues with doing that is that you have any sort of interactive element in there, a form-field, a link that someone has focused on. That focus is lost because the element… even though you have a new thing that looks similar, it’s not the same literal element. So if focus is lost, it can create confusion for people using screen readers. There’s just a whole bunch of problems with that.

Chris: Any state-based UI thing worth its weight is going to implement some for of DOM diffing, where they say, “Here’s what the UI should look like. Here’s what it looks like right now in the DOM. What’s different?” And it’s going to go and change those things. It’s effectively doing the stuff you would do just manually updating the UI yourself, but it’s doing it for you under the hood. So you can just say, “Here’s what I want it to look like.” And then the library or framework figures it out.

Chris: The smaller things like Preact or Alpine, they’re actually doing that directly. They’re converting the string you provide them of what the UI should look like into HTML elements. And then they’re comparing each element to its corresponding piece in the literal DOM. As you end up with UIs that get bigger and bigger and bigger, that can have a performance implication because querying the DOM over and over again becomes expensive. If you want to get a sense for the type of interface where this becomes a problem, right-click and inspect element on the “Favorite” button on Twitter, or the “Like” button on Facebook. And take a look at the nesting of divs that gets you to that element. It’s very, very deep. It’s like a dozen or so divs, nested one inside the other just for that single tweet.

Chris: When you start going that many layers down, it starts to really impact performance. What the virtual DOM does is instead of checking the real DOM every time, it creates an object-based map of what the UI looks like in JavaScript. And then does the same thing for the UI you want to replace the existing one with, and it compares those two. That’s a lot more performance in theory, than doing that in the real DOM. Once it gets a list of the things it needs to change, it just runs off and makes those changes. But it only has to attack the DOM once. It’s not checking every single element, every single time. If you have interfaces like Twitters or Facebooks or QuickBooks or something like that, virtual DOM probably makes a lot of sense.

Chris: The challenge with it is… the difference between Preact and React is 27 kilobytes before you unpack the whole thing into its actual codewave. The raw download and unpacking and compiling time on that alone can add quite a bit of latency to the initial load on a UI. That becomes even more pronounced if your users are on not the latest devices from Apple. Even an Android device from a couple of years ago or a feature phone, or if you have people in developing countries, it’s just really… the time to get going is slower. And then on top of that, the actual interactive time is slower because of the extra abstraction.

Chris: So it’s not just you load it and they’re comparable in speed. Each micro interaction that someone makes and the changes that need to happen can also be slightly slower just because of all that extra code in there. If you have a really, really complex UI with lots of nested elements and lots of data, then the virtual DOM’s performance gains outweigh that extra code weight. But any typical UI for a typical app that most of what I see developers using React or Vue for, the benefit you get from the virtual DOM just isn’t there and they’d be better off. Even if you want to keep the same convenience of React, use Preact. It’s a fraction of the size, it’ll work exactly the same way, and it’ll more performing. This is the kind of thing that I tend to argue for.

Chris: We need to be better about picking the right tool for the job. If you go with an approach like that, if you get to a point where a virtual DOM actually makes sense, it’s much easier to port Preact into React than if you rolled your own. That’s the situation. If you’re really worried about that, you get some future-proofing built in too.

Drew: Some might say, they might make the argument that these frameworks, things like Vue, React are so highly optimized for performance that you get so much benefit there that surely just pairing that with a package manager in a bundler to make sure you’re only sending down the code that you want to. Surely, you are way ahead already just by doing that?

Chris: Yeah. I don’t agree. I don’t really have much more to elaborate on that other than… I guess maybe, but not really. Even with a bundler, you still need that React core. Even with the bundling, that’s still going to be bigger than using something like Preact.

Chris: Drew, I really appreciate you leading the question on this. Because one of the other things I do talk about in my book, The Lean Web, and my talk of the same name, is how these tools… You mentioned the bundling, for example. One of the things we do to get around the performance hit that we take from using all this JavaScript is we throw even more JavaScript at the front-end to account for it. One of the ways we do that is package managers and module bundlers.

Chris: As you alluded to… for those of you who don’t know, these are tools that will… they will compile all of your little individual JavaScript bits into one big file. The newer ones and the more… I don’t want to call them thoughtful. But the newer ones will use a feature called tree shaking, where they get rid of any code that isn’t actually needed. If that code has some dependencies that aren’t used for the thing you’ve actually done, they’ll drop some of that stuff out to make your packages as small as possible. It’s actually not a terrible idea, but it results in this thing I typically call dependency health where you have this really delicate house of cards of dependencies on top of dependencies on top of dependencies.

Chris: Getting your process set up takes time. And anybody who has ever run an NPM install and then discovered that a bunch of dependencies were out of date and had to spend an hour trying to figure out which ones needed to be fixed and oh, it’s actually a dependency in a dependency and you don’t have the ability to go fix it yourself. It’s a whole thing. Maybe it works for you, but I’d rather spend my time not messing around trying to get my dependencies together.

Chris: I’ve started collecting tweets from people where they complain about time wasted on their workflow. One of my favorites, Brad Frost a couple year ago, was talking about the depressing realization that the thing you’ve been slogging through in modern JS could have taken you 10 minutes in jQuery. I’m not really a jQuery fan, but I feel that pain when it comes to working with frameworks.

Chris: The other issue with a lot of these tools is they start to become gatekeepers. I don’t know how much you really want to dive into this or not, Drew. But one of my big push-backs against JS, all the things in a workflow. Especially when you start to then say, “Well, if we’re already using JS for the HTML, why not use it for CSS too?” You start to exclude a lot of really talented people from the development process. It’s just a really big loss for the project for the community as a whole.

Drew: Well, I certainly am… I started picking up React at the beginning of 2020, adding that to my skillset. I’ve been doing it now for nearly seven months. I’ve got to say one part I’m least confident in is setting up the tooling around getting a project started.

Drew: It seems like there’s an awful lot of work to get something to Hello World, and there’s even more that you’ve got to know to get it to be production ready. That has to make development more difficult to get started with if this is being put forward as what you should be doing in 2020 to learn to be a web developer. Somebody coming in new to it is going to have a real problem. It’s going to be a real barrier to entry, isn’t it?

Chris: Absolutely. The other piece here is that JavaScript developers aren’t always the only people working on a code base or contributing in a meaningful way to that code base. The more we make knowing JavaScript a requirement for working with a code base, the less likely those people are to be able to actually participate in the project.

Chris: An example of that, that I like to talk about is WordPress, who has been recently… I shouldn’t say recently at this point. It’s been a couple of years now. But they’ve been shifting their back-end stack more and more to JavaScript, away from PHP, which is not inherently a bad thing. Their new editor, Gutenburg, is built on React.

Chris: In 2018, WordPress’s lead accessibility consultant, Rian Rietveld, whose name I almost certainly butchered… she very publicly resigned from her positioned and documented why in a really detailed article. The core of the problem was that her and her team were tasked with auditing this editor to make sure that it was going to be accessible. WordPress comprises now 30% of the web. Their goal is to democratize publishing, so accessibility is a really important part of that. It should be an important part of any web project. But for them in particular, it is acutely important. Her team’s whole job is to make sure… her team’s whole job was to make sure that this editor would be accessible. But because neither she nor anyone on her team had React experience and because they couldn’t find volunteers in the accessibility community with that experience, it made it really difficult for her and her team to do their work.

Chris: Historically, they could identify errors and then go in and fix them. But with the new React based workflow, they were reduced to identifying bugs and then filing tickets. They got added to a backlog along with all the other feature development requests that the JavaScript developers were working on. A lot of stuff that could have been easily fixed didn’t make it into the first release.

Chris: In May of 2019, about a year after Rian resigned, there was a detailed accessibility audit done on Gutenburg. The full report was 329 pages. The executive summary alone was 34 pages. It documented 91 accessibility related bugs in quite a bit of detail. Many of these were really… I don’t want to call them simple low-hanging fruit, but a lot of them were basic things that Rian’s team could have fixed and it would have freed up the developers to focus on feature development. That’s ultimately what it seems like they ended up doing, was spending a lot of time on feature development and pushing this stuff off til later. But that team is super important to the project, and they suddenly got locked out of the process because of a technical choice.

Chris: Alex Russell is a developer on the Chrome team. He wrote this article a couple of years ago called The Developer Bait and Switch, where he talked about the straw man argument of frameworks. This idea that these tools let you move faster and because of that, you can iterate faster and deliver better experiences. It’s this idea that a better developer experience means a better user experience. I think this is a very clear example of how that argument doesn’t always play out the way people believe it does. It’s a better experience for maybe some people, not for everyone.

Chris: CSS developers, people working on design systems, their ability to create tools that others can use sometimes gets limited by these tool choices too. In my experience, I used to be better at CSS. It’s changed a lot in the last few years and I am nowhere near as good as I used to be. In my experience, the people who are really advanced CSS developers… and I do mean that in the truest sense. People who work on CSS are proper web developers working on a programming language. It’s a very special, or can be a very specialized thing. The people who are exceptionally good at it, in my experience, are not always also very good at JavaScript because you end up diving really deep into one thing and you slide a little bit on some other stuff. Their ability to work with these technologies gets hindered as well, which is too bad because it used to not be the case.

Chris: When the stack was simpler, it was easier for people from multiple disciplines to participate in the development process. I think that’s to the detriment of both the things we build and the community at large, when that’s no longer the case.

Drew: I found recently in a project researching ways to deal with some of the CSS problems, workflow problems, we’re having multiple working on the project and the bundle size increasing and the old CSS never getting removed. It was a React project, so we were looking at some of these CSS in JavaScript approaches to see what would be best for us to use to solve the problems that we had. What became very quickly apparent is there’s not only one solution to do this. There are dozens of different ways you could do this.

Drew: CSS in JS is a general approach, but you might go from one project to the next and it’s completely influenced in a completely different way. Even if you’re a CSS person and you learn a particular approach on a project, those skills may not be transferrable anyway. It’s very difficult to see how somebody should investment too much time in learning that if they’re not particularly comfortable with JavaScript.

Chris: Yeah. The other interesting thing that I think you just got out a little bit is when I talk about this, one of the biggest pieces of push-back I get is that frameworks enforce conventions. You’re going with Vanilla JavaScript, you’ve got this green field-blue sky, you can do anything you want kind of project. With React, there’s a React way to do things.

Chris: But one of the things I have found is that there are Reacty approaches, but there’s not a strict one right way to do things with React. It’s one of the things people love about it. It’s a little bit more flexible, you can do things a couple of different ways if you want. Same with Vue. You can use that HTML based thing where you’ve got your properties right in the HTML and Vue replaces them, but you can also use a more JSX-like templating kind of syntax if you’d prefer.

Chris: I’ve heard multiple folks complain about when they’re learning React, one of the big problems is you Google how to do X in React and you get a dozen articles telling you a dozen different ways that you could do that thing. That’s not to say they don’t put some guardrails on a project. I don’t think it’s as clearcut as, “I’ve chosen a framework. Now this is the way I build with it.” To be honest, I don’t know that that’s necessarily something I’d want either. I don’t think you’d want those tightly confined… some people do, maybe. But if you’re touting that as a benefit, I don’t think it’s quite as pronounced as people sometimes make it out to be.

Chris: You got into an interesting thing though just there, where you were mentioning the CSS that is no longer needed. I think that is one of the legitimately interesting things that something like CSS and JS… or tying your CSS to JavaScript components in some way can get you is if that component drops out, the CSS also in theory, goes away with it. A lot of this to me feels like throwing engineering at people problems. Invariably, you’re still dependent on people somewhere along the line. That’s not to say never use those approaches, but they’re certainly not the only way to get at this problem.

Chris: There are tools you can use to audit your HTML and pull out the styles that aren’t being used even without using CSS and JavaScript. You can write CSS “the old-fashioned way” and still do the linting of unused styles. There are authoring approaches to CSS that give you a CSS in JS-like output and keep your style sheet small without spitting out these gibberish human unreadable class names that you get with CSS and JS sometimes. Like X2354ABC, or just these nonsense words that get spit out.

Chris: This is where I start to get really into the old man yells at cloud kind of thing. I’m really showing my developer age here. But yeah, it’s not necessarily that these things are bad, and they’re built to solve legitimate problems. I sometimes feel like there’s a little bit of a… if it’s good enough for Facebook, it’s good enough for us kind of thing that happens with these. Well, Facebook uses this tool. If we’re a real engineering program… team, department, organization, we should too. I don’t necessarily think that’s the right way to think about it. It’s because Facebook deals with problems that you don’t, and vice-versa. The size and scale of what they work on is just different, and that’s okay.

Drew: Exactly. I see some of these things like CSS and JavaScript to be almost like a polyfill. We’ve got legitimate problems, we need a way to solve it. The technology isn’t providing us a way to solve it yet. Maybe whilst we wait for the web platform to evolve and to get around to addressing that problem, this thing that we do right now with JavaScript kind of will see us through and we’ll be okay. We know it’s bad. We know it’s not a great solution, but it helps us right now. And hopefully in the while we can pull it out and use the native solution.

Chris: It’s really funny you bring this up. Because literally last night, I was watching a talk from Jeremy Keith from last year about progressive web apps. But he was talking about how a couple of decades ago, he was trying to convince people to use JavaScript. Which seems ridiculous at the time, but JavaScript was this new thing. He showed people how you could do cool things like change the color of a link on hover with this new… It seems absurd that you would need JavaScript for that now, because that’s what CSS does for you. But things like the focus attribute or property just didn’t exist at the time.

Chris: One of the things he said in the talk that I think really resonated with me is that JavaScript in many ways, paves those cow paths. It’s this very flexible and open language that we can use to create or bolt in features that don’t exist yet. And then eventually, browsers catch up and implement these features in a more native way. But it takes time. I completely understand what you’re saying about this. It’s not the perfect solution, but it’s what we have right now.

Chris: I think for me, the biggest difference between polyfills and some of these solutions is polyfills are designed to be ripped out. If I have a feature I want to implement that the browser doesn’t support yet, but there’s some sort of specification for it and I write a polyfill… once browsers catch up, I can rip that polyfill out and I don’t have to change anything. But when you go down the path of using some of these tools, ripping them up out means rewriting your whole code base. That’s really expensive and problematic. That’s not to say never use them, but I feel really strongly that we should be giving thought to picking tools that can easily be pulled out later. If we no longer need them or the platform catches up, it doesn’t require a huge rewrite to pull them out.

Chris: So getting to that we have a whole bunch of styles we don’t use anymore thing, that’s why I would personally favor a build tool technology that audits your CSS against the rendered markup and pulls out the things you don’t need. Because down the road if a platform catches up, you can pull that piece of the build tool out without having to change everything. It’s just augmenting what you already have, whereas CSS and JS doesn’t give you that same kind of benefit. I’m just picking on that one, but I think about a lot of these technologies more broadly.

Chris: I do feel things like React or Vue are probably paving some cow paths that browsers will eventually catch up with and probably use similar approaches if not the same, so there may be less rewriting involved there. A lot of the ecosystem stuff that gets plugged in around that may be less so.

Drew: I think it’s right, isn’t it, that the web platform moves slowly and carefully. You think if five years ago, we were all putting JavaScript Carousels on our pages. They were everywhere. Everyone was implementing JavaScript Carousels. If the web platform had jumped and implemented a Carousel solution to satisfy that need, it would not be sat there with nobody using it because people aren’t doing that with Carousels anymore. Because it was just a fad, a design trend. To counteract that and stop the platform itself becoming bloated and becoming a problem that needs solving, it does have to move at a lot steadier pace. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it’s related to the framework conversation. But it’s the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you’re getting all this benefit because you’re not reloading the entire page framework. I feel like they don’t always make good on those performance promises. Would you agree with that?

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don’t think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who’s unfamiliar with those. When a single-page app, instead of having separate HTML files or if you’re using something like a database driven site like WordPress, even though you don’t have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That’s what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don’t have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that’s slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they’re not confused about where they are or what’s going on. Because they can’t see the change that’s happening, they’re hearing it announced. If you don’t actually shift focus anywhere, that announcement doesn’t happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don’t necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website’s being built, it doesn’t always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you’re going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it’s not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it’s being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. Absolutely. Absolutely. One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that’s already there. So there’s no reloading, they don’t lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It’s again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you’d have just a rectangle embedded in an HTML page which is your Flash Player, and you’d build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we’re putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn’t exist, I spell article like arcitle instead of article and the browser runs across that, it’s going to be like, “Oh, I don’t know what this is. Whatever, I’ll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let’s say I forget the B in bold, so I write old instead, font way old. The browser’s going to be, “I don’t know what this is. Whatever, we’ll just keep going.” Your thing won’t be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn’t exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn’t complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn’t work at all.

Chris: There’s an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don’t disable it and most people are using devices that can actually handle modern JavaScript. That’s true, but that’s not the only reason why JavaScript doesn’t work right, even if you have a linter there for example and you catch bugs ahead of time and things. There’s plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we’re recording this… a bad deploy took down Cloudflare. Interestingly as we’re recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They’re an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you’d like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn’t part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone’s in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it’s probably even more now. That’s a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There’s just all sorts of reasons why JavaScript can fail and when it does, it’s so catastrophic.

Chris: And so we built this web that should be faster than ever. It’s 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn’t have to be that way.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I’ve hammered on this a couple times. I’m not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn’t mean obsolete. It doesn’t mean never embrace new stuff, but don’t be so quick to just jump on all the shiny new stuff just because it’s there. I know it’s one of the things that keeps this industry really exciting and makes it fun to work in, there’s always something new to learn. But when you pick these new things, do it because it’s the right tool for the job and not just because it’s the shiny new thing.

Chris: One of the other things we didn’t get into as much as I would have liked, but I think is really important, is that the platform has caught up in a really big way in the last few years. Embracing that as much as possible is going to result in a web experience for people that is faster, that is less fragile, that is easier for you to build and maintain because it requires fewer dependencies such as using what the browser gives you out-of-the-box. We used to need jQuery to select things like classes. Now browsers have native ways to do that. People like JSX because it allows you to write HTML in JavaScript in a more seamless way. But we also have template literals in Vanilla JavaScript that give you that same level of ease without the additional dependency. HTML itself can now replace a lot of things that used to require JavaScript, which is absolutely amazing.

Chris: We talked a little bit about… this is a CSS thing, but hovers over links and how that used to require JavaScript. But using things like the details and summary elements, you can create disclosure, like expand and collapse or accordion elements natively with no scripting needed. You can do auto complete inputs using just a… I shouldn’t say just, I hate that word. But using a humble input element and then a data list element that gets associated with it, with some options. If you’re curious about how any of this stuff works over at vanillajstoolkit.com, I have a bunch of JavaScript stuff that the platform gives you. But I also have some used to require JavaScript and now doesn’t kind of things that might be interesting too if you want some code samples to go along with this.

Chris: On the CSS side of things, my most popular Vanilla JS plugin ever is this library that lets you animate scrolling down to anchor links. It is very big. It’s the hardest piece of code I’ve ever had to write. And it now is completely replaced with a single line of CSS, scroll behavior smooth. It’s more performant. It’s easier to write. It’s easier to modify its behavior. It’s just a better overall solution.

Chris: One of the other things that I wish we did more is leaning on multi-page apps. I feel a little bit vindicated here, because I recently saw an article from someone at Google that actually pushes for this approach now too. I thought that was pretty interesting, given this huge angular and then framework… all the things, boom, that Google started a few years back. Kind of cool to see them come back around to this. Using things like static site generators and awesome services like Netlify and CDN caching, you can create incredibly fast web experiences for people using individual HTML files for all of your different views. So kind of leaning on some of this out-of-the-box stuff.

Chris: In situations where that’s not realistic for you, where you do need more JavaScript, you do need some sort of library, maybe taking a look at the smaller and more modular approaches first instead of just going for the behemoths of the industry. Instead of React, would Preact work? Instead of angular… I mean, instead of Vue rather, would Alpine JS work? There’s also this really interesting pre-compiler out there now called Svelt, that gives you a framework-like experience and then compiles all your code into Vanilla JavaScript. So you get these really tiny bundles that have just what you need and nothing else. Instead of CSS and JavaScript, could you bolt in some third party CSS linter that will compare your HTML to your CSS and pull out the stuff that got left in there by accident? Would a different way of authoring your CSS, like object oriented CSS by Nicole Sullivan, work instead? We didn’t really get to talk about that, but it’s a really cool thing people should check out.

Chris: And then I think maybe the third and most important piece here, even though it’s less of a specific approach and more just a thing I wish more people kept in mind, is that the web is for everyone. A lot of the tools that we use today work for people who have good internet connections and powerful devices. But they don’t work for people who are on older devices, have spotty internet connections. This is not just people in developing areas. This is also people in the U.K., in certain parts of the U.S. where we have absolutely abysmal internet connections. The middle of our country has very slow internet. I know there’s places in part of London where they can’t wire a new broadband in for historical reasons, so you’re left with these old internet connections that are really bad. There’s places like that all over the world. Last time I was in Italy, same thing. The internet there was horrible. I don’t know if it’s changed since then.

Chris: The things we build today don’t always work for everyone, and that’s too bad. Because the vision of the web, the thing I love about it, is that it is a platform for absolutely everyone.

Drew: If listeners want to find out more about this approach, you’ve gone into loads of detail to it in your book, The Lean Web. And that’s available online. Is it a physical book or a digital book?

Chris: It’s a little bit of both. Well, no. It’s definitely not a physical book. You go to leanweb.dev. You can read the whole thing for free online. You can also if you want, there’s EPUB and PDF versions available for a really small amount of money, I forget how much now. I haven’t looked at it in a while. The whole thing is free online if you want it. You can also watch a talk on this topic where I go into more details if you want.

Chris: But I’ve also put together a special page just for listeners of Smashing Podcast at gomakethings.com/smashingpodcast, because I’m very creative with naming things. That includes a bunch of resources in addition to the book, around things that we talked about today. It links to a lot of the different techniques that we covered, other articles I’ve written that go deeper into some of these topics and expand on my thinking a little bit. If folks want to learn more, that would probably be the best place to start.

Drew: That’s terrific. Thank you. I’ve been learning all about the Lean Web. What have you been learning about lately, Chris?

Chris: Yeah, a couple of things. I alluded to this a little bit earlier with watching Jeremy’s video on progressive web apps. I have been putting off learning how to actually write my own progressive web app for a couple of years because I didn’t have a specific need on anything I was working with. I recently learned from one of my students who is in South Africa, that they have been dealing with rolling blackouts because of some stuff they have going on down there. As a result, she is not able to work on some of the projects we’ve been doing together regularly, because the power goes out and she can’t access the learning portal and follow along.

Chris: For me, now building an experience where it works even if someone doesn’t have internet has become a higher priority than… I realized that maybe it was before, so I just started digging into that and hope to get that put together in the next few weeks. We’ll see. Jeremy Keith’s resources on this have been an absolute lifesaver though. I’m glad they exist.

Chris: I know, Drew, you mentioned one of the reasons you like to ask this question is to show that people no matter how seasoned they are, are always learning. Just a little related anecdote. I have been a web developer for I think, about eight years now. I still have to Google the CSS property to use for making things italic, literally every single time I use it. For some reason, my brain defaults to text decoration even though that’s not the right one. I’ll try a couple of combinations of different things, and I always have one word wrong every time. I also sometimes write italics instead of italic. Yeah. If anybody ever there is ever feeling like, oh, I’m never going to learn this stuff… just know that no matter how seasoned you are, there’s always some really basic thing that you Google over and over again.

Drew: I’ve been a web developer for 22, 23 years, and I have to Google the different properties for Flexbox still, every time. Although I’ve been using that for 23 years. But yeah, some things just… there’s probably going to more of those as I get older.

Chris: Yeah. Honestly, I ended up building a whole website of stuff I Google over and over again, just to have an easier copy-paste reference because that was easier than Googling.

Drew: That’s not a bad idea.

Chris: That’s the kind of lazy I am. I’ll build a whole website to save myself like three seconds of Googling.

Drew: If you the listener would like to hear more from Chris, you can find his book on the web at leanweb.dev, and his developer Tips newsletter and more at gomakethings.com. Chris is on Twitter at Chris Ferdinandi. And you can check out his podcast at vanillajspodcast.com or wherever you usually get your podcasts. Thanks for joining us today, Chris. Do you have any parting words?

Chris: No. Thank you so much for having me, Drew. I had an absolutely smashing time. This was heaps of fun. I really appreciate the opportunity to come chat.

Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
guillermo-rauch-200x200-1
28 Aug

Smashing Podcast Episode 23 With Guillermo Rauch: What Is Next.js?

by TBSCategories: News

Smashing Podcast Episode 23 With Guillermo Rauch: What Is Next.js?

Smashing Podcast Episode 23 With Guillermo Rauch: What Is Next.js?

Drew McLellan

Today, We’re talking about Next.js. What is it, and where might it fit into our web development workflow? I spoke to co-creator Guillermo Rauch to find out.

Show Notes

Weekly Update

Transcript

Photo of Guillermo RauchDrew McLellan: He’s the founder and CEO of Vercel, a cloud platform for static sites that fits around a Jamstack workflow. He’s also the co-creator of Next.js. He previously founded LearnBoost and CloudUp, and is well-known as the creator of several popular node open source libraries like Socket.io, Mongoose, and SlackIn. Prior to that, he was a core developer on MooTools, so we know he knows his way around JavaScript like the back of his hand. Did you know he once received a royal commission from the King of Spain to create an ice sculpture out of iceberg lettuce? My smashing friends, please welcome Guillermo Rauch. Hi Guillermo, how are you?

Guillermo Rauch: I’m smashing freaking good, thanks for having me.

Drew: I wanted to talk to you today about the whole world of Next.js, as it’s something that obviously you’re personally very knowledgeable about, having been involved as a co-creator right from the start. Next.js is one of those project names that has been on my radar while working in the Jamstack space, but it isn’t something that I’ve actually personally looked at or worked with too closely before. For people who are like me, who perhaps aren’t aware of what Next.js is, perhaps you could give us a bit of background into what it is and what problems it tries to solve.

Guillermo: Next.js is a very interesting member of the Jamstack universe, because Next.js actually started being a fully SSR-focused framework. It started getting a lot of adoption outside the Jamstack space where people were building very large things specifically when they wanted to have user generated content or dynamic content or social networks or e-commerce, and they knew that they wanted SSR because their data set was very large or very dynamic. It fell under the radar I think for a lot of people in the Jamstack world, but later on Next.js gained the capabilities for static optimization.

Guillermo: On one hand, for example, if you wouldn’t do data fetching at the top level of your page with Next.js, your React page would be … Also by the way, for those who are not fully in the know, Next.js is simply React framework for production, but has this capability of doing some rendering. Then when you get in static optimization capabilities, if you wouldn’t define data fetching at the top level of your page, it automatically exported as HTML instead of trying to do anything with server rendering.

Guillermo: Then later on, it also gained the capability for static site generation, meaning that you can define a special data hook, but that data hook gets data at build time. Next.js became a hybrid, very powerful dynamic and static framework, and now it’s been growing a lot in the Jamstack space as well.

Drew: People might say that React is already a framework, you certainly hear it described that way. What does it actually mean to be a framework for React?

Guillermo: That’s a great observation, because I always point out to people that React at Facebook and React outside of Facebook are completely different beasts. React at Facebook actually is used together with server rendering, but even their server rendering, for example, doesn’t use Node.js, it uses a highly specialized virtual machine called Hermes which communicates to their sort of production hack and PHP stack and answers all this advanced and exotic Facebook needs.

Guillermo: When they open source React, it’s almost like open sourcing a component. I always call it like open sourcing the engine, but not giving you the car. What happened is people really wanted to go and drive with it, they wanted to get to places with React. In the community, people started creating cars, and they would embed React as the engine, which was what the driver, the developer was after in the first place, make React the fundamental part of the car. Things like Next.js and Gatsby and React Static and many other frameworks started appearing that were solving the need for like, “I actually want to create fully loaded pages and applications.”

Guillermo: Whereas React was kind of more like the component and the engine for specific widgets within the page, this was certainly the case for Facebook. They will broadly and publicly admit that they invented it for things like the notification batch, the chat widget, the newsfeed component, and those components were React routes that were embedded into the contents of the production existing app with lots and lots of lines of code and even other JS libraries and frameworks.

Guillermo: What it means to create a framework for React, it means you make React the fundamental part of the story, hopefully and this is something we’ll try to do with Next.js, the learning curve is primarily about React with some added surface for Next.js, particularly around data fetching and routing. We also do a lot of production optimizations, so when you get React, when you get Create React app, which is sort of like, I like to call it a bootstrapped car that Facebook gives you, maybe the needs for production are not really met. Or if you try to do it yourself by configuring Webpack and configuring Babel and configuring server rendering and static generation, it’s also hard to put together a car from scratch. Next.js will give you this zero config and also production optimized set of defaults around building entire big things with React.

Drew: So it’s like it almost puts a sort of ecosystem around your React app with a collection of pre-configured tools to enable you to-

Guillermo: Correct.

Drew: Hit the ground running and do static site generation or server rendering or routing.

Guillermo: Correct, and you used a word there that is very, very key to all this, which is pre-configured. We’re fortunate enough to draw the attention of Google Chrome as a contributor to Next.js. One of the leaders of this project, her thing is that when they were working on frameworks internally at Google, they faced a lot of the same problems that the community and open source are facing today. There were many different competing initiatives at Google on how to scale and make really performant web apps out of the box.

Guillermo: You would join as a Googler and you would be given a framework with which you would create really big production ready, very high performance applications. Shubie was part of a lot of those initiatives, and what she found is that there’s two key ingredients to making a framework succeed at scale. One is pre-configuration, meaning that you come to work, you’re going to start a brand new app, you should be given something that is already ready to go and meets a lot of the production demands that are known at that given point in time.

Guillermo: On the other hand, the other really important step that we’re working towards is conformance. You can be given the most highly optimized production ready pre-configured framework, but if you go ahead and, for example, start introducing lots of heavy dependencies or third party scripts or use very inefficient layouts that take a long time to paint and so on and so forth, then you’re going to make that pre-configuration sort of go to waste. By mixing pre-configuration with conformance over time, the developer is not only having a great starting point, but it’s also guided to success over time.

Drew: It seems that a characteristic of Next.js, that it’s quite opinionated, the UI layer is React, it uses type script, uses Webpack, and those are all choices that the project has made and that’s what you get. Correct me if I’m wrong, but you couldn’t swap out React for Vue, for example, within Next.js.

Guillermo: That’s a good point, where technical decision making meets sort of an art. On one hand, I’d really like to claim that Next is very unopinionated, and the reason for this is that if you specifically go to github.com/vercel/nextjs and the examples directory, you’ll see that there’s almost like a combinatoric explosion of technologies that you can use together with Next.js. You’ll see fire-based, you’ll see Graphic UL, you’ll see Apollo, you’ll see Redux, you’ll see MobX, in the CSS space there’s even more options.

Guillermo: We have a default CSS port that’s embedded, but then you can use two flavors of it, one with import, one with style tags which we call Style JSX, which resembles very much like the web platform approach to Shadow CSS. The reason I mean unopinionated is we want Next.js to stay very close to the “bare metal” of the web, and not introduce lots of primitives that if the web from 10 years from today would be incompatible with. Then if you look at the examples, you’ll see that there’s all these other technologies that you can plug in.

Guillermo: The base level of opinionation is that there is React and you’re not going to be able to replace it, at least anytime soon. Then there is the concept of you should be able to create pages, and this was kind of like a new thing when we first launched it, which was everyone is trying to create single-page applications. What we realized is like the internet is made up of websites with lots of pages that create distinct entry points via search engines, via Twitter, via Facebook, via social networks, via email companions, like you always guide the person toward an entry point, and that person that comes through that entry point shouldn’t have to download the burden of the entirety of the application.

Guillermo: Then that path led us to implementing server rendering, then static generation for multiple pages, et cetera, et cetera. That other base level of opinionation is Next should be a framework that works for the web, not against the web. Then on top of that, React was missing data fetching and routing primitives, and we added those. There’s a level of opinionation that has to deal with like everybody needs a router, so might as well have a router built in by default.

Drew: The big advantage of having those defaults is it takes away a lot of the complexity of choice, that it’s just there, it’s configured, and you can just start using it without needing to think too much, because I think we’ve all-

Guillermo: Exactly.

Drew: Been in situations where there are far too many choices of what components to use, and it can be overwhelming and get in the way of being productive.

Guillermo: Exactly.

Drew: What sort of projects do you see people using Next.js for? Is it for basically any situation where you might build a production React app, or is it more suited to particular types of content heavy sites? Does it matter in that sense?

Guillermo: Yeah, so this has been an age old debate of the web, is the web for apps, is the web for sites, is it a hybrid? What is the role of JavaScript, et cetera, et cetera? It’s kind of hard to give a straight up answer, but my take on this is the web was evolved always to be a hybrid of content that is evolving to be more and more dynamic and personal to the user. Even when you say like a content website, the high end content websites of the world have code bases that are very much comparable to apps.

Guillermo: A great example here is like New York Times, they’ll give you embedded widgets with data analysis tools and interactive animation, and they’ll recommend what story to read next, and they have a subscription model built in which sometimes gives you part of the content and sometimes counts how many articles you’ve read. Like if I told you this when the web was invented, like Tim Berners-Lee would be like, “No, that’s crazy, that’s not possible on the web,” but that’s the web we have today.

Guillermo: Next.js is answering a lot of these complex modern needs, which means you’ll see lots of e-commerce usage, you’ll see lots of content with that. E-commerce meaning, by the way, not just like buy items, but experiences like the largest real estate websites on the web, realtor.com, zillow.com, trulio.com, that entire category is all Next.js, then content sites. We just onboarded washingtonpost.com as a customer of Vercel and Next.js, we have then a third category that is more emergent but very interesting, which is full apps and user-generated content, like tiktok.com, and kind of like you would think the original single-page application use case as well being quite represented there.

Guillermo: Next.js sort of shines when you need to have lots of content that has to be served very, very quickly, has to be SEO optimized, and at the end of the day, it’s a mix of dynamic and static.

Drew: I’ve previously spoken to Marcy Sutton about Gatsby, which seems to be in a similar sort of space. It’s always great to see more than one solution to a problem and having choice for one project to the next. Would you say that Next.js and Gatsby are operating in the same sort of problem space, and how similar or dissimilar are they?

Guillermo: I think there’s an overlap for some use cases. For example, my personal blog rauchg.com runs on Next.js, it could’ve just been a great Gatsby blog as well. There is that overlap in the smaller static website sort of space, and by small I don’t mean not relevant. A lot of dotcoms that are super, super important run on basically static web, so that’s the beauty of Jamstack in my opinion. Because Next.js can statically optimize your pages and then you can get great Lighthouse scores through that, you can use it for overlapping use cases.

Guillermo: I think the line gets drawn when you start going into more dynamic needs and you have lots of pages, you have the need to update them at one time. Although Gatsby is creating solutions for those, Next.js already has production ready live solutions that work with any sort of database, any sort of data backend for basically “generating” or “printing” lots and lots of pages. That’s where today customers are going to Next.js instead of Gatsby.

Drew: One of the problems that everyone seems to run into as their JavaScript-based solution gets bigger is performance and how things can start getting pretty slow, you have big bundle sizes. Traditionally, things like code splitting can be fairly complex to get configured correctly. I see that’s one of the features that jumped out at me of Next.js, that it claims that the code splitting is automatic. What does Next.js do in terms of code splitting to make that work?

Guillermo: Your observation is 100% right. One of the biggest things with the web and one of the biggest weights on the web is JavaScript, and just like different materials have different densities and weights irrespective of the actual physical volume, JavaScript tends to be a very dense, heavy element. Even small amounts of JavaScript compared to, like for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.

Guillermo: Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. The first one that was my first intuition when I first came up with the idea for Next.js was you’re going to define, for example, 10 routes. In the Next.js world you create a pages directory and you drop your files in there Index.js, About.js, Settings.js, Dashboard.js, Termsofservice.js, Signup.js, Login.js. Those become entry points to your application that you can share through all kinds of media.

Guillermo: When you enter those, we want to give you JS that is relevant for that page first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Next.js also, which is very, very nice, automatically pre-fetches the rest of the pages that are connected to that entry point, such that it feels like a single-page application. A lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Look, you can find those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it’s better optimized with regards to that initial paint, that initial entry point.”

Guillermo: That was the initial code splitting approach, but then it became a lot more sophisticated over time. Google contributed a very nice optimization called Module and No Module, which will give differential JS to modern browsers, and legacy JS that’s heavy with polyfields to other browsers, and this optimization 100% automated and produces massive savings. We gave it to one of our customers that we host on Vercel called Parnaby’s, I believe if I’m not mistaken, it was something very, very significant. It was maybe like 30% savings in code sizes, and that was just because they upgraded Next.js to a version that optimized JS bundles better.

Guillermo: That was kind of the point that we were going over earlier, which is you choose Next.js and it only gets better and more optimal over time, it’ll continue to optimize things on your behalf. Those are, again, pre-configurations that you would never have to deal with or be bothered with, and the research of which you don’t ever even want to do, to be honest. Like I wasn’t obviously very involved with this, but I look at some of the internal discussions and they were discussing all these polyfields that only mattered to Internet Explorer X and Soho, I was like, “I don’t even want to know, let’s just upgrade Next.js and get all these benefits.”

Drew: There is sometimes great benefits on there with sticking with the defaults and sticking with the most common configuration of things, which seems to be really the Next.js approach. I remember when I started writing PHP back in the early 2000s, and everybody was using PHP and MySQL, and at the time I’d just come from Windows so I wanted to use PHP and Microsoft Sequel Server. You can do it, but you’re swimming against the tide the whole way. Then as soon as I just switched over to MySQL, the whole ecosystem just started working for me and I didn’t need to think about it.

Guillermo: Yeah, everything just clicks, that is such a great observation. We see that all the time, like the Babel ecosystem is so powerful now that you could become, for example, a little bit faster by swapping Babel for something else, but then you trade off that incredible ecosystem compatibility. This is something you touched on performance earlier, and like for a lot of people, build performance and static generation performance is a big bottleneck, and this is something that we are very diligent in improving the performance of our tools incrementally.

Guillermo: For example, one of the things that Next.js is doing now is that it’s upgrading its default from Webpack 4 to Webpack 5, which has some breaking things, and that’s why we’re first offering it to people as an opt-in flag, but later on it’ll become the default. Webpack 5 makes incredible performance improvements, but we’re not sacrificing the Webpack ecosystem, we incrementally improved. Sure, there were some very small things that needed to be sacrificed, but that’s an incredible benefit of the JS ecosystem today that a lot of people are glossing over, I think, because maybe they see, “Oh, we could’ve done X in Soho, maybe it was a little faster, or maybe MPM in Soho would take less time.” They pick up some details and they miss the bigger picture, which is the ecosystem value is enormous.

Drew: The value of having all the configuration and the maintenance and that side of it done by a project like Next.js rather than taking that on yourself by swapping to using something else is incredible, because as soon as you move away from those defaults, you’re taking on the burden of keeping all the compatibilities going and doing it yourself. One of the things that I’ve been really interested in with Next.js is there are options available for either doing static site generation or server-side rendering, or maybe a hybrid of the two perhaps. I think there’s been some recent changes to this in a recent update, can you tell us a little bit about that and when you might choose one or the other?

Guillermo: Yeah, for sure. One of the key components of this hybrid approach combined with the page system that I described earlier is that you can have pages that are fully static or pages that server rendered. A page that’s fully static has the incredible benefit of what I call static hoisting, which is you can take that asset and automatically put it at the edge. By putting it at the edge, I mean you can cache it, you can preemptively cache it, you can replicate it, you can make it so that when a request comes in, it never touches the server because we know ahead of time, “Hey, Slash Index is a static.”

Guillermo: That’s a very, very interesting benefit when it comes down to serving global audiences. You basically get an automatic CDN out of the box, especially when you deploy the modern edge networks like Vercel or AWS Amplify or Netlify and so on. Next.js has this premise of if it can be made static, it should be static. When you’re first starting a project and you’re working on your first page or you’re kicking the tires of the framework, might as well make everything static.

Guillermo: Even for high end needs, so for example, vercel.com, our own usage of Next.js is fully static. It’s a combination of fully static and static site generation, so all our marketing pages are static, our blog is statically generated from a dynamic data source, and then our dashboard which has lots of dynamic data, but we can deliver it as shells or skeletons, all the pages associated with viewing your deployments, viewing your projects, viewing your logs, et cetera, et cetera, are all basically static pages with client-side JavaScript.

Guillermo: That serves us incredibly well because everything where we need a very fast first-pane performance is already pre-rendered, everything that needs SEO, already pre-rendered, and everything that’s extremely dynamic, we only have to worry about security, for example, from the perspective of the client side which uses the same API calls that, for example, our CLI used or our integrations use, et cetera, et cetera. A fully static website, very cheap to operate, incredibly scalable and so on and so forth.

Guillermo: Now, one particular thing that we needed with our blog was we wanted to update the data very quickly. We wanted to fix a typo very quickly and not wait for an entire build to happen, and this is a very significant benefit of Next.js, that as you straddle from a static to a dynamic, it gives you these in between solutions as well. For our blog we used incremental static generation, so essentially we can rebuild one page at a time when the underlying content changes.

Guillermo: Imagine that we had not just a couple hundred blog posts and we had lots of blog posts being generated all the time and being updated all the time, like I mentioned one of our customers, Washington Post, in that case you need to go more toward full SSR, especially as you start customizing the content for each user. That journey of complexity that I just described started from I have one marketing page, to I have a blog that has a couple thousand pages, to I have tens of thousands or millions of pages. That’s the Next.js journey that you can traverse with your own business.

Guillermo: Then you start as a developer to choose between perhaps less responsibility to more responsibility, because when you opt in to using SSR, you’re now executing code on the server, you’re executing code on the cloud, there’s more responsibility with more power. The fact that you can decide where you use each kind of tool is I think a very, very interesting benefit of Next.

Drew: Just in practicalities of combining the static site generation and the server-side rendering, how does that work in terms of the server element? Are you needing a dedicated platform like Vercel to be able to achieve that, or is that something that can be done more straightforwardly and more simply?

Guillermo: Next.js gives you a dev server, so you download Next and you run your Next Dev, and that’s the dev server. The dev server is obviously incredibly optimized for development, like it has the latest fast refresh technology that Facebook released, where … Actually, Facebook didn’t release it, Facebook uses it internally to get the best and most performant and most reliable hot module replacement, such that you’re basically typing and it changes are reflecting on the screen, so that’s the dev server.

Guillermo: Then Next gives you a production server called Next Start, and Next Start has all the capabilities of the framework for self-hosting. The interesting thing about Vercel is that when you deploy Next to it, it gets automatically optimized and it’s 100% serverless, meaning there’s no responsibility whatsoever of administration, scaling, cashing and cashing validation, purging, replication, global fail over and so on and so forth that you would have to take on when you run Next Start yourself.

Guillermo: That’s also the great benefit of Next.js, so for example, apple.com has several different properties, subdomains and pages on dotcom on Next.js they self-host, due to very, very advanced and stringent security and privacy needs. On the other hand, washingtonpost.com uses Vercel, so we have this sort of wide range of users, and we’re extremely happy to support all of them. The nice thing about where serverless is headed in my opinion is it can give you best of both worlds in terms of the most optimal performance that only gets better over time, with the best developer experience of like, “Hey, I don’t have to worry about any sort of infrastructure.”

Drew: The Next.js is an open source project that’s being developed by the team at Vercel. Are there other contributors outside of Vercel?

Guillermo: Yeah, so Google Chrome being the main one that actively submit server PRs, help us with optimizations and testing it with partners, like very large Next.js users that are already part of the Google ecosystem, for example, due to using lots and lots of apps, so they need to be involved closely as partners. Facebook, we maintain a great relationship with the Facebook team. For example, fast refresh, we were the first React framework to land that, and they helped guide us through all the things that they learned of using React and fast refresh at Facebook.

Guillermo: We work with lots of partners that have very large deployments of Next.js apps in the wild from all kinds of different sort of use cases, like imagine e-commerce and content. Then there’s just lots and lots of independent contributors, people that use Next.js personally, but also educators and members of front infrastructure teams at large companies. It’s a very, very wide community effort.

Drew: It sounds like the concern that somebody might have, that this is being developed in a significant part by Vercel, that they might have the concern that they’re going to get sort of locked into deploying on that particular platform, but it sounds very much like that’s not the case at all, and they could develop a site and deploy it on Firebase or Netlify or…

Guillermo: Yeah, absolutely. I like to compare it a lot for like the Kubernetes of the Front End age in a way, because at the end of the day I am a firm believer that … Kubernetes is something that pretty much almost everyone needs when they need to run Linux processes, like you were talking about opinionation and you’re saying it’s a good technology, it’s very much not opinionated, but there is some opinionation that we kind of forget about. It’s like at the end of the day, it grew out of running a specific demons of Linux programs packaged as containers.

Guillermo: Next is in a similar position, because what we take for being the universal primitive of the world as a React component, obviously it’s opinionated, but we do think that for lots of enterprises, just like they all gravitate towards Linux, we are seeing the same thing towards React and Vue, but Vue luckily has Nuxt too, which is a very awesome solution, it’s equivalent in ideation and principles as Next. We’re gravitating towards these platforms like Next.js, like Nuxt, like Sapper for the Svelte ecosystem.

Guillermo: I think these should be open platforms, because again, if everybody’s going to need this, might as well not reinvent the wheel across the entire industry, right? We very much welcome that position, we welcome people to deploy it and reconfigure it and rebuild it and redistribute it and so on.

Drew: Just recently a new version of Next.js was released, I think version 9.5. What significant changes were there in that release?

Guillermo: The most awesome one is, as I was saying earlier, a lot of things start static and then become more dynamic as things grow. This was the venture for WordPress, by the way. WordPress in the beginning was based on a static file database approach, and then grew into needing a database, kind of like what you described with how PHP evolved to be more and more MySQL. What’s nice about Next.js 9.5 is that it makes incremental static generation a production ready feature, so we took it out of the unstable flag.

Guillermo: This feature allows you to make that journey from static to dynamic without giving up on all the static benefits, and without having to go full for server-rendered dynamic, so it stretches the useful lifetime of your sort of static. The way we use it at Vercel, for example, as I mentioned, it’s like our blog gets fully pre-rendered at build time, but then for example, we’re actually in a couple minutes about to make a major announcement, and when we blog about it we want to be able to tweak it, fix it, preview it, et cetera without having to issue a five to 10-minute build every time we change one letter of one blog post.

Guillermo: With incremental static generation, you can rebuild one page at a time. What could take minutes or even seconds, depending on how big your site is, now takes milliseconds. Again, you didn’t have to give up on any of the benefits of static. That’s perhaps the thing I’m most excited about that went stable on Next.js 9.5, and specifically because the JS community and the React community and the framework community and static site generated community have been talking about this unicorn of making a static incremental for a long time, so the fact that Next.js did it, it’s being used in production and it’s there for everybody to use, I think it’s a major, major, major milestone.

Guillermo: There’s lots of little DX benefits. One that’s really nice in my opinion is Next.js, as I said, has a page system. You would argue, “Okay, so let’s say that I’m uber.com and I’ve decided to migrate on Next.js, do I need to migrate every URL inside over to Next.js in order to go live?” This has become a pretty important concern for us, because lots of people choose Next.js, but they already are running big things, so how do you reconcile the two?

Guillermo: One of the things that Next.js allows you to do in 9.5 is you can say, “I want to handle all new pages that I created with Next.js with Next.js, and the rest I want to hand off to a legacy system.” That allows you incremental, incremental is the keyword here today, incremental adoption of Next.js. You can sort of begin to strangle your legacy application with your Next.js optimized application one page at a time, when you deploy and you introduce in your Next.js page, it gets handled by Next. If it doesn’t match the Next.js routing system, it goes to the legacy system.

Drew: That sounds incredibly powerful, and the incremental rendering piece of that, I can think of several projects immediately that would really benefit that have maybe 30-minute build times for fixing a typo, as you say. That sort of technology is a big change.

Guillermo: We talked to one of the largest, I believe, use cases in Jamstack in the wild, and it was basically a documentation website and their build times were 40 minutes. We’re doing a lot in this space, by the way, like we’re making pre-rendering a lot faster as well. One of my intuitions for years to come is that as platforms get better, as the primitives get better, as the build pipelines get better we’re going to continue to extend the useful lifetime of statics. Like what ended up taking 40 minutes is going to take four.

Guillermo: A great example is we’re rolling out an incremental build cache, as well, system. I sort of pre-announced it on Twitter the other day, we’re already seeing 5.5 times faster incremental builds. One of the things that I like about Jamstack is that the core tenet is pre-render as much as possible. I do think that’s extremely valuable, because when you’re pre-rendering you’re not rendering just in time at runtime. Like what otherwise the visitor would incur in in terms of rendering costs on the server gets transferred to build time.

Guillermo: One of the most exciting things that’s coming to Next is that without you doing anything as well, the build process is also getting faster. On the Vercel side, we’re also taking advantage of some new cloud technology to make pre-rendering a lot faster as well. I think we’re always going to live in this hybrid world, but as technology gets better, build times will get better, pre-rendering will get better and faster, and then you’ll have more and more opportunities to do kind of a mix of the two.

Drew: Sounds like there’s some really exciting things coming in the future for Next.js. Is there anything else we should know before we sort of go away and get started working with Next.js?

Guillermo: Yeah. I think for a lot of people for whom this is new, you can go to nextjs.org/learn, it’ll walk you through building your first small static site with Next.js, and then it’ll walk you through the journey of adding more and more complexity over time, so it’s a really fun tutorial. I recommend also staying tuned for our announcement that I was just starting to share on twitter.com/vercel, where we share a lot of Next.js news. Specifically we highlight a lot of the work that’s being done on our open source projects and our community projects and so on. For myself as well, twitter.com/rauchg if you want to stay on top of our thoughts on the ecosystem.

Drew: I’ve been learning all about Next.js today, what have you been learning about lately, Guillermo?

Guillermo: As a random tangent that I’ve been learning about, I decided to study more economics, so I’ve been really concerned with like what is the next big thing that’s coming in terms of enabling people at scale to live better lives. I think we’re going through a transition period, especially in the US, of noticing that a lot of the institutions that people were “banking on”, like the education system, like the healthcare system, a lot of those, like where you live and whether you’re going to own a house or rent and things like that, a lot of these things are changing, they have changed rapidly, and people have lost their compass.

Guillermo: Things like, “Oh, should I go to college? Should I get a student loan?” and things like that, and there is a case to be made for capitalism 3.0, and there is a case to be made for next level of evolution in social and economic systems. I’ve been just trying to expand my horizons in learning a lot more about what could be next, no pun intended. I’ve found there’s lots of great materials and lots of great books. A lot of people have been thinking about this problem, and there is lots of interesting solutions in the making.

Drew: That’s fascinating. If you, dear listener, would like to hear more from Guillermo, you can find him on Twitter at @RauchG, and you can find more about Next.js and keep up to date with everything that goes on in that space at nextjs.org. Thanks for joining us today, Guillermo. Do you have any parting words?

Guillermo: No, thank you for having me.

Smashing Editorial (il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
chris-coyier-200x200-opt
11 Aug

Smashing Podcast Episode 22 With Chris Coyier: What Is Serverless?

by TBSCategories: News

Smashing Podcast Episode 22 With Chris Coyier: What Is Serverless?

Smashing Podcast Episode 22 With Chris Coyier: What Is Serverless?

Drew McLellan

Today, we’re talking about Serverless architectures. What does that mean, and how does it differ from how we might build sites currently? I spoke to Chris Coyier to find out.

Show Notes

Weekly Update

Transcript

Photo of Chris CoyierDrew McLellan: He’s a web designer and developer who you may know from CSS-Tricks, a website he started more than 10 years ago and that remains a fantastic learning resource for those building websites. He’s the co-founder of CodePen, the browser based coding playground and community used by front-enders all around the world to share what they make and find inspiration from those they follow. Alongside Dave Rupert is the co-host of ShopTalk Show, a podcast all about making websites. So we know he knows a lot about web development, but did you know he once won a hot dog eating competition using only his charm? My smashing friends, please welcome Chris Coyier. Hello Chris, how are you?

Chris Coyier: Hey, I’m smashing.

Drew: I wanted to talk to you today not about CodePen, and I don’t necessarily want to talk to you about CSS-Tricks, which is one of those amazing resources that I’m sure everyone knows appears right at the top of Google Search results when looking for answers about any web dev question. Up pops your face and there’s a useful blog post written by you or one of your guest contributors.

Chris: Oh, I used to actually do that. There was a… I don’t know, it probably was during the time of when Google had that weird social network. What was that? Google Plus?

Drew: Oh, Plus, yeah.

Chris: Yeah, where they would associate a website with a Plus account, and so my Plus account had an avatar, and the avatar was me, so it would show up in search results. I think those days are gone. I think if you…

Drew: I think so, yeah-

Chris: Yeah.

Drew: But I kind of wanted to talk to you about something that has been a little bit more of a sort of side interest of yours, and that’s this concept of serverless architectures.

Chris: Mm (affirmative).

Drew: This is something you’ve been learning sort of more about for a little while. Is that right?

Chris: Yeah, yeah. I’m just a fan. It seems like a natural fit to the evolution of front-end development, which is where I feel like I have, at least, some expertise. I consider myself much more of a… much more useful on the front-end than the back-end, not that I… I do it all these days. I’ve been around long enough that I’m not afraid of looking at a little Ruby code, that’s for sure. But I prefer the front-end. I’ve studied it more. I’ve participated in projects more at that level, and then along comes this little kind of a new paradigm that says, “You can use your JavaScript skills on the server,” and it’s interesting. You know? That’s how I think of it. There’s a lot more to it than that, but that’s why I care, is because I feel it’s like front-end developers have dug so deep into JavaScript. And now we can use that same skill set elsewhere. Mm, pretty cool.

Drew: Seems like a whole new world has opened up, whereas if you were just a front-end coder… I say, just a front-end coder, I shouldn’t. If you’re a front-end coder, and you’re used to working with a colleague or a friend to help you with the back-end implementation, suddenly that’s opened up. And it’s something that you can manage more of the whole stack yourself.

Chris: Yeah, yeah. That’s it.

Drew: Addressing the elephant in the room, right at the top. We’re talking about serverless, and obviously, naming things is hard. We all know that. Serverless architecture doesn’t mean there are no servers, does it?

Chris: I think it’s mandatory, like if this is the first podcast you’re hearing of it, or in the first… you’re only hearing the word “serverless” in the first dozen times you ever heard it, it’s mandatory that you have a visceral reaction and have this kind of, “Oh, but there are still servers.” That’s okay. If that’s happening to you right now, just know that, that’s a required step in this. It’s just like anything else in life. There’s stages to understanding. The first time you hear something, you’re required to kind of reject it a little bit, and then only after a dozen times or so, or after it’s proven its worth a little bit to you, do you get to enter the further stages of understanding here. But the word has won, so if you’re still fighting against the word “serverless”, I hate to tell you, that the train has left the station there. The word is already successful. You’re not going to win this one. So, sorry.

Chris: But I do think it’s interesting that… it’s starting to be like, maybe there actually aren’t servers involved sometimes. I would think one of the things that locked serverless in as a concept was AWS Lambda. They were kind of the first on the scene. A lambda is like a function that you give to AWS and it puts it in the magical sky and then… it has a URL, and you can hit it and it will run that function and return something if you want it to. You know? That’s just HTTP or whatever. That’s how it works, which… the first time you hear that, you’re like, “Why? I don’t care.” But then, there’s some obvious things to it. It could know my API keys that nobody else has access to. That’s why you run back-end to begin with, is that it knows secret stuff that doesn’t have to be in the JavaScript on the client side. So if it needs to talk to a database, it can do that. It can do that securely without having to expose API keys elsewhere. Or even where that data is or how it gets it, it’s…

Chris: So that’s pretty cool. I can write a function that talks to a database, get some data, returns that. Cool. So, Lambda is that, but AWS works. You have to pick a region. You’re like, “I don’t know. Where it should be, Virginia? Oregon? Should I pick the Australia one? I don’t know.” They have 20, 30. I don’t even know how many they have these days, but even lambdas had regions. They, I think, these days have Lambda@Edge, which means it’s all of the regions, which is kind of cool. But they were first, and now everybody’s got something like Lambda. All the cloud services. They want some kind of service in this world. One of them is CloudFlare. CloudFlare has workers. They have way more locations than AWS has, but they executed it kind of at a different time too… the way a CloudFlare worker… it’s similar to a lambda in that you can run Node. You can run JavaScript. You can run a number of other languages too, but… I think of this stuff largely, the most interesting language is JavaScript, just because of the prevalence of it.

Chris: It happens just at the CDN level, which I guess is a server, but I tend to not think of CDNs as a server. Not as obviously as something else. It’s starting to feel even more serverless-y lately. Is a CDN a server? I mean, I guess it’s a computer somewhere, but it feels like even less server-y.

Drew: It feels like, yes, a CDN may be a server, but it’s the most sort of minimal version of a server. It’s like a thin server, if you like.

Chris: Yeah. Sure.

Drew: All right. I’ve heard it said… I can’t remember the source to credit, unfortunately, but I’ve heard serverless described as being “like using a ride-sharing service like Uber or Lyft” or whatever. You can be carless and not own a car, but that doesn’t mean you never use a car.

Chris: Yeah, it doesn’t mean cars don’t exist. Mm, that’s nice.

Drew: You just summon one when you need it, but at the same time, you’re not paying the upfront purchase cost of a car. You’re not paying maintenance or fuel or-

Chris: Right, and the pricing makes sense, too, right? That’s nice. That’s a nice analogy, I think. And then, because it’s at the CDN level too, it just intercepts HTTP requests that are already happening, which means you don’t ask it… you don’t send a request to it and it sends a request back. It’s just happening during the request naturally, which also makes it feel less server-y. I don’t know, it’s interesting. It’s interesting for sure. So that’s a big deal, though, that you brought up the pricing thing. That you only pay for what you use. That’s significant too, because… let’s say, you’re a back-end dev, who’s used to spinning up servers their whole life. And they run the costs, “I need this kind of server with this kind of memory and this kind of CPU and these kind of specs. And this is how much it’s going to cost.” Serverless comes along and chops the head off of that pricing.

Chris: So, even if you’re a back-end dev who just doesn’t like this that much, that they’re just not into it, like your skill set is just what it is over the years, you compare the price and you’re like, “What? I could be paying 1% of what I was paying before?” You are not allowed to not care about that, right? If you’re this back-end dev that’s paying a hundred times more for their service than they need to be paying, you’re just kind of bad at your job then. Sorry to say. This has come along and this has shattered pricing in a lot of ways. You have to care about that. And it’s kind of cool that somebody else is… It’s not like you don’t have to worry about security at all, but it’s not your server. You don’t have… your lambda or cloud function, or your worker, or whatever, isn’t sitting on a server that’s right next to some really sensitive data on your own network. It’s not right next to your database.

Chris: If somebody writes code that somehow tries to eject itself from the worker or the lambda, or whatever, and try to get access to other things in their way, there’s nothing there to get. So the security’s a big deal too, so again, if that’s your job as the server admin, is to deal with the security of this thing. Running it, running certain things in Lambda, you just get some natural security from it, which is great. So, it’s way cheaper. It’s way more secure. It encourages these small modular architecture, which can be a good idea. It seems to be domino after domino of good ideas here. That’s why it’s notable. You know?

Drew: Yeah, I mean, traditionally with a server based architecture that we’ve been running for decades on the web, you have a web server that you run yourself. It holds your front-end code, your back-end code, your database and everything. Then you need to maintain that and keep it running and pay the bills, and even if it’s not being used, it’s there clocking up bills. The user would make a request and it would build all that HTML query stuff from the database, send it all down the line to the browser. That process works. It’s how loads of things are built. It’s probably the majority of how the web is built. It’s how things like WordPress work. Is this really a problem that we need to solve? I mean, we’ve talked about costs a little bit. What are the other sort of problems with that, that we’re… that we need to address, and that serverless might help us with?

Chris: Yeah, the problems with the old school approach. Yeah, I don’t know, maybe there isn’t any. I mean, I’m not saying the whole web needs to change their whole… the whole thing overnight. I don’t know. Maybe it doesn’t really, but I think it opens up doors. It just seems like, when good ideas arrive like this, they just slowly change how the web operates at all. So, if there’s some CMS that is built in some way that expects a database to be there, it means that maybe the hosts of the future will start leveraging this in interesting ways. Maybe it feels to you like it’s still just a traditional server, but the hosts themselves have farmed it out, how they operate, to serverless architectures. So you don’t even really know that that’s happening, but they’ve found a way to slash their costs by hosting the stuff that you need in serverless ways. Maybe yeah don’t even need to care as a developer, but at a meta level, that’s what’s happening. Maybe. I don’t know.

Chris: It also doesn’t mean that… Databases are still there. If it turns out that architecturally having a relational database is the correct way to store that data, great. I mention that because this world of Serverless is kind of growing up at the same time that JAMstack is. And JAMstack is this architecture that’s, “You should be serving your website off of static hosts, that run nothing at all except for…” They’re like little CDNs. They’re like, “I can do nothing. I don’t run PHP. I don’t run Ruby. I run nothing. I run on a tiny little web server that’s just designed to serve static files only.”

Chris: “And then, if you need to do more than that, if you need to pull data from a relational database, then please do it at some other time, not at the server time. You can either do it in a build process ahead of time, and pull that stuff out of the database, pre-build static files and I’ll serve those, or do it at runtime.” Meaning you get this shell of a document, and then it makes a JavaScript request to get some data and prefills it then. So you do it ahead of time or after time, but it doesn’t mean, “Don’t use a relational database.” It just means, “Don’t have the server generate it at the time of the request of the document,” which is a… I don’t know, it’s a little bit of a paradigm shift.

Chris: It’s not just JAMstack either. We’re also living in the time of JavaScript frameworks. We’re living in a time where it’s starting to be a little more expected that the way that a JavaScript application boots up, is that it mounts some components, and as those components mount, it asks for the data that it needs. And so, it can be kind of a natural fit for something like a React website to be like, “Well, I’ll just hit a serverless function to cough up the data that it needs. It hits some JSON API essentially. I get the JSON data that I need and I construct myself out of that data, and then I render onto the page.” Now, whether that’s good or bad for the web, it’s like, “I don’t know. Too bad. Ship has sailed. That’s how a lot of people are building sites.” It’s just client rendered things. So, serverless and modern JavaScript kind of go hand in hand.

Drew: I suppose you don’t have to wholesale… be looking at one architecture or another. There’s an area in the middle where parts of an infrastructure might be more traditional and parts could be serverless, I’m guessing?

Chris: Yeah. Well, they’re trying to tell you that anyway. Anybody that wants to sell you any part of their architecture is like, “You don’t have to buy in all right now. Just do it a little bit.” Because of course, they want you to dip your toe into whatever they’re selling, because once you dip the toe, the chances that you splash yourself into the pool is a lot higher. So, I think that… it’s not a lie, though, necessarily, although I find a little less luck in… I don’t want my stack to be a little bit of everything. I think there’s some technical death there that I don’t always want to swallow.

Drew: Mm (affirmative).

Chris: But it’s possible to do. I think the most quoted one is… let’s say I have a site that has an eCommerce element to it, which means… and let’s say large scale eCommerce, so 10,000 products or something, that this JAMstack architecture hasn’t gotten to the point where that’s always particularly efficient to rebuild that statically. So, the thinking goes, “Then don’t.” Let that part kind of hydrate naturally with… hit serverless functions and get the data that it needs, and do all that. But the rest of the site, which isn’t… there’s not as many pages, there’s not as much data, you could kind of pre-render or whatever. So a little bit of both.

Drew: Of course, plenty of people are dealing with legacy systems that… some old database thing that was built in the 2000s that they may be able to stick a sort of JSON API layer on top of…

Chris: Yeah.

Drew: … and build something more modern, and perhaps serverless, and then still interact with those legacy systems by sort of gluing it altogether in a weird way.

Chris: Yeah. I like that though, isn’t it? Aren’t… most websites already exist. How many of us are totally green-fielding websites? Most of us work on some crap that already exists that needs to be dragged into the future for some reason, because I don’t know, developers want to work faster, or you can’t hire anybody in COBOL anymore, or whatever the story is. You know?

Drew: So terminology wise, we’re talking about JAMstack which is this methodology of running a code pretty much in the browser, serving it from a CDN. So, not having anything dynamic on the server. And then when we talk about serverless, we’re talking about those small bits of functionality that run on their server somewhere else. Is that right? That we were talking about these cloud function kind of-

Chris: Yeah, I mean, they just happen to be both kind of hot ideas right now. So it’s kind of easy to talk about one and talk about the other. But they don’t necessarily need to be together. You could run a JAMstack site that has nothing to do with serverless anything. You’re just doing it, you just pre-build the site and run it, and you can use serverless without having to care about JAMstack. In fact, CodePen does nothing JAMstack at all. Not that we want to talk about CodePen necessarily, but it’s a Ruby on Rails app. It runs on a whole bunch of AWS EC2 instances and a variety of other architecture to make it happen. But we use serverless stuff whenever we can for whatever we can, because it’s cheap and secure, and just a nice way to work. So, no JAMstack in use at all but serverless all over the place.

Drew: That’s quite interesting. What sort of tasks are you putting serverless to on CodePen?

Chris: Well, there’s a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… the point of CodePen is that you write each HTML, CSS and JavaScript in the browser and it renders it in front of you, right? But you can pick pre-processor languages as well. Let’s say you like Sass. You turn Sass on in the CSS, and you write Sass. Well, something has to process the Sass. These days, Sass is written in Dart or something.

Chris: Theoretically, you could do that in the client. But these libraries that do pre-processing are pretty big. I don’t think I want to ship the entire Sass library to you, just to run that thing. I don’t want to… it’s just not, that’s not the right architecture for this necessarily. Maybe it is down the road, I mean, we could talk about offline crap, yada, yada, Web Workers. There’s a million architectural things we could do. But here’s how it does work now, is there’s a lambda. It processes Sass. It has one tiny, tiny, tiny, little job.

Chris: You send it this blob of Sass and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job and we probably pay for that lambda, like four cents or something. Because lambdas are just incredibly cheap and you can hammer it too. You don’t have to worry about scale. You just hit that thing as much as you want and your bill will be astonishingly cheap. There is moments where serverless starts to cross that line of being too expensive. I don’t know what that is, I’m not that master of stuff like that. But generally, any serverless stuff we do, we basically… all nearly count as free, because it’s that cheap. But there’s one for Sass. There’s one for Less. There’s one for Babbel. There’s one for TypeScript. There’s one for… All those are individual lambdas that we run. Here’s some code, give it to the lambda, it comes back, and we do whatever we’re going to do with it. But we use it for a lot more than that, even recently.

Chris: Here’s an example. Every single Pen on CodePen has a screenshot. That’s kind of cool, right? So, the people make a thing and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. If you share it in Slack, you get the little preview of it. We use it on the website itself to render… instead of an iframe, if we could detect that the Pen isn’t animated, because an iframe’s image is much lighter, so why not use the image? It’s not animated anyway. Just performance gains like that. So each of those screenshots has a URL to it, obviously. And we’ve architected it so that that URL is actually a serverless function. It’s a worker. And so, if that URL gets hit, we can really quickly check if we’ve already taken that screenshot or not.

Chris: That’s actually enabled by CloudFlare Workers, because CloudFlare Workers are not just a serverless function, but they have a data store too. They have this thing called key-value store, so the ID of that, we can just check really quick and it’ll be, “True or false, do you have it or not?” If it’s got it, it serves it. And it serves it over CloudFlare, which is super fast to begin with. And then gives you all this ability too. Because it’s an image CDN, you can say, “Well, serve it in the optimal format. Serve it as these dimensions.” I don’t have to make the image in those dimensions. You just put the dimensions in the URL and it comes back as that size, magically. So that’s really nice. If it doesn’t have it, it asks another serverless function to make it really quick. So it’ll make it and then it’ll put it in a bucket somewhere… because you have to have a origin for the image, right? You have to actually host it somewhere usually. So we put it in an S3 bucket real quick and then serve it.

Chris: So there’s no queuing server, there’s no nothing. It’s like serverless functions manage the creation, storage and serving of these images. And there’s like 50 million or 80 million of them or something. It’s a lot, so it handles that as scale pretty nicely. We just don’t even touch it. It just happens. It all happens super fast. Super nice.

Drew: I guess it… well, a serverless function is ideally going to suit a task that needs very little knowledge of state of things. I mean, you mentioned CloudFlare’s ability to store key-value pairs to see if you’ve got something cached already or not.

Chris: Yeah. That’s what they’re trying to solve, though, with those. Those key-value pairs, is that… I think that traditionally was true. They’re like, “Avoid state in the thing,” because you just can’t count on it. And CloudFlare Workers are being like, “Yeah, actually, you can deal with state, to some degree.” It’s not as fancy as a… I don’t know, it’s key values, so it’s a key in a value. It’s not like a nested, relational fancy thing. So there’s probably some limits to that. But this is baby days for this. I think that stuff’s going to evolve to be more powerful, so you do have some ability to do some state-like stuff.

Drew: And sometimes the limitation, that sort of limited ability to maintain state, or the fact that you have no… you want to maintain no state at all, kind of pushes you into an architecture that gives you this sort of… Well, when we talk about the software philosophy of “Small Pieces Loosely Joined”, don’t we?

Chris: Mm (affirmative).

Drew: Where each little component does one thing and does it well. And doesn’t really know about the rest of the ecosystem around it. And it seems that really applies to this concept of serverless functions. Do you agree?

Chris: Yeah. I think you could have a philosophical debate whether that’s a good idea or not. You know? I think some people like the monolith, as it were. I think there’s possible… there’s ways to overdo this and to make too many small parts that are too hard to test altogether. It’s nice to have a test that’s like, “Oh, I wonder if my Sass function is working. Well, let’s just write a little test for it and make sure that it is.” But let’s say, what matters to the user is some string of seven of those. How do you test all seven of them together? I think that story gets a little more complicated. I don’t know how to speak super intelligently to all that stuff, but I know that it’s not necessarily that, if you roll with all serverless functions that’s automatically a better architecture than any other architecture. I like it. It reasons out to me nicely, but I don’t know that it’s the end-all be-all of all architectures. You know?

Drew: To me, it feels extremely web-like, in that… this is exactly how HTML works, isn’t it? You deliver some HTML and the browser will then go and fetch your images and fetch your JavaScript and fetch your CSS. It seems like it’s an expansion of that –

Chris: It’s nice.

Drew: … sort of idea. But, one thing we know about the web, is it’s designed to be resilient because network’s fragile.

Chris: Mm (affirmative).

Drew: How robust is the sort of serverless approach? What happens if something… if one of those small pieces goes away?

Chris: That would be very bad. You know? It would be a disaster. Your site would go down just like any other server, if it happens to go down, I guess.

Drew: Are there ways to mitigate that, that are particularly –

Chris: I don’t know.

Drew: … suited to this sort of approach, that you’ve come across?

Chris: Maybe. I mean, like I said, a really super fancy robust thing might be like… let’s say you visit CodePen and let’s say that there’s a JavaScript implementation of Sass and we noticed that you’re on a fairly fast network and that you’re idle right now. Maybe we’ll go grab that JavaScript and we’ll throw it in a service worker. Then, if we detect that the lambda fails, or something, or that you have this thing installed already, then we’ll hit the service worker instead of the lambda, and service workers are able to work offline. So, that’s kind of nice too. That’s interesting. I mean, they are the same language-ish. Service workers are JavaScript and a lot of Cloud functions are JavaScript, so there’s some… I think that’s a possibility, although that… it’s just, that’s some serious technical that… It just scares me to have this chunk of JavaScript that you’ve delivered to how many thousands of user, that you don’t necessarily know what they have, and what version of it they have. Eww, but that’s just my own scarediness. I’m sure some people have done a good job with that type of thing.

Chris: I actually don’t know. Maybe you know some strategies that I don’t, on resiliency of serverless.

Drew: I guess there’s a failure mode, a style of failure, that could happen with serverless functions, where you run a function once and it fails, and you can run it a second time immediately afterwards and it would succeed, because it might hit a completely different server. Or whatever the problem was, when that run may not exist on a second request. The issues of an entire host being down is one thing, but maybe there are… you have individual problems with the machine. You have a particular server where its memory has gone bad, and it’s throwing a load of errors, and the first time you hit it, it’s going to fail. Second time, that problem might have been rooted around.

Chris: Companies that tend to offer this technology, you have to trust them, but they also happen to be the type of companies that… this is their pride. This is the reason why people use them is because they’re reliable. I’m sure people could point to some AWS outages of the past, but they tend to be a little rare, and not super common. If you were hosting your own crap, I bet they got you beat from an SLA percentage kind of level. You know? So it’s not like, “Don’t build in a resilient way,” but generally the type of companies that offer these things are pretty damn reliable. The chances of you going down because you screwed up that function are a lot higher than because their architecture is failing.

Drew: I suppose, I mean, just like anything where you’re using an API or something that can fail, is just making sure you structure your code to cope with that failure mode, and to know what happens next, rather than just throwing up an error to the user, or just dying, or what have you. It’s being aware of that and asking the user to try again. Or trying again yourself, or something.

Chris: Yeah, I like that idea of trying more than once, rather than just being, “Oh no. Fail. Abort.” “I don’t know, why don’t you try again there, buddy?”

Drew: So I mean, when it comes to testing and development of serverless functions, sort of cloud functions, is that something that can be done locally? Does it have to be done in the cloud? Are there ways to manage that?

Chris: I think there are some ways. I don’t know if the story is as awesome. It’s still a relatively new concept, so I think that that gets better and better. But from what I know, for one thing, you’re writing a fairly normal Node function. Assuming you’re using JavaScript to do this, and I know that on Lambda specifically, they support all kinds of stuff. You can write a fricking PHP Cloud Function. You can write a Ruby Cloud Function. So, I know I’m specifically talking about JavaScript, because I have a feeling that most of these things are JavaScript. Even no matter what language it is, I mean, you can go to your command line locally and execute the thing. Some of that testing is… you just test it like you would any other code. You just call the function locally and see if it works.

Chris: It’s a little different story when you’re talking about an HTTP request to it, that’s the thing that you’re trying to test. Does it respond to the request properly? And does it return the stuff properly? I don’t know. The network might get involved there. So you might want to write tests at that level. That’s fine. I don’t know. What is the normal story there? You spin up some kind of local server or something that serves it. Use Postman, I don’t know. But there’s… Frameworks try to help too. I know that the serverless “.com”, which is just terribly confusing, but there’s literally a company called Serverless and they make a framework for writing the serverless functions that helps you deploy them.

Chris: So if you like NPM install serverless, you get their framework. And it’s widely regarded as very good, because it’s just very helpful, but they don’t have their own cloud or whatever. You write these and then it helps you get them to a real lambda. Or it might work with multiple cloud providers. I don’t even know these days, but their purpose of existing is to make the deployment story easier. I don’t know what… AWS is not renowned for their simplicity. You know? There’s all this world of tooling to help you use AWS and they’re one of them.

Chris: They have some kind of paid product. I don’t even know what it is exactly. I think one of the things they do is… the purpose of using them is for testing, is to have a dev environment that’s for testing your serverless function.

Drew: Yeah, because I guess, that is quite a big part of the workflow, isn’t it? If you’ve written your JavaScript function, you’ve tested it locally, you know it’s going to do the job. How do you actually pick which provider it’s going to go into and how do you get it onto that service? Now, I mean, that’s a minefield, isn’t it?

Chris: Yeah. I mean, if you want to use no tooling at all, I think they have a really… like AWS, specifically, has a really rudimentary GUI for the thing. You can paste the code in there and hit save and be like, “Okay, I guess it’s live now.” That’s not the best dev story, but I think you could do it that way. I know CloudFlare workers have this thing called Wrangler that you install locally. You spin it up and it spins up a fake browser on the top and then dev tools below. Then you can visit the URL and it somehow intercepts that and runs your local cloud function against it. Because one of the interesting things about workers is… you know how I described how it… you don’t hit a URL and then it returns stuff. It just automatically runs when you… when it intercepts the URL, like CDN style.

Chris: So, one of the things it can do is manipulate the HTML on the way through. The worker, it has access to the complete HTML document. They have a jQuery-esque thing that’s like, “Look for this selector. Get the content from it. Replace it with this content. And then continue the request.” So you can mess with code on the way through it. To test that locally, you’re using their little Wrangler tool thing to do that. Also, I think the way we did it was… it’s also a little dangerous. The second you put it live, it’s affecting all your web traffic. It’s kind of a big deal. You don’t want to screw up a worker. You know? You can spin up a dev worker that’s at a fake subdomain, and because it’s CloudFlare, you can… CloudFlare can just make a subdomain anyway. I don’t know. It’s just kind of a nice way to do a… as you’re only affecting sub-domain traffic, not your main traffic yet. But the subdomain’s just a mirror of a production anyway, so that’s kind of a… that’s a testing story there.

Chris: It brings up an interesting thing, though, to me. It’s like… imagine you have two websites. One of them is… for us it’s like a Ruby on Rails app. Whatever. It’s a thing. But we don’t have a CMS for that. That’s just like… it’s not a CMS, really. I think there’s probably Ruby CMSs, but there’s not any renowned ones. You know? It seems like all the good CMSs are PHP, for some reason. So, you want a quality CMS. Drew, you’ve lived in the CMS market for a long time –

Drew: Absolutely.

Chris: … so you know how this goes. Let’s say you want to manage your sites in Perch or whatever, because it’s a good CMS and that’s the proper thing to use to build the kind of pages you want to build. But you don’t want to run them on the same server. Unless you want to manage the pages on one site, but show them on another site. Well, I don’t know, there’s any number of ways to do that. But one JavaScript way could be, “Okay, load the page. There’s an empty div there. Run some JavaScript. Ask the other site for the content of that page and then plunk it out on the new page.” That’s fine, I guess, but now you’re in a client side rendered page. It’s going to be slow. It’s going to have bad SEO, because… Google will see it eventually, but it takes 10 days or something. It’s just a bad story for SEO. It’s not very resilient, because who knows what’s going to happen in the network. It’s not the greatest way to do this kind of “content elsewhere, content on site B, show page of site A”, situation.

Chris: You could also do it on the server side, though. Let’s say you had… Ruby is capable of granting a network request too, but that’s even scarier because then if something fails on the network, the whole page could die or something. It’s like a nervous thing. I don’t love doing that either. But we did this just recently with a worker, in that we… because the worker’s JavaScript, it can make a fetch request. So, it fetches site A, it finds this div on the page, and then it goes and asks site B for the content. Gets the content. Plugs it into that div, and serves the page before it gets anything. So it looks like a server rendered page, but it wasn’t. It all happened at the… on the edge, at the worker level, at the serverless level.

Chris: So it’s kind of cool. I think you can imagine a fetch request on the browser probably takes, I don’t know, a second and a half or something. It probably takes a minute to do it. But because these are… site B is hosted on some nice hosting and Cloudflare has some… who knows what kind of super computers they use to do it. They do. Those are just two servers talking to each other, and that fetch request happens just so super duper, duper fast. It’s not limited to the internet connection speed of the user, so that little request takes like two milliseconds to get that data. So it’s kind of this cool way to stitch together a site from multiple sources and have it feel like, and behave like, a server rendered page. I think there’s a cool future to that.

Drew: Are there any sort of conventions that are sort of springing up around serverless stuff. I’m sort of thinking about how to architect things. Say I’ve got something where I want to do two sort of requests to different APIs. I want to take in a postal address and geocode it against one, and then take those coordinates and send that to a florist who’s going to flower bomb my front yard or something. How would you build that? Would you do two separate things? Or would you turn that into one function and just make the request once from the browser?

Chris: Mm (affirmative). That’s a fascinating question. I’d probably have an architect function or something. One function would be the one that’s in charge of orchestrating the rest of them. It doesn’t have to be, your website is the hub and it only communicates to this array of single sources. Serverless functions can talk to other serverless functions. So I think that’s somewhat common to have kind of an orchestrator function that makes the different calls and stitches them together, and returns them as one. I think that is probably smart and faster, because you want servers talking to servers, not the client talking to a whole bunch of servers. If it can make one request and get everything that it needs, I think that’s probably generally a good idea-

Drew: Yeah, that sounds smart. Yep.

Chris: But I think that’s the ultimate thing. You get a bunch of server nerds talking, they’ll talk about the different approaches to that exact idea in 10 different ways.

Drew: Yeah. No, that sounds pretty smart. I mean, you mentioned as well that this approach is ideal if you’re using APIs where you’ve got secret information. You’ve got API keys or something that you don’t want to live in the client. Because I don’t know, maybe this florist API charges you $ 100 dollars every time flower bomb someone.

Chris: Easily.

Drew: You can basically use those functions to almost proxy the request and add in the secret information as it goes, and keep it secret. That’s a viable way to work?

Chris: Yeah, yeah. I think so. I mean, secrets are, I don’t know, they’re interesting. They’re a form of buy in I think to whatever provider you go with, because… I think largely because of source control. It’s kind of like, you could just put your API key right in the serverless function, because it’s just going to a server, right? You don’t even have to abstract it, really. The client will never see that code that executes, but in order for it to get there, there’s probably a source control along the way. It’s probably like you commit to master, and then master… then some kind of deployment happens that makes that thing go to the serverless function. Then you can’t put your API key in there, because then it’s in the repo, and you don’t put your API keys in repos. That’s good advice. Now there’s stuff. We’ve just done… at CodePen recently, we started using this git-crypt thing, which is an interesting way to put keys safely into your repos, because it’s encrypted by the time anybody’s looking at that file.

Chris: But only locally they’re decrypted, so they’re useful. So it’s just kind of an interesting idea. I don’t know if that helps in this case, but usually, cloud providers of these things have a web interface that’s, “Put your API keys here, and we’ll make them available at runtime of that function.” Then it kind of locks… it doesn’t lock you in forever but it kind of is… it’s not as easy to move, because all your keys are… you put in some input field and some admin interface somewhere.

Drew: Yeah, I think that’s the way that Netlify manage it.

Chris: They all do, you know?

Drew: Yeah. You have the secret environment variables that you can set from the web interface. That seems to work quite nicely.

Chris: Yeah, right. But then you got to leave… I don’t know, it’s not that big of a deal. I’m not saying they’re doing anything nefarious or anything. How do you deal with those secrets? Well, it’s a hard problem. So they kind of booted it to, I don’t know, “Just put them in this input field and we’ll take care of it for you, don’t worry about it.”

Drew: Is there anything that you’ve seen that stands out as an obvious case for things that you can do with serverless, that you just couldn’t do with a traditional kind of serverfull approach? Or is it just taking that code and sort of almost deploying it in a different way?

Chris: It’s probably mostly that. I don’t know that it unlocks any possibility that you just absolutely couldn’t run it any other way. Yeah, I think that’s a fair answer, but it does kind of commoditize it in an interesting way. Like, if somebody writes a really nice serverless function… I don’t know that this exists quite yet, but there could kind of a marketplace, almost, for these functions. Like, I want a really good serverless function that can take a screenshot. That could be an open source project that lots of eyeballs around, that does a tremendously good job of doing it and solves all these weird edge cases. That’s the one I want to use. I think that’s kind of cool. You know? That you can kind of benefit from other people’s experience in that way. I think that will happen more and more.

Drew: I guess it’s the benefit that we talked about, right at the top, of enabling people who write JavaScript and may have written JavaScript only for the front-end, to expand and use those skills on the back-end as well.

Chris: Yeah, yeah. I think so, I think that’s… because there’s moments like… you don’t have to be tremendously skilled to know what’s appropriate and what’s not for a website. Like, I did a little tutorial the other week, where there was this glitch uses these… when you save a glitch, they give you a slug for your thing that you built, that’s, “Whiskey, tango, foxtrot. 1,000.” It’s like a clever little thing. The chances of it being unique are super high, because I think they even append a number to it or something too. But they end up being these fun little things. They open source their library that has all those words in it, but it’s like a hundred, thousands of words. The file is huge. You know? It’s megabytes large of just a dictionary of words. You probably learn in your first year of development, “Don’t ship a JavaScript file that’s megabytes of a dictionary.” That’s not a good thing to ship. You know? But Node doesn’t care. You can ship hundreds of them. It’s irrelevant to the speed on a server.

Drew: Yeah.

Chris: It doesn’t matter on a server. So, I could be like, “Hmm, well, I’ll just do it in Node then.” I’ll have a statement that says, “Words equal require words,” or whatever, and a note at the top, “Have it randomize a number. Pull it out of the array and return it.” So that serverless function is eight lines of code with a packaged@JSON that pulls in this open source library. And then my front-end code, there’s a URL to the serverless function. It hits that URL. The URL returns one word or a group of words or whatever. You build your own little API for it. And now, I have a really kind of nice, efficient thing. What was nice about that is, it’s so simple. I’m not worried about the security of it. I don’t… you know?

Chris: It’s just… a very average or beginner JavaScript developer, I think, can pull that off, which is cool. That’s an enabling thing that they didn’t have before. Before, they were like, “Well, here’s a 2MB array of words.” “Oh, I can’t ship that to the client.” “Oh, you’ll just shut down then.” You might hit this wall that’s like, “I just can’t do that part then. I need to ask somebody else to help me with that or just not do it or pick more boring slugs or some…” It’s just, you have to go some other way that is a wall to you, because you couldn’t do it. And now, you’re, “Oh, well, I’ll just…” Instead of having that in my script slash, or in my source slash scripts folder, I’ll put it in my functions folder instead.

Chris: You kind of like moved the script from one folder to the other. And that one happens to get deployed as a serverless function instead. How cool is that? You know? You’re using the same exact skill set, almost. There’s still some rough edges to it, but it’s pretty close.

Drew: It’s super cool. You’ve put together a sort of little micro site all about these ideas, haven’t you?

Chris: Yeah. I was a little early to the game. I was just working on it today, though, because… it gets pull requests. The idea… well, it’s at serverless.css-tricks.com and… there’s a dash in CSS-Tricks, by the way. So it’s a subdomain of CSS-Tricks, and I built it serverlessly too, so this is… CSS-Tricks is like a WordPress site, but this is a static site generator site. All the content of it is in the GitHub repo, which is open-source. So if you want to change the content of the site, you can just submit a poll request, which is nice because there’s been a hundred or so of those over time. But I built all the original content.

Drew: It’s a super useful place, because it lists… If you’re thinking, “Right, I want to get started with serverless functions,” it lists all the providers who you could try it and…

Chris: That’s all it is, pretty much, is lists of technology. Yeah.

Drew: Which is great, because otherwise, you’re just Googling for whatever and you don’t know what you’re finding. Yeah, it’s lists of API providers that help you do these sorts of things.

Chris: Forms is one example of that, because… so the minute that you choose to… let’s say, you’re going to go JAMstack, which I know that’s not necessarily the point of this, but you see how hand in hand they are. All of a sudden, you don’t have a PHP file or whatever to process that form with. How do you do forms on a JAMstack site? Well, there’s any number of ways to do it. Everybody and their sister wants to help you solve that problem, apparently. So I think if I was the inventor of the word JAMstack, so they try to help you naturally, but you don’t have to use them.

Chris: In fact, I was so surprised putting this site together. Let’s see. There’s six, nine, twelve, fifteen, eighteen, twenty one, twenty two services out there, that want to help you serverlessly process your forms on this site right now. If you want to be the 23rd, you’re welcome to it, but you have some competition out there. So the idea behind this is that you write a form in HTML, like literally a form element. And then the action attribute of the form, it can’t point anywhere internally, because there’s nothing to point to. You can’t process, so it points externally. It points to whatever they want you to point it to. They’ll process the form and then they tend to do things that you’d expect them to, like send an email notification. Or send a Slack thing. Or then send it to Zapier and Zapier will send it somewhere else. They all have slightly different feature sets and pricing and things, but they’re all trying to solve that problem for you, like, “You don’t want to process your own forms? No problem. We’ll process it for you.”

Drew: Yeah, it’s a super useful resource. I’d really recommend everyone check it out. It’s serverless.css-tricks.com. So, I’ve been learning all about serverless. What have you been learning about lately, Chris?

Chris: Well, I’m still very much in this world too and learning about serverless stuff. I had an idea to… I used to play this online role playing game ages ago. I just recently discovered that it’s still alive. It’s a text based medieval fantasy kind of game. I played it when AOL was a thing, because AOL wanted to have these games that you had to be logged on to play it, because they wanted you to spend hours and hours on AOL, so they could send you these huge bills, which was, I’m sure, why they did so well at some point.

Drew: So billing by the second. Yeah.

Chris: Yeah. So games was big for them. If they could get you playing games with other people on there. So this game kind of… it didn’t debut there, but it moved to AOL, because I’m sure they got a juicy deal for it, but it was so… I mean, it’s just, couldn’t possibly be nerdier. You’re a dwarven mage and you get rune staff from your leather sheath. And you type commands into it like a terminal. Then the game responds to you. I played that game for a very long time. I was very into it. I got into the community of it and the spirit of it. It was kind of a… it was like I was just alone by myself at my computer, but yet I look back on that time in my life, and be like, “That was a wonderful time in my life.” I was really… I just liked the people and the game and all that. But then I grew up and stopped playing it, because life happens to you.

Chris: I only found out recently, because somebody started doing a podcast about it again… I don’t know how I came across it, but I just did. I was like, “This game is alive and well in today’s world, are you kidding me? This text based thing.” And I was more than happy to reactivate and get my old characters back and play it. But only to find out that the clients that they have you download for this game, haven’t evolved at all. They are awful. They almost assume that you’re using Windows. There’s just these terribly cheesy poorly rendering… and it’s text based, you think it’d at least have nice typography. No. So I’m like, “I could be involved. I could write a client for this game. Put beautiful typography in it.” Just modernize the thing, and I think the players of the game would appreciate it, but it felt overwhelming to me. “How can I do it?” But I find some open source projects. One of them is like… you can play the game through an actual terminal window, and it uses some open source libs to kind of make a GUI out of a terminal window.

Drew: Really?

Chris: I don’t know. So that was kind of cool. I was like, “If they wrote that, there must be code in there to how to connect to the game and get it all going and stuff. So at least I have some starter code.” I was trying to go along the app, “Maybe I’ll do it in Flutter or something,” so the final product app would work on mobile phones and, “I could really modernize this thing.” But then I got overwhelmed. I was like, “Ah, this is too big a… I can’t. I’m busy.” But I found another person who had the same idea and they were way further along with it, so I could just contribute on a design level. And it’s been really fun to work on, but I’ve been learning a lot too, because it’s rare for me to jump into a project that’s somebody else’s baby, and I’m just contributing to a little bit, and that has totally different technology choices than I would have ever picked.

Chris: It’s an Electron app. They picked that, which is also kind of a cool way to go too, because it’s my web skills… so I’m not learning anything too weird, and it’s cross-platform, which is great. So, I’ve been learning a lot about Electron. I think it’s fun.

Drew: That’s fascinating. It’s always amazing how little side projects and things that we do for fun, end up being the place where we sometimes learn the most. And learn skills that can then feed back into our sort of daily work.

Chris: That’s the only way I learn things. I’m dragged into something that… I was like, “They’re not…” It’s rendered with a JavaScript library called Mithril, which is… I don’t know if you’ve ever heard of it, but it’s weird. It’s not… it’s almost like writing React without JSX. You have to “create element” and do all these… but it’s supposed to benchmark way better than it… And it actually kind of matters because in this text based game, the text is just flying. There’s a lot of data manipulation, which is like… you’d think this text based game would be so easy for a browser window to run, but it’s actually kind of not. There’s so much data manipulation happening, that you really have to be really… we have to be conscientious about the speed of the rendering. You know?

Drew: That’s fascinating-

Chris: Pretty cool.

Drew: Yeah. If you, dear listener, would like to hear more from Chris, you can find him on Twitter, where he’s @chriscoyier. Of course, CSS-Tricks can be found at css-tricks.com and CodePen at codepen.io. But most of all, I recommend that you subscribe to the ShopTalk Show podcast if you haven’t already done so, at shoptalkshow.com. Thanks for joining us today, Chris. Do you have any parting words?

Chris: Smashingpodcast.com. I hope that’s the real URL.

Smashing Editorial (il)


Articles on Smashing Magazine — For Web Designers And Developers

chris-ferdinandi-200x200-opt
28 Jul

Smashing Podcast Episode 21 With Chris Ferdinandi: Are Modern Best Practices Bad For The Web?

by TBSCategories: News

Smashing Podcast Episode 21 With Chris Ferdinandi: Are Modern Best Practices Bad For The Web?

Smashing Podcast Episode 21 With Chris Ferdinandi: Are Modern Best Practices Bad For The Web?

Drew McLellan

Photo of Chris FerdinandiToday, we’re asking if modern best practices are bad for the web? Are modern frameworks taking us down the wrong path? I speak to Lean Web expert Chris Ferdinandi to find out.

Show Notes

Weekly Update

Transcript

Drew McLellan: He’s the author of Vanilla JS Pocket Guide Series, creator of the Vanilla JS Academy Training Program, and host of the Vanilla JS Podcast. He’s developed a Tips newsletter, it’s read by nearly 10,000 developers each weekday. He’s taught developers at organizations like Chobani and The Boston Globe. And his JavaScript plugins have been used by organizations like Apple and Harvard Business School. Most of all, he loves to help people learn Vanilla JavaScript. So we know he’d rather pick Vanilla JavaScript over a framework, but did you know he was once picked out in a police lineup as being the person least likely to have committed the crime? My Smashing friends, please welcome Chris Ferdinandi. Hello, Chris. How are you?

Chris Ferdinandi: Oh, I’m smashing. Thanks for having me.

Drew: I wanted to talk to you today about this concept of a Lean Web, which something of a passion for you, isn’t it?

Chris: Yes, very much so.

Drew: Why don’t you set the scene for us? When we talk about a Lean Web, what is the problem we are trying to solve?

Chris: Yeah, great question. Just as a caveat for all the listeners, this episode might get a little old man yells at cloud. I’m going to try to avoid that. When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. I’ve come to believe that a lot of what we think of as best practices today might actually be making the web worse.

Chris: The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I’m sorry, not the developer experience. The user experience rather, over the developer experience, and the ease of building things from a team perspective, which is what I think where we put a lot of focus today and as we’ll probably get into in our conversation.

Chris: I’ve actually come to find that a lot of these things we think of as improving the developer experience do so for a subset of developers, but not necessarily everybody who’s working on the thing you’re building. So there’s a whole bunch of issues with that too, that we can dig into. But really, the Lean Web is about focusing on simplicity and performance for the user and really prioritizing or putting the focus on the people who use the things we make rather than us, the people who are making it.

Drew: As the web matures as a development platform, there seems to be this ever increasing drive towards specialization.

Chris: Yes.

Drew: People who used to cover Full Stack, and then we split into front-end and back-end. And then that front-end split into people who do CSS or JavaScript development. And then increasingly within JavaScript, it becomes more specialized. Somebody might consider themselves and market themselves as a React developer or an Angular developer, and their entire identity and outlook is based around a particular framework that they are highly skilled in. Is this dependency on frameworks, the core of our work on the web, a bad thing?

Chris: It’s nuanced. I used to be very strongly in the yes, always camp. I think broadly, I still feel like yes, our obsession as an industry with frameworks and tools in general really, is potentially a little bit to our detriment. I don’t think frameworks are inherently bad. I think they’re useful for a very narrow subset of use cases. And we end up using them for almost everything, including lots of situations where they’re really not necessarily the best choice for you or for the project.

Chris: When I think about a lot of the issues that we have on the web today, the core of those issues really starts with our over-reliance on frameworks. Everything else that comes after that is in many ways, because we throw so much not just frameworks which is JavaScript in general, at the web. I say that as someone who professionally teaches people how to write and use JavaScript. That’s how I make my money. And I’m here saying that I think we use too much JavaScript, which is sometimes a little bit of an odd thing.

Drew: In the time before the big frameworks sprouted up, we used to build user interfaces and things with jQuery or whatever. And then frameworks came along and they gave us more of this concept of a state-based UI.

Chris: Yes.

Drew: Now, that’s a fairly complex bit of engineering that you’re required to get in place. Does working with less JavaScript exclude using something like that, or do you have to re-implement it yourself? Are you just creating a loaded boilerplate?

Chris: A lot of it depends on what you’re doing. If you have a non-changing interface, you can build a state-based UI with… I don’t know, maybe a dozen or so lines of code. If you have a non-changing interface, I would honestly probably say state-based UI. It’s not necessarily the right approach. There’s probably other things you can do instead. Think of static site generators, some pre-rendered markup, even an old-school WordPress or PHP driven site.

Chris: But where this starts to get interesting is when you get into more dynamic and interactive interfaces. Not just apps. I know people love to draw this line between websites and apps, and I think there’s this weird blend between the two of them and the line is not always as clear. When you start to get into more the user does stuff, something changes. State-based UI becomes a little bit more important. But you still don’t need tons of code to make that happen.

Chris: I look at something like React or Vue, which are absolutely amazing pieces of engineering. I don’t want to take away from the people who work on those. I ended up as a learning exercise, building my own mini-framework just to get a better sense for how these things work under the hood. It is really hard to account for all of the different moving pieces. So I have tremendous respect for the people who build and work on these tools. But React and Vue are both about 30 kilobytes after minifying and gzipping. So once you unpack them, they’re substantially bigger than that.

Chris: Not all of it, but a good chunk of that weight is devoted to this thing called the virtual DOM. There are alternatives that use similar APIs or approaches. For React, you have Preact, which is 2.5 kilobytes or about 3 kilobytes instead of 30. It’s a tenth of the size. For Vue, you have Alpine JS instead, which is about 7 kilobytes. Still, substantially smaller. The big difference between those and their big brother counterparts, is that they’ve shed the virtual DOM. They may drop a method or two. But generally, it’s the same approach and the same kind of API in the way of working with code, and they’re substantially smaller.

Chris: I think a lot of the tools we use are potentially overpowered for the things we’re trying to do. If you need a state-based UI and you need reactive data and these dynamic interfaces, that’s great. I think one of the big things I try and talk about today is not… never use tools. For me, Vanilla JS is not you’re handwriting every single line of code and every single project you do. That’s madness. I couldn’t do that, I don’t do that. But it’s being more selective about the tools we use. We always go for the multi-tool, the Swiss Army knife that has all these things in it. And sometimes, all you really need is a pair of scissors. You don’t need all the other stuff, but we have it anyways.

Chris: Which is a really long way to… I’m sorry, of answering your question. Which is sometimes it’s more code than you could or would want to write yourself, but it’s not nearly as much code as I think we think it requires. When I say you don’t need a framework, I get a lot of push-back around this idea that, “Well, if you don’t use a framework, you’re basically writing your own.” Then that comes with its own problems. I think there’s a place in between using React or Vue and writing your own framework, and it’s maybe picking something that’s a little bit smaller. There are sometimes reasons where writing your own framework might actually be the right call, depending on what you’re trying to do. It’s all very fluid and subjective.

Drew: It’s quite interesting that as a learning exercise, you implemented your own state-based framework. I remember in the past, I used to think that every time I reached for a library or something, I liked to think that I could implement it myself.

Chris: Sure, sure.

Drew: But reaching for the library saved me the hassle of doing that. I knew if I had to write this code myself, I knew what approach I’d take to do it. And that was true all the way up to using things like jQuery and things. These days, I think if I had to write my own version of Vue or React, I have almost no idea what’s happening now in that library, in all that code.

Drew: For those of us who are not familiar, when you say something like Preact drops the virtual DOM and makes everything a lot smaller, what’s that virtual DOM giving us?

Chris: To answer that question, I want to take just a slight step back. One of the nicest things that frameworks and other state-based libraries give you is DOM diffing. If you’re not really updating the UI that much, you could get by with saying, “Here’s a string of what the markup is supposed to look like. In HTML, I’ll just put all this markup in this element.” When you need to change something, you do it again. That is a little expensive for browsers, because it triggers a repaint.

Chris: But I think potentially more importantly than that, one of the issues with doing that is that you have any sort of interactive element in there, a form-field, a link that someone has focused on. That focus is lost because the element… even though you have a new thing that looks similar, it’s not the same literal element. So if focus is lost, it can create confusion for people using screen readers. There’s just a whole bunch of problems with that.

Chris: Any state-based UI thing worth its weight is going to implement some for of DOM diffing, where they say, “Here’s what the UI should look like. Here’s what it looks like right now in the DOM. What’s different?” And it’s going to go and change those things. It’s effectively doing the stuff you would do just manually updating the UI yourself, but it’s doing it for you under the hood. So you can just say, “Here’s what I want it to look like.” And then the library or framework figures it out.

Chris: The smaller things like Preact or Alpine, they’re actually doing that directly. They’re converting the string you provide them of what the UI should look like into HTML elements. And then they’re comparing each element to its corresponding piece in the literal DOM. As you end up with UIs that get bigger and bigger and bigger, that can have a performance implication because querying the DOM over and over again becomes expensive. If you want to get a sense for the type of interface where this becomes a problem, right-click and inspect element on the “Favorite” button on Twitter, or the “Like” button on Facebook. And take a look at the nesting of divs that gets you to that element. It’s very, very deep. It’s like a dozen or so divs, nested one inside the other just for that single tweet.

Chris: When you start going that many layers down, it starts to really impact performance. What the virtual DOM does is instead of checking the real DOM every time, it creates an object-based map of what the UI looks like in JavaScript. And then does the same thing for the UI you want to replace the existing one with, and it compares those two. That’s a lot more performance in theory, than doing that in the real DOM. Once it gets a list of the things it needs to change, it just runs off and makes those changes. But it only has to attack the DOM once. It’s not checking every single element, every single time. If you have interfaces like Twitters or Facebooks or QuickBooks or something like that, virtual DOM probably makes a lot of sense.

Chris: The challenge with it is… the difference between Preact and React is 27 kilobytes before you unpack the whole thing into its actual codewave. The raw download and unpacking and compiling time on that alone can add quite a bit of latency to the initial load on a UI. That becomes even more pronounced if your users are on not the latest devices from Apple. Even an Android device from a couple of years ago or a feature phone, or if you have people in developing countries, it’s just really… the time to get going is slower. And then on top of that, the actual interactive time is slower because of the extra abstraction.

Chris: So it’s not just you load it and they’re comparable in speed. Each micro interaction that someone makes and the changes that need to happen can also be slightly slower just because of all that extra code in there. If you have a really, really complex UI with lots of nested elements and lots of data, then the virtual DOM’s performance gains outweigh that extra code weight. But any typical UI for a typical app that most of what I see developers using React or Vue for, the benefit you get from the virtual DOM just isn’t there and they’d be better off. Even if you want to keep the same convenience of React, use Preact. It’s a fraction of the size, it’ll work exactly the same way, and it’ll more performing. This is the kind of thing that I tend to argue for.

Chris: We need to be better about picking the right tool for the job. If you go with an approach like that, if you get to a point where a virtual DOM actually makes sense, it’s much easier to port Preact into React than if you rolled your own. That’s the situation. If you’re really worried about that, you get some future-proofing built in too.

Drew: Some might say, they might make the argument that these frameworks, things like Vue, React are so highly optimized for performance that you get so much benefit there that surely just pairing that with a package manager in a bundler to make sure you’re only sending down the code that you want to. Surely, you are way ahead already just by doing that?

Chris: Yeah. I don’t agree. I don’t really have much more to elaborate on that other than… I guess maybe, but not really. Even with a bundler, you still need that React core. Even with the bundling, that’s still going to be bigger than using something like Preact.

Chris: Drew, I really appreciate you leading the question on this. Because one of the other things I do talk about in my book, The Lean Web, and my talk of the same name, is how these tools… You mentioned the bundling, for example. One of the things we do to get around the performance hit that we take from using all this JavaScript is we throw even more JavaScript at the front-end to account for it. One of the ways we do that is package managers and module bundlers.

Chris: As you alluded to… for those of you who don’t know, these are tools that will… they will compile all of your little individual JavaScript bits into one big file. The newer ones and the more… I don’t want to call them thoughtful. But the newer ones will use a feature called tree shaking, where they get rid of any code that isn’t actually needed. If that code has some dependencies that aren’t used for the thing you’ve actually done, they’ll drop some of that stuff out to make your packages as small as possible. It’s actually not a terrible idea, but it results in this thing I typically call dependency health where you have this really delicate house of cards of dependencies on top of dependencies on top of dependencies.

Chris: Getting your process set up takes time. And anybody who has ever run an NPM install and then discovered that a bunch of dependencies were out of date and had to spend an hour trying to figure out which ones needed to be fixed and oh, it’s actually a dependency in a dependency and you don’t have the ability to go fix it yourself. It’s a whole thing. Maybe it works for you, but I’d rather spend my time not messing around trying to get my dependencies together.

Chris: I’ve started collecting tweets from people where they complain about time wasted on their workflow. One of my favorites, Brad Frost a couple year ago, was talking about the depressing realization that the thing you’ve been slogging through in modern JS could have taken you 10 minutes in jQuery. I’m not really a jQuery fan, but I feel that pain when it comes to working with frameworks.

Chris: The other issue with a lot of these tools is they start to become gatekeepers. I don’t know how much you really want to dive into this or not, Drew. But one of my big push-backs against JS, all the things in a workflow. Especially when you start to then say, “Well, if we’re already using JS for the HTML, why not use it for CSS too?” You start to exclude a lot of really talented people from the development process. It’s just a really big loss for the project for the community as a whole.

Drew: Well, I certainly am… I started picking up React at the beginning of 2020, adding that to my skillset. I’ve been doing it now for nearly seven months. I’ve got to say one part I’m least confident in is setting up the tooling around getting a project started.

Drew: It seems like there’s an awful lot of work to get something to Hello World, and there’s even more that you’ve got to know to get it to be production ready. That has to make development more difficult to get started with if this is being put forward as what you should be doing in 2020 to learn to be a web developer. Somebody coming in new to it is going to have a real problem. It’s going to be a real barrier to entry, isn’t it?

Chris: Absolutely. The other piece here is that JavaScript developers aren’t always the only people working on a code base or contributing in a meaningful way to that code base. The more we make knowing JavaScript a requirement for working with a code base, the less likely those people are to be able to actually participate in the project.

Chris: An example of that, that I like to talk about is WordPress, who has been recently… I shouldn’t say recently at this point. It’s been a couple of years now. But they’ve been shifting their back-end stack more and more to JavaScript, away from PHP, which is not inherently a bad thing. Their new editor, Gutenburg, is built on React.

Chris: In 2018, WordPress’s lead accessibility consultant, Rian Rietveld, whose name I almost certainly butchered… she very publicly resigned from her positioned and documented why in a really detailed article. The core of the problem was that her and her team were tasked with auditing this editor to make sure that it was going to be accessible. WordPress comprises now 30% of the web. Their goal is to democratize publishing, so accessibility is a really important part of that. It should be an important part of any web project. But for them in particular, it is acutely important. Her team’s whole job is to make sure… her team’s whole job was to make sure that this editor would be accessible. But because neither she nor anyone on her team had React experience and because they couldn’t find volunteers in the accessibility community with that experience, it made it really difficult for her and her team to do their work.

Chris: Historically, they could identify errors and then go in and fix them. But with the new React based workflow, they were reduced to identifying bugs and then filing tickets. They got added to a backlog along with all the other feature development requests that the JavaScript developers were working on. A lot of stuff that could have been easily fixed didn’t make it into the first release.

Chris: In May of 2019, about a year after Rian resigned, there was a detailed accessibility audit done on Gutenburg. The full report was 329 pages. The executive summary alone was 34 pages. It documented 91 accessibility related bugs in quite a bit of detail. Many of these were really… I don’t want to call them simple low-hanging fruit, but a lot of them were basic things that Rian’s team could have fixed and it would have freed up the developers to focus on feature development. That’s ultimately what it seems like they ended up doing, was spending a lot of time on feature development and pushing this stuff off til later. But that team is super important to the project, and they suddenly got locked out of the process because of a technical choice.

Chris: Alex Russell is a developer on the Chrome team. He wrote this article a couple of years ago called The Developer Bait and Switch, where he talked about the straw man argument of frameworks. This idea that these tools let you move faster and because of that, you can iterate faster and deliver better experiences. It’s this idea that a better developer experience means a better user experience. I think this is a very clear example of how that argument doesn’t always play out the way people believe it does. It’s a better experience for maybe some people, not for everyone.

Chris: CSS developers, people working on design systems, their ability to create tools that others can use sometimes gets limited by these tool choices too. In my experience, I used to be better at CSS. It’s changed a lot in the last few years and I am nowhere near as good as I used to be. In my experience, the people who are really advanced CSS developers… and I do mean that in the truest sense. People who work on CSS are proper web developers working on a programming language. It’s a very special, or can be a very specialized thing. The people who are exceptionally good at it, in my experience, are not always also very good at JavaScript because you end up diving really deep into one thing and you slide a little bit on some other stuff. Their ability to work with these technologies gets hindered as well, which is too bad because it used to not be the case.

Chris: When the stack was simpler, it was easier for people from multiple disciplines to participate in the development process. I think that’s to the detriment of both the things we build and the community at large, when that’s no longer the case.

Drew: I found recently in a project researching ways to deal with some of the CSS problems, workflow problems, we’re having multiple working on the project and the bundle size increasing and the old CSS never getting removed. It was a React project, so we were looking at some of these CSS in JavaScript approaches to see what would be best for us to use to solve the problems that we had. What became very quickly apparent is there’s not only one solution to do this. There are dozens of different ways you could do this.

Drew: CSS in JS is a general approach, but you might go from one project to the next and it’s completely influenced in a completely different way. Even if you’re a CSS person and you learn a particular approach on a project, those skills may not be transferrable anyway. It’s very difficult to see how somebody should investment too much time in learning that if they’re not particularly comfortable with JavaScript.

Chris: Yeah. The other interesting thing that I think you just got out a little bit is when I talk about this, one of the biggest pieces of push-back I get is that frameworks enforce conventions. You’re going with Vanilla JavaScript, you’ve got this green field-blue sky, you can do anything you want kind of project. With React, there’s a React way to do things.

Chris: But one of the things I have found is that there are Reacty approaches, but there’s not a strict one right way to do things with React. It’s one of the things people love about it. It’s a little bit more flexible, you can do things a couple of different ways if you want. Same with Vue. You can use that HTML based thing where you’ve got your properties right in the HTML and Vue replaces them, but you can also use a more JSX-like templating kind of syntax if you’d prefer.

Chris: I’ve heard multiple folks complain about when they’re learning React, one of the big problems is you Google how to do X in React and you get a dozen articles telling you a dozen different ways that you could do that thing. That’s not to say they don’t put some guardrails on a project. I don’t think it’s as clearcut as, “I’ve chosen a framework. Now this is the way I build with it.” To be honest, I don’t know that that’s necessarily something I’d want either. I don’t think you’d want those tightly confined… some people do, maybe. But if you’re touting that as a benefit, I don’t think it’s quite as pronounced as people sometimes make it out to be.

Chris: You got into an interesting thing though just there, where you were mentioning the CSS that is no longer needed. I think that is one of the legitimately interesting things that something like CSS and JS… or tying your CSS to JavaScript components in some way can get you is if that component drops out, the CSS also in theory, goes away with it. A lot of this to me feels like throwing engineering at people problems. Invariably, you’re still dependent on people somewhere along the line. That’s not to say never use those approaches, but they’re certainly not the only way to get at this problem.

Chris: There are tools you can use to audit your HTML and pull out the styles that aren’t being used even without using CSS and JavaScript. You can write CSS “the old-fashioned way” and still do the linting of unused styles. There are authoring approaches to CSS that give you a CSS in JS-like output and keep your style sheet small without spitting out these gibberish human unreadable class names that you get with CSS and JS sometimes. Like X2354ABC, or just these nonsense words that get spit out.

Chris: This is where I start to get really into the old man yells at cloud kind of thing. I’m really showing my developer age here. But yeah, it’s not necessarily that these things are bad, and they’re built to solve legitimate problems. I sometimes feel like there’s a little bit of a… if it’s good enough for Facebook, it’s good enough for us kind of thing that happens with these. Well, Facebook uses this tool. If we’re a real engineering program… team, department, organization, we should too. I don’t necessarily think that’s the right way to think about it. It’s because Facebook deals with problems that you don’t, and vice-versa. The size and scale of what they work on is just different, and that’s okay.

Drew: Exactly. I see some of these things like CSS and JavaScript to be almost like a polyfill. We’ve got legitimate problems, we need a way to solve it. The technology isn’t providing us a way to solve it yet. Maybe whilst we wait for the web platform to evolve and to get around to addressing that problem, this thing that we do right now with JavaScript kind of will see us through and we’ll be okay. We know it’s bad. We know it’s not a great solution, but it helps us right now. And hopefully in the while we can pull it out and use the native solution.

Chris: It’s really funny you bring this up. Because literally last night, I was watching a talk from Jeremy Keith from last year about progressive web apps. But he was talking about how a couple of decades ago, he was trying to convince people to use JavaScript. Which seems ridiculous at the time, but JavaScript was this new thing. He showed people how you could do cool things like change the color of a link on hover with this new… It seems absurd that you would need JavaScript for that now, because that’s what CSS does for you. But things like the focus attribute or property just didn’t exist at the time.

Chris: One of the things he said in the talk that I think really resonated with me is that JavaScript in many ways, paves those cow paths. It’s this very flexible and open language that we can use to create or bolt in features that don’t exist yet. And then eventually, browsers catch up and implement these features in a more native way. But it takes time. I completely understand what you’re saying about this. It’s not the perfect solution, but it’s what we have right now.

Chris: I think for me, the biggest difference between polyfills and some of these solutions is polyfills are designed to be ripped out. If I have a feature I want to implement that the browser doesn’t support yet, but there’s some sort of specification for it and I write a polyfill… once browsers catch up, I can rip that polyfill out and I don’t have to change anything. But when you go down the path of using some of these tools, ripping them up out means rewriting your whole code base. That’s really expensive and problematic. That’s not to say never use them, but I feel really strongly that we should be giving thought to picking tools that can easily be pulled out later. If we no longer need them or the platform catches up, it doesn’t require a huge rewrite to pull them out.

Chris: So getting to that we have a whole bunch of styles we don’t use anymore thing, that’s why I would personally favor a build tool technology that audits your CSS against the rendered markup and pulls out the things you don’t need. Because down the road if a platform catches up, you can pull that piece of the build tool out without having to change everything. It’s just augmenting what you already have, whereas CSS and JS doesn’t give you that same kind of benefit. I’m just picking on that one, but I think about a lot of these technologies more broadly.

Chris: I do feel things like React or Vue are probably paving some cow paths that browsers will eventually catch up with and probably use similar approaches if not the same, so there may be less rewriting involved there. A lot of the ecosystem stuff that gets plugged in around that may be less so.

Drew: I think it’s right, isn’t it, that the web platform moves slowly and carefully. You think if five years ago, we were all putting JavaScript Carousels on our pages. They were everywhere. Everyone was implementing JavaScript Carousels. If the web platform had jumped and implemented a Carousel solution to satisfy that need, it would not be sat there with nobody using it because people aren’t doing that with Carousels anymore. Because it was just a fad, a design trend. To counteract that and stop the platform itself becoming bloated and becoming a problem that needs solving, it does have to move at a lot steadier pace. The upshot of that is HTML that I wrote in 1999 still works today because of that slow process.

Drew: One of the other areas where things seem to be bloating out on the web is… I guess it’s related to the framework conversation. But it’s the concept of a single-page app. I feel like that a lot of promises are made around single-page apps as to their performance, like you’re getting all this benefit because you’re not reloading the entire page framework. I feel like they don’t always make good on those performance promises. Would you agree with that?

Chris: Yes. Although I will confess, despite having a very lengthy chapter in my book on this and talking about that a lot in talks and conversations with people, I don’t think single-page apps are always a terrible thing. But I do think this idea that you need one for performance is overstated. You can oftentimes get that same level of performance with different approaches.

Chris: I think one of the bigger challenges with single-page apps is… For anybody who’s unfamiliar with those. When a single-page app, instead of having separate HTML files or if you’re using something like a database driven site like WordPress, even though you don’t have actual physical HTML files for each page in your WordPress site, WordPress is creating HTML files on the fly and sending them back to browsers when URLs are requested. For purposes of this conversation, instead of having separate HTML files for every view in your app, a single-page app has a single HTML file. That’s what makes it a single-page app. JavaScript handles everything. Rendering the content, routing to different URL paths, fetching new content if it needs to from an API or something like that.

Chris: One of the spoken benefits of these or stated benefits of these is that only the content on the page changes. You don’t have to re-download all the JS and the CSS. Oh, and you can do those fancy page transitions that designers sometimes love. In theory, this is more performant than having to reload the whole page.

Chris: The problem with this approach from my perspective is that it also breaks a bunch of stuff that the browser just gives you for free out-of-the-box, and then you need to recreate it with more JS. You have an app that’s slow because it has a lot of JS. So you throw even more JavaScript at it to improve that performance and in doing so, you break a bunch of browser features and then have to re-implement those with even more JS too.

Chris: For example, some things that the browser will do for free with a traditional website that you need to recreate with JavaScript when you go the single-page app. You need to intercept clicks on links and suppress them from actually firing, with your JavaScript. You then need to figure out what you actually need to show based on that URL, which is normally something that would get handled on the server or based on the file that goes with that URL path. You need to actually update the URL in the address bar without triggering a page reload. You need to listen for forward and back clicks on the browser and update content again, just like you would with clicks on links. You need to update the document title.

Chris: You also need to shift focus in a way that announces the change in page to people who are using screen readers and other devices so that they’re not confused about where they are or what’s going on. Because they can’t see the change that’s happening, they’re hearing it announced. If you don’t actually shift focus anywhere, that announcement doesn’t happen. These are all things that the browser would do for you that get broken with single-page apps.

Chris: On top of that, because you have all this extra JavaScript, this is complicated. So most people use frameworks and libraries to handle this sort of thing. Because of all this extra JavaScript to support this approach, you end up with potentially slower initial page load than you would have otherwise. Depending on the content you have, this approach I think sometimes can make sense. If you have an app that is driven by API data where you don’t necessarily know what those URL paths are going to look like ahead of time.

Chris: Just an example here. You have an animal rescue where you have some adoptable animals, and that data comes from Petfinder, the animal adoption website. You have a bunch of animals there. Petfinder manages that, but you want to display them on your site with the Petfinder API. When your website’s being built, it doesn’t always necessarily have visibility to what pets are available in this exact moment and what kind of URL paths you’re going to need. A single-page app can help you there because it can dynamically on the fly, create these nice URLs that map with each dog or cat.

Chris: Something like Instagram with lots of user created content, maybe that also makes sense. But for a lot of things, we do know where those URLs are going to be ahead of time. Creating an HTML file that has the content on it already is going to be just as fast as… sometimes even faster than the JavaScript based single-page app approach, especially if you use some other techniques to keep your overall CSS and JavaScript size down. I use this approach on a course portal that I have. The page loads feel instantaneous because HTML is so easy for browsers to render compared to other parts of the stack. It feels like a single-page app, but it’s not.

Drew: Especially when you consider hosting solutions like a Jamstack approach of putting HTML files out in a CDN so it’s being served somewhere physically close to the user.

Chris: Yep.

Drew: Loading those pages can just be so, so quick.

Chris: Yes. Absolutely. Absolutely. One of the other arguments I think people used to make in favor of single-page apps is offline access. If someone loads it and then their network goes down, the app is already up and all the routes are handled just with the file that’s already there. So there’s no reloading, they don’t lose any work. That was true for a long time. Now with service workers and progressive web apps, that is I think less of a compelling argument, especially since service workers can fetch full HTML files and cache them ahead of time if needed.

Chris: You can literally have your whole app available offline before someone has even visited those pages if you want. It just happens in the background without the user having to do anything. It’s again, one of those technologies that maybe made sense for certain use cases a few years ago a little less compelling now.

Drew: It reminds me slightly of when we used to build websites in Flash.

Chris: Yes.

Drew: And you’d have just a rectangle embedded in an HTML page which is your Flash Player, and you’d build your entire site in that. You had to reimplement absolutely everything. There was no back button. If you wanted a back button, you had to create a back button, and then you had to create what the concept of a page was. You were writing code upon code, upon code to reimplement just as you are saying things that the browser already does for you. Does all this JavaScript that we’re putting into our pages to create this functionality… is this going to cause fragility in our front-ends?

Chris: Yes. This is almost certainly from my mind, one of the biggest issues with our over-reliance on JavaScript. JavaScript is just by its nature, is a scripting language, the most fragile part of the front-end stack.

Chris: For example, if I write an HTML element that doesn’t exist, I spell article like arcitle instead of article and the browser runs across that, it’s going to be like, “Oh, I don’t know what this is. Whatever, I’ll just treat it like a div.” And it keeps going. If I mistype a CSS property… Let’s say I forget the B in bold, so I write old instead, font way old. The browser’s going to be, “I don’t know what this is. Whatever, we’ll just keep going.” Your thing won’t be bold, but it will still be there.

Chris: With JavaScript, if you mistype a variable name or you try to use a property, you try to call a variable that doesn’t exist or a myriad of other things happen… your minifier messes up and pulls one line of code to the one before it without a semicolon where it needs one, the whole app crashes. Everything from that line on stop working. Sometimes even stuff that happens before that doesn’t complete, depending on how your app is set up. You can very quickly end up with an app that in a different approach, one where you rely a lot more on HTML and CSS, it would work. It might not look exactly right, but it would still work… to one that doesn’t work at all.

Chris: There’s an argument to be made that in 2020, JavaScript is an integral and important part of the web and most people don’t disable it and most people are using devices that can actually handle modern JavaScript. That’s true, but that’s not the only reason why JavaScript doesn’t work right, even if you have a linter there for example and you catch bugs ahead of time and things. There’s plenty of reasons why JavaScript can go horribly awry on you. CDNs fail.

Chris: Back in July of last, a year ago this month… at least, when we’re recording this… a bad deploy took down Cloudflare. Interestingly as we’re recording this, I think a week or two ago, Cloudflare had another massive outage that broke a whole bunch of things, which is not a knock on Cloudflare. They’re an incredibly important service that powers a ton of the web. But CDNs do sometimes go down. They are a provider used by 10% of Fortune 1,000 companies. If your JS is served by that CDN and it breaks, the JavaScript file never loads. And if your content is dependent on that JS, your users get nothing instead of getting something just not styled the way you’d like.

Chris: Firewalls and ad blockers get overly aggressive with what they block. I used to work at a company that had a JavaScript white list because they were extremely security conscious, they worked with some government contract stuff. They had a list of allowed JavaScript, and if your site or if your URL wasn’t part of that, no JavaScript. You have these sites. I remember going to a site where it had one of the hamburger kind of style menus on every view whether it was desktop or mobile, and I could not access any page other than the homepage because no JavaScript, no hamburger, that was it.

Chris: Sometimes connections just timeout for reasons. Either the file takes a while or someone’s in a spotty or slow connection. Ian Feather, an engineer at BuzzFeed, shared that about 1% of requests for JavaScript on the site fail which is 13 million requests a month. Or it was last year, it’s probably even more now. That’s a lot of failed JavaScript. People commuting go through tunnels and lose the internet. There’s just all sorts of reasons why JavaScript can fail and when it does, it’s so catastrophic.

Chris: And so we built this web that should be faster than ever. It’s 2020, 5G is starting to become a thing. I thought 4G was amazing. 4G is about as fast as my home wifi network. 5G is even faster, which is just bonkers. Yet somehow, we have websites that are slower and less performant than they were 5 or 10 years ago, and that makes no sense to me. It doesn’t have to be that way.

Drew: How do we get out of this mess, Chris?

Chris: Great question. I want to be really clear. I know I’ve hammered on this a couple times. I’m not saying all the new stuff is bad, never use it. But what I do want to encourage is a little bit more thoughtfulness about how we build for the web.

Chris: I think the overlying theme here is that old doesn’t mean obsolete. It doesn’t mean never embrace new stuff, but don’t be so quick to just jump on all the shiny new stuff just because it’s there. I know it’s one of the things that keeps this industry really exciting and makes it fun to work in, there’s always something new to learn. But when you pick these new things, do it because it’s the right tool for the job and not just because it’s the shiny new thing.

Chris: One of the other things we didn’t get into as much as I would have liked, but I think is really important, is that the platform has caught up in a really big way in the last few years. Embracing that as much as possible is going to result in a web experience for people that is faster, that is less fragile, that is easier for you to build and maintain because it requires fewer dependencies such as using what the browser gives you out-of-the-box. We used to need jQuery to select things like classes. Now browsers have native ways to do that. People like JSX because it allows you to write HTML in JavaScript in a more seamless way. But we also have template literals in Vanilla JavaScript that give you that same level of ease without the additional dependency. HTML itself can now replace a lot of things that used to require JavaScript, which is absolutely amazing.

Chris: We talked a little bit about… this is a CSS thing, but hovers over links and how that used to require JavaScript. But using things like the details and summary elements, you can create disclosure, like expand and collapse or accordion elements natively with no scripting needed. You can do auto complete inputs using just a… I shouldn’t say just, I hate that word. But using a humble input element and then a data list element that gets associated with it, with some options. If you’re curious about how any of this stuff works over at vanillajstoolkit.com, I have a bunch of JavaScript stuff that the platform gives you. But I also have some used to require JavaScript and now doesn’t kind of things that might be interesting too if you want some code samples to go along with this.

Chris: On the CSS side of things, my most popular Vanilla JS plugin ever is this library that lets you animate scrolling down to anchor links. It is very big. It’s the hardest piece of code I’ve ever had to write. And it now is completely replaced with a single line of CSS, scroll behavior smooth. It’s more performant. It’s easier to write. It’s easier to modify its behavior. It’s just a better overall solution.

Chris: One of the other things that I wish we did more is leaning on multi-page apps. I feel a little bit vindicated here, because I recently saw an article from someone at Google that actually pushes for this approach now too. I thought that was pretty interesting, given this huge angular and then framework… all the things, boom, that Google started a few years back. Kind of cool to see them come back around to this. Using things like static site generators and awesome services like Netlify and CDN caching, you can create incredibly fast web experiences for people using individual HTML files for all of your different views. So kind of leaning on some of this out-of-the-box stuff.

Chris: In situations where that’s not realistic for you, where you do need more JavaScript, you do need some sort of library, maybe taking a look at the smaller and more modular approaches first instead of just going for the behemoths of the industry. Instead of React, would Preact work? Instead of angular… I mean, instead of Vue rather, would Alpine JS work? There’s also this really interesting pre-compiler out there now called Svelt, that gives you a framework-like experience and then compiles all your code into Vanilla JavaScript. So you get these really tiny bundles that have just what you need and nothing else. Instead of CSS and JavaScript, could you bolt in some third party CSS linter that will compare your HTML to your CSS and pull out the stuff that got left in there by accident? Would a different way of authoring your CSS, like object oriented CSS by Nicole Sullivan, work instead? We didn’t really get to talk about that, but it’s a really cool thing people should check out.

Chris: And then I think maybe the third and most important piece here, even though it’s less of a specific approach and more just a thing I wish more people kept in mind, is that the web is for everyone. A lot of the tools that we use today work for people who have good internet connections and powerful devices. But they don’t work for people who are on older devices, have spotty internet connections. This is not just people in developing areas. This is also people in the U.K., in certain parts of the U.S. where we have absolutely abysmal internet connections. The middle of our country has very slow internet. I know there’s places in part of London where they can’t wire a new broadband in for historical reasons, so you’re left with these old internet connections that are really bad. There’s places like that all over the world. Last time I was in Italy, same thing. The internet there was horrible. I don’t know if it’s changed since then.

Chris: The things we build today don’t always work for everyone, and that’s too bad. Because the vision of the web, the thing I love about it, is that it is a platform for absolutely everyone.

Drew: If listeners want to find out more about this approach, you’ve gone into loads of detail to it in your book, The Lean Web. And that’s available online. Is it a physical book or a digital book?

Chris: It’s a little bit of both. Well, no. It’s definitely not a physical book. You go to leanweb.dev. You can read the whole thing for free online. You can also if you want, there’s EPUB and PDF versions available for a really small amount of money, I forget how much now. I haven’t looked at it in a while. The whole thing is free online if you want it. You can also watch a talk on this topic where I go into more details if you want.

Chris: But I’ve also put together a special page just for listeners of Smashing Podcast at gomakethings.com/smashingpodcast, because I’m very creative with naming things. That includes a bunch of resources in addition to the book, around things that we talked about today. It links to a lot of the different techniques that we covered, other articles I’ve written that go deeper into some of these topics and expand on my thinking a little bit. If folks want to learn more, that would probably be the best place to start.

Drew: That’s terrific. Thank you. I’ve been learning all about the Lean Web. What have you been learning about lately, Chris?

Chris: Yeah, a couple of things. I alluded to this a little bit earlier with watching Jeremy’s video on progressive web apps. I have been putting off learning how to actually write my own progressive web app for a couple of years because I didn’t have a specific need on anything I was working with. I recently learned from one of my students who is in South Africa, that they have been dealing with rolling blackouts because of some stuff they have going on down there. As a result, she is not able to work on some of the projects we’ve been doing together regularly, because the power goes out and she can’t access the learning portal and follow along.

Chris: For me, now building an experience where it works even if someone doesn’t have internet has become a higher priority than… I realized that maybe it was before, so I just started digging into that and hope to get that put together in the next few weeks. We’ll see. Jeremy Keith’s resources on this have been an absolute lifesaver though. I’m glad they exist.

Chris: I know, Drew, you mentioned one of the reasons you like to ask this question is to show that people no matter how seasoned they are, are always learning. Just a little related anecdote. I have been a web developer for I think, about eight years now. I still have to Google the CSS property to use for making things italic, literally every single time I use it. For some reason, my brain defaults to text decoration even though that’s not the right one. I’ll try a couple of combinations of different things, and I always have one word wrong every time. I also sometimes write italics instead of italic. Yeah. If anybody ever there is ever feeling like, oh, I’m never going to learn this stuff… just know that no matter how seasoned you are, there’s always some really basic thing that you Google over and over again.

Drew: I’ve been a web developer for 22, 23 years, and I have to Google the different properties for Flexbox still, every time. Although I’ve been using that for 23 years. But yeah, some things just… there’s probably going to more of those as I get older.

Chris: Yeah. Honestly, I ended up building a whole website of stuff I Google over and over again, just to have an easier copy-paste reference because that was easier than Googling.

Drew: That’s not a bad idea.

Chris: That’s the kind of lazy I am. I’ll build a whole website to save myself like three seconds of Googling.

Drew: If you the listener would like to hear more from Chris, you can find his book on the web at leanweb.dev, and his developer Tips newsletter and more at gomakethings.com. Chris is on Twitter at Chris Ferdinandi. And you can check out his podcast at vanillajspodcast.com or wherever you usually get your podcasts. Thanks for joining us today, Chris. Do you have any parting words?

Chris: No. Thank you so much for having me, Drew. I had an absolutely smashing time. This was heaps of fun. I really appreciate the opportunity to come chat.

Smashing Editorial (il)


Articles on Smashing Magazine — For Web Designers And Developers

Newer postsOlder posts
×

Powered by WhatsApp Chat

WhatsApp Chat is free, download and try it now here!

× Chat with Us