Ben: Hello, and welcome to PodRocket. Today, we are here with returning guest Guillermo Rauch, who's the CEO of Vercel and the creator of Next.js. It's great to have you back on the show, Guillermo. How are you doing today? Guillermo Rauch: Thanks for having me, doing great. Happy to be back. Ben: Yeah, great to have you back. I really enjoyed our first conversation which was probably, I don't know, a year ago, time flies. But I know a lot of new things have happened in the Vercel world, the Next world and I know you recently had your big user conference and there were a ton of exciting announcements coming out of that and want to talk about that, learn about what's new. Maybe before we jump in, you could do a very, very quick overview of what is Next, in case there's folks who are not familiar or maybe have a basic familiarity, but want to know what is Next all about, and then we'll jump into more of the details. Guillermo Rauch: Yeah. Next.js is a framework for building websites and applications on top of React and it has a couple distinguishing features like, when you incorporate Next.js into your stack, it can add itself to any data source in the world. You can combine Next.js with headless e-commerce back ends, with headless CMS back ends, with all kinds of rest or graphical APIs. So it's gotten a lot of popularity over the last couple of years as a way of modernizing the front end part of your application where your customer experience lives. And perhaps the most salient feature of Next.js is that it does a lot to make really high performance applications happen out of the box. So instead of having to relearn and re-implement everything that makes a great high performance production application from scratch, you can just take advantage of Next.js to do so. And in the context of the React world, where a lot of folks in the React space have been more used to client side applications or single page applications. Next.js takes this different viewpoint of using the server, the cloud and the edge by default. So it's kind of more optimized for SEO and just really large scale applications. But it can also be used for building very small things like a simple static page so scales up and down really well. In conjunction with it, we build DEVAR cell platform which allows you to deploy your Next.js applications really seamlessly and take advantage of a global network that delivers your front end with the highest possible performance, while also minimizing the amount of operations work that you have to do as a team to really scale out this front end applications. So to give you an example, Next.js and Vercel power underarmor.com, which is one of the largest retailers in the U.S. for sports and clothing gear. And they take advantage of that ability to plug in into an existing stack and speed up their applications with Vercel. Ben: Awesome. Yeah, thanks. And recently, I know you had your Big User Conference and launched Next version 13. And so why don't we look at a couple of the exciting announcements you did there. Maybe we could start by talking about compilation infrastructure and Turbopack. I know that was a huge announcement and out of excitement on Hacker News and whatnot. So can you give us a quick overview like what is Turbopack and why did you decide to rebuild the compilation layer from scratch? Guillermo Rauch: For sure. Next.js is done a lot of technical feats that I'm really proud of, but when I ask people sometimes, what do you love most about Next.js is that they tell me, well, when I started using Next.js, I outsourced the configuration of Webpack. So one of the things, in addition to all this great out of the box production optimizations that we shipped with Next.js, it was this idea of zero configuration. So when Next.js came out, the status quo was that to build a React application, you had to configure compilers, bundlers, Minifiers, plugins, tool chains, development environments. And we said, well no, I just want to build an app, I want to build a landing page, I want to build a dashboard, I want to build an eCommerce storefront. So we took this really opinionated stance of you don't have to configure a Webpack. And I think in addition to all the great features that have given companies the scalability, like I mentioned, I think it was a nontrivial part of our success that we took that stance and many have followed through with that same stance ever since. And certainly you could still extend Webpack, but the idea was, you sit down, you start writing your first component, your first page and you're ready to go, zero configuration. Now in the past six years since we first started dabbling into this idea of frameworks on top of React, things have changed quite dramatically. One of them is that the size of front and code basis has grown exponentially. We ended up hiring the creator of Webpack to work at Vercel and I remember in his first conversation with me, he was like, I could have never imagined that Webpack would be used to the extent that it's being used, to the size of code bases that people were telling me are running on this thing. It was my research project when I was in college, he told me. And now it's been downloaded billions of times. It's a tremendous scale. And the problem really was that Webpack and many other tools like it like Babel, like Terraserver, a lot of what really made a dent in the world as a default tool chain for modern front end applications, it was all written JavaScript because it kind of emerged organically. This thing is like a startup, all these tools like React, Next.js were having really fast product market fit and we needed to iterate very quickly. For example, at the time TypeScript was around, but it wasn't being used even to the extent that it's being used today. So the natural thing to do was to write all the tooling for all these tools for JavaScript in JavaScript itself. Now that things have matured more in the ecosystem and that a lot of the standards are being set, for example, the vast majority of applications in Next.js are being created with TypeScript. The vast majority of people are no longer extending configuration for things like Webpack. The front-end ecosystems reached a certain level of stability and because of the demand are so high in terms of numbers of files, numbers of packages, numbers of components, the tooling written in JS has not really scaled well. And what we started finding out was that the only way to continue to deliver a great developer experience, especially when people work on local and when they push a production to make their CI builds, was to start rewriting a lot of these tools in Rust. So essentially the first thing that we introduced at Next.js Coff was our successor to Webpack, it's called Turbopack, it's written in Rust, not only because it gets better native level performance when it's processing files or interfacing with your file system, which Rust is just faster than JavaScript at, but it also has a new architecture that focuses on incremental compilation. And the main idea here is that it doesn't matter how big your code based gets, the scalability mode of this tool is just basically better by design in a way where the work that's already been done will not be done again. So Turbopack borrows some of the lessons of tools like Basil at Google that were used to run mono repos with billions of lines of code, this concept of incremental compilation. So in a nutshell, we're creating a quote unquote, faster horse. So we took Webpack and all of its success and lessons and we're using Rust which is basically hundreds of times faster at doing what Webpack was doing in JS. But in addition, we're introducing this novel, fairly novel architecture. I think it's quite novel in the front-end world to do things incrementally, to not do the same work twice. And we're extremely excited about it and the world has received in similar fashion. Ben: Got it. Yeah, it's super exciting. Do you have plans in the future to rewrite other parts of the tool chain in Rust or with a new architecture or have what's next now that you've launched Turbopack? Guillermo Rauch: And to back up a little bit, again, the Next.js code bases were getting so big so fast that when we started facing some of the scalability challenges with Webpack, one of the first things that we turned to was native code. So what we did is we replaced Babel. So Babel was being used to translate the JavaScript syntax that developers who are using in practice into the JavaScript syntax supported by web browsers. So to give you an example, React uses JSX a lot, which is not a bias spec officially supported syntax of JavaScript. And it translates into function calls, it translates into ReactDOM createElements. So those syntactical features, Babel was processing the files in translating them into a JavaScript source that was understood by web browsers. Now, what was happening is that this Babel thing was actually pretty fast and it had a series of rounds of optimizations by extremely smart people. I remember, I think Sophie at the React team at Meta were doing a lot of optimizations. Of course the Babel team were doing a lot of optimizations. So you were down to like each file that you have to transpire takes a millisecond to be processed with Babel. The problem was, I remember looking at a trade one time that an engineer put in front of me and it's like, Babel seems fast in isolation, but the problem is that some of the code bases that we're optimizing against have millions of files in them. So it turns out that millions of milliseconds is a long time. So we replaced Babel with SWC. So it was basically a Babel like tool written in Rust. And now we went from the realm of milliseconds to microseconds. So that's when we realized, holy crap, Rust is not just two times better, it's 10, 20 depending on what phase of the process you're measuring, hundreds or even thousands of times faster. So that's when our first journey started to move to a more native tool chain. And now it actually makes sense to take a pause and even reflect on this. Most compilers in the world, most compiler tool chains are always written native code. When you download the SWIFT compiler, the C++ compiler, any mature tool chain for programming at scale is always written highly optimal native code. So that's kind of when we started partaking into that endeavor. Now Webpack is a thing that stitches together all your modules into optimal bundles to deliver to the web browser. It was kind of obvious to us at that time like, at some point we're going to have to rewrite that in Rust as well. It also happened with a Minifier, so Terraserver got replaced with SWC Minify and we saw incredible improvements. I think sometimes we measured for mature code basis. One customer of ours, like 13 times faster unification. And we're talking like a process that sometimes takes minutes, now it's starting to take seconds. So it's very exciting to a point about what's coming, we need to mature, stabilize and make Turbopack even more extensible such that you can still have a lot of the benefits that you had with Webpack in terms of ecosystem support and extensibility, but obviously with this improved architecture and with really fast performance. Ben: Yeah, very exciting. And it seems like the other kind of the big announcements in terms of Next.js 13 is on the routing and rendering side. So maybe you could tell us a bit more about the new file system based router and what went into that, what does it do and why is it exciting? Guillermo Rauch: For sure. One of the distinguishing features of Next.js that I think we're also quite early too, is that Next.js gives you the ease of use of something like PHP where you throw a file through the file system and then it essentially becomes a route. So I mentioned that concept of zero config. So Next.js said no to the momentum of I'm going to write my Webpack config for every project that I start. Next.js has also said no to, I'm going to configure a router and download a router module and stitch it together anytime I want to put a route into the universe, like my homepage. I shouldn't have to download react router, wire it in, define my route, no, just put a file into the file system and it immediately becomes a route and so on. It turned out, this ended up having tremendous benefits, not just for developer experience, but as I think about the Vercel platform, we can intelligently bundle code according to the entry point that we can know statically at build time based on your file system it can say, well, it turns out that it can take the homepage route and bundle it intelligently as an edge function so that it can run globally. So the idea of a static declarative file system ended up having tremendous implications to even the ability for Next.js to become a serverless and edge compatible framework. So with Next.js 13, we're doubling down on this idea of a declarative file system based router. And some of the things that it brings onto the table now are things like support for layouts, support for co-locating application code together with your route tree without accidentally exposing source files as routes. So the code actually is just easier to read because your routes and your application code can be in the same place and you can have a lot of confidence and safety in your design. The other thing that's quite crucial in terms of the rendering infrastructure is that everything is server first by default. And that the data fetching going back to those PHP roots or that PHP inspiration, the data fetching mechanism is unified. If you're familiar with Next.js, you always had to start with the question of is this page going to be static? And then you would define a get static props type of loader of data, or you were going to say, okay, this page is going to be dynamic, meaning it's going to execute compute every time this route gets accessed. And you'd have to define a get server side props loader. Now, Next.js is saying just define your data fetching inside the component itself, which improves developer experience and it removes this question of like, a page is all or nothing or binary static or dynamic. And now you can really start to take advantage of investments that have been going into React for years for their suspense based streaming infrastructure. So imagine a page that has a navigation that is driven by the CMS. So you're a multinational company that has multiple brands and you want to hover on an element that says it brands and there's 20 there and tomorrow you acquire another company and you want to add another brand. Okay, now there's 21 brands, that data is infrequently changing and because it's part of your core navigation, we can call that static data, even though it actually changes and it can even change at run time because someone makes a change in the CMS. That piece of data can be very safely cached inside every edge that executes the rendering life cycle of that page. And I'll contrast that with, let's move sideways that to that navigation. It says, welcome back route G, because I'm logged in. We can call that dynamic data. That data needs to be evaluated on a per user basis and I'm going to prioritize there, correctness over, for example, speed and staleness. For example, if I log out and I refer to basic, I never see myself being logged in, it would be a security problem. So that little example gives you in one layout, two kinds of data that we're thinking about here. And in Next.js 13 you can collocate those types of static and dynamic data right inside the component. So it's a very natural way of writing application that depends on data that is completely agnostic to the data backend still so it can be GraphQL, you can talk to the database directly if you want. So it kind of delivers on this dream that we've had for many years, which is that super easy to write, but actually delivers a global maximum of performance stability and cost effectiveness that I think no other framework's capable of today. So what we like to say is Next.js 13 delivers on this promise of dynamic at the speed of static. So in past years people got excited about things like Jamstack, static generators and similarly over the years we've found a lot of problems with those architectures. But there were also some benefits, static is really fast, static doesn't go down and static is cost effective. So Next.js 13 gives you kind of that ability and that power, but still within the umbrella of dynamic rendering so that you can run experiments, you can run A/B tests, you can combine static and dynamic data into one component. So I'm extremely excited about this part of the announcements. Ben: And it's super exciting to hear because last night I was listening to our interview from a year or so ago and just catching up and reminding myself what we spoke about and the thing you said you were most excited about for the future was kind of the work that you were probably at that time starting to lay the groundwork for Next 13. And you said you were most excited about blurring the lines between the kind of false dichotomy of static and dynamic. And now sounds like React 13 is a big step towards that goal. Guillermo Rauch: We've shipped it. Yeah, very exciting and we didn't change your mind, also very exciting. Ben: And so the other thing that it was refreshing myself on that we spoke last time about is the goal of bringing more workloads to the edge. So can you speak a bit to kind your efforts towards that? Guillermo Rauch: Yeah, for sure. So one of the key things that has happened in the world of infrastructure in the last couple of years is the emergence of this edge run times. This ability to say, I can run JavaScript code at the edge as fast as I could be delivering a static page, for example. And this has been typically powered by either V8 isolates or web assembly. So this new technologies for virtualization that make it really cost effective to run dynamic compute from zero, from scratch. So this is not compute like Kubernetes that you scale up, you have to create a cluster in every region of the world and every city that you do business in and you have to scale up some machines, some pods, some containers. Now this is literally in five milliseconds, you could be running compute that has never been running in that data center before. So this is one of the key things that we're tying Next.js 13 into is, if we want to deliver a dynamic at speed of static, we have to infuse Next.js with this edge compatible run time that has this scaling characteristics when you deploy it to production and even when you're previewing it on the Vercel platform. So Next.js 13 is designed to be an edge first framework. And this also ties into that ability to combine static and dynamic because I mentioned, suppose you want to say, I'm going to play around and optimize my contact sales button if I have a marketing page and depending on the geography, I want to do a test or like west coast, I give them this type of button, east coast, I give them this type of button. And then I also want to revert it really quickly if it doesn't work out. If my merchants start diving, I want to go to some backend and flip a toggle and immediately worldwide my button reverts back to where it was. The only way to do this is by having some engine that's running compute for every request. If I had only done a static generated site where I could give you just index that HTML to every user, I start losing that ability to experiment, to do flags, to enable certain features for only subsets of users, to revert things really quickly. And one of the features that we introducing Next 12 was this concept of Edge middleware. So with Edge middleware, you can start doing a little bit of that compute at the edge. You can think of it as almost like a dynamic router of sorts that lives at the edge and it allows you to sort of direct traffic, but it was too coarse. With Edge middleware, you can say, okay, this request goes to page A or it goes to page B. With Next.js 13, we can start making those decisions in a more granular fashion. We can even do it at the component level because we're piggybacking on this ability to be fearlessly dynamic and to also be cost effective for companies and individuals when you're deploying into the cloud. So a lot of our thinking was not just, okay, let's make a better file system based router, or let's make data fetching easier, but let's also bring everyone in our community on the web into this journey of modern, faster, cheaper cloud virtualization. Ben: Got it. And I know we're going to talk about Vercel more in a minute and I know Vercel is one of the best places to host a Next.js app, particularly because of the native support for this Edge First architecture. For folks who are hosting on one of the many other platforms from [inaudible 00:24:51] or CloudFlare, Super base or Amazon or Google, can you adopt that Edge first architecture in the same way you could on Vercel or are there things you get hosting your app on Vercel that you can't get on all the other providers? Guillermo Rauch: Yeah. I think the key thing that you get on Vercel is that it's a native platform that has been designed for this kind of cutting edge patterns in mind. And you know that if you deploy a Next.js application in Vercel, I think it's `from the same creators, from the same team. We have our roadmap in mind to be completely aligned towards the future of Next.js. So it's a safe choice in my mind when it comes down to, okay, who understands Next.js better in this world than the creators of the technology? However, we're very open in terms of the built output of Next.js can be consumed by absolutely any platform in the world and adapt it to their infrastructure. So CloudFlare, I now support for Next.js Edge applications, and I'm sure there's a lot of benefits to be gained from if you're already in that ecosystem, you know can use Next.js and take advantage of whatever tools they have there. On Vercel, the idea of hosting is not just the only enticing feature, we think of Vercel as a collaboration platform and a workflow on top of Next.js. We give you the real time feedback and the ability to share your Next.js applications as they're being created. Very much like what Figma did for design files. It's not just a point in time solution, but it's just a better way of building software. So we give you analytics along the way of how your website is performing in the real world, we give you the ability to comment and share every iteration of your front end as is being created. We plug into all of the Next.js features like image optimization to not just speed up the delivery of HTML, but of every asset that you deliver on your page. And we have the global network of over 20 different regions that we deploy Next.js too. So one of the biggest differentiations is that when you use Vercel, you're using a global first platform, whereas perhaps the typical approach to deploying an application is, I go to AWS, I choose one region, I create some kind of resource there and then I think about, okay, how do I combine it with some other CDN and then how do I combine it with some other vendor? Whereas Vercel puts into that pit of success that I was talking about earlier where you know that it's going to work well, it's been designed such that the platform delivers on all the potential of the framework. Ben: And there's a lot more exciting updates that came out in Next 13. We will put a link to the Next 13 launch blog post in the episode description for folks who want to check them out. Before we move on, one that caught my eye that I thought was really exciting was Next font, which is kind of your new font system. And I've definitely felt the frustration of wrangling fonts when building web apps before. So curious to learn a bit more about your approach there and what you felt was Next font. Guillermo Rauch: Yeah, for sure. So one of the things about fonts is that everyone loves them. The vast majority of websites want to use custom fonts or customized whatever the operating system. I believe there is a survey or data set that said over 60% of websites use custom fonts on the internet today or at the very least of high traffic sites. Needless to say, custom fonts are extremely common. The problem is that the web has been designed to be this medium that is very spontaneous. Compare with iOS apps where you download a big application at the beginning of your, I'm going to use Facebook, I download it, I pay a huge price at the beginning of that, I download hundreds of megabytes to get that Facebook app and then all the app updates sort of happen asynchronously and then I have all my assets there. The web works differently. The vast majority of sites that you're going to visit today, you have no cash for whatsoever. You have no preconception or you don't have any asset on your device that relates to that website that you're going. And this becomes even more pronounced when you think about advertisement, email campaigns and the rate of deployment. Everyone's deploying assets very quickly, so the cash is become stale very fast. So the web is very spontaneous medium. That's why at Vercel we obsess so much with how fast we can render something cold. Hot, I think everybody can do fast, hot rendering. But fast cold rendering is really the name of the game because as I mentioned, the vast majority websites that you visit, you have no cash for. And we have to do everything fast, we have to do TLS fast, we have to do TCP and now with Quick and HCP-3, we have to do the UDP fast, we have to do the lookup of metadata fast, we have to put up dynamic compute fast, we have to fetch the assets fast, the static assets, we have to connect to your data source and we have to do that fast. So when you think about fonts, this issue is even more pronounced because imagine that you don't do fonts well, which is actually my observation how most people do fonts. You download the page and it says, go and fetch this font from this third party domain. And maybe the font is like a megabyte because it's not optimized for the variance that you want, bold, italic, the character atlas that your page actually needs. And meanwhile you're suspending the rendering of the page, perhaps you're not even rendering the text yet. We all have that experience of like, we go to a website and the text is not there and the text comes in two seconds later. And this is because people want the aesthetics of the custom font, but perfecting the optimization both from a font size perspective, also from the idea that the font can be served on your same domain name. So if I go to vercel.com, the font can come in through the same connection that I've already established instead of looking it up in a third party. And again, you were asking about benefits of Vercel. Vercel being a global network makes it such that you both have the cake and eat it too. You get your domain name to be obviously yours and to serve every asset that your application needs. But also it's globally fast so your font gets delivered in the same domain. So this component that we open source called [inaudible 00:32:19] slash font basically gives you a very simple developer experience for attacking all of this, gotcha that exists with fonts, whether it's shipping the wrong variance, whether it's not shipping your fonts in your same domain name, which is not in line in critical CSS that's necessary for the fonts to work, which we're already doing. But of course this part of this package as well, it also gives you this ability to say, actually I want a font enter and I want to grab it from Google Fonts, but I want to host it on my own domain. So we made the DX of it saying, I already know the font that I want, just bring it to me really fast. So it's one of those technologies that I think is really special because it's easy to use and it gets pretty close to the absolute global maxima of performance optimization. Speaker 1: Awesome. So I want to talk next about Vercel. So any kind of new exciting things on the Vercel platform side? Guillermo Rauch: Yeah, so one of the things that I think was at the very genesis of the Vercel platform was this idea of the deployment preview URL. So when I first designed Vercel and kind of interested to the world, the idea was you run one command and you get an immutable URL back of where your application lives at that given point in time. So you type in Vercel, get a URL, make a change, type in Vercel, get a new URL. And the main idea was I was iterating on my startup at the time. I was trying to play with different landing pages, different styles, different designs and iterating very, very quickly as one does, especially in the early days of a company. And I wanted that ability, I make a change, boom, I can send the URL to somebody over Slack at a time, over irc, over text message, whatever it is. This idea of perishability was baked into the beginning of this entire story. What we were missing was how can we connect that into the actual collaboration flow of a company? How can we make it such that if the front engineers working at Netx.js application, they can share that link with their coworkers or perhaps even their clients if they're at an agency or their freelancers or consultants and then get comments from what the other person thinks about your work. So that's what we baked into Vercel with what do we call preview comments. It's currently in beta, but you can actually get to try it today by enabling your projects or if you want to check it out, we run this incredible experiment where, as part of the Next.js 13. So one interesting thing about Next.js 13 is, it's a stable release and if you are using Next.js already, you should absolutely upgrade and it just gets better and faster. Now the app directory, which we just talked about with the new rendering features that's in beta. So you have to opt in into the experiment for the new support for layouts and streaming and rear server components. And the documentation for this is in beta.nextjs.org. So if you go there, you're going to notice at the bottom of the page there's a toolbar that has some profile photos of people that have been recently active, if you log in. And then basically gives you that ability to comment and report feedback on any piece of text or anything that stands out to you. You can press, give feedback here. So that tool bar is the experience that gets embedded into every preview deployment that you make on Vercel. And ever since we introduce it into our beta documentation, over 3000 developers give us feedback. So this idea of providing feedback and comments right into the thing that you're building, I think it's really revolutionary. I think it's going to change how people evolve products. We're making a better Next.js docs site because every time we scroll it on it or we open it, we see the feedback and comments from the community right there in context. So the fact that we're going to roll this out to our entire Vercel user base soon gets me really excited. Ben: And continuing on the Vercel side, you recently acquired Split B and have starting to move into the analytics space. So could you tell us a bit about why you did that acquisition and what the future looks like for Split B and the analytics side of things? Guillermo Rauch: You can think of Vercel as a company that's on a quest to take every third party asset and make it first party. If I had to really simplify things like open every webpage and notice that the things that make up page slow are typically third party scripts, third party styles, third party fonts, third party analytics. So everything is third party should be made at first party. That's another thing that makes me so excited about the edge function concept because a lot of things that people put as scripts on the client should just leave us compute on the edge. So we talk about fonts being an example there. Another example is analytics, if I want to understand how many people are on my site, where they come from, what devices are using, what pages are they spending more time on, typically it's meant a couple things, one, it's meant really slow and bloated third party scripts that impact the performance of your site. Another thing it's meant is they're not well integrated into your framework. They kind of don't even know what your framework is. They tell you just copy, paste this script salad into your head and then they don't really understand even what you're building. And then in many cases, they're so overbearing with how much they want to grab in terms of information about the visitor that by default it just means that you have to stamp a cookie banner on your page and you're just trying to get some high level data anonymized, GDPR compliant into what's going on. And that's exactly what Vercel Analytics for audiences, which we've incorporated through the acquisition of this company, Split B is giving you. So it's giving you privacy first analytics, performance first analytics, and it's integrated right into Vercel and the frameworks that we work on. So that's another example of how we have this holistic conception of let's build the best possible platform for frameworks like Next.js and let's just not optimize perhaps like I mentioned, the delivery of a page as the end all be all, but think about the problem holistically. And what we've found is that analytics tend to be one of those things that are truly essential to evolving a product and most people get it wrong and Vercel is there to help you. Ben: And on the analytics side, when you talk about being more and deeper integrated with the framework, do you have plans to add more functionality to the Split B product in terms of how it ties at the component level or what does that look like in the future? Guillermo Rauch: So it already does a subtle thing that's actually really important, which is that a lot of the navigations that happen in modern front-end applications are what you would think of a soft navigation or a client side navigation because we pre render or server rendered initial load. But then what's really cool about Next.js and what makes it so fast is that as you're scrolling through the page, we are pre-fetching the next links that you might click, so by the time you actually hover a link, we're actually rendering it or starting to evaluate critical resources about that next click. By the time you actually complete the click, it feels incredibly fast. That's kind of like a defining feature of Next.js. In fact, when I use the internet myself these days, and obviously I'm really obsessive about this, but I can tell somebody is built with Next.js because that click is so fast. But with a lot of naive integrations of analytics, they miss tracking those soft navigations. So of course Split B is correct by default. We're building it with this framework in mind. So not only with Next.js but other frameworks, it'll correctly detect those impressions that are happening or page views that are happening client side. The other thing is that unlike solutions like, perhaps CloudFlare or others that are trying to also make it easier to embed analytics, we give you an SDK that integrates right inside your rebo. So you can control the rollout of the introduction of analytics and you can embed it programmatically. So speaking towards the future, we're going to start giving you more hooks in this analytics package to track things like custom events, you're going to be able to tie it into your React Hooks. Another thing that's really cool is that we already had web vitals analytics, so we would give you performance metrics about your site. And this were already framework aware. So we cannot tell you, okay, your real world performance of a certain page is suffering, go and look at this part of your source code to debug it. So over time, to your point, we want to do more around component centric analytics, both for performance and for audiences to give you a sense of what's working and what's not working. And another thing we want to do with audiences is get more into experiments and AV testing. So we realize that the concept of a page is just too broad and most people want to get insights into what's happening more concretely in branches of experiments in specific buttons or new things that are rolling out and understand who are the people that are being impacted by this. So it's very early days, but we have a really ambitious roadmap of where we want to take this. Ben: One question I see pop up a lot in the context of Next is React native for folks who are building applications that have both web view side and a React native side, how do you think about React native generally and long term any kind of deeper tie in with Next? Guillermo Rauch: I think one of the interesting patterns that we've been noticing is a lot of folks are starting to embed more web views into iOS and Android applications. And because Next.js makes the web so fast and so as I mentioned, so instant to load on this cold basis or when you haven't seen the page before, it's still so fast loaded, it's naturally found its way into that kind of experience. The other thing we're seeing a lot with Turbo repo, which is our tool for managing large monorepos, is that folks are starting to share a lot of code between React native, expo code bases and Next.js code bases. So at Vercel we're huge fans of this concept of the monorepo. Your company should have one place where all your code resides, even though the boundaries of this code might be that it might turn out that you have, I don't know, 10 different front-end apps and five mobile apps. They should still live in one code base such that they can start sharing more resources over time. And at the very least, a developer has that option available to them where like, oh, I want to share the data layer between my Next.js App and my React native app. So we're seeing a lot of real world success with this. This was kind of theoretical a couple years ago, but now it's very common that I see startups that are already sharing a very non-trivial amount of their code and have very high performance native apps and obviously very cool and high performance web apps as well. So I'm very bullish on React sort of being the operating system for all software in the future. Ben: So finally, would love to hear what you're most excited about for the future. And I know I asked that a year ago and you did a pretty good job of predicting exactly what you would build in the next year. So the bar is pretty high here and whatever you say, we're going to hold you to that. So choose our words carefully. Guillermo Rauch: Yeah, for sure. So I think Next.js 13 really marks the beginning of an entire decade of innovations for us because it creates the right platform or the right infrastructure. That's why during the conference we talked so much about the right compiler infrastructure, the right rendering infrastructure and I think the emergent behavior, the consequences of this are pretty non-trivial. To give you an example, the vast majority of developers today are very constrained in their ability to experiment with their software because it's so daunting. You can't just write an if else branch to say, I want to try this out. I want to enable a new kind of experience even for just one user, or I want to actually deliver a new version of our homepage just for our own team, just for the company so that we can all get in there, experience it, test it on mobile, test it on our devices and then give feedback back into the organization. So that idea of the constant real time feedback combined, the constant shipping of this experiment to production is something that has me really excited because the only constraining factor there until now was the technology. Of course, we couldn't write an if else branch in the past because we're caching everything. We were taught that we had to cache with CDNs and all of a sudden my page is static or that we were taught that we had to do static generations. So I just have a bunch of HTML files to work with in really long build times. So we're getting rid of all those, I would call them like elusory trade-offs of software engineering until of course we're building on these incredible innovations and on the shoulders of giants like the Eight and of course, reacts multi-year investments. So I think it's going to change the way that people write software so I'm very excited about it. On the compiler side, it's just early days, but this Turbopack and Turbo repo incremental compilation architectures have never been democratized or made available to open source with the ease of use I think that we're bringing to the table. So I would love to see, and I think we will see teams adopting this monorepos and creating even more ambitious and larger code bases without sacrificing their developer experience. We had a lot of teams reach out again and going back to those elusory trade off saying like, oh, I had to split my app into this arbitrary micro front-ends because the app couldn't scale. Either Webpack would get too slow or the developer experience would get too slow, or the shipping to prod would get too slow. So it would take this bad trade offs to try to still make progress and then block the software delivery pipeline. So those are the key things that I think are going to happen over the next couple of years that are quite... They're very different to what the vast majority of the world is used to. Ben: Well, Guillermo, thank you so much for joining us today. It's been great to learn about Next 13, Vercel and hear about a vision for the future. So yeah, it's been great and we'll look forward to speaking to you again in the future. Guillermo Rauch: Thank you.