Smashing Podcast Episode 32: Review Of The Year 2020
Email Newsletter
Weekly tips on front-end & UX.
Trusted by 200,000+ folks.
In this episode, we’re taking a look back at 2020. Who did we speak to in our episodes this year, and what did we learn? Let’s listen back to some clips to find out.
Show Notes
You can find all of our past episodes, including a full transcript of every interview at podcast.smashingmagazine.com.
See you in 2021, everyone! 😁
Transcript
Drew McLellan: In January, I talked to Amy Hupe about her work on the UK government’s design system, and in particular, how the team increased adoption of the system by the wider organization by encouraging contributions. Here’s Amy.
Amy Hupe: We started really early. So way before we had a kind of public design system, we started to engage with people who we thought kind of would be interested contributors. I should mention here we had a brilliant service designer on the team. She joined us in… I’m not going to get the dates correct in any way at the moment, but I think she worked with us in the whole of sort of 2018, and her name’s Ignacia. She just did a fantastic job of kind of going around and engaging people. So one of the things that she did was to go and identify all of the different patterns in government and all the different kinds of variations of those patterns. So going out and kind of saying, “Okay. There’s 10 different ways to ask for an address in government. Let’s look at them all together and decide which we think is the most appropriate approach. How can we consolidate these into one?”
Amy Hupe: She ran a big workshop to try and get people kind of looking at those and doing that kind of consolidation as a team. I think definitely her approach to kind of building collaboration in way before we actually released anything to the public really helped with that because it meant that people already had that kind of awareness of it, and many people had already contributed to it in some fashion or another before we actually took it public. So we were kind of past a few steps ahead. So I think that was really important and just persistence, a lot of persistence from the whole team in kind of helping people to contribute.
Amy Hupe: I think there’s an idea that if you get people to contribute to a design system, that’s a pretty sweet gig, because you can just get people to do all the work for you, and you kind of just sit there, and you make your little code fixes, and everybody’s actually giving you all the good stuff. But actually, as anyone who’s worked on a design system will know, it’s incredibly complex. It’s very difficult to make a centralized solution that works for multiple different teams.
Amy Hupe: Really, unless you’ve worked on a design system, it’s not reasonable to expect anyone to really understand what that takes. So there’s a lot of kind of handholding. There’s a lot of work involved in supporting contributors to contribute. I think I’ve said this before, but it probably takes longer, I think, to help somebody to contribute to a design system than it would to just make the thing yourself and the centralized team. But I think recognizing the value that it brings and being persistent in your efforts to make people aware of contribution, help them to do it, help them to feel kind of motivated to do it, I think yeah, that persistence was really so key to our success in that area.
Drew: We were joined by Microsoft’s Stephanie Stimac and Aaron Gustafson to talk about Edge adopting Chromium as its rendering engine. I asked Aaron about the competitive landscape between browsers and where the multiple browsers coalescing on the same rendering engine would stamp out that healthy competition and therefore be bad for the open web.
Aaron Gustafson: This is something that I definitely having been a long time web standards person kind of struggle a bit with. I totally get the business justification for it. From Microsoft’s standpoint, it made a lot of sense. From a front end dev perspective, it’s nice to not have to cater to a bunch of different engines. I mean, on the whole, those of us who’ve been working on the web for a long time have certainly seen a lot of convergence in terms of rendering. We don’t have as many problems as we had, say back in the Netscape for seven days, where we had just like… I knew companies that were creating unique style sheets for each different browser, which was just untenable.
Aaron Gustafson: But I think what’s kind of different now is that back in the original browser wars, you had all of these proprietary engines, and everybody was kind of in a game of one-upsmanship in terms of trying to ship new platform features and new JavaScript features or in the case of Microsoft reverse engineering JavaScript in order to create JScript and trying to figure out how to fit it all together.
Aaron Gustafson: But now we have the ability to actually work together in open source projects and still have the dialogue and still… I don’t know. Fight’s not the right word, but to have serious discussions about the impact of different approaches and to disagree with each other and to really work on making specs really good and to also have competing approaches to the underlying code within the context of, say a Chromium project or WebKit or something of that nature or Missoula in the Firefox space.
Aaron Gustafson: So yes. On one hand, we did lose another rendering engine, and I felt that same pain when opera decided to go to Chromium. But I feel somewhat heartened being inside Microsoft and seeing how committed we are to actually participating in the Chromium project in a meaningful way and not just kind of sitting back and just accepting everything that comes downstream from Chromium, but actually kind of vetting what’s going into the platform and participating in that… Yeah.
Aaron Gustafson: So I’m a little bit heartened by that and feel like we’re not just there to take from that project and just accept whatever gets passed down by all of the different people who have a stake in that project, but to actually be collaborating in there as well.
Drew: In February, I talked to Stephanie Walter about working with UI frameworks like Bootstrap and friends and balancing that with the customized needs of a usable interface. I asked Stephanie if it was possible to create a highly usable UI whilst using an off-the-shelf framework or if it was always going to be a bit of an awkward compromise.
Stephanie Walter: Yeah. I think it is. But it’s also depends on the level of compromise you’re willing to do, and this compromises on both sides. At the moment, I’m compromising a lot of buttons, for instance, because you have some really specific buttons in a material UI. I don’t really like the ripple effect on the button. I think it works great on mobile because on mobile, you need a kind of big feedback when user clicks or touches the button. But then they step this kind of ripple effect that goes all the way on the button. It’s a little bit overkill, especially when there’s a lot of button. But still we are going to keep this ripple effect because it would be super complex to remove it because this was built in to the React framework and to have another hover effect on this button, something more subtle that would not be this kind of bushy thing here. It would be super complex. So this is the kind of compromises you do.
Drew: Ethical design was the subject of my conversation with Trina Felber and Martin Michael Fredrickson. I asked if taking an ethical approach to design and avoiding dark patterns was a case of thinking long term about the health and growth of a business rather than just the short-term sales goals. Here’s Martin.
Martin Michael Fredrickson: That’s perfectly true. I think you have to look at the business that you do online as if you had a store on the main street in a medium sized city, where you have to keep your reputation intact. If you don’t treat your customers well, then if you don’t treat your customers well, long term, you’ll run out of business because people, they will go to some other store, or they’ll buy from online. So whatever you do online, you really have to think that there’s a long-term effect, and also, there’s a hidden cost in doing things that are complex or things that manipulate. If you declutter, as Trina says, there will be a long-term saving, and that’s never calculated when you talk about business model. You always talk about how much money you can make. You never talk about the cost of making that amount of money.
Drew: In March, I talked to Eduardo Bouças about an open source tool called Sourcebit that gathers content from disparate sources and makes it available to your static site generator. I asked Eduardo if this could improve the user experience of authorizing for an SSG by enabling integration with tools such as headless CMS’s.
Eduardo Bouças: Exactly. Yeah. The way that it could… I kind of see two different ways of using the tool that can help developers. One is making Sourcebit part of your deployment routine. So if you’re using a hosting platform, like Netlify, for example, and you configure your deploy commands to be, I don’t know, Hugo build, is it, the build command for Hugo or something, the sort of command that generates the static files for Hugo. You would also have another command as part of that routine. That would be something like Sourcebit fetch. So at build time, Sourcebit will go pull all the other data, generate all the files that Hugo needs, and then the whole deployment will already use those files and deploy all the content that is coming from the CMS.
Eduardo Bouças: So that’s kind of one possible use case for Sourcebit. The other one is to use Sourcebit as a local development in the local development workflow. So you can run Sourcebit with something that we call the watch mode. So Sourcebit keeps looking for changes in the remote data source, so in this case, the headless CMS. So whenever you publish an article or you change an entry into CMS, Sourcebit will acknowledge that, and it will regenerate all the files for you locally.
Eduardo Bouças: So what that means for developer working locally is that you can have your CMS window next to your Hugo site running locally, and then you can see changes happening in real time. You change something on the CMS, and then you can see that change being reflected on the local site, which I find super useful. So those are kind of the two ways that you could use Sourcebit.
Drew: Conversion optimization was the topic of the day. When I spoke to veteran podcaster and consultant, Paul Boag. We talked about some of the techniques that sites use to convert visitors to customers. But I wanted to ask Paul how you measure the impact of the changes you make. Paul explained.
Paul Boag: Yeah. Absolutely. I think, again, this is something that many organizations are quite poor at is being clear about how they’re going to measure success. Now, yes, your conversion rate is one metric. You should absolutely be following. But even with conversion, you kind of need to be a little bit more sophisticated than how many people are buying. You also need to pay attention to average order value. You need to pay particular attention to lifetime value, right? So how much a customer’s worth over their entire life, because you may well find that you’re getting quite high churn of customers, if you using dark patterns and things like that. But really, conversion should be just one of the metrics that you’re measuring.
Paul Boag: There’s also things like you need to be paying attention to engagement, how engaged are people with your content, because that makes a big difference in whether they eventually go on to convert. So you’re looking at things like, how much are your videos, do they watch, how long do they spend on your site, and what they looking at while they’re doing it? Are they engaging on social media and those kinds of things? Then the final aspect is obviously usability. You need to be measuring how quickly someone can complete a particular task on their website and how easy they find that the system to use and various other different criteria.
Paul Boag: There are loads of mechanisms that you can use for measuring those different things. There’s some great tools out there and also some good metrics that you can adopt. So for example, with usability, there’s something called the system usability scale which can be a very useful metric to measure. But equally, there are tools like maze.design is one that I often use, which will measure how long it’s taking someone to make a purchase, for example, get through the checkout. So yeah. Having that kind of broad range of metrics, you’re not just focusing on, how many sales did we make this quarter? You’ve got to look at the bigger picture.
Drew: In April, I chatted to Laura Kalbag from Better Blocker about online privacy. We talked about the ever-thinning borders between what is considered public and what’s private and how the things we consider private might not be seen that way by the companies we entrust our data to. Here’s Laura.
Laura Kalbag: I have a classic example of this that happened to me a few years ago. So I was on Facebook, and my mom had just died, and I was getting ads for funeral directors. I thought it was really strange because none of my family had said anything on a social media platform at that point. None of my family had said anything on Facebook because we had agreed that no one wants to find out that kind of thing about a friend or family member via Facebook. So we’d not said about it.
Laura Kalbag: So I asked my siblings, “Oh, have any of said anything on Facebook that might cause this strange.” Because I usually just get ads for makeup and dresses and pregnancy tests and all those fun things they like to talk. It’s women of a certain age. Instead, my sister got back to me. She said, “Well, yeah. My friend lives in Australia.” So I sent her a message on Facebook Messenger and told her that our mom had died. Of course, Facebook knew that we’re sisters. It has that relationship connection that you can choose to add on there. I mean, it could probably guess we were sisters anyway, by the locations we’ve been together, the fact that we share a surname and decided, “Oh, that’s an appropriate ad to put in her feet.”
Drew: It’s sobering, isn’t it, to think that technology is making these decisions for us, that actually affects people potentially in this example quite a sensitive or vulnerable time?
Laura Kalbag: Yeah. We say it’s creepy. A lot of the time people say, “Oh, it’s almost like the microphone on my phone or my laptop was listening to me because I was just having this conversation about this particular product, and suddenly it’s appearing in my feed everywhere.” I think what’s actually scary is the fact that most of them don’t have access to your microphone. But it’s the fact that your other behaviors, your search, the fact that it knows who you’re talking to because of your proximity to each other and your location on your devices. It can connect all of those things that we might not connect ourselves together in order just to say, “Oh, maybe they’ll be interested in this product because they were probably thinking, talking about it already.”
Drew: As the coronavirus pandemic hit, and many nations went into some form of lockdown, I spoke with Rachel Andrew about how Smashing was adapting its in-person conference scheduled to happen online instead. Having just had to postpone Smashing conference, San Francisco, I asked Rachel what the plan was for moving upcoming conferences and workshops into the virtual domain.
Rachel AnDrew: Very, very quickly, once we realized we were going to have to postpone San Francisco, obviously, we have workshops, both myself and Vitaly run workshops at smash and comp, and they were sold out in San Francisco, both of our workshops. Obviously, we have lots of other people who come and run workshops for us, people who we’ve worked with for a long time, and they were finding that all their workshops, and for those of us do workshops, they’ve actually a key part of our income.
Rachel AnDrew: Public speaking, you don’t earn a lot of money typically going and public speaking. Most people aren’t paid a lot, not when you consider the amount of time it takes to write talks and so on. Workshops tend to be quite a nice way for people who are good at teaching this stuff to earn some money. So they represent people’s income. So not only needed myself and Vitaly had lost our workshops early this year. We also realized that a lot of our Smashing speakers also were reliant on those workshops.
Rachel AnDrew: So we thought, “Well, why not just take them online?” Very, very quickly, really within days of that happening, we decided that me and Vitaly would kind of be the first to stick our heads over the power, but given it’s us, and we could sort of figure out how to do it. We also have very different workshops. Vitaly is much more kind of collaborative. He has group activities and things. I teach classroom style. So between us, we thought, “Well, we’re kind of covering all the bases.” So we thought, “Let’s just do it. Let’s see if it works.” So we advertise them. We sort of figured out how long did each take, and then we sort of sat down and said, “Well, what does an online workshop really look like? What is this?”
Drew: I think from a technical perspective as web developers who immediately think, how on earth are we going to deliver something like that, I mean, there must be lots of different platforms that you looked at. What were the different things you looked at and what Smashing eventually come with?
Rachel AnDrew: So we’ve had a look at all sorts of things, and we’re still kind of in the process of doing that. We’re using Zoom at the moment. The reason we’re using Zoom is accessibility. It was the most accessible of the platforms. Obviously, we don’t want to cut people out because of the platform we’ve chosen. I think the other platforms are getting better and people are… I think that a lot of platforms have had people come to them and say, “Yeah, you look great. But we need you to be accessible.” So zoom is the easiest for people to use at the moment.” So that’s why we’ve ended up using them. I don’t know whether we will do forever. But that’s what we’re using at the moment, and it’s worked pretty well as a way to do this stuff.
Drew: As Zoom fatigue set in and the world started to adjust to what was quickly being called the new normal, I talked to Phil Smith about how technology can help us to respond to situations like COVID-19. Building the React Native app, CardMedic in just 10 days. I asked Phil how he goes about balancing picking the best technology for the job versus the technologies he’s familiar with and can work rapidly in.
Phil Smith: That is a good question. I think as soon as the project was mentioned to me, I thought I know exactly how I’m going to build all of this. If I didn’t have kids and I sat in a dark room, I think I could have probably turned it all around in about five days if I’d have been working on it solid, solid, solid because the requirements were very much in line with my experience of building apps. I’ve built similar kind of things, where it calls on an API, stores the results in state and presents them. I’m now at a position where there’s some bits where I’m like, “Okay, I need to go back and refactor that.”
Phil Smith: I’ve spoke about typing tin, but actually the types can be quite loose in the app, and that needs to be tightened up. On the back end, there aren’t many tests and now we’re starting to roll the back end out because lots of people have come forward and said, “Actually, this is a great resource. I’d like to volunteer my services to translate this into my native language.” The back ends being used by more people, so I’m just thinking, “Hang on, I need a few more tests in here to make sure that nothing can break because there are people using this in production now.” I think I answered your question. Essentially, there was no decision making. I just had to get it out there as quickly as possible.
Drew: As workplaces closed and many of us adapted to working at home, I spoke to Ben Frain about optimizing your home workspace to be a comfortable and productive place is not going to result in long-term physical health problems. With limited budgets available for getting set up at home, I asked Ben if a good chair was the best place to start.
Ben Frain: That would be my advice. Yeah. I mean, I can’t profess to be an authority on these things, but it seems it’s probably the single most important thing you could do to make yourself comfortable throughout the day. You can start with something fairly expensive. I made the same mistake, and I ended up getting a 45-pound office chair from Amazon, and I didn’t realize that it didn’t have a tilt forward, whatever the right word for that thing is, on the axis. So what I found is it was digging into the underside of my thighs, sort of behind my knees, and I was thinking, “Why are my legs going dead after 45 minutes of sitting in that thing?”
Ben Frain: I think particularly if you work for a company that provides decent office chairs, you just take them for granted, and it isn’t until you look at that particular make and brand that you go, “Oh my God, this is a $700 chair.” When you realize that crikey, people have thought about this and done a lot for you, and then obviously you come to your home environment and you think, “Why not spending X hundred dollars on a chair?” But maybe it is worth it. Particularly if you’re here for the long haul.
Drew: And the long haul is what we got. Something else that’s around for the long haul is Drupal. In June, I spoke with Angie Byron about the changes in Drupal 9. 20 years since its first release, Drupal has come a long way. I asked Angie what the process of upgrading an existing Drupal site was like when moving to Drupal 9 and if it was likely to be a big burden for those with long-running sites.
Angie Byron: I think there’s basically three scenarios. So one is if you were running Drupal 8, and every time a new minor release of Drupal 8 came out, you upgraded it to a right away, and you started making use of the new stuff. Your path is going to be basically nothing. You’ve already been doing all the work and you’re fine. If you moved to Drupal 8 a while back and you haven’t been keeping up with the BC changes, there is a little bit of work for you.
Angie Byron: It’s definitely the easiest upgrade in over a decade of our software anyway, and we have a ton of different tools to help you with it. There’s a dashboard that shows all of the contributed modules and what their Drupal 9 situation is. There’s automated tools for going through and checking your code and flagging any deprecated functions that you have, and there’s tools for automatically going up and finding, “Oh, this is the latest version of your module, and it’s Drupal 9 ready? You should go download it,” that kind of stuff.
Angie Byron: So from Drupal 8 to 9, I would say that that part’s pretty well covered. If you’re coming from a prior version of Drupal, say Drupal 7 or below to Drupal 9, that does start to look a little bit trickier. Among the changes that we made in Drupal 8, where for example, we moved entirely to object-oriented PHP, and we started utilizing design patterns that were found in other software project, which is a really smart thing to do architecturally, but it does mean that if you had a ton of custom code in your old life, that in Drupal 9, you’re going to need to find alternatives for that.
Angie Byron: So Acquia is a product and development called Acquia Migration Accelerator which is aiming to solve that problem, where we’re creating a nice React-defined application, which reads in your old Drupal 7 data, creates equivalent Drupal 8 data for you along with all the modules that you’re going to need that map to your old Drupal 7 modules where possible to try and expedite that process quite a bit because we want to make sure that everybody who’s on older versions can still make it over to the new world order, where everyone’s on the same version, and we’re all working together.
Angie Byron: Then in addition, we’ve also extended the Drupal 7… The open source community of Drupal, their end of life in Drupal 7 as of November of next year. Currently, anyway, we need to discuss whether COVID impacts that or not. But there’s a number of different companies, and Acquia is one of them that offers extended support for Drupal 7 beyond that, to 2024 at least. So that sort of makes it so that people who have an easy upgrade have a year and a half to get it done, people have a less easy upgrade, have potentially three and a half years to get it done or longer if they need to, and we’re trying really hard to make it possible for everybody to move over and then building tools like Acquia Migrate Accelerator to help speed up the process.
Drew: Learning React was the subject of a conversation with Mina Markham. Mina and I had both been in a position of learning React for the first time. Reflecting on how much burden frameworks like React put on the browser, I asked Mina if putting so much control in the hands of the client was a mistake.
Mina Markham: I want to say yes with the caveat of, again, my experience is very much contained to mostly static websites. I don’t do a lot of product development. So maybe in that realm, this makes more sense. But from my perspective, I feel like we’re a lot of the times using a hatchet when we just need a butter knife. I don’t know why we need put all this in the browser, put so much work and so much pressure on the client when we can do things much… I feel like we could do this much simpler. One of the things that always made me a little hesitant to use React, or I say hesitant, but what I mean when it made me viscerally angry and I actively opposed it was when I would go to a website, and literally nothing would render because there was one error or something like really the entire page is broken because one function broke down.
Mina Markham: It just kind of annoyed me that a lot of the times, it was an all or nothing approach. One of the talks that I gave at AEA in the past and other places in the past was sort of talking about how to include progressive enhancement and not just your development, but also a larger of art direction and design of sites. I would point out specifically examples of websites that didn’t do progressive enhancement or any kind of graceful degradation. It was either you have the JavaScript running in the browser, or you get absolutely nothing. It would be just a simple site that represent information about the history of web design, which was one of the sites actually talked about, the history of web design from like 1990 until now. It was a beautiful website with lots of timelines, animation of things. But it also could have been rendered statically with just a list. There were steps in between showing nothing and showing that beautifully enhanced experience that I think got lost because of the way we’ve been approaching modern web development now.
Drew: I talked to Andy Bell about CUBE CSS, a styling methodology in the manner of BEM, SMACSS, and OOCSS. Many CSS approaches try to work against the natural properties of CSS like the cascade. CUBE very much embraces that behavior. Here’s Andy.
Andy Bell: A good sort of analogy for it is SCSS, like Sass, is an extension of the natural CSS language, isn’t it? You’re pretty much right in CSS still. So CUBE CSS is like that. So it’s an extension of CSS. So we should still write CSS, as CSS should… well, it’s supposed to be written. Let’s be honest, that how it’s supposed to be written. The name gives it away, Cascading Style Sheets. So it’s embracing that again because what I’ve found is that I’ve gone all the way down to the micro-optimization level. I’ve been down the path that I see a lot of people going down recently where… I’ve mentioned this in the article as well, where I can see… There’s some evidence of it recently. I’ve spotted people have been creating spacer components and stuff like that, and I understand that problem. I’ve been in that situation.
Andy Bell: The way I fixed it was, instead of drilling down and trying to micro-optimize, I actually started thinking about things on a compositional level instead because it doesn’t matter how small your components are. At some point they’re going to be pages. They’re going to be views. You cannot avoid that. That’s how it’s going to be. So instead of trying to say, “Right, I need these tiny little helpers to do this layout,” you say, “Right, I’ve got a contact page view or a product page view, and that’s a skeletal layout composition. Then inside of that, I can slot whatever components I want in there.”
Andy Bell: We’ve got things like Grid and Flexbox now which make that much more achievable, and you can essentially put whatever you want inside of the skeletal layout. It doesn’t matter. Then the components should, at that point, behave how you want them to behave, with or without container queries.
Drew: Gatsby was the subject of my chat with Marcy Sutton. Whilst most static site generators are front-end code agnostic, Gatsby uses React, and therefore you end up with Gatsby code running as part of your final web experience. I asked Marcy what that code was and what functionality it was providing.
Marcy Sutton: Yes. I’d say the biggest piece of that is client side routing. So Gatsby right now is using retreader under the hood. It just kind of its own implementation. But that is the piece that when you load your static site for the first time, there are HTML files there. So if the user turns JavaScript off for some reason, your site should still be there, still have content. But if JavaScript is enabled, that’s when this hydration step happens, where when you use links in your Gatsby site, it will go pre-fetch resources from that page. So it will load faster. So that is all enabled with this JavaScript layer that Gatsby gives you.
Marcy Sutton: So beyond that, it really depends kind of what you’re using in your site, what will end up in that JavaScript bundle. But for things that use a lot of interactivity, like accessible interfaces, that’s a good place to be. For me, I really enjoy having JavaScript available to me at all times and having my markup just be in a good spot. I know it’s a matter of preference, whether you want your HTML and your JavaScript and your CSS, all kind of neatly coupled, and there’s room for variations within building Gatsby. You don’t always have to use something like CSS and JS. But it’s really about getting the power of that dynamic JavaScript layer available to you while you’re writing your website. It’s not like this add-on in a separate file.
Drew: When I think of how a static site generator usually works, I’m thinking of content in perhaps markdown files and the generator runs across that content and merges it with templates and creates tens, hundreds, thousands of HTML files, which are the pages of your website. When I think of a React site or app, I’m thinking more about single-page experience, where the interfaces be created by React on the fly. So you’re saying Gatsby does both of those? It’s creating all the pages and also enhancing it with JavaScript?
Marcy Sutton: It is, yes. Gatsby will use Node.js at build time, it will go over your React components and compile them into HTML files, which honestly, the first time I looked at Gatsby, I wouldn’t turn JavaScript off and was like, “All right, are there other pages here? What is this?” I was so happy that Gatsby works that way by default. It will create built files from your React components, which is awesome.
Marcy Sutton: I have explored more progressive enhancement approaches since it’s in JavaScript, like, what if you want to output something progressively enhanced for users, where if they do have JavaScript turned off, you don’t want all this broken code that assumes JavaScript is there. So there are some quirks with it. But you can work around that kind of thing, at least for your core user flows where you want someone to still be able to buy something. You might need to add some support and for those use cases. But I’ve been pleasantly surprised that the way that Gatsby rolls that out by default.
Marcy Sutton: So it is a choice that they made to build sites that way, and we’re always evaluating, is it still the best way? What do we need to do to give our users what they’re asking for? So we’re doing some explorations internally, ongoing just to make sure Gatsby is doing the best job it can at building a website, so keeping bundle sizes small and making sure that for making trade-offs for what we say is performant code with pre-fetching, do we have the data to back that up? That’s the kind of thing as a developer advocate that I’m super interested in, is making sure that what we’re packaging and bundling on websites is actually needed and will really make the best Gatsby site it can make.
Drew: Talking with Chris Ferdinandi in July, I asked if modern best practices were bad for the web. Chris backs a movement known as the Lean Web, and I asked him what that entailed. Here’s Chris.
Chris Ferdinandi: 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. 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.
Chris Ferdinandi: As we’ll probably get into in our conversation, 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 kind of issues with that too that we can kind of 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: In August, Chris Coyier joined us to talk about all things serverless. I asked him what sort of the tasks they were putting serverless to over at CodePen?
Chris Coyier: 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. 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. 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.
Chris Coyier: 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. 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.
Chris Coyier: 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 Coyier: 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.
Chris Coyier: So each of those screenshots has a URL to it, obviously. We’ve architected it so that that URL is actually a serverless function. It’s a worker. So if that URL gets hit, we can really quickly check if we’ve already taken that screenshot or not. 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?”
Chris Coyier: 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.
Drew: I talked to Next.js co-creator, Guillermo Rauch about the features on offer in Next.js and asked about its automated code splitting functionality. As the size of our JavaScript bundles can have quite an impact on performance, I was interested to know if Next had ways to tackle that. Here’s Guillermo.
Guillermo Rauch: Yeah. Your observation is 100% right. So one of the biggest things with the web and one of the biggest weights on the web is JavaScript. 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, for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.
Guillermo Rauch: So Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. So the first one that was my first intuition when I first sort of came up with the idea for Next.js was, okay, 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, terms-of-service.js, signup.js, login.js. Those become entry points to your application that you can share through all kinds of media.
Guillermo Rauch: 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. So 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, “Well, look. You can define 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.”
Drew: In September, I had the pleasure of talking to Cassie Evans about SVG animation. We talked about the approachability of SVG for developers who are already familiar with HTML. Here’s Cassie.
Cassie Evans: 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 there some really approachable entry points because it does look like HTML.
Cassie Evans: 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: 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 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 Evans: 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: The Jamstack framework, RedwoodJS was the topic of conversation with Anthony Campolo. I asked Anthony what it meant to be a full-stack Jamstack framework in practical terms.
Anthony Campolo: 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: Vue.js version three was released in October, and I caught up with Natalia Tepluhina from the Vue core team. Discussing the new version, I was curious if the major version bump was just a result of a few backward incompatible modifications or if this was a very clear revisiting of Vue to make deeper changes to the framework.
Natalia Tepluhina: 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, 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.
Natalia Tepluhina: So reactivity was one of the things. 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 were working with our state management Vuex.
Natalia Tepluhina: So this was again a huge part. 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 Vue 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. 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? So we were working on these main features to create the Vue 3 as major version.
Drew: Following that we dived into TypeScript with Stefan Baumgartner to find out how it can help us write better code with fewer bugs. Observing the trend for organizations to move their code basis entirely to JavaScript, I asked Stefan if TypeScript was something larger teams would benefit from more than individuals.
Stefan Baumgartner: So I’m currently in the same transition. So we have lots of Java and C++ developers who are going to write a lot of JavaScript in the future. TypeScript can be some sort of guide for those scary areas of new programing language. 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 Baumgartner: But also, I think, especially when you have lots of people working in the same code 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, or 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 Baumgartner: 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. This is not just an investment for the next project of next week, but more for one who say, okay, especially if you have 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: In November, I chatted with David Darnes about the static site generator, Eleventy. We talked about templating and how many static site generators are quite heavily opinionated about what type of templating you should use. I wondered if Eleventy held the same sort of strong beliefs. Here’s Dave.
David Darnes: No, I have to say it’s as close as unopinionated as you could get. A bit of a personal view, but I struggled to see any framework or anything that can be unopinionated because, in order to create something, you have to have an opinion on how you want to do something. It’s kind of oxymoron. I’m sure people could correct me on that. But yeah. You can switch to whatever templating language you feel most comfortable with. I mean, we were just talking about languages that you are comfortable with. Eleventy appeals to that in a sort of sense with what templating languages use inside your HTML, or heck even your CSS, if you want.
David Darnes: For me, I just went straight to the nunjucks because nunjucks is the default templating language inside of Eleventy. That means I can use the dot HTML extension and kind of leave it as it is. Now, I’m just going to confuse people even more and say, “You can name that however you want anyway. You can have real fun with it.” But you can use handlebars. I think you can just use regular JavaScript templating and iterate through it like that. Handlebars quite popular and Liquid as well. I can’t think of all of them off the top of my head, but if you set it all up in the configuration, you can just pick however you want it.
David Darnes: I’d say I’m a real big fan of just templating languages in general. It wasn’t too long ago when I found out that you could use twig inside of WordPress, and that kind of blew my mind. I was like, “Oh, thank goodness. I don’t have to handle a for loop inside of PHP.” Again, I think something a little bit more comfortable and understandable, more readable as well. So yeah. Eleventy has lots of different templating options, and it should appeal to people who are comfortable with those different ones.
Drew: I spoke with Leslie Cohn-Wein about how Netlify uses its own platform to build Netlify and how their Deploy Preview functionality becomes an effective staging platform for front-end changes.
Leslie Cohn-Wein: Maybe my favorite part of that whole process is the magic of Deploy Previews, which we get through Netlify. So what happens is you’re working in GitHub, you push up your PR. So you open up your PR in GitHub, and that is going to automatically create a build of your Deploy Preview of the app. So we actually use Deploy Previews of the app itself to test out, to make sure everything is working the way it should. We run our tests. That’s what we use sort of to manually verify during code review. So we have sort of all of that continuous deployment set up right from GitHub.
Leslie Cohn-Wein: Then one of the other cool things that we have set up is that we actually have a couple of different Netlify sites that are pulling from the same repository where our app lives. So we have both our app. We’ve got an instance of Storybook that has sort of our UI components for the app. So we have both our app itself. We’ve got the Storybook UI components, and we have basically a Netlify site that shows our Storybook UI, and then we also have a third site that runs a webpack bundle analyzer. So it’s sort of a visual UI that gives you a tree map visualization of all of the apps bundles, and we can sort of gauge their size, and it’s just a reminder for us to double-check sort of as every deploy of the app goes out, we can check and make sure we’re not doing anything weird with our bundle size there.
Leslie Cohn-Wein: So all three of those sites get generated in one pull request of the app. So you’ll get links to preview, your Deploy Previews essentially, of both the app Storybook and to that app profile for us to check through.
Drew: In December, I talked with Chris Murphy about product design and what it means for business to be designed focused. We discussed if an individual founders design focus, does that leak into the business, and if a product is naturally an extension of the person who created it.
Chris Murphy: I think that’s a really good question, Drew, and I think that the answer to it is it depends. I think it depends on that person, and it depends on the scale of the company. If you take a look at Hiut Denim, and I use Hiut a lot in my teaching, it’s a really good example of a company that’s doing one thing well, and that’s their sort of strapline jeans. I think if you look at David’s previous… David and Clare, because they’re a partnership. If you look at David Hieatt and Clare Hieatt’s previous company, which was Howies, that company had grown so big, there were so many people involved.
Chris Murphy: Once scale starts to creep in, it starts to become very difficult to keep an eye on all of the little touchpoints that matter in the customer journey. I think it’s really telling that when they left Howies, because Howies had been bought by… It’s complicated. Go read it on the internet. But it was Timberland, and Timberland was bought, and there’s all this story.
Chris Murphy: I think it’s really interesting that what they’re focused on now is jeans. That’s it. They’re telling an amazingly good story around jeans. They’re also packaging everything really, really well, and the jeans are like a vehicle for stories, really. This is something I think, Drew, is going to become more important as we come out the other end of COVID, which I hope we come out the other end of. Everyone who’s making those jeans is being paid a proper wage. One of the problems I have at the minute when I look at the world is not everybody is being paid a proper wage, and I find that a little bit concerning, as someone… Look, I’m 51. My son is 25, 24, 25, something like that. It’s terrible. I should know all this stuff. He’s a wedding photographer. He has been a wedding photographer for like a year and a bit. His business is completely decimated because no one’s really getting married at the minute because it’s just difficult. He has no salary because he didn’t have enough self-employed books to get the support.
Chris Murphy: He’s fallen through the cracks, and there’s a lot of other people who’ve fallen through the cracks. I would argue that’s a design problem, that we need to look at that as a design problem. But if I also look at that wider issue of COVID and the government and all of these things without getting too political, I read an article in the Guardian yesterday about Matt Hancock’s neighbor, and anyone who’s listening who’s not from the UK, Matt Hancock is the Health Secretary. His neighbor, who was running a business, was texting him and asking for advice about, “How do I supply products for this COVID thing?” There’s an awful lot of rumblings around the chumocracy, is what the papers call it, friends of friends of government ministers who seem to be getting jobs because they know the right people.
Chris Murphy: I get this sense that we’re going to come to the other end of this and see this… Individuals see that, and they think, “Well, where is this money going, and are people being paid properly? What’s the price of this one-pound T-shirt from shop X?” I don’t want to mention any brands. But everything has to be paid for, and everything that’s made, people have to be paid to make it. I think people are increasingly interested in, are people being paid fairly?
Drew: GraphQL was the topic of our final, full episode of the year, and I had a chat with Eve Porcello and asked where GraphQL fits into the development stack.
Eve Porcello: Yeah. GraphQL kind of fits between the front end and the backend. So it’s kind of living in the middle between the two and gives a lot of benefits to front-end developers and backend developers. If you’re a front-end developer, you can define all of your front end’s data requirements. So if you have a big list of React components, for example, you could write a query, and that’s going to define all of the fields that you would need to populate the data for that page.
Eve Porcello: Now, with the backend piece, it’s really own, because we can collect a lot of data from a lot of different sources. So we have data in REST APIs and databases and all these different places, and GraphQL provides us this nice little orchestration layer to really make sense of the chaos of where all of our data is. So it’s a really useful for kind of everybody all over the stack.
Further Reading
- Autonomy Online: A Case For The IndieWeb
- How To Build Custom Data Visualizations Using Luzmo Flex
- Embracing Introversion In UX
- It’s Good To Talk: Thoughts And Feelings On Creative Wellness
(il, mrn)