The Changelog: Software Development, Open Source - What the web could be (in 2021 and beyond) (Interview)

Episode Date: January 12, 2021

Vercel CEO Guillermo Rauch and JS Party panelist Amal Hussein join Jerod to discuss the state of the web platform! We opine on why it's so important and unique, where it stands today, what modern web development looks like, and where the whole thing is headed in 2021 and beyond.

The way to be native is for Facebook to render a newsfeed just for you, that's optimal with the standpoint of their ads and the content and whatever. On mobile, they have to download hundreds of megabytes of code. They basically pre-download every possible user journey. And then the updates are also super heavy as a result. The web, I can tell you, hey, go to guillermosfacebook.com. You've never seen it before in your life. And it can render just in time with all this amazing code that's been preloaded in the cloud. I can render the perfect optimal page for you.

And that's a property I think if we want the web to win, I think we need to maximize, if we want the web to win, I think we need to, like, maximize our utilization of that property. Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. Our feature flags are powered by LaunchDarkly. Check them out at LaunchDarkly.com. And we're hosted on Linode cloud servers. Get $100 in free credit at Linode.com slash changelog.

This year, we simplified and improved the changelog.com setup by further replacing Docker Swarm and Terraform with Linode Kubernetes Engine LKE. Not only is this new setup more cohesive, but deploys are 20% faster and changelog.com is more resilient with a mean time to recovery of just under eight minutes. Interacting with this entire setup is done via a single pane of glass with K9S. Linode is our cloud of choice. We trust them and we think you should build anything you're working on, a fun side project or that next big info move at work with Linode. The best part, you can get started on Linode with $100 in free credit. Get all the details at linode.com slash changelog or text changelog to 474747 and get instant access to that $100 in free credit.

Again, linode.com slash changelog. What's up? Welcome back. This is Adam Stachowiak, Editor-in-Chief here at Changelog, and you are listening to The Changelog. We feature the hackers, the leaders, and the innovators in the world of software. Today, CEO of Vercel, Guillermo Rauch, and JS Party panelist, Emo Hussain, join Jared Santo to discuss the state-of-the-web platform, why it's so important and unique,

where it stands today, what modern web dev looks like, and where the whole thing is heading in 2021 and beyond. I'm joined today by two friends, Guillermo Rauch of Vercel and Amel Hussain of JS Party, is the way I'll introduce you. Regular on JS Party. You may know her voice if you're a listener to that.

Welcome to the show, friends. Hi. You may call me Lady Amel of JS Party. Okay, Lady Amel. Good sir. And Gishirma, thanks for joining us on the changelog thanks for having me we are excited today to talk about the web a beloved platform by all three of us here on this call and we're going to talk about where the web has been why it's important and maybe even cast forward and talk about where we think it is going to share my your reputation in

my mind is a person who's always on the edge of what is happening today and tomorrow. Long-time listeners of the show may recall you were on the Change Log back four years ago now. It doesn't seem like it was that long ago, but time flies. It does not. Talking about hyper, talking about now. Hyper term is actually called at the time. Now and Zite, which I introduced you as CEO of Vercel. Zite, Vercel, same company, rebrand, rename.

Vercel is what it's called now. That was a long time ago. You're also more recently on JS Party, talking to Divya and myself about Next.js and what's going on there. But welcome back to the ChangeLog, I guess. It's been a long time. Yeah, it's been, and the web has continued to evolve

and things have gotten better every day and happy to talk about, you know, some of the trends that we're all here advocates for fans of the web. In fact, Amel has a podcast called The Web Platform Show. Is that what it's called? Podcast. Yeah, Web Platform Podcast. We keep it pedantic and simple. There you go. ChangeLog Trivia.

We run the changelogshow.com. So things change. But the web also changing. Amel, in your opinion, what's so special about it? Why is it different? You know, why is it better than other platforms out there? Why do you dedicate your life and your work and your resources towards the web platform? Yeah, I mean, I think you only need to have a conversation with me for about five minutes

before you realize that I love the web. And I think the web is the best. And in fact, my husband is actually an engineer that works on mobile platforms. And our house is like, you know, Mr. and Mrs. Smith. Yeah. Mr. and Mrs. Smith of like, you know, team web versus team mobile. And you know, he's always making fun of me. And he's like, well, you know, at least I have a predictable roadmap. And I'm like, well, you know, at least I have choice and freedom. But anyways, so the web is quite literally, in my opinion, I think the greatest thing like we've accomplished as human beings. And it's simply because, you know, our archive of information, our access to each other, you know, we've been able to make the world a better place because of the internet.

You know, of course, there's downsides. But the best thing about the web is that it's an open protocol. And so that means, you know, it uses standards. And, you know, you can kind of hook into it without any kind of middle person, you know, sans your ISP provider, you know, that's the middleman that people are often trying to kill. You know, it's the open web and the reach of the web is like no other. And it's very important that we keep the web open and accessible. And, you know, really, in a time, you know, during a pandemic, like the web has shown that it's even more important.

And so it's interesting to see companies starting to reinvest in their testing infrastructure for the web and taking their web presence a lot more seriously. Because we're realizing, yeah, this is this critical thing. And maybe we got a little excited about native apps for a little while. But there's no beating the good old-fashioned open web curl from anywhere you know reach from anywhere there you go that resonates with me especially like the permissionless aspect of it because shamer what are your what's your take on i mean you've been doing web dev for so long now yeah i'll add to that that um so the web has this uh native way of connecting ideas through hyperlinks and a set of protocols to drive them.

So there's that aspect that continues to be the thing that inspires me a lot. So when we launched Vercel, the main idea at the beginning was this idea of deploying very quickly, getting this deploy preview and this URL to share your product with your teammates and with anybody that you want to collaborate with. So all about this idea of just like, let's expose a hyperlink quickly, earlier in the process. I continue to be inspired because I see so many people taking advantage of this optimization of how you can work, right? Like we nowadays share lots of notion documents

in our workplace. We share calendly URLs for scheduling time with people. So this idea of the web is an open platform that is connected so easily between strangers and organizations. And what he talked about, which is that I don't need permission to publish this new way of sharing calendars or sharing documents or sharing product previews. It's all built in. And I think no other platform has gotten there. I know that links work to some extent with native apps, but it's always a huge mess. I don't know if i'm ending up on the web or ending up in native app right it's three or four interstitial modals that tell me to download or pay or face id and so there's nothing like the web in that ability to connect ideas people applications and documents absolutely i

will name drop vrbo which is like a vacation rental web. Think of it like Airbnb for vacation rentals. And they have a website which has the URL of a vacation rental. And you can share that URL. And my sister shares it with me on iOS inside the Messages app. And I click on that and it takes me to safari which takes me to the app store yeah to download their app and i don't want their app because i already know there's a web page that represents this i click back to safari i'm actually looking at the web page right there and all they will put on their mobile detected version of their web page is just like the the picture the first picture not all 37 pictures of the place and then download the app on the app

store and i'm like this is not what i want in life this is terrible yeah it's not what we're promised right like at the end of the day it comes down to user experience i want to tap i want to get this you know experience if it's limited because i need to grant more permissions to the system right or i need to log in or i need to pay for something. I think that's understandable. Yeah, give it a reason. But it has to be a smooth transition. And I think only the web can do that today. And it's still to be seen whether PWA is what takes us all the way through that transition. But I would say any company will see better results

when they give their customers ultimately what they want, right? Which is, in my case, I just want to see if I can rent it right away. And if I want to rent it right away, that's even better, right? Like you can make that happen. Yeah, I have to echo a couple shout outs to some web APIs that I think have helped smooth, I would say the link communication in mobile apps, the web share API, I don't know if y'all are familiar or remember it. It's not that old. But essentially, it's a way for you to kind of share information with anything from your phone. So you can actually implement it, which is really nice, works beautifully on Android and iOS. But i think for me like the walled gardens you know like the areas

where you know you're interacting with the web through a device that's perhaps like owned by a proprietary company and you know the company has interests in you using their app store and like it's it's just um i feel like the web has had a really tough battle, you know, both with like devices getting smaller and, you know, faster and better to use, right? And like the long arc of the web, you know, how long it takes for things to get updated, et cetera. Like not all websites really caught up with it, right? And so you don't have this graceful, beautiful,

out of the box experience. And so there's just so many kind of uphill battles that i've seen for the web we're still very much in the thick of it specifically also for new internet users like folks coming online for the first time you know there's like millions of people in brazil and india coming online for the first time you know every year and you know they're kind of learning about the internet through apps and when i say apps i mean like native apps that come on their come pre-installed on their like low-end devices and and i can say the same thing for like my my younger siblings that are much younger than

me you know so it's just the web has a lot of catch-up to do, I would say, in certain areas. But obviously, there's no... If you take the accessibility of the web and you kind of power it with the... You supercharge it with the powers of native apps, that's what you're supposed to get with progressive web apps and potentially projects like Fugu from Chrome

that are trying to... Yeah, and I'll say another thing I'll add there. You were mentioning about projects like Fugu from Chrome, you know, that are trying to, you know, but. Yeah. And I'll say another thing I'll add there, you were mentioning about like, there's this APIs that are really powerful and they exist. I think what we're going to see over the next few years is that we're going to catch up to the reality that you can actually create a much better mobile web experience today than you probably realize. And these are some of the things that with Next.js and Vercel we're working on, you know, making it easier and easier and easier to get to that point.

But when I look at the mobile web, I see a lot of low-hanging fruit, right? Like I see APIs that exist that are not being leveraged, like you mentioned, you know, like, oh, there's WebShare and there's many others that could be used that are even supported in iOS. I see just low-hanging fruit in the sense of it's clear that the development team or the creator has been thinking desktop first. And then there is this kind of mismatch of capability that annoys people where they might still want to request a desktop site because this function that they're used to using on desktop is not on mobile so even though responsive web has grown a lot and like people love it and it's like oh i'm gonna make everything responsive i'm gonna make things mobile first it hasn't really materialized i still see all

throughout the web that there is missing capabilities on mobile or things just seem more optimized and better thought through for desktop. So I think it's going to change specifically around verticals like e-commerce where there's demonstrably more growth in page views and growth of page views on e-commerce sites and mobile. Now, conversion is probably much better on desktop or if the user chooses to install a native app. But that's in a lot of cases because we haven't engineered the web well enough for mobile. So like performance is not there. So that's another low hanging fruit example of detail I'd like to point out is a key difference between

native apps and mobile websites. It's just how smoothly taps work, and how smooth the transition is to the next pain, or thing that you're revealing or whatever. And that's not a battle that you're losing. Because, you know, native has all this, you know, low level optimizations, GPU, whatever. In a lot of cases, you haven't even tried to optimize your mobile website. And that's, you know, like a cool example here is hover styles, delayed taps on iOS, especially hover styles that have been left from desktop that have CSS transitions. So you tap and iOS tries to show you the entire transition from nothing to hover to the next

state. And that's taking hundreds of milliseconds. So that battle you didn't lose because, oh, SwiftUI with M1 chip is so fast and the web can't compete. We need WebAssembly 3.0. No, that's just because you can optimize for mobile web. So that's what I'm really excited about. It's not just like,

I know that iOS won't give us every API that we want and they have this conflicting business interest and security concerns. But even today, we can make things so much better. So that might come down to tooling to a certain degree, because a lot of those things that lack is not because the lack of thoughtfulness or desire by the developer or the team or the company. Absolutely. Oftentimes, it's because of priorities and constraints and money and their externalities, so to speak.

And they just don't have either the knowledge they need to even know how to accomplish what you just described, right? How to avoid that thing that looks clunky. Yeah. Or they don't have the time to do it. And tooling really helps there. So we can talk about the web platform, but then you can also talk about web development, right? As the principles and practices. So from year two's perspective in 2020, as we're turning the corner to 2021, what was the state of the art in web development? I know there's debates about what is state of the art,

but in your guys' opinion, currently, not where it's going to be tomorrow or next year, but in 2020, what are people using? What are common practices? Catch us all up or at least give your vantage point of what you think is modern web development today. Do you want to start, Kishoremo? Yeah, obviously, I want to preface by saying we have a pretty opinionated viewpoint in that we create a React-based framework, Next.js. Right. It's obviously very popular, but we adverse sell our platform.

It works on top of the web platform and open standards. And we let you import projects like Next.js or any other modern front-end technology. So in that sense, we're also not opinionated. But what we try to do with Next.js is we want to create the state of the art from our point of view or the art of the possible. What's the best possible developer experience that we can give people? And what's the best possible end user experience? And from those ideas, we invest in the framework to embed them. So from the perspective of developer experience, I think the state of the art is

clearly collaborating on top of React components. I mentioned collaborating because one of the modern trends is for companies, organizations, teams to agree on a shared toolkit, a design system, a set of reusable components that they can build sites, applications, prototypes from, and they can do so very efficiently. So React has enabled the web platform developers to agree on a standard to encapsulate look and feel in behavior. So the best example here is we used to have templating languages, especially on monolithic server-side first frameworks like Ruby and Rails, et cetera.

And to a great extent, a template language can combine both HTML and CSS into reusable little functions that output strings. And then you have ways of sharing components with a certain look. What React has done in my mind has been this introduction of a greater possibility of composability, especially with hooks. Now we can encapsulate look and also behavior. And we can even take hooks and sort of share the behavior part and apply them to different components. So it's like playing with Lego bricks that have effects. So they're like Lego bricks and steroids, so to speak.

So to me, the state of the art looks like teams that don't just know JavaScript, HTML, CSS, they also know how to encapsulate that knowledge into reusable components. So React as a platform is a reality in my mind. And I mentioned React as a platform because React embeds things that are not very intuitive if you come from imperative JavaScript or even other programming languages where you have to embed these concepts of purity. And there's rules of hooks. So the shareable behavior bits that I talked about, they have rules that are not necessarily the rules of the language, right? So like how closures work or not work with hooks is always something that like trips beginner developers in React. So to me, the React platform is here.

It's real. It's making people really productive. It's making developers happy. Now, the other side of the coin is, is it making users happy? Because you have all these sophisticated libraries and you use a lot of JS and you can render on the clientover of single-page applications, huge monolithic bundles, only using client and not leveraging server rendering and pre-rendering. And that's where a lot of the new trends over the last couple of years, one of the things that made Next.js very popular to begin with was we gave you server rendering and pre-rendering out of the box.

Whereas when you used React, as it came from reactjs.org, you had to assemble it together with Webpack, and then you didn't have any server rendering or pre-rendering capability. So the state of 2020 is we've gotten a lot of power, but we're starting to use it in the ways that are really performant for end users. And the trends that are interesting to me there is somewhat of a return to the server-side rendering world, but slightly different because with Jamstack, we have server rendering and build time, which is really interesting if you have things that are fairly static. We have server rendering through serverless infrastructure

with Lambda functions like how Vercel handles Next.js server-side rendering. And you can combine and mix and match technologies like this to make really performant websites. And that's where it still is a battle and web vitals are now coming into the equation to allow us to measure properly what performance means. Because I think until 2020, we didn't have a good idea of how do we quantify web performance. So I'm really happy that that's also part of our future. by LaunchDarkly, feature management for the modern enterprise, power experimentation in

production. Here's how it works. LaunchDarkly enables development and operation teams to deploy code at any time. Even if a feature isn't ready to be released to users, wrapping code with feature flags gives you the safety to test new features and infrastructure in your production environments without impacting the wrong end users. When you're ready to release, more widely simply update the Thank you. listening to you i was like oh wow you're describing so many of the things that like i you know i practice on my own like set of teams or like, or within, like, within our company, things that we practice. So I'm like, yes, check, check, check. That's great. But that being said, I think for me, like, plus one to everything Guilherme shared. However, I'd like to kind of maybe not push back, but I would say

my counter is that I think React definitely pushed forward this whole model of componentization. And I think it's taken it to the next level. I would say React specifically for me is like the API is just getting, I would say, more and more confusing. And or, you know, maybe it's trying to do too much right with concurrent mode and all this other stuff like i'm not quite sure like i'm personally on board with that like just yet and i'm seeking as somebody who's you know used the tool since like early days and you know who's generally like a long-time user so i would say that it might be kind of the beginning of like i would say like a shift kind of a pendulum shift is what i see happening where folks are kind of the beginning of, like, I would say, like a shift,

kind of a pendulum shift is what I see happening where folks are kind of really going a little more pure, right? So I think React really did a wonderful thing of bringing us out of this crazy land of templating and custom domain knowledge, you know, where you're mostly using JavaScript, mostly using CSS, mostly using HTML, but all in JavaScript, you know?

Yeah. And, you know, but I think now we're kind of realizing, like, the performance, there's a lot of performance gains to be made by, like, you know, reducing complexity even in the tooling layer, right? So, like, do we really need virtual DOM, right? Like, I'd say that, like, no, right? Do we need, like, right? Like, I'd say that, like, no, right? Do we need like all these other things, like you can architect yourself out of problems that maybe, you know, React is trying to solve. So in that sense, I would say for me, it's like an asterisk on that. I don't think React is going anywhere, like, especially again, with the arcs of the web. But that being said, I think for me,

I kind of want to go back to the tooling discussion. Like, I think it's the secret sauce is all in the tooling. Like, I think, you know, abstracting away complexity for developers actually also means a better and healthier web, right? Because a developer is not going to test something on every browser or, you know, make sure their, you know, tools or their web pages are accessible, right? So the better our tooling gets and the more widespread that tooling can be, the better the entire web will be. So I think we need to really focus on our tooling

and yeah, and shifting. Like we need to focus on shifting, like shifting people forward in mass, you know? Like, how are we going to do that? That's the biggest challenge of modern web development and like managing legacy code and practices. And, you know, we're not all on the same challenge of modern web development and like managing legacy code and practices. And, you know, we're not all on the same set of tooling. We're not all on the same, right?

And we don't need to be. But ultimately, like the web is moving forward. And more so the way the web is accessed is moving forward, right? Devices are getting smaller. Like the web is in more places now, right? I have like 50 things in my house that are connected to is in more places now, right? I have, like, 50 things in my house that are connected to the web, for example, right? Like, so we just need to think about, you know,

how we're going to keep moving our code forward with the web. And so I think, like, you know, tooling is a big part of that. And so how do we distribute that tooling is the question. Like, more effectively than we are now because i think it's very like siloed right now i think the modern web development bubble is too for me it's too much of a bubble you know like i don't think it's as widespread as we think it is well we're definitely on the inside of the bubble and listeners to js party and amel's podcast like we're definitely on the forefront of that but for people who haven't been so close to the edge,

Gashermo, you mentioned Jamstack, you mentioned pre-rendering. These are things that are going on. I think the concept of pre-building with all the data that you have before you deploy is a thing now that's very popular, very much a modern move. Of course, it's also a legacy move.

We have changed it with Jamstack we're kind of decorating we're doubling down and saying we can do way more than just your blog posts spit out into HTML before you put things out and that's why the advent of things like Gatsby and a lot of the stuff you're doing at Vercel and with Next.js which is a hybrid approach

is popular but can you give the old Jamstack 101 to folks, Kisheremo, and just get us all on the same page with what that means and what it implies? Yeah, and I like what Amel said with regards to tooling being the fundamental investment that we need to make. And that doesn't stop at React,

but component systems like Svelte and Vue are also extremely suitable for the modern web. And what we're seeing there as well is that there's frameworks being created on top that facilitate a lot of the features that people actually need on their day-to-day to build robust web applications and sites. So Nuxt for Vue, for example, and SvelteKit for Svelte. We're seeing this kind of new category of tooling emerge on top. Next.js, I think, was an early mover with React,

but we're seeing Nuxt for Vue, and we're seeing SvelteKit for Svelte. And that touches on the concept that you're talking about now, which is they're all hybrid frameworks and for those of you that are familiar with jamstack jamstack was a movement or principle that said well the web should be static and but not static in the sense of just like do everything on the client side with js meaning you you give an empty index HTML file that loads some JS. But also within JAMstack is two other ideas. One, that you should pre-render content, so you should just have it in the HTML.

And two, that you should use a CDN. If you can stick to pure JAMstack for everything that you do, you're probably going to have some performance benefits that are not negligible. Because in contrast, you could have a monolithic server in one particular region that doesn't scale horizontally, especially if you haven't invested a lot in your DevOps and clusters and so on. And then you might or might not have installed a CDN, and you might or might not be caching in that CDN correctly. So what Jamstack brought was a set of constraints that said, well, it will be static and it will be cached at the edge, right?

The problem with that, as it turned out, is people have also very good reasons for dynamically rendering pages. Amen. And also, sites of a certain size cannot just pre-render every page. And together with all that, when we're talking about mobile web versus native, a tremendous advantage that I see for the web is that when you tap on a link, it can render just in time the page just for you without you having to have downloaded a massive application with all the possible code paths, not just for you, but for every known language, every known variant, every experiment, and every other cohort of users, right? So the web has this magical,

and it goes back to my concept of the hyperlink. You go to this hyperlink, and it's almost like a black box. You don't know what's going to come out on the other side, right? And that has this beauty of, I can give you the specific set of code. I can give you the specific HTML and the specific CSS for what you need just in time at that very time. And that's only possible if you combine ideas of Jamstack with more traditional ideas like server rendering. So this concept that we pioneered in Next.js, and this is what frankly drove and got us the attention from Google Chrome's team that started contributing directly to Next.js because it matched very well what they'd seen internally at Google as being the best ways to scale really large sites and really large applications. always with a combination of CDN caching for the parts that are known to be static, but also leveraging this sort of what I call the power asymmetry of the world, which is the average mobile phone in India, which is that Xiaomi Redmi phone, is not going to be as powerful as a server pre-warmed with all your application code

sitting on a data center. And not only will it not be as powerful, by transferring some of the rendering load to that powerful server, you reduce the battery life, you reduce the download amount that you're putting on that device. So I think one of the ways forward for the web will be to acknowledge that there is no silver bullet where you say, oh, if I make everything static and if I jam-stack this or that, I'm going to get great performance because you may also limit the ability to customize, personalize, and create very dynamic content just for a certain user, context,

country, language at a certain moment. But not only that, as I mentioned with Web Vitals, one thing that we've learned as well in 2020 and before that, but it became very clear in 2020 is just because a CDN can give you HTML really quick doesn't mean that you're going to have a fast website. So the example I like to give here is when Facebook launched the new Facebook.com built entirely on top of React, which was supposed to be this engineering marvel. one of the because the open web is so introspectable and debuggable a developer went ahead and like inspected it and realized that they weren't even using css that much they weren't using box shadow and they were using a spacer diffs and the box shadow one was particularly puzzling to me because i remember the old days of the web where we didn't have the box shadow property and we had

to use background images or not even background we have these box shadow property and we had to use background images. Or not even background images, we had to use image tags. And Facebook was doing that because they realized that for that particular element that was floating on the screen, box shadow had really bad performance. So performance is not just a matter of you downloaded that box shadow property in line into the HTML really quickly from the edge that's just obviously it's going to help but then begins this other complete new like you know box of surprises

or a box of performance and that's where the web vitals uh metrics that google has created are extremely helpful because if you're experienced with backend engineering, you know that one of the easy things to measure in this pipeline is, okay, I'm going to measure the P99 percentile distribution of response times and render times. In fact, github.com used to include this in their status page.

Like status.github.com will show you the mean page render time, the P95 page render time, et cetera. And you would say, okay, it's 300 milliseconds. And you're like, okay, that's really good. It's like two blinks of an eye or whatever. It's like the threshold of attention or whatever. But then you realize, okay,

I gave that to the web browser and now the web browser is struggling with rendering box shadows or intercom widgets and GDPR pop-ups, and all the layout is shifting, and there's three cookie banners and another one to accept the terms of service. Actually, that was fresh on today. Today, I went to a website. This is a marketing website website and i was presenting two blocking modals one to accept terms of service i was like turn service of what i've just posted

in this website and the other one is a massive gdpr uh modal and both of those things kind of came in a little later so you're just starting to see it and then they pop in exactly so the first pain the browser is spending all this effort in making that first paint, and then it interrupts itself with all this new JS and CSS and HTML that paints on top. And then the background rendering continues. So this world, you cannot understand it with a single metric.

That's an Insta-close by me. Yeah. You know know i'm not even gonna waste my time with that i'm just i'm on to the next tab because there's plenty of web pages out there right yeah but yeah so like the web vitals for me uh invention is a breakthrough and it's very important to mention here that there are heuristics right uh because the only thing that could truly help us here is an AI that tells us the website feels good, or you just look at your business metrics or something like that. But Web Vitals are three.

One says cumulative layout shift. That's really important because when you load something on the client side that the pre-rendered page or server-rendered page kind of didn't know about, then the layout becomes really messy. And that puts a lot of effort on the web. Because it's like, oh, I did all this effort to paint this pretty picture. And then you're telling me that I have to split it in two

and create this new rectangle in the middle because an ad loaded or so on. So that one is cumulative layout shift. It's one of the web vitals. Then we have largest contentful paint, LCP. That one is cumulative layer shift is one of the web vitals then we have largest content full paint lcp that one is super interesting because it was single page applications one of my personal pet peeves was that they always render into a spinner so it's like if you're doing edge jam stack etc it's like the edge is like really fast time to spinner and that's not really going to

help your business right like if i go to amazon.com and i have really fast rendering of a spinner then that's not really good so that would be like the first paint of the pipeline. But what you're most interested in is like, how long does it take until the most meaningful paint has been made? So the one that has the products, the buy button, et cetera. And that's LCP, largest contentful paint. And the other one that I'm really interested into with all this new modern web tooling

that we're talking about is that if I press buy, will the website respond at all? First of all, because sometimes it doesn't do anything because the JS isn't loaded. Or, you know, I don't know if you've ever seen this. It takes you to the top of the page with an anchor because the href has an anchor. So you press buy and it just goes to the top it doesn't do anything until js loads uh or even worse like is that because the anchor doesn't exist yet like that element doesn't exist yet when you're clicking it yeah the element has not received the on click handler yet oh it hasn't

been all it does is just go to the top and there's no really people use the anchor tag but there's no really anywhere to go because the buy button is supposed to do something with uh on the page with javascript um so uh first input delay refers also to the fact that you might click and you might not do anything for a very long time because it's still working through loading all the j. And a stat that gets thrown around a lot, but I think is worth reiterating is when you take that phone from India and you, and just mere act of loading JS,

just downloading it, parsing and compiling it, that could take, you know, 20 seconds for something that the iPhone can do in a couple hundred milliseconds. So that first simple delay web vital is, okay, I'm going to tap, and it's going to respond to my input very quickly, which is what most people want.

And I'm going to preface this by also saying, or caveat this by saying, this is all kind of heuristic what a contentful paint is before it reports it. But at least now we say, okay, these three core web vitals, we must all agree that they have to have really good values. So much so that Google is going to start ranking pages incorporating these measurements which kind of also closes the chapter on amp in some ways because we all probably remember that amp was not received very favorably because amp had this property that

you could be on a google carousel only if you'd built with AMP. But what's interesting is, and the reason I was never too upset with AMP is that I could tap on those things. I could tell that they were infinitely faster than the web, at least from my experience. And mostly it was due to prefetching and other things. But what's nice is that what came out of AMP was them realizing, for example, that layouts had to be stable. So this new cumulative layout shift with Vital comes from that learning of, look, what makes an AMP page be fast? One of the components is that they thought very deeply

about a more constrained layout system that made it less likely to have a layout shifting around when you first load the page. So in some ways, like the circle is now closed. And we can say, you know, if you're good at these three core web vitals, then you'll have, you know, kind of this optimal placement and ranking, because you're making a fast website. So it's a way of kind of submitting the proof back into the internet that you have a really fast website. Wow. That was like a 101 in web performance.

There you go. Like a digestion pill in web performance or something like that. Web developers learn. Wow. Is Web Vitals finalized? Do they agree upon it? Is there argumentation about... something like that. Web developers learn. Wow. Is Web Vitals finalized? Like, is that, do they agree upon it?

Is there argumentation about? I'm pretty confident that they're set because my understanding is that, and you can fact check me on this, is that I think I heard March, but the Google algorithm will start incorporating

the core Web Vitals. So Web Vitals are many, but the three that I talked about are the core ones. And yeah, I started going to kind of this tangent because we're talking about jm stack and one of the things that uh kind of comes out of that movement is that you know at the end of the day like your edge caching a static html is not going to do as much for performance as you might initially think in some cases it's super good and it helps tons, etc. But there's that.

And there's also a personalized web, which, and this is my personal opinion, I think the way to be native is for Facebook to render a news feed just for you that's optimal with the standpoint of their ads and the content and whatever, on mobile, they have to download hundreds of megabytes of code. They basically pre-download every possible user journey. And then the updates are also super heavy as a result. The web, I can tell you, hey, go to guillermosfacebook.com. You've never seen it before in your life and it can render just in time with all this amazing, you know,

code that's been preloaded in the cloud. I can render the perfect optimal page for you. And that's a property I think we need, like if we want the web to win, I think we need to like maximize our utilization of that property because that's where like, it's a non-starter, like, you know, mobile native has opposite advantages in some, in some ways, like raw CPU computation, or maybe GPU access or whatever, they might beat us. But in that specific supercritical dimension,

the code distribution of redeployment and that first initial paint could actually be where we destroy mobile native. Right. And I mean, it matters so much with data usage, especially in, you know, like I would say developing countries, you know, where folks are like data is currency. I mean, it's like that in the US as well. I shouldn't really say developing countries.

It's more like, you know, data is really currency and people are very conscious of like how much their apps are updating and like which websites are quote unquote fat, right? Right. But yeah, I totally agree. The web wins on versioning and distribution, hands down. I would say it's interesting, this Web Vitals is... I think Google has kind of been playing around with some of these metrics for quite a few years now

in terms of what's important. It was like TTL, time to first meaningful paint. And there's like several acronyms over the like six years and i've kind of like i've kind of stopped paying attention because i just profile yeah fcp even right like we used to talk about first contentful and now it's largest which makes sense but with the iterated a lot first meaningful right they iterated a lot and it's fine like this is it's all good i think it's um you know like kind of going back to your earlier point like it's nothing is one size fits all um with the web and i think for me going back to like our earlier discussion around like what makes a world-class team or world-class stuff like a software project. For me, it's in 2020 or 2021, right,

whatever. It's software that's progressive, truly, truly progressive at its core, which means that, you are handling for different capabilities and different devices within one software base, within one code base, I should say, right, so that you are like able to do progressive enhancements and progressive, what's the word of what's the opposite of enhancement, like de-hancement? I don't know. Degradation. Degradation. Thank you. Degradation. Yeah, you know, you can gracefully, you know, because really, that that's how you're going to win across, like the reach of the web, you know,

because that's the unique challenge that we have developing for the web is, you know, we don't have these known devices and known constraints, right? Yeah, what you mentioned about data really resonates with me because I've heard, I'm from Argentina originally, and I've heard outside of the bubble, and there's always bubbles, right? Like, why do you have this bubble? Like, in my country, like, where where i grew up which was outside of the city of buenos aires i was like outside of the bubble but even the province of buenos aires is a bubble relative to the rest of the country and her stories from out from other places in the

country were like you are like i'm gonna go back to the town where i can connect to a certain wi-fi to download the app such that they can leave and then use my worst data plan to then interact with the app. And there's all these constraints that have to deal with this long tail of users. From our perspective, it's a long tail. But if we align our software adequately, and we empathize with those other you know other use cases then we make our software reach places that you know we didn't even think possible that's what i think you know whatsapp did really well like whatsapp got massive distribution argentina one of their first clients was that it was like a mobile java something client light client that was like less than a megabyte to download.

Like you have to really empathize with like all these massive numbers of people that actually can consume your content if you distribute it correctly to them. And I think that's another power of the web that will be hard for, you know, an app store ecosystem like iOS is to compete with. Yeah, I agree. I would say though, I think to kind of push that further, there's some really interesting things coming to the web platform,

Temporal being one of them, which for those of you who use projects like Moment or other daytime libraries and like time zone management tooling, it's being able to actually get that in the browser natively is huge. I think Temporal's in stage three or, sorry, they're hopefully going to be advancing to stage three. It just, it took a long time.

There's a lot to coordinate, but we'll link it in the show notes. You can check it out. It's just a daytime like support and time zone support coming native to you, which is nice. And that's a great example, by the way, too, of the power of the browser in so far. There's a lot of code that has already been written, has already been loaded by the web browser instance

that why would you try to then ship more code that is not loaded yet that hasn't been downloaded parse compiled loaded to do the same thing the browser already has so this is like one of the key things out of the web that we also need to leverage one of the recent optimizations that we made in xJS was just more advanced polyfilling such that we are not giving gigantic polyfills to browsers that already support the modern JS syntax features. Right. And this is an example of the browser has already loaded V8

with the capability to use, for example, the class syntax. However, you're investing all this work to pre-compile into another type of syntax and make your bundle a lot larger and then not really reutilizing that which has already been loaded. And that, by the way, is another subtle advantage that the web has against native.

So when iOS needs to load a new app, it's just basically like a sandbox of untrusted code that is being run by the app developer. And very little of that is shared with other instances of other apps. However, when you leverage primitives of the web browser, the web browser is already optimized for caching and rendering a lot of different things like the font atlas and different capabilities of JS engines.

You might already have even parsed and compiled and cached your previous bundle from another page visit. The moral of the story is, try to use what's already been loaded and don't try to download it again. You're never going to beat, you know, the software that's already running on the device. Thank you. and offers everything you need out of the box. One-click scaling, zero downtime deploys, built-in SSL, private networking, managed databases, secrets and configuration management, persistent block storage, and infrastructure as code. Heroku customers running production and staging workloads

typically see cost reductions of over 50% after switching to Render. Here's the best part. We work closely with the team at Render to ensure you have zero risk. By giving you $100 in free credits, plus they're going to assign a world-class engineer to your account to offer guidance and answer any questions you have. When you're ready to transition your infrastructure, they'll be there to help you with that too.

Automate your cloud hosting with Render at render.com slash changelog. Get $100 in free credits to try the Render platform, plus a world-class engineer assigned to your account to guide you along the way. Just send an email to our special email, changelog at render.com, to get access to those free credits. All that begins at render.com slash changelog. So where do we think this is all headed?

I mean, there's definitely things happening, exciting stuff. There's things that we've learned in 2020 and run up to it. Things that happen culturally around the web. I mean, we've seen a lot of the large players really take a stranglehold culturally or socially, even just in terms of, you know, web traffic. The pandemic has been a interesting thing to watch. It's been very much a rich get richer kind of a situation with the large players such as Facebook, such as Google, such as, you know, insert Fang stock here, really booming, you know, and really taking a large

share of the value out there on the web. And we've seen people pushing back and trying to like, decentralize, move things in other places, etc., that's on websites. But in terms of the web platform, are there people making moves to provide more opportunity, more tooling, ways of kind of letting the little people have their place and do things on the web and flourish like a lot of the big players are flourishing right now. Oh my gosh. I, I, this is,

it's like such a big question. I was like, do you want us to be here all day, Jared? It's answering 60 seconds or less. Yeah. Okay. You want my 60 second answer?

Yeah. I'll ding you. I'll be customer focused. That's my answer. Like ultimately the web is powered by people who love your products, your websites, your apps, your, you know, so build for your customers first and like focus your efforts around your, your customers, your users. Um, and you'll never go astray. Right. Um, I see too many developers getting either hung up on just things that are really not user facing.

Right. And I can give you a really good example. And we might get some, get some, we might get in trouble for this, but, but TypeScript, right.

So TypeScript, TypeScript. I mean, if I could put a survey out there for the number of hours that developers have spent, like fiddling with their types and like making something work you know for a system that like quite frankly like what typescript has done is incredible but but the reality is there's always going to be gaps you know and we see that

with lodash and other like things that you know the beauty of javascript is just never going to be able to fully be expressed with typescript right right? And so, you know, like, just don't spend time on things that your users are never going to experience. Like, focus on, like, optimizing the code that is going to run in the browser. That's going to run in the browser for your customers, yeah. I couldn't agree more. I even have a similar opinion of TypeScript. All our teams love TypeScript, right?

Oops, sorry, Jared. I have no horse in this game. No, you don't, but, lot of typescript fans i'm sure you know and i like typescript as well i don't yeah i don't i don't dislike it i mean i'm starting to like i'm actually a huge nerd for correctness systems and proof construction software and like checkers proof checkers etc but the thing that i'll say is and i kind of updated my thinking on this recently i used to think typescript is a trap for not thinking about the customer and thinking always about your type construction spending endless amount of time on the beauty of your type of constraints with no regard for whether you're over-constricted in the state space of possible valid programs or,

or whether you're doing the opposite, which is like writing plain JS, which is under declaring all the possible correct ways of using your software. So I think there's always a balance like JS plus unit tests, constraints that valid programs to be executed to a certain extent, but that's not enough. So introducing TypeScript is a great thing. It's incremental.

You can adopt it progressively, but you can get into this pit of like, all I'm doing is focusing on over-prescriptive correctness of a limited version of my software, which I haven't even given to users yet. But then the reason I say updated, my thing is I realized, well, you could argue that for abstractions too.

People have a lot of times fallen for the pit of like, I'll write a better React or I'll write a new state management library for React. So I think the type of developer that'll not use TypeScript wisely might be the same one. And this is my current hypothesis is the one that was like also doing a lot of activities or libraries being written or whatever

and not thinking so much about the end user first. Oh, like the not invented here. Oh, that's another one. That's another 60 second one for you. People who don't leverage open source technologies and like try to reinvent the wheel. And like a lot of folks like really,

I mean, oh my God, the examples I could give you, but I won't. But really like just use open source. But aren't many of those great open source libraries actually reinventions of the wheel? I mean, isn't that how we progress? Sure.

We could get into that. That could be an infinite. That could be an infinite. You know what I've been saying recently, and I really stand by this, is in my mind, the introduction of the idea of a component as a primitive,

together with functions classes strings etc feels to me very fundamental it feels to me like when we invented atomic theory in the 1800s we never looked back and we're not like currently trying to reinvent atomic theory right so fun fact you know react has this like atomic structure icon so the metaphor even goes there. But I think that answers why I think at some point you realize, this makes sense. This is an industry-agreed standard. This feels fundamental.

I'm not going to try to reinvent it. And there is a pointless, not invented here of, you know what? I'm going to write a better Moment.js today. And there's standards coming out, and there's data fence, and there's all this other, like, maybe there's no true space. Oh, that would be a terrible idea. Yeah, I was going to say, maybe there's no true legitimate space. Maybe there is. Maybe right now there's someone that is solving it

for the domain of internationalization or something that I haven't considered previously. However, you know, we could agree with a certain degree of certainty that that wouldn't be a good idea today. So I think picking your battles with invention and creativity, I like what Brett Victor's motto here, or mantra, which is inventing on principle. So if you have a principle that has not been thoroughly applied to a certain domain, like direct manipulation in his case, that he can alter a visual representation directly by manipulating that representation itself, you say, okay, my principle has not yet been applied to the domain of TypeScript. Then there's room for invention there. But broadly, I agree with Amel

that, agree and disagree, in some senses, I think TypeScript has created new ways of wasting time. Yeah, I agree. It has created new ways, but I just wanted to say that I don't hate it. I was late to the game. Every time I do a big refactor and my app compiles perfectly, I feel a lot more confident now with TypeScript, let's say, than I did with JavaScript, like real talk. And so yeah, and also, I think the question about like, JS is still being there, I think it's so

important, because the agility of JS, when you're experimenting, when you're playing with what an API could look like, even when you want to give something to a customer before you know, what do you want to build, right? Like, there's still so many good places for it. I think we can't be dogmatic about putting TypeScript everywhere. So yeah, I would certainly agree. I'm ready to make my first prediction for 2021 now that I'm sitting here listening to you two.

And I'm going to go ahead and predict that TypeScript will have reached the top of the hype cycle, begin its way down. And the takedown pieces. Oh, the takedowns are coming. You think there's more? Nerds be nerds.

So you have some faith. I think the takedown pieces are going to, why I switched off TypeScript is going to be the new blog post for 2021. Oh my God. No, I think TypeScript, the good parts, it's probably going to have, this is my guess. Oh, I like that. I'm not an expert.

Yeah. Pragmatic TypeScript. Thank you very much. I want to push pragmatic TypeScript the good parts. It's probably going to have this, my guess. Oh, I like that. I'm not an expert. Yeah. Pragmatic TypeScript. Thank you very much. I want to push Pragmatic TypeScript as well. TypeScript the good parts. Someone needs to write that book. Yeah. It's already happening.

I recently saw an article on like how you get, or I think it was a page in a documentation that started resurfacing on like type checking has a cost in terms of performance. So like there's already a case to be made about like using types of a certain way to maximize type checking performance, for example. And I think I've already seen some take those specific features like usually I think that's we're gonna see that but at the same time, I think we're going to continue to see growth because so many people that are maintaining larger projects have not even started using it. And the type system is an area of intense

research and innovation in its own. So I think we're going to see more and more very interesting features and capabilities. Another thing I'm excited about is assembly script, this subset of TypeScript that can be compiled to WebAssembly. I think we're going to continue to see traction there. It's gaining support for closures. So it's basically saying like,

this thing that almost looks like JS is compiling to this tremendously optimal standard that you can execute in safe sandboxes at the edge of the network. That stuff is going to blow up, I think. Yeah, yeah, I agree. I think that's going to be huge. Like edge computing in general and edge everything has been growing. And yeah, but I would say I'll leave our listeners with this one thing. Feel free to like reinvent the wheel just do it on your own time i would say like as long as your website is like not optimal for your customers that are like you know you want to make the web a better place for them so that they like feel better about using the

web on their shrinking tinier devices right so So reinvent the next big thing on your own time, you know? Yeah, that's what I was saying. I'm so excited about Web Vitals because it'll create the possibility for people to say, like, look, this metric is not looking good for us. I'm going to invent on that principle. I'm going to say this new thing got us out of this problem. And that's having that kind of end user impact

that you're describing, right? Like we're inventing because not necessarily there's a better abstraction or better ergonomics or, but we're actually benefiting users too. Right, agreed. Love it, love it. Well, okay, Sharima, thanks so much for coming on the ChangeLog.

Amel, thanks for being wing person. Is that what I call you? For being my wing person here today? Yeah, wing person or wing lady is fine too. Wing lady, I like that as well. Yeah, we established that I am m'lady or whatever. M'lady of JS Party. M'lady.

Thanks to both of you for your passion for the web platform, for continuing to push it forward while dragging us along and our best practices and helping us to invent things but inventing them on our own time i like that i think i might go invent something right after the show on my own time right here but uh thanks for coming on the show and uh we really appreciate it we'll talk to you guys next time it's good to be back thanks so much for tuning in if this is your first time tuning in thanks for tuning in if this If this is your manyth time, thank you for tuning in for so long. One of the cool things we love around here is our master feed.

You can subscribe to this show and all our shows via our master feed. Check it out at changelog.com slash master. If you want to increment on that one more level, check out changelog plus plus at changelog.com slash plus plus. That's our membership. Get the no ads versions of our show. Get closer to the metal. And of course, enjoy supporting us in all of our podcasts.

Thanks again to our awesome partners Fastly, Launch Darkly, and Linode. And of course, thank you to Breakmaster Cylinder, our beats master in residence. Thanks again for tuning in. That's it for this week. We'll see you next week. Thank you.