Variables are a basic tool that help organize colors on a project. For a long time, front-end engineers used preprocessor variables to configure colors on a project. But now, many developers prefer the modern native mechanism for organizing color variables: CSS Custom Properties. Their most important advantage over preprocessor variables is that they work in realtime, not at the compilation stage of the project, and have support for the cascade model which allows you to use inheritance and redefinition of values on the fly.

When you’re trying to organize an application color scheme, you can always place all custom properties that relate to color in the root section, name them, and use it in all needed places.

That’s an option, but does it help you to resolve issues of application theming, white labeling, a brand refresh, or organizing a light or dark mode? What if you need to adjust the color scheme to increase contrast? With the current approach, you will have to update each value in your variables.

In this article, I want to suggest a more flexible and resistant approach on how to split color variables using custom properties, which can solve many of these issues.

Setup Color Palette

The coloring of any website begins with the setup of a color scheme. Such a scheme is based on the color wheel. Usually, only a few primary colors form the basis of a palette, the rest are derived colors — tones and mid-tones. Most often, the palette is static and does not change while the web application is running.

According to the color theory, there are only a few options for color schemes:

• Monochromatic scheme (one primary color)
• Complementary scheme (two primary colors)
• Triad scheme (three primary colors)
• Tetradic scheme (four primary colors)
• Adjacent pattern (two or three primary colors)

For my example, I will generate a triad color scheme using the Paletton service:

I now have three main colors. On the basis of these, I will calculate the tones and mid-tones (the HSL format in combination with the calc function is a very useful tool for this). By changing the lightness value, I can generate several additional colors for the palette.

Now if the palette is modified, then it will be necessary to change only the value of the primary colors. The rest will be recalculated automatically.

If you prefer HEX or RGB formats, then it does not matter; a palette can be formed at the stage of compiling the project with the corresponding functions of the preprocessor (e.g. with SCSS and the color-adjust function). As I’ve mentioned before, this layer is mostly static; it’s extremely rare that the palette may be changed in a running application. That’s why we can calculate it with preprocessors.

Note: I recommend also generating both HEX literal and RGB for each color. This will allow playing with the alpha channel in the future.

The palette level is the only level where the color is encoded directly in the variable names, i.e. we can uniquely identify the color by reading the name.

Define Theme Or Functional Colors

Once the palette is done, the next step is the level of functional colors. At this level, the value of the color is not so important as its purpose, the function it performs, and what it exactly colorizes. For example, the primary or app brand color, border color, color of the text on a dark background, the color of the text on a light background, button background color, link color, hover link color, hint text color, and so on.

These are extremely common things for almost any website or application. We can say that such colors are responsible for a certain color theme of the application. Also, the values of such variables are taken strictly from the palette. Thus, we can easily change application themes by simply operating with different color palettes.

Below, I have created three typical UI controls: a button, a link, and an input field. They are colored using functional variables that contain values from the palette that I previously generated above. The main functional variable that is responsible for the application theme (conditional brand) is the primary color variable.

Using the three buttons at the top, you can switch themes (change the brand color for controls). The change occurs by using the appropriate CSSOM API (setProperty).

This approach is convenient not only for theming but also for configuring individual web pages. For example, on the zubry.by website, I used a common stylesheet and a functional variable --page-color to colorize the logo, headings, controls, and text selection for all pages. And in the own styles of each page, I just redefined this variable to set the page its individual primary color.

Use Component Colors

Large web projects always contain decomposition; we split everything into small components and reuse them in many places. Each component usually has its own style meaning it doesn’t matter what we used to decompose BEM or CSS Modules, or another approach; it’s important that each such piece of code can be called local scope and reused.

In general, I see the point in using color variables at the component level in two cases.

The first is when components that according to application style guide are repeated with different settings, e.g. buttons for different needs like primary (brand) button, secondary button, tertiary, and so on.

The second is when components that have several states with different colors, e.g. button hover, active and focus states; normal and invalid states for input or select field, and so on.

A more rare case when component variables may come in handy is the functionality of a “white label”. The “white label” is a service feature that allows the user to customize or brand some part of the user interface to improve the experience of interacting with their clients. For example, electronic documents that a user shares with his customers through a service or email templates. In this case, the variables at the component level will help to configure certain components separately from the rest of the color theme of the application.

In the example below, I’ve now added controls for customizing colors of the primary (brand) button. Using color variables of the component level we can configure UI controls separately from each other.

How To Determine What Level A Variable Has?

I came across the question of how to understand what can be put in the root (theme or functional level), and what to leave at the level of a component. This is an excellent question that is difficult to answer without seeing the situation you are working with.

Unfortunately, the same approach as in programming does not work with colors and styles, if we see three identical pieces of code then we need to refactor it.

Color can be repeated from component to component, but this does not mean that it is a rule. There can be no relation between such components. For example, the border of the input field and the background of the primary button. Yes, in my example above that’s the case, but let’s check following example:

The dark gray color is repeated — this is the border of the input field, the fill color of the close icon, and the background of the secondary button. But these components are in no way connected with each other. If the border color of the input field changes, then we will not change the background of the secondary button. For such a case we must keep here just the variable from the palette.

What about green? We can clearly define it as the primary or brand color, most likely, if the color of the main button changes, then the color of the link and header of the first level will also change.

What about red? Invalid state of input fields, error messages, and the destructive buttons will have the same color at the whole application level. This is a pattern. Now I can define several common functional variables in the root section:

Regarding the level of component colors, we can easily identify components that can be customized using custom properties.

The button is repeated with different settings, the background color and text for different use cases change — primary, secondary, tertiary, destructive or negative case.

The input field has two states — incorrect and normal, where the background and border colors differ. And so, let’s put these settings into color variables at the level of the corresponding components.

For the rest of the components, it is not necessary to define local color variables, this will be redundant.

You need to dive into the pattern language of your project, which is, probably, being developed by the design team and UX. Engineers must fully understand the whole concept of a visual language, only then we can determine what is common and should live on a functional level, and what should remain in the local scope of visibility.

But everything is not so complicated, there are obvious things. The general background of the page, the background, and color of the main text, in most cases this is what sets the theme of your application. It is extremely convenient to collect such things that are responsible for the configuration of a particular mode (like dark or light mode).

Why Not Put Everything In The Root Section?

I had such an experience. On Lition project, the team and I were faced with the fact that we needed to support IE11 for the web application, but not for the website and landings. A common UI Kit was used between the projects, and we decided to put all the variables in the root, this will allow us to redefine them at any level.

And also with this approach for the web application and IE11 case, we simply passed the code through the following post-processor plugin and transformed these variables into literals for all UI components in the project. This trick possible only if all variables were defined in the root section because the post-processor can’t understand the specifics of the cascade model.

Now I understand that this was not the right way. Firstly, if you put component colors into the root section, then you break the separation of concerns principle. As a result, you can end up with redundant CSS in the stylesheet. For example, you have the folder of components where each component has its own styles. You also have a common stylesheet where you describe color variables in the root section. You decide to remove the button component; in this case, you must remember to also remove the variables associated with the button from the common styles file.

Secondly, this is not the best solution in terms of performance. Yes, a color change causes only the process of a repaint, not reflow/layout, this in itself is not too costly, but when you make some changes at the highest level, you will use more resources to check the entire tree than when these changes are in a small local area. I recommend reading the performance benchmark of CSS variables from Lisi Linhart for more details.

On my current project Tispr, the team and I use split and do not dump everything in the root, on the high level only a palette and functional colors. Also, we are not afraid of IE11, because this problem is solved by the corresponding polyfill. Just install npm module ie11-custom-properties and import library into your application JS bundle:

// Use ES6 syntax
import "ie11-custom-properties";
// or CommonJS
require('ie11-custom-properties');

Or add module by script tag:

<script async src="./node_modules/ie11-custom-properties/ie11CustomProperties.js">

Also, you can add the library without npm via CDN. The work of this polyfill is based on the fact that IE11 has minimal support for custom properties, where properties can be defined and read based on the cascade. This is not possible with properties starting with double dashes, but possibly with a single dash (the mechanism similar to vendor prefixes). You can read more about this in the repository documentation, as well as get acquainted with some limits. Other browsers will ignore this polyfill.

Below is a palette of the Tispr web application as well as the controls of the “white label” functionality for the e-documents (such as user contracts, invoices, or proposals).

Why Not Store Color Variables On The JavaScript Side?

Another reasonable question: why not store the palette and function variables in JavaScript code? This can also be dynamically changed and later redefined colors through inline styles. This could be an option, but most likely this approach would be less optimal since you need to have access to certain elements and change their color properties. With CSS variables, you will only change a single property, i.e. the variable value.

In JavaScript, there are no native functions or API for working with colors. In the CSS Color Module 5, there will be many opportunities to make derived colors or somehow calculate them. From the perspective of the future, CSS Custom Properties are richer and more flexible than JS variables. Also, with JS variables, there will be no possibility to use inheritance in cascade and that’s the main disadvantage.

Conclusion

Splitting colors into three levels (palette, functional, and component) can help you be more adaptive to changes and new requirements while working on a project. I believe that CSS Custom Properties are the right tool for organizing color split — it does not matter what you use for styling: pure CSS, preprocessors, or CSS-in-JS approach.

I came to this approach through my own experience, but I’m not alone. Sara Soueidan described in her article a similar approach in which she split variables into global and component levels.

I would also like to suggest reading the Lea Verou’s article where she describes possible cases of applying CSS variables (not only in terms of color).

(ra, yk, il)

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

• Chris’ microsite The Power of Serverless for Front-end Developers
• Chris on Twitter
• ShopTalk Show podcast

Weekly Update

• “Setting Up Redux For Use In A Real-World Application,”
  by Jerry Navi
• “Can You Design A Website For The Five Senses?,”
  by Suzanne Scacca
• “Creating A Static Blog With Sapper And Strapi,”
  by Daniel Madalitso Phiri
• “A Practical Guide To Product Tours In React Apps,”
  by Blessing Krofegha
• “How To Create A Porsche 911 With Sketch ,”
  by Nikola Lazarević

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.

(il)