1.4 - Next js 10 with Guillermo Rauch

Hey, Perfect Peeps! Welcome back to perfect.dev. Today with me I have Guillermo Rauch, and he is the founder and CEO of Vercel. It's a cloud platform for static sites that fits around a Jamstack workflow. He's also the co-creator of Next.js. He previously founded LearnBoost and CloudUp and is well known as the creator of several popular Node open source libraries like Socket.IO, Mongoose, and Slacken. Prior to that, he was the core developer of MooTools. So welcome.

If I can— thanks for having me—

the right link again today, it's a struggle, I swear. There we go. It's, it's like learning StreamYard all over again every time I get into it.

It's a great platform.

It's, it's fantastic. I love the web. We— Brittany and I were just talking offline, and those, those who haven't seen Brittany yet, I think Brittany is now a a co-host and also partner on Coding Cat Dev. So super excited. Hello, Brittany.

Hey everyone, nice to be here.

Yeah, so just kind of to dive into it, we last spoke almost a year ago, I think was the date on our actual recording. So I'm super excited to start 2021 out with you and dive into Vercel and Next.js. Um, there's been a lot going on, so I'm gonna read through the list real quick and then we can break down some of it. So, um, last time I talked to you, uh, Vercel was still Zeit. So Zeit became Vercel and gained $21 million in funding. Um, and then pretty much in the second half of the year, uh, Vercel took on another $40 million in Series B, which happened just in December, a couple months ago.

Yeah.

Um, And then kind of on the Next.js side, which is often what I wanna talk to you about anyways, you moved on from Next.js 9 to 10. Super exciting. I mean, there's a lot, lot to unpack there.

A lot to unpack, but the story is very much around the success of Next.js, the success of Vercel as a deployment and collaboration platform for frontend developers. And you mentioned Next.js 9. And when you introduced the company, you said static and Jamstack. And one of the interesting things that happened in 2020 was Next.js kind of became this hybrid framework for both static and dynamic experiences. And that happened with a bunch of features around progressively deployed into Next.js like 8, 9, and 10. And this is where we really catalyzed the growth that we were having. Because it started making sense for every developer in the world. The developers that wanted to do static, the developers that had very advanced dynamic needs. And so we saw just tremendous growth in 2020 and a bunch of investors prompted a Series B round and we found amazing partners to continue to work on, on, on open source and the Vercel platform. And yeah, we're really excited.

So is the team growing like immensely due to that, or is that a lot of like infrastructure type funding? What's that look like?

Yeah, that's a great question. So I would say the team is going to grow quite dramatically throughout 2021, but we want to do so very responsibly and inclusively. So, you know, the thing that a lot of startups do is like, oh, I just raised a lot of money, just bring in, you know, 50 white guys into the team. And like, we're now, we're twice as big, half as productive, and not inclusive. So we wanna do this responsibly. We wanna be true to our open source ethos, continue to invest a lot in Next.js, the open source project. We want to bet on a lot of people that, you know, another thing companies do when they raise a ton of money is, oh, let's just hire every established expert in every domain. And we're certainly gonna do a lot of that, but also bet on people that have been excluded from the industry or otherwise underrepresented. So there's a lot of interesting things that are gonna happen throughout 2021. The main thing is continuing to see this growth in the frontend development space and help developers succeed. The new thing that I would add is helping the rest of the team also succeed, kind of like using the power of frontend development to bring along and unlock collaboration for the entire company.

Yeah, that's, that's amazing to be able to grow like that. So there's a lot of fun new things coming into, uh, Next.js, and being able to back that with Vercel is incredible. I've only heard of one other way to fully utilize everything with Next.js, and it's with, um, I think it's like a Docker container, um, on AWS. So Outside of that, with the whole static regeneration, which hopefully we can dive into for a minute, um, it's kind of, it's kind of incredible to see, um, just the, the change that has occurred, um, going from, in my head, a server-side rendered product being Next.js, and then kind of with Gatsby on the side trying, trying to do more static, and then Next bringing static in, and I almost feel like it's come full circle where it's like all we're thinking as we're rewriting Coding Cat on Next.js is how do we go static first, and then when we need server-side, let's go. So it's crazy that— and I think that's where Next 10 is, has really changed or turned the corner for it.

That touches a little bit on one of the questions that I had. I've seen a ton of movement this year to Next.js from Gatsby. Just because of the ability for you to choose what you want or what you need. Totally. And so what do you think is driving that move? Is it just the choice or is there like developer experience?

Yeah, that's a great question because I think there's lots of little things. So developer experience is a great one, right? Like, our developing— development experience is just faster, boots up faster, feels better, etc. But I think what, what Vercel has done, it's been, uh, that's made us really prolific is that we always looked at developer experience as a condiment to great user experience. So you can't put limits on what the developer needs to do, like say, "Oh, you can only be static or you can only do up to this number of pages that you can pre-render at build time," when the developer needs to answer for business needs at the end of the day. So maybe they're working with an e-commerce website has millions of products or maybe they need to have really great SEO or maintain the current SEO that they already have when they're modernizing their front end, which is something that we hear a lot with Next.js. So I think it's been that combination of Next.js caters a lot to DX while being very realistic. And for example, something that's really cool is the Static generation capability emerged from lots of different conversations that we're having with customers like HashiCorp that they were like, "Mm, you know, this is cool but I need a little bit more power here, a little bit, some more dynamism here." We started off fully static with Next Export which is what predated the sort of hybrid capability of Next.js. You had to be, all static or all server rendered. And HashiCorp was like, yeah, we're hitting the limits of Next Export. And it's very similar to what the limits that you find with Gatsby, like where you say everything is static. And we could have said, well, no, just wait, we'll, um, we'll make that more powerful or faster. And what we did is like we had lots of other interesting conversations with developers and was like, you know, there's something more that we need to add here And also having two ways of— like, I have to be in two different modes or rewrite my application from static to dynamic doesn't make a lot of sense. And that's where we kind of gain this hybrid capability. And now the developer chooses static or dynamic on a per-page basis inside the same application. So it became really powerful.

Yeah, it's kind of incredible. I mean, I've been doing front end for you know, 12 years, and this feels revolutionary to me. Um, and not having to worry about setting up my own Express server and all of those backend things, it's just messy, right? Yeah.

Um, yeah, that resonated a lot as well throughout 2020. Frontend developers, in my opinion, even today, it's just like the best job you could possibly have in the industry because you're working on like where the customer is, you're working on the fun stuff really. What is the experience that makes the most sense for Coding Cat Dev's website? Or whether it's your personal website or whether it's your company's website, brands in e-commerce today need to become very differentiated because Amazon is already providing the cookie-cutter, every product in the world. And the cloned product from Amazon in one gigantic catalog. So companies that want to compete with that, they're finding themselves, they need to provide an experience that is truly unique and true to their brand and customer relationship and perhaps also true to their specialty, right? Maybe they don't sell every product in the world, they sell one category of product. And what's going to make the difference there I think is the quality of your front-end experience. It's not gonna be, I have a really fast backend, or I wrote my backend in Java or Rust. Those are not the things that are gonna make you competitive.

Yeah, that's true. It's a lot on the business side that's differentiating at this point. That cookie cutter, I hear you. Like, my day job is all in consulting and it feels very much that, but there is the business side too. So like, Businesses are looking for cheap solutions and a lot of times that's good, but if you want to take that next step forward and be better, I feel like Next.js is where people need to dive into. So yeah, you're going to continue to see growth in the next year. So I'm going to, I'm going to dive into my first like Vercel-ish question, if that's okay. Sure. So currently we are just kind of getting started rewriting the site and, and what we're going through right now. It's on GitHub. So Brittany and I have pull requests, we require that. And as we're going through it, it's doing the deploy preview and it's like, sweet, that's cool. And that part's amazing, right? And what always throws me off is it takes the preview and when you actually do the, like a dev merge for a production deployment, even though it's our dev site, it immediately pops it up and it's like, okay, we're good because your preview build was good. Was that, that was always kind of the plan to make that like better, like DX type of experience?

Yeah. Um, so the, the, you know, 10-year plan or 20-year plan or 100-year plan for Vercel is that you, there's no waiting anywhere, right? Like there's no waiting on, you push your code and you have your live site. You push your code and you have an experiment that you're sharing with Brittany. You push your code and You fix the bug. So, and we think even on top of that, like, sharing that deploy preview that you were talking about to get the feedback from the rest of the world is an essential part of this. Because when you work on consulting, when you work with clients, like agencies and their clients, feedback and product usage is what drives improvement, right? And it's really interesting because in our industry, Software is never done. In fact, software is so annoying sometimes that it's not only never done, but if you retreat and stop maintaining it, it degrades like if I leave out a pie outside the fridge for a week. That's how software is. It degrades if you're not constantly upkeeping it and maintaining it.

I like the pie reference.

I was just watching a pie show last night, so I think that's why, but a cooking show. But the key thing that Vercel sort of thinks about is we have to embrace this idea of you're constantly improving your product. You're constantly merging in changes. And to your point about when you merge, when you look at your PR, you get that deploy preview, Then if there are no changes whatsoever when you want to ship it to prod because there's no different environment variables or there's no distinction between your production dataset or your staging dataset, Vercel will just reuse all the artifacts that have already been built. And this is not entirely novel insight. This is how Google and Facebook have been able to scale engineering workforces of the tens of thousands. They realized, well, a lot of these people, when they work only locally, they're building the same things over and over again. What if we could reuse the artifact that was built by Alex when Brittany pushes? So, we're going very strongly in that direction because not only do we know it's been proven inside these organizations, but it just feels better when it comes down to collaborating, right? You kind of want to see instantaneously how it feels. And that's also very true to the frontend problem, right? Frontend doesn't benefit that much from, oh, I have a type system or the code compiled. You actually have to experience it to validate that it's great. You have to test it on your mobile phone. So I go and open my deploy preview on my mobile phone. And an issue as well is that I'm an iOS— Chrome fan, but we have a lot of Android fans as well. So, there is this small distinction between the Android Chrome experience and the, you know, iOS Safari experience. So, we want to get this— we want to make code very fluid, very realistic, and very shareable and collaborative.

Yeah, that's awesome. So, for us, the next step that we're kind of getting into— so, we're pretty simple at this point, but now we're starting to get into where we need some CI/CD and some true testing kind of in the middle. And my, my normal go-to would just be, okay, I'm gonna throw an image up on Google Cloud Build and do all the, the things I need to do out of that. Is, is there that capability in Vercel, or should I kind of take it out of Vercel and do something and then kind of wait for the build step afterwards?

No, we definitely want to embrace more of the testing sort of world because we think that we have a unique opportunity to also make it similarly fast, right? So as an example, we could run your test asynchronously if it's a preview deploy. We, we don't necessarily have to block you to start experiencing if you have a huge battery of tests that like could take a long time because they use end-to-end testing, for example. So right now we're starting to partner with companies like Checkly They will get your deploy preview, they will run headless web browsers. So they will run Chrome as if it was your user, massively parallel, and then they will go and check your frontend for problems and they will try to report if you have errors in your console or we plan to extend that capability to do performance testing as well. Like, what did that headless browser think of your performance? Did it load fast? So we wanna bring a lot of this automations right into that push process. You push, you get your preview URL, but you also have correctness and also performance assurance that comes with it.

Awesome, and so that's kind of things that are gonna be worked on in 2021 more so?

Yeah, so we plan to integrate these systems better. So today it's possible to do this with Cypress and Next.js. It's possible to use Checkly and the deploy preview to do more of the end-to-end user simulation. But we want to make this more and more and more ergonomic, right? At the end of the day, this best practice that you're talking about, like CI/CD, they're standard for software development today. So you should expect them out of the platform for sure.

Cool. No, that's great. That's great to hear. Yeah, Brittany, I know you have some questions coming from Gatsby type of background.

Yeah, we talked about that a little bit earlier, and I really wanted to know what was in store for 2021, and we've touched a little bit on that. Um, I heard you mention Safari and Chrome. Have you had any issues working with Firefox and Next.js, or do you have something in the pipeline for Firefox?

So in terms of, uh, Next.js and the browsers it supports, we have extensive tests— speaking of testing— extensive testing in parallel across all browsers we support, right? So we want you to have an incredible experience in Firefox right out of the bat with, with Next.js. Now, having said that, there's a lot of stuff that the developer comes and adds on top that can create problems, right? And the one that I find most interesting really is in iOS, the viewport kind of like changes over time. So if you scroll in a certain way or if you swipe in a certain way, it's almost like Safari is making the developer job so hard. I always related to if you were a painter and your canvas was constantly changing in size, you wouldn't be able to create a great painting. So I call out testing Safari on iOS especially because I do think that for most devs, Firefox, Chrome, will have become more an edge for Microsoft, they're becoming more of a certainty. Sometimes Firefox still is a little bit different, but the thing that really kills it is mobile web browsers. That's where I think the web, we really all need to collectively improve our components, our tap interactions, the snappiness of our front ends. Obviously think more mobile first, think more responsively, and that's where, again, like the deploy preview, what I find is it's incredible in that most developers are still developing on localhost:3000 and Chrome, and occasionally they toggle the viewport for like, oh, I'm gonna see what this looks like on mobile, but that's very different from reality, you know, and you can forget quite a bit as well to do it. So the real URL of your frontend helps a lot there. And also in terms of 2021, I think this is a good segue into we're still working a lot in the infrastructure of Next.js. There's a big innovation that came out of React now called React Server Components. In a nutshell, it'll make it even easier to get data for your components, which I think has been always a complaint in the dev space, especially for some of us that have come from PHP backgrounds where we're like getting data from MySQL right into our template. Like, it felt just very easy. So, uh, the core React engine is, is creating some innovations, uh, many of which are actually inspired from Next.js and the success of server rendering and getServerSideProps and getStaticProps in Next.js. Uh, they're giving us the hooks to make that data fetching be more ergonomic and be more co-located with your component logic. So we're really excited about that capability and it requires a lot of investment in Next.js, it requires investment in Vercel to support the sort of streaming rendering capability that React is introducing. So in some ways the world is like, okay, we went from static We added capabilities for hybrid static dynamic, we added incremental static generation and so on. But now we have the opportunity to also reconcile these worlds more and make data fetching even more automatic and elegant and let the developer opt out of static and add some dynamism without even having to rewrite most of the page. So I'm really excited about that kind of infrastructure primitive that we're going to have in 2021.

Yeah. That was pretty exciting coming out of it. I watched the YouTube video and being new to React somewhat now, I guess I've got a few months under my belt now. But just listening to that talk, I was lost. I'm like, I'm totally confused on the benefit of what's going on here. So I'll have to go back. And research it because it feels like something major and I'm just missing it. It's almost the equivalent to me of like, what are hooks? And now I don't even know how to write something without hooks. So that's probably what's gonna happen next.

Yeah, the nice thing is that I love it when technology will make a lot of different things across the entire stack better. But again, going to Brittany's point earlier, it starts with a great developer experience. Yeah. So the killer feature of React Server Components is that developer experience. It feels like I'm writing code that is accessing my data layer directly and I don't have to think about hooks and I don't have to think about separating my functions and so on. But at the same time, what it unlocks throughout 2021 is absolutely incredible. Like small JS bundles or no JS bundles at all, personalization so that it can render a page differently for Brittany and for myself because we're in different cities. It enables us to make some static optimizations even more automatic. So the downstream effects of it are huge and we're all gonna discover them together throughout 2021 because it's quite an impactful kind of low-level primitive. Kind of to your point, similar to when React introduced hooks. But at the same time, it enables all these optimizations and new capabilities like streaming rendering. Like, I can begin giving you bits of the page as the databases respond.

Yeah.

So I'm never blocked anywhere. So it's, it's absolutely incredible.

So this is going to take the JavaScript all out of the client, or allow us to take it all out of the client.

Totally. If the client doesn't need it, now the framework is smart enough to say, well, there's no bundle. But it's even more profound than that because if we say— what I used to think a lot about, and I would share the concern always with the React team, I used to think about a simple scenario from my, you know, old WordPress and PHP days. So WordPress has this feature that I love, which is if you're browsing the WordPress site and you're logged in as an admin, it adds a toolbar at the top with all your admin options. Now try to do that with React. Well, what's going to happen depending on what flavor of React developer you are, you might do something where you're not even prerendering. If you use create-react-app, you give me a spinner and then you render the blog post, so you threw away SEO. These are the things that Next.js fix. But even within the world of Next.js, how do I say, If I'm an admin, I don't even wanna give you the JS bundle on the client side to enable the interactivity of what happens when you hover those menus. I remember, I'm just speaking from memory, you would hover some of these admin menus at the top above your blog post. So in an ideal world, which is a world that React Server Components is gonna enable, I'm gonna say if admin, use this component called AdminToolbar and then the system, Next.js, will be smart to only give the bundle that has the components required for that admin toolbar to the client that is an admin. And the client that is not an admin doesn't even know that that exists. So that's a major, major performance. I think even just imagination improvement. Like, I think developers have probably been even abstaining away from creating this kind of dynamic experience just because of the mental overhead of like, oh my God, now I have to flag this component dynamic. I have to reserve space for it in the dynamic— in the static prerendering that I think we were not even making use of, of incredible technology like that.

Yeah, that's, that's crazy. And that's gonna be pretty cool when it comes out because now, to your point, it kind of blows my mind having to like write all that stuff in and, and check off and like, uh, it's just so painful. I, I love the new introduction of the next dynamic piece in there though? At least like—

Yeah, this has always been our pragmatism. We've been in conversations with partners and the React team and so many other players in the industry about this requirement. When I explain to people, I always bring it down to an example like this. It's very clear that we're talking about a very simple product concern. It's taken so much engineering to enable this. It's insane how much it's taken and for good reasons too. It's not that people at Facebook or Google or whatever or Vercel, we work slowly or we don't wanna solve the problem, right? But the scenario that we've been in is like we had, and this is kind of like one of the values of Vercel, which is always meeting the customer where they are. And like we did with static pages, with hybrid dynamic pages, what we did there was we invented this sort of, Next/dynamic component. And you could say, well, this toolbar at the top is dynamic. So, but that is still like the DX is not very good. Um, it, it takes quite a bit more work to like really get to the point where you've nailed it. Um, and it doesn't work so well with the static mode, of course, because now the static mode will have to, like I said, reserve the space for the toolbar even for— or otherwise you're gonna get a layout shift. Because you do a static prerender and this is the Jamstack way, right? Then you use JS on the client side and say, "Oh my God, I'm an admin. Oh, I have to render this dynamic Next component at the top. Oh, and let's push the page down," which slows down everything. So static was also kind of like a no-go for that. But if you were using server rendering, again, the DX was just not great. So React Server Components brings that unification to this world and better DX and just a lot of incredible automation.

Yeah, that's super cool. So often what I'm looking at, trying to get that Lighthouse score, right? So we're talking about how much we're sending out to the browser and it's constant. Like Brittany knows this, I'm always like, oh, we're back above 150, what's going on? And so, like, we look at the components and it's like, well, shit, we just loaded a Cloudinary video thing and it's 100K. It's like, oh my gosh, that should be dynamic, right? And we always are constantly playing this game. But I guess the question coming out of that is what I'm looking at is Lighthouse all the time and comparing that and other tools. Um, when we're using Vercel, Vercel gives this, this neat new analytics page that basically comes up and comes for free. What, what is the comparison there? Because it seems like they're very similar but yet different.

For sure, for sure. So, uh, to your point about what you're, what you're all doing with analyzing the videos and what the impact that— I think, you know, for a very long time, that's just going to be the job of the front-end engineer. You'll have to always be measuring and paying attention to budgets and guardrails and try to be as smart as you can with where is time being spent and what can I do to optimize. I think if we're not all replaced by an artificial general intelligence, I think that'll be the job of a software engineer for many, many years to come. Where do we bring automation and how do we help you do that job better really becomes the question. So Lighthouse is a test that people run synthetically, like almost in a lab, right? Like you open DevTools, you run your Lighthouse test and what it does is it tries to simulate the conditions of, by default, a Motorola device, like the average device in the world on a 3G connection. And then it tries to say we need to hit all these deadlines of time, basically. Like, we have to get the page painted completely, right? The Largest Contentful Paint— we have to paint it completely within this threshold. When I interact, it has to be responsive within this other threshold. And that's great, but where Vercel can help you is in automating that. Okay, if I push automate that synthetic score and tell me if I'm above 80 or if I'm above 90 and so on. But, but here's the thing, synthetic tests— and to your point out why the Vercel Analytics tab exists, and we're not just telling you at build time, hey, you're not good enough, or you're really good, congratulations— we need to also get the point of view of your real traffic. Because actually maybe you're not getting that many Motorolas on 3G networks, right? Or conversely, maybe you're getting a lot, or maybe you're getting a share of Chrome and Motorola and you want to understand, okay, what is my score from the perspective of the Chrome client or the Safari client or the Firefox client? And what is the perspective from the point of view of the mobile device? So those— we need both really. We need the synthetic and we need what we call real user monitoring. RUM. So Vercel started by prioritizing this— again, one of our values— we want to be as realistic as possible, right? Like, this is why we created deploy previews for you to test the reality of your product as close as possible to production. So much so that we use the same CDN, the same edge network for production that for your deploy previews, because we want you to test, quote unquote, test in production. But when it comes down to performance, we also want to give you first, okay, from your current traffic, what would be the Lighthouse score if that device had computed it? What we did is we looked at the equation that computes Lighthouse in a synthetic score and we're deriving the same or an approximation really as best as we can from the data that we get from the device without also impacting your own performance or adding latency. So it's a very inexpensive check of data that is completely anonymized. And then we tell you, okay, this device thinks you're 80, or this device thinks you're 90. So it's really brilliant.

It's awesome.

Yeah, so I'm just gonna bring up real quick here just to kind of show people. So people on the podcast, I'm just gonna walk through. So web.dev's up, um, on the screen right now for dev.codingcat, which is our new Next.js and kind of what Guillermo's talking about here. Um, this is, this is that synthetic version, if you will, or that container that it's running through. And a lot of people go to this and they take a look at it. And one of the main things, if I can find the button, which I can't at the moment, um, interesting. Um, usually they have— there it is, sorry. So usually when you run it, you can dive in here. And one thing that keeps popping up for us that is interesting is this unused JavaScript. And actually this is kind of the core of what Next.js is, but I've, I've read a lot about that part of it and it seems that that's just kind of part of the game. Like you have to have that small amount of Next.js in there.

Yeah, I'm used Unused JavaScript is not bad per se, right? Because you kind of want to load some JS that'll be useful for future interactions, right? You can't always optimize the first sort of paint at the absolute expense of everything else because the best example here is I want my large contentful paint to happen really quickly, but then I want to do more things with that. Like I wanna buy something, right? So imagine that you're creating an item page for an e-commerce website. And so your priority is to get that large Contentful Paint loaded super, super quickly. But as a business, your goal is not just to paint a brochure. That's what old school marketing did, right? I still get, in my place in San Francisco, I get the mail spam of colorful Target brochures, but I can't tap on anything and buy it, right? Only optimizing for large contentful paint would give you that experience of you just got a painted brochure, it's really quick, I look at it and zero latency, right? But I want to interact. I think some unused JavaScript might not be bad because I'm already anticipating that when I press buy, we're going to load a modal to get your details for checkout.

That sounds like prefetching. Is that like prefetching?

Next.js facilitates it. That's why some of the tests You also can't take every test at face value, right? So Next.js tries to aggressively prefetch unused JavaScript when it has the time. So it does this very intelligently. It prioritizes everything that's on the top of the viewport and then it tries to do so when you don't have to do anything that's important. Like, so it tries to deprioritize the prefetching automatically. But the idea is to give you that sort of app feel, right? Like when I open up a mobile app and I tap, there's no waiting, pretty much.

It's instant.

Yeah.

And so you do all that under the hood?

And yes, and automatically on the development, completely automatic. So if you use the Link component to link pages, or if you use the Next dynamic component, we prefetch the code before you're going to need it.

Okay, so just to kind of finish this thought, let me, let me bring this back up real quick. Uh, um, so on the Vercel side of things, what we were talking through, um, so you, you get these deployments, and this might be a little hard to see, let me boost that up a little further. Um, so over here, and this is, this is kind of why I was curious, like, what the difference is, because we're consistently like, okay, sweet, we're at 100, and if I go to like a P99 and check out that, it's like, all right, like this to me is our actual feeling. Like when Brady and I are going through this, it's like, man, this is super fast. Why is Lighthouse complaining so much? And so it's really nice to be able to see this. And I assume as time goes on, this analytics is updated for all the new events.

Oh, absolutely. As you get more data points, as you get more devices, And this is not me saying, hey, don't pay attention to the synthetic score and there is no Motorola on 3G in the world, obviously, right? But it's best if you have, as a developer or engineering manager or product person or designer, you have a holistic view. Okay, like you said, we intuitively know sometimes, right? Like, oh, really fast in Chrome for sure. And again, doesn't mean let's systematically exclude the slow devices of the world, right? 'Cause you're gonna hamper your ability to grow into emerging markets or you're just gonna be out of tune. I'm an engineer in San Francisco, I don't care about anything else. It's only fast enough stuff. But again, having all the data available to you makes you prioritize better. You could spend the next, 3 months of your life, make the best possible landing page for a device that's never going to visit your website.

I know it. And sometimes we get stuck in that cycle and like Brittany's got like, hey, come on, let's get back to features. Stop messing with performance.

It's nice to have that score to see and visualize and to see the things that you can improve on, but you, you can only emulate so much.

Exactly. Exactly. We noticed this a lot with synthetic tests, by the way. So We're making investments into stability of when we issue synthetic tests at scale, we want to really reproduce what a real device is because when you do it on the Chrome page, on the Chrome pane, what it does to simulate a slower device is it creates a lot of garbage processes that do a lot of wasted computation. Like, uh, Jokes aside, you could create a Lighthouse synthetic test tool that mines Bitcoin productively, right? Because we're trying to simulate a loaded machine and we could use this simulation to mine some Bitcoin at the same time and it'll give you, and again, it's a bad approximation really 'cause an Android device just has less, microchip capabilities. It's not just that it's busy, right? So, but again, it's a pretty good approximation. Like, if you're under a lot of stress, your computer's under a lot of stress, that's an approximation of what a Motorola or, uh, you know, the new, um, what's it called, the Redmi phone, the Xiaomi Redmi, is becoming the new average, the mean device of the world, is Xiaomi Redmi 9 or something like that. It's a dominant device in China. It's becoming huge in Brazil. Xiaomi is expanding all throughout Asia. They're making investments in Europe. It's certainly not this. This is not going to be the average device in the world. I'd still encourage synthetic testing to be a priority, of course.

Very cool. There's two last questions that we have. One is, talking about like MDX and, and what your viewpoint is on where that's headed. And I know, I know Next has, um, @next/mdx is, is kind of the new, um, npm package for that. What's, what's your viewpoint on it? Where's— where are we headed with it? We're using it personally. I just want to know, like, that's the safe way to go?

Yeah, so MDX, for those that are not aware, mdx is something we conceived as a community because I remember I was really fed up with how one of the Markdown integrations into React worked. Basically, mdx is a way of writing Markdown to generate React pages and it allows you to use React components in the Markdown. So, for developers, we love using Markdown. It's just so freaking efficient. You know, hash heading, enter, enter, text, text, text, hash heading, image, you know, exclamation mark, bracket bracket. But we're like, okay, how cool would it be if you could embed JSX React components in there? And it's also very well aligned philosophically with Markdown because Markdown was conceived to have a scape hatch for HTML. So the Markdown specification says you can do all this stuff, but you can also embed arbitrary HTML elements through throughout. So, we're like, let's come up with this MDX thing. And I posted a kind of a little article on proposing the idea and I tweeted about it. And then a lot of people had already been thinking about that. In fact, someone had arrived to the same exact naming almost. So, they named their project MDXC because they were working for like MDX JSX compiler. Then the community really quickly got together. Someone that was really good at writing parsers and compilers started writing a specification for the grammar and we started dreaming up tooling for it and so on. I use it for my blog. MDX is a great technology for developers, obviously, because a journalist that is publishing a breaking news piece on New York Times or CNN about the Capitol will not just, "Okay, sorry, I'm gonna write some JSX and mark that," right? No, they're gonna want a higher level flow with a CMS and a review process. So MDX is a great technology for when you're working on smaller sites that are content heavy and you don't anticipate that you're gonna have millions of pages and you have, you know, in the single-digit thousands at most, I would say, and you're comfortable with your entire team sort of writing in that format. So we endeavor to make MDX support in Next.js even better than it is today. We have a plugin, but over time we wanna polish that experience more and more because we think we always wanna make Next.js absolutely great for when you're kicking the tires and you're getting started. Before you have to scale. Like, why do premature optimization, right? Sure. If my own blog right now is 10 articles and I love it, and I'm able to use incredible Next.js features— like, I have a blog post that embeds an animation of, uh, the JS1K competition. And, you know, if I hadn't had MDX and the JavaScript escape hatch, I could have not created a very compelling component an experience like that. But then we also recognize that when you scale to the size of HashiCorp or Sentry, those people are putting a lot of load onto MDX and it still works great, but then you can even get bigger than that and you go into CMSs that are having millions or tens of millions. So we also want to cater to those. MDX is just an absolutely phenomenal technology. And yeah, if you're enjoying it, I recommend using it.

Sweet. So, were you saying that it's not as performant for larger scale?

Yeah, so what I'm talking about there is precisely two things. One is you put all your posts in one repository, right? And that starts having some limits even of workflow, right? Because, like, you, um, you want to have someone, uh, write a blog post that is not familiar with GitHub and And then they have to learn GitHub and learn MDX. I think for a lot of technical folks, that's perfectly fine. Now, if you start having millions of articles, a cold build process of that MDX site is probably gonna get pretty slow. And prerendering every single page when not all those pages are gonna be accessed is also pretty expensive, monetarily speaking. One of our customers, the Washington Post, has articles that date back to the '70s and '80s and they're all online. But imagine if every build was trying to pre-render ahead of their access, these less frequently accessed articles.

I'm so happy that we went through this because this is—

You literally just said this.

Yeah. This is the next question. I wanted to leave it for last because It's, it's been bugging me like crazy. Like, yeah, I, Coding Cat's this tiny little thing and I'm thinking like way in the future, but I'm like, what happens if we have 10,000 pages?

Um, yeah, it might not make sense to pre-render everything, every, every single one of them ahead of time. Well, we can do that just in time.

So here's my thought, and I, tell me if I'm way off. If I take and I can do analytics and say, here's our top 25 pages and here's our latest 100. That's the group that we do on our build. And then the rest we can just do on the—

what's it called?

Generate every 60 seconds or 1 second or whatever.

Not even that. So, today with Next.js, you have the capability where, like, it goes to the page and if it hasn't been prerendered yet, it does it just in time. And then it populates the static cache. Okay. It's like overhead. It's the same as—

exactly.

So that's a great way of doing it because the reality is, I mean, this has been rediscovered through time many times, you find power law distributions everywhere, right? Like, you know, 80% of the project takes 20% of the time and then like the last 20% is really hard. And, you know, right now on the web, 10 websites account for 33% of page views. Yeah. And then the next 10,000, or I should say the next 9,990, account for 33% of page views. And then the long tail of the web, 3 million sites, the other 33% of page views. So this is likely to happen even if your site is fully static. This is likely to be true for your site as well. So what I always recommend is if you can afford the time and computational capabilities to pre-render everything and you intend to serve the same exact content to every visitor, by all means. So if Coding Cat's personal website or company website is 1,000 pages all the same for every visitor and Next.js is really fast at pre-rendering,, and you want to do it at build time, do it. You know, it's just, it's actually more optimal.

Perfect.

Yeah.

I mean, that sets us up really well. I think what we don't want to do is get into like really long build times. You have a spelling issue or whatever, a component broke. Like we want that rebuilt quick. And then when we can get that going, you know, with all the CI/CD hooks and everything else in there, so we can make sure that doesn't happen. But, um, if we can get that going and then have that regeneration part in there, The only other hurdle for us is we have a paywall on our lessons, certain lessons, and that way we can say, okay, now we can safely guard this for cookies. I mean, that tells our whole story, and I think it almost tells the entire story of Next.js. I'm sure there's stuff I'm leaving out, but we're gonna do a course on how we built Coding Cat.

Oh, that's amazing. So that's amazing.

So that'll, that'll be— right now we're We're hosting our backend on Firebase and keeping our MDX or Markdown in Firebase and just kind of populating those components on the fly. And we're just gonna keep going at it.

We're seeing this a lot. We're seeing the remote MDX use case a lot as well, which is amazing because it's like, again, a hybrid of a static with a dynamic data store and then the end user result is optimal. So it's really great.

Yeah, it was, it was either that or go back to Sanity, sanity.io, and, uh, start to utilize their products. Um, the one thing that we keep lacking over there is authorization, authentication stuff. So I think they're, they're releasing that, I see, soon. So we'll see, we'll see if we stay where we're at. So at this time, we're just about to wrap up, and as, as you all know, we like to do perfect picks at the end. Guillermo, did you have a chance to, uh, come up with one?

Um, I didn't, but please, I'll come up with it now, so please.

Okay, well, the prompt, we'll do ours and you kind of think of yours. I think last time, last time you threw out a quote, uh, impossible just takes longer, which— oh nice, that was, that was a great quote. I remember now, I threw your, I threw your blog in there, so I'll, I'll pop up some of ours and we'll do ours and you, you keep thinking. Let's see here. Do the right thing, top left. Okay, so there's, there's your blog I threw up for you, but you can, you can make a decision. So my, my first pick is actually, um, Vercel's Next.js has a discussion group, which I didn't know about until not that long ago. So I kind of wanted to bring that up as one of my top picks, which I think is a very awesome and open forum that people can go out to. And I just love these new GitHub Pages, so I thought that was pretty sweet. And my second pick is this app called lightest.app, because as we just went through, uh, I'm constantly looking at performance, maybe too often. And you can kind of put either your competitors into this, or just, uh, for us, I have our old site versus our new site, which I can very clearly see how much better it is. So I thought that was pretty cool. So those are, those are my two picks.

That's amazing.

You have, you have, uh, a new Netflix show you're, uh, yeah, I have been, uh, binging this show and it's based on a book series by Julia Quinn and it was just really good. So I wanted to sick pick that. It's, uh, about family in the 1830s, I believe. And it goes through like the high society stuff. And it was kind of interesting.

Yeah, very cool.

I'll do one too along those lines. I love the Great British Bake Off.

Oh yeah, all the cooking shows are so good.

Very cool.

And I think he was showing up there. My other sick pick was, or my other perfect pick was my console log site. This is just my digital garden that I throw any notes that I take when I'm doing courses and stuff up, and there's tons of different things in there. So go check that out.

Very cool. Any last, any last thoughts as we're on our way out?

Yeah, I'll do mine. So I love this website called lighthouse-metrics.com, which is similar to the one you just showed. What it does that's really cool is it takes your Lighthouse test and it runs it all over the world. So if you go try my website, put rowgy.com, and what it'll do is it'll give you the score from the— again, synthetic as we spoke, but it'll give you the perspective of if this theoretical really slow Motorola device was in is US East, US West, EU North, EU West, Asia Pacific South, and Asia Pacific North. Again, with all the caveats of synthetic, as we mentioned, and all the caveats around stability, sometimes these tests can be noisy and people run them a couple of times. It's really cool. I'll say too, I've been loving this app called CleanShot X. So it's basically the absolute best app to take screenshots and record GIFs. And this has been an obsession of mine for a very long time. So I know the space a little bit because I built a company that was doing some of this that later WordPress acquired. And I know the effort that it goes into, for example, optimizing the performance of a GIF recording and the things that they do. And it's just an incredible app. And finally, I'll say a lot of you also don't know this, but you can go to nextjs.org/commerce to use our new e-commerce starter kit. So we built basically what we consider to be a very high-performance, innovative, beautiful storefront that can plug in. If you go to click View Demo, it basically plugs into any backend. Exactly. We have BigCommerce support right now, but we can use Shopify, you can use Salesforce Commerce Cloud. We even threw in that cookie banner there to make it realistic. We endeavor to make it, you know, as realistic as we can because we know that, you know, anybody can create a very fast 99 Lighthouse thing that does nothing. So we created a more comprehensive storefront that hopefully, you know, matches some of the needs that people have. And, uh, you know, you can clone and deploy to Vercel with just a couple clicks. Um, it's just the source code is all free for you to modify.

You know what I was just thinking of too? Um, You guys released your conference app as open source, right? Yes. Is that, is that on the blog? Is that under Vercel's blog or Next.js?

Yeah, so go to vercel.com/home. I think we linked it off from the solutions page there. Yeah, so the Commerce Starter Kit and the Vercel Events Starter Kit. So basically we hosted Next.js Conf online. It was a massive success. There's 82,000 registrations and we built a little frontend for the event where the schedule was, where all the videos were being embedded, where the sponsors' pages and we just open sourced it as well. So if you're hosting an event of any kind online, which I think a lot of people are thinking about now because of the pandemic, You can also clone and deploy this in just a couple of minutes. And again, the source code is free for you to modify entirely. So, all you need to know is just a little bit of Next.js.

That's amazing. The next time we host, like, a meetup, I might just try this out, see how it goes. Excellent. Very cool. Well, thank you so much for coming back on. I really appreciate it. I know that you're a busy person. So, I'll say it again. I love having you on, so as much as I can have you on, I will. And, uh, I hope we can find some more time in your schedule.

For sure. Uh, see everyone soon.

Thank you so much.