Ben: Hello and welcome to PodRocket. Today I'm here in the virtual studio with Brian from my team and we're here with a very exciting guest, Guillermo Rauch, who's the co-founder of Vercel and the co-creator of Next.js. How're you doing Guillermo? Guillermo Rauch: Great. Thanks for having me. Ben: Yeah, we've been really excited about this episode for a long time. And so maybe we can jump right in. I feel Next is probably the most ubiquitous tool or product we've talked about on the podcast. But even so, I think it would be great for you to just give a quick introduction in case there's anyone who hasn't used it or hasn't heard of it and we can go from there. Guillermo Rauch: Yeah, we think of Next.js as a modern framework and platform for front-end development that scales. It can start with one simple static page but also scale to billions of dynamic pages. And it also scales well with team size you can use it for your own blog or you can use it for really, really large enterprise front-end applications comprised of multiple front-ends, micro front-ends, pages and systems that span multiple different brands, multiple different domains and really large organizations. Ben: And when you say framework, Next is based off of React so what does Next to that's kind of above and beyond what you get with just pure React out of the box? Guillermo Rauch: For sure. For many years, React was presented as a V in MVC meaning it's sort of the rendering layer, I like to think of it as an engine. And what was missing was a developer experience around it, it was missing this idea of, again, when I'm going to create something for the web I mostly need more than just the V and the view layer, I need an entire framework. So, the React team recognized this early on and they create React App which is focused on single page applications. Concurrently, we had been trying to solve the same problem, "Hey, how do we create a platform and development experience around React?" Because we loved the hypothesis of React, the functional programming style, the component model but we had taken a different approach which was more focused on multiple pages instead of single pages. Guillermo Rauch: And it was also focused on server-side rendering instead of just client-side rendering. So when we talk about scalability, many things that have driven a lot of the popularity of Next.js are that we looked at, what are the top sites on the internet doing? What are the large things doing today? Well, at the time, they were doing server rendering, they're still doing it obviously. They're also focused on shipping as little JS on the client as possible and sort of hydrating selectively later on in the lifecycle of the rendering and we took a lot of inspiration from that. Guillermo Rauch: And even though we took a slightly different route, it ended up paying off over the long term because even though a lot of folks that thought that their problem space was I'm going to create a single page application, later on because of SEO, because of loading performance, we realized that they needed something more sophisticated and actually I should say, more universal. Because Next can run on a server, it can run at the Edge, it can run on the client so it gives you a lot of flexibility. Ben: And I think one of the things that people love about Next.js is it makes it easy to have an application that has both server-side rendering, static site generation and then even incremental stat regeneration which is maybe a newer concept. But at the same time, that power, I think some people maybe have a little trouble wrapping their head around that if they haven't actively built an application that has all of those paradigms. So, could you explain those concepts and maybe how people should think about choosing which app you may need to employ for whatever its use cases? Guillermo Rauch: Yeah, for sure. One of the frameworks that I've always thought about is, when I send you a hyperlink, you click on it and you go and request it from somewhere. Increasingly, the internet is becoming very globally distributed so that's somewhere ends up being the closest edge of an Edge network. Next.Js is part of Vercel, a company that creates an Edge network to distribute frontend application. So, if I'm in San Francisco and I go to that hyperlink, we're going to hit the Edge of San Jose near the Bay Area in California. So what happens then is that that's your first opportunity and that little quick trip to come back with content, not just a shell of the application. Guillermo Rauch: You were going to a new site, to come in one hop back with the news information that you were looking for. So we kind of thought about it early on from this perspective of, "Look, let's make a framework that's as fast as the speed of light." Because what was happening at the time in the JavaScript community was, you were going to the Edge and what you were getting back was this empty shell, almost the iOS model, that you're downloading an app and then the app has to boot on the device and then it shows a spinner and then it has to fetch data and then it has to render data. So, we looked at that and wow, that's almost the antithesis of the web in my mind because the web has this awesome ability to just go and fetch everything all at once. Guillermo Rauch: So we kind of designed the framework around that and now this techniques have all these fancy names like server rendering, incremental static regeneration, all those things but basically they're this idea of, can we get content data in code all at once? Ben: And I'm curious in another thing that I think people about Next is it has a fair amount of opinions. And in today's day and age, there are so many different tools in the tool chain for modern front-ends and people that you start using Next and it gives you a lot out of the box. There's kind of generally accepted ways of doing things but as the creator of the tool, how do you kind of think about that balance between being opinionated but also letting the framework be flexible so that people can build things in the way they want and extend it in the way they want? Guillermo Rauch: For sure. They're definitely strong opinions, right? So for example, the React component model is very fixed into the framework. We actually have an option to replace it with Preact for certain size of pages but you have to use sort of the API's of React and JSX and things like that. We think that that's a durable abstraction, it almost be like saying the framework depends on functions or classes. When you think about the component model of React, I think, it almost added a missing piece to the language. We have the basic JavaScript language and its runtime and then we need the basic language on top to recent abide UIs and pages and we think that React added that missing piece. Guillermo Rauch: The other thing I always try to do is very minimal or no configuration, zero configuration ideally so that's kind of baked into the framework as well. There's opinions around pages and URLs. Again, the idea is to sort of bring the old, in some ways, web 1.0 model and modernizing it and augment it with JavaScript rather than doing it all in JavaScript. So, there's some opinions about how routing works which is sort of this URL friendly routing. Even when Next was created, a thing that would be popular at the time was not having a lot of URLs or using # for URLs and things like that so that's another opinion. And beyond that, I think we're very, very flexible. Guillermo Rauch: You can bring in your styling system of preference. We think that solutions like Tailwind are sort of becoming very standard and we integrate really well with those. Same with TypeScript, not every project uses TypeScript but TypeScript is becoming one of those de-facto standards especially in the enterprise so there's a really good built-in TypeScript integration. So, Next evolves minimally, I would say, but whenever there's an important trend that we see in the web and that we validated with ourselves, with our projects and with our customers, we think about integrating deeply. Ben: So I'm curious to learn a bit more about Vercel which is kind of the company you've built around Next. What is Vercel do? How does it differ from some of the other platforms out there? I think Netlify kind of has some similar aspects so, what's special about Vercel? Guillermo Rauch: For sure. So, one of the things that I learned early on when I was researching React was companies like Facebook had developed front-end infrastructure teams that were tasked with conceiving the frameworks and the runtimes to scale this massive front-end code basis. When companies like Facebook, Google and Amazon created such teams, most people were not even thinking about using JavaScript at all. So they kind of had this 10, 20 year headstart, right? And what I realized was, most companies in the world will never be interested in having such teams or creating their own frameworks or creating their own front-end platforms but as the web becomes more dynamic, more interactive, more connected, front-end and especially JavaScript is becoming more important than ever before. Guillermo Rauch: So Vercel set out to solve this challenge of how can we deeply integrate framework and Edge platform to provide you not only with a great developer experience but with a great end-user experience. A lot of the types of customers that have gravitating towards Next.js are, for example, in the e-commerce space and they demand a lot of great end-user performance. It doesn't matter if the developer is in cloud nine with great per, great errors, great whatever if the end-user is not happy at the end of day. So I think that's a really important differentiator, that deep integration between framework and platform. Guillermo Rauch: Vercel's still agnostic, you can use Next.js, you can use others but Next.js informs the development in the platform so we're not operating in a black box and sort of reacting to what happens in the ecosystem, there is that cool framework, what cloud capabilities does it need? We're sort of shaping the cloud capabilities that will create that great DX and UX at the end of the day. So one example of how we think about UX, when you ship a deployment on Vercel, we automatically gather performance data from end user devices that then inform the next cycle of development. So we can think of it as a complete feedback loop from developing, previewing your deployments, shipping, gathering data, developing and so on. Ben: Got it. So essentially, by building the hosting platform alongside the framework, you're able to, I guess, have that tight feedback loop and build the best possible developer- Guillermo Rauch: Correct. Ben: Experience and the best place to run your applications? Guillermo Rauch: Yeah. And sometimes cloud informs framework and sometimes framework informs cloud. So a good example is what we noticed was really exciting about the cloud was the rise of server less. That now you could do this dynamic computation and scale it up to 1000s of VMs basically instantly. And we saw great opportunity there because we saw that happens a lot with our kind of customers. You do an e-commerce drop... The other day, Kendrick Lamar launched his latest album or website on Vercel, we have all these spikes of traffic that are completely unpredictable. Kendrick did an emails and said, "Hey, by the way, we're going to run a load test." We saw from zero to millions of requests per second instantly. Guillermo Rauch: So that's an example cloud inference framework because what we did is say, "Hey what if Next.js instead of in the build process yielding this container, what if it could yield static assets and functions independently and then the build and deploy pipeline can sort of optimize a cloud around that?" So that was a case of interesting cloud advancements informing the framework and even the development experience and then we're seeing opportunities in the other direction all the time as well. Ben: And so today, if I build a Next app that utilizes kind of the full gamut of modern cloud paradigms like functions, static hosting and I guess maybe key value store or something that. I could deploy my app on Vercel, can I also easily deploy on other stacks like Netlify or Amazon and Google? Or what is the hosting landscape look like if, for whatever reason, maybe I already use a different hosting provider and I'm not ready to switch to Vercel? Guillermo Rauch: Yeah, for sure. So Next.js is an open source project and we tend to think of it as Kubernetes for the modern age in some ways, right? Because instead of back-end focus, its front-end focused. Instead of lots of infra, it's basically like you build an invisible infra and you can kind of go the full spectrum, right? You can take Next and say, "Well, I want to use all this outputs but I still want to put them inside a container." "I don't want to optimize, I want to do single region instead of global." "I want to handle my own sort of monitoring and then metrics based auto scaling of my container." And things that, you can go into that. But then you're seeing the rise of these newer platforms that will go ahead and sort of optimize accordingly. Guillermo Rauch: The way that I think about it is... This actually happened also in the Kubernetes ecosystem back in the day, still happening to some extent. Where a lot of conforming distributions of the software emerged. So as long as the API works, you can say that you're compliant, right? We saw that also with the big cloud platforms adding support for the different APIs. And I think the same is happening and will happen with Next.js where, for example, Amplify, looks at the Next.js build output and then optimizes it for their own platform. And then sometimes they build their own integrations on top as well like the Cognito integration so that Next feels better integrated with each ecosystem. Ben: And as a business, you guys make money off hosting primarily, is that accurate? Guillermo Rauch: Not really. So one of the things that perhaps is surprising because so many developers think of it individually as, "Oh, well, I host my app there." Something that's really interesting is that there's an entire workflow that follows your usage of the platform. So the most basic is, every time you push your Git provider, we create a deploy preview. And this deploy preview actually shares the same global cloud infrastructure as your production deployment. So every time you push, you automatically get this pre-production deployment where you can sort of test, verify and integrate with other systems. So what we've been noticing is a lot of companies are primarily interested in the workflow because maybe they haven't even hit prod yet. Guillermo Rauch: They're adopting the platform because it allows them to develop and preview better and that creates a very interesting collaboration feedback loop from the sort of team perspective but also across service providers. A good example is we have an integration with Checkly, It's a platform for headless monitoring and quality assurance. So every time a deploy [inaudible 00:17:19] is created, a headless web browser can kick in and verify that your deploy conforms to certain tests or certain verifications. The same can go for a variety of other integrations that you can build yourself or that are built in the Vercel marketplace. So once you sort of go through the workflow then sort of the last mile say, "Well, I'm going to also deploy to production." It's almost a different branch in some ways. Guillermo Rauch: That also has a slightly more powerful optimizations but again, it's a very comprehensive approach, it kind of follows you throughout the entire development of the project. Ben: Got it. So you guys are really building a software platform around the developer experience of kind of every part of building a Next app- Guillermo Rauch: Correct. Ben: ... From first commit to production and beyond. And do you have customers who host on Google or Amazon but use your tools for that kind of workflow? Guillermo Rauch: Yeah. One thing we've been noticing is once they tried for workflow, they realize that we tend to outperform and just to shine in different ways that their providers don't. So what happens is sometimes the workflow informs future decisions about hosting, sometimes something that happens that's really nice is a lot of enterprises started adopting this modern front-end platform because they're in the process of breaking down a monolith. So we're seeing a very common pattern, you had a PHP monolith or a Ruby on Rails monolith, you started creating native applications and those applications need to consume an API. So you started going through a process of rolling out REST or GraphQL but then your front-end stayed a monolith. Guillermo Rauch: So you are like, "This teams are working with this APIs and it's really well organized by my front-end team is still interpolating HTML with my SQL queries and my PHP code base." So you break it down and you deploy your front-end on Vercel as a way of leveraging that existing API infrastructure that you're building and that might be in your Kubernetes cluster, that might be in some API as a service provider. With e-commerce, we see a lot that folks are splitting but also going to hosted headless e-commerce solutions instead of trying to reinvent the wheel or sometimes they're combining multiple hosted solutions. So what's interesting about the modern cloud is that we're kind of blurring the lines of where the software really is, right? Sometimes it's in AWS, sometimes it's in CloudFlare and the customer luckily doesn't notice the about performance but the developer also increasingly as they have to care as much. Ben: On that note, I heard you say in another podcast that the great developer experiences lead to great user experiences and maybe you can expand on that a bit because I think that's a pretty interesting point and maybe not something that's always intuitive to companies when they're trying to figure out their technology choices. Guillermo Rauch: Yeah, for sure. I'm a huge believer that developers always want to do the right thing. I've never met a developer that will tell you, "Well, yeah. I had a great DX, I didn't really care about the user, I just pushed, I feel good." They want to do the right thing. What happens is that sometimes the tool and even sometimes the ecosystem can be antagonistic. So, we've seen this approach in the past where Dev roles on Twitter will be like, "Oh, my God. That website is so slow, you should go and fix it." Almost like shaming developers, that doesn't work. What also doesn't work is, "Well, to obtain great UX go and get three PhDs, write your own compiler and inline some web assembly and then there's going to be great UX," I think, great DX and great UX will never be at odds because developers always want to do the right thing. Guillermo Rauch: It is true that sometimes there is more pain to guarantee a better UX. A concrete example is and this is a good example of Next and Vercel cooperation. Next.js has an image component, what it does is it optimizes your images such that each device... For example, if you're rendering an image on a phone, you want to ship a smaller image than if you have a huge monitor, for example. So that's table stakes, optimizing for the right view port. What's also table stakes nowadays is you have to know the dimensions of the image ahead of time so that you can render the page in one nice pass and nothing jitters around and whatnot. It's tricky because knowing the image dimensions ahead of time does incur in some more pain, sometimes your infrastructure doesn't know the dimensions of the image, your CMS doesn't know them. Guillermo Rauch: So that's a good example I think where, okay, it's clear that to get the best UX there has to be some more arrange and more care, more time. It's even more typing in some ways, right? Because the image element is IMG, source, SRC and then I have to add width and height to prevent that layout shift. But we've done a lot in Next.js to do two things. One is remove the pain so for example, if we know the image statically, we can now infer width and height automatically. That it's a dynamic data source, we document and integrate it with CMS providers that know how to give you the width and height. And then the other part is education, right? Guillermo Rauch: When the image component fails and tells you, "You're not supplying width and height." That's where I think a lot of tools and I really look up to the Rust community here in how much care goes into error message design. So typically, what we do is we render a friendly error message that then is actionable, typically has a URL and then it's an opportunity for education because I think that if the developer just saw, width and height is not there, sorry. Build error. You failed, right? But if it goes to a link and tells you in an empathetic way even with a little animation, it says, this is what would happen to your view port and you probably hate it as a user of the web, right? I hate it when things float around the page. Guillermo Rauch: So if you have that empathy and then you provide the guidance to the promised land, so to speak, I think developers will be happy and users will be happy. Ben: So it seems like Vercel and Next, you guys are really leaning into the e-commerce use case. I'm curious, what specifically about modern e-commerce sites then lends itself well to using Next and maybe what are some of the items on your roadmap to really double down on that use case and make Next an amazing tool for e-commerce developers? Guillermo Rauch: Yeah. It's such an interesting emergent thing that I didn't quite predict although it doesn't surprise me that Next has been so successful with e-commerce. When they first created, I needed to build a page. I always tell this story because it's so funny because I loved React, there was so much hype about React and I just wanted a page that had my navigation, it had a little forum, it had a footer with terms of service and privacy policy and I just refused to do all that on the client-side. I remember thinking, so if you use React as a single page application, the terms of service get in line in the JS bundle. And I remember examining the bundle, I was like, "Wow, they're just a bunch of text inside JS file." Guillermo Rauch: And I was like, "Okay, that's not going to work." And the other thing I was thinking about was the Vercel console, yeah, sure, it could have been a single page app but I really loved GitHub. I really love how GitHub console didn't have spinners all over the place and their public repos are really well indexed on Google. It turns out that you can actually build a cloud platform and console that doesn't have spinners all over the place. And so that was the initial inspiration, the fact that e-commerce and then ad backed content became really big was almost like a, I guess, good product market fit there. But I'll give you some things that I've reflected on why I think e-commerce has become so big for us. Guillermo Rauch: So one is that the need for speed is very easily translated into dollars. So I recently tweeted about how one of our customers on boarded their e-commerce storefront without making major rewrites or new features and whatnot and then lifted their sales by 16%, just by re-platforming on Next.js and Vercel. And why? The answer is the speed and obviously availability, not crashing, a lot of other things could get into the mix. But if you make your e-commerce site faster, users are more likely to purchase, it's been extensively documented. So when VP of digital, VP of e-commerce, VP of Marketing at all these major e-commerce companies are making decisions, the developer has a very strong argument for Next.js. Guillermo Rauch: It's not just they'll feel better, it's, "Hey, I really think that this is going to change our business for the better." So, that's one thing. The other one is SEO, I've talked to customers at major fortune 500 companies that had gone the route of client-side rendering and lots of JS and saw their SEO drop dramatically. And SEO is kind of this weird, I'm not a huge fan of talking about SEO, LogRocket has done an amazing job by the way, I love the articles. I don't talking about it because there's just so much myth. It's almost like searching YouTube for a conspiracy theory, right? But one thing that I think was very interesting is that there was all this talk about how Google could actually run headless web browsers and they could run their single page applications and they'll still be crawled. Guillermo Rauch: And to be fair to the developers that went down that path, Google didn't really ever make very clearly because they don't really want to talk about the internals of the beast so much. So it wasn't that clear that it was going to hurt you. But I've actually talked to really large websites, it did hurt them. Google basically will put your pages into a lower priority queue, it'll do less rendering, it'll perceive your site as slower so it'll hurt you. So for e-commerce and for a lot of e-commerce, SEO is also very, very critical. So Next.js was also shining there. And the other thing that's actually perhaps less obvious and I haven't talked about this much is that Next.js purposefully was designed to not do back-end at all, right? Guillermo Rauch: It was designed to query APIs. Now, that doesn't mean that he can do a full stack application, you certainly can, especially as databases are becoming more back into service, right? With HTTP gateways, with things like Superbase. But Next.js took this design of you can bring your data from anywhere. You can use GraphQL, you can use REST, I have customers that use gRPC, you can use whatever you want. And that meant that all these e-commerce customers could repurpose this investments that they had already been making or as the move towards headless e-commerce happened, they could consume those APIs. So I would say those three attributes have made Next very just popular in e-commerce. Ben: Yeah, and I think also on the subject of SEO and Brian certainly knows more about this than I do. But one of the things when it comes to SEO that's not as mysterious is that performance matters. And I think- Guillermo Rauch: 100%. Ben: ... Recently especially like the past year, it seems the Google algorithm has been leaning harder and harder into performance that determines rank. And I imagine the abilities of Next to do server-side rendering or static site generation, those things are a big reason why it makes Google performance [crosstalk 00:30:18]. Guillermo Rauch: Yeah. One interesting thing that Google has done that i think is very commendable is they tried really hard to make the web fast with AMP, for example. And their ideas were really good because for example, one of the things that AMP did was thinking more about layout and how to make it more efficient, how to prevent layout shifting, all those things that we're already thinking about way back. But they took this really bad route of, "Hey, there's this weird side internet that is faster." And it's faster sometimes, the performance was still kind of not a huge home run. It's been documented in several places. So then they were like, "Okay. let's stay with the goal, the objective of making the web faster and then let's put out this metrics that everyone can conform to, the core web vitals." Guillermo Rauch: So now they're saying, if you have good core web vitals, we'll rank higher your website on any given search. So Next.js has optimized very heavily for really good core web vitals. The thing that's perhaps also lesser known is that where are these core web vitals obtained from? They're obtained from anonymized data from real world Chrome users, the chrome user experience report which in itself is also an open dataset that you can query. So, what's nice about that is that now we're sort of taking this holistic approach, okay, I loaded Vercel.com or LogRocket on my Chrome, did it load faster or did it load slow? That goes as a data point into that report. Guillermo Rauch: And this is where another of the benefits of Vercel really shines is that we give you that data in real time. The chromosphere extension report lags by certain months for good reasons but you get the report given to you later on and it may be a little too late and now your SEO has really not done well. So we inform you also from the perspective of the end-user device and not just from Chrome but from every type of browser, every type of device. And we can help you along the way because there's so much that the framework can also do for good web vitals. Something we see a lot in e-commerce is you bring in a chat widget for the chat bot for real time help for e-commerce which is a really hard trend in e-commerce and it loads three megabytes of JavaScript and it blocks the thread and it competes with the purchase intent. Guillermo Rauch: So that's going to throw your core web vitals even if Next.js was or not in the picture. And that's why we need to take this holistic approach of, "Hey, Next we'll do whatever is humanly and AI possible to make your site faster but you also have to look at the data." Ben: So let's say I already have my e-commerce site built on some sort of e-commerce CMS like Shopify and I want to migrate my front-end to Next, do I have to build from scratch or are there kind of pre-built templates that talk to Shopify and make it easy to get started? How do people usually make that migration? Guillermo Rauch: Yeah. So something is really popular is our Next.js commerce template. So if you go to Nextjs.org/commerce, you'll be able to download an entire starter kit that works not just with Shopify but with many other e-commerce back-ends. It has really good performance out of the box. We then went ahead and added a cookie banner because we wanted to make the point that, "Hey, a cookie batter doesn't have to ruin performance also." So we tried and we continue to iterate on it to make it as real world as possible, incorporate all these challenges that e-commerce storefronts have and give you 90% of the work for free so that you can get up and running really quickly. Guillermo Rauch: So that kind of also rules out a common objection of decoupled front-end back-end which seems more complex, it seems like it's more work. I think there's good intentions behind that but at the end of the day, the client server architecture is always there anyways. And when you look at the code and you see how easy it is to consume, for example, the Shopify GraphQL API, you'll see that it's both easy end performance. Ben: I'm curious. We spoke on the podcast to Kyle Mathews from Gatsby a couple months ago. And they're really leaning into the integrations with other CMSs like WordPress. Is that an area of integrations that your team is working on as well or is that an area where Gatsby is made a better choice or generally, how do you think about Gatsby as kind of a competitor? Guillermo Rauch: Yeah, I think Gatsby is really focused on the static generation use case. I remember, years ago, thinking really deeply about static because we started so dynamic. And my initial intuition was like, "Wow, static is just a subset of dynamic." I used to repeat that phrase in the company a lot. But we realize that it's not enough to just say, "Well, just do dynamic." Because then you have some static stuff inside, you can also optimize for that. So we learned a lot from Gatsby and others in the ecosystem in terms of let's add this static feature to Next.js as well. But we didn't want to say, "Well, there's a cap on the growth of Next." If they use a static generation, you can only do 1000 pages or whatever fits in the build process. Guillermo Rauch: And we also didn't want this really long build times because that goes into the DX, right? If you statically generate a LOD but the developer is having 15 minute feedback loops, it's really not great. So incremental static regeneration was a technique that we devised for, "Hey you can mark the page as a static and then we can also regenerate it asynchronously." So it has the exact same benefits of a static generation in that you can pre-render pages. The pre-rendering step can happen at build time for a subset of pages that you decide how many and that's really nice because it gives developers some feedback about whether the integration with their CMS worked well or whether they're rendering correctly and they do risk the rollout which is another feature that I really like. Guillermo Rauch: But then, once you've shipped, you can continue to push static pages to the Edge and that's what incremental static regeneration enables. And that kind of solves that problem or false dichotomy of, "Well, I can be static and cached or can be dynamic and then caching is not automatic." With increment static regeneration, we did a log to sort of move forward that conversation. And with regard to your question about CMSs, it kind of goes back to my perspective that Next gets data. It can come from Prisma and be more low level ORM. As long as it serialize this into Jason and then we can pass it to properties into React components, we look at data kind of holistically. Guillermo Rauch: So we look at data coming from e-commerce, we look at data coming from CMS, a lot of our bigger customers just build their own API's, frankly, right? Because they had already built the most likely and those tend to mix continent data. We see a lot of this with GraphQL where you might have a query that aggregates both content and more traditional metadata. Ben: I guess to dig in there, definitely makes sense that your Next is, I guess, agnostic would maybe be the way to describe it about where the data is coming from to build your front-end on. But certainly Next.js commerce seems like its just a fantastic developer experience, that it gives developers so much out of the box. We were checking out a recent Vercel asked me anything post and there are a bunch of questions from the community about what more can Next do to make it easier to get data from common sources? So, you called out Superbase earlier, different back-ends data services. So I wonder, is there more on the roadmap to make it super easy to-? Guillermo Rauch: That's a great question. Yeah, because writing API calls is never a good experience, right? I sometimes mentioned that, if you're launching a developer product today, you probably want to make it a React hook or similar instead of a curl API call just because I guess it's just relatable and focuses a lot on really fast integration. So I think that on top of that layer, I can make an API call using Fetch and get some data. You can also build higher level component based integrations for getting data with one caveat which is that if you're a very dynamic site, you have to be very careful of waterfalls. We are introducing ways that you can co-locate data and components and the technology that enables this is the introduction of Suspense and some new technologies in React 18. Guillermo Rauch: So you can imagine a really awesome future where you're sort of bringing components and understand what data they need or you bring in components that know just about data and then can sort of help other components become full of data, so to speak. And that creates a better composing experience than just making promise all chains or kind of writing very long GraphQL queries and so on. Data as always is still a very challenging space because of the what I mentioned, the waterfall problem and over fitting queries based on what the customer is very likely to do afterwards. It can get really, really complicated but overall, we think that over the next couple of years, the React data experience will change dramatically for the better. Ben: On that note, what are you most excited about in the future of front-end, be it React or things specific to the Next roadmap? Guillermo Rauch: What I'm most excited about these days is putting more and more workloads at the Edge instead of on the client. I think developers tend to obsess about doing code golf with client-side JS. Especially critics of React tend to say, "Well, the rig runtime is already too big. It's a non starter." Our answer to that is that especially this comes from the experience of looking at how fast front-end code bases and mono repos are growing at large companies, the solution is never to tell developers to stop and not do their jobs or spend years and years and years code golfing to get JS from 80 kilobytes to 66. It's more, "Hey, let's leverage modern cloud infrastructure to put more and more workloads there." The cloud tends to be actually metrically more powerful than the device so we're going very deep in that trajectory. Guillermo Rauch: The other one is what I kind of mentioned that static is a subset of dynamic and really fully realizing that dream. Right now, it's still kind of the developer has to choose, "Well, this page is incrementally static, this page is dynamic." We can combine with a better data frameworks, we can create a much better developer experience there and ultimately, user experience because we're going to be able to sort of stream in portions of pages at different times with different speeds with much better sort of fault tolerance around component boundaries and a lot of other improvements. So, it kind of goes back to that idea that kind of originated this all which is, let's make Next and Vercel as fast as the speed of light. We're getting very, very close to that, I think and it's exciting that we can make such a contribution. Ben: You've raised over $100 million for the business and a very, very impressive list of customers so it seems you're building a really awesome business around Next with Vercel. We have a question from James Quick who's been on the podcast before, what advice do you have for developers that want to become entrepreneurs? Guillermo Rauch: One thing I'm excited a lot about in the open source space is you can create an amazing piece of software that then gets augmented by a global cloud platform. And that means that I think the equation around how easy it is to conceive a business on top of what you're creating is becoming, I think, more stable. It used to be in the past that this happened with Redis and a lot of pieces of software, where you create something then AWS grabs it, hosts it and then AWS does a better job than the Creator. I think we're entering a world where things are more balanced because what you're open sourcing is a version of that software. Guillermo Rauch: And when you think about what the clouds are capable of doing today, it's very likely that the customer that is interested in using that open source software for example, for self hosting doesn't want to operate a global Edge network with 20 regions like Vercel with a full DevOps team and SRE team to sort of programmatically improve and deploy that. So I think this equation is becoming a healthy balance of, "Look, we can make it fully open source. There's zero, there's no pre-premium whatever. There's no got yous. But platforms are here to make your job easier at the next level of scale." Guillermo Rauch: It's almost the distinction that Snowflakes CEO drew one time before snowflake a lot of the databases were kind of this idea of you take the database, you put it in the cloud, you call it a cloud database but because you took the same out of software, the amount of human resources, he called it squirrels, that are behind the database trying to massage and [inaudible 00:45:22] so that it doesn't fall over we're really massive. What we realized is that once we move into fully cloud native solutions, we have new primitives to work with, new API's, new power and then you can create way more scalable things and that certainly was the case for Snowflake. Guillermo Rauch: So I think that paradigm will continue to thrive. I think the next Snowflake will sort of be open source because there's no reason for it not to be. And then you can still create an amazing cloud experience especially as the enterprises move very, very fast towards cloud. Ben: So you just announced Next.js comf. Tell us more about that. Why should developers check it out? Guillermo Rauch: Yeah. So, go to Nextjs.org/comf to claim your ticket. It's free, global and it's our annual user conference. So it just won't be us, it'll be the entire NCS community. It'll be our partners, we talked about the CMS and e-commerce ecosystems, it'll all be there. We'll have amazing talks in the community. It's happening on October 26. Fully remote, online, virtual and there are a lot of announcements and surprises. This is probably the most exciting thing about an event in a very, very long time. I know it's ours but yeah, in some ways it marks a new beginning for Next.js. We've kind of been teasing out the new things that are going into it and there are some spoilers throughout the page but do check it out. Brian: Okay. So one of the things that we've figured out after 50 episodes of PodRocket is that it's a smart thing to do to ask previous guests what to ask future guests. And so I mentioned James Quick. We also asked [Swix 00:47:12] if he had questions for Guillermo and he has two, they both look difficult which is kind of on brand for him. So I'll start with the first one, right? I'll just read it. Is Vercel keen on low code builders on the front-end like Web flow and more capabilities like storage authentication, work for [inaudible 00:47:31] on the back-end? Guillermo Rauch: Very much so. So, one of the things that we've been noticing recently is, a lot of our customers are building platforms on top of Vercel that compiled down to Next.js and obviously Vercel websites under the hood. So Next.js because it's so dynamic allows you to dynamize the content even by host name or domain name. So there's a bunch of extremely successful platforms that give you a completely no code experience. For example, when you drag and drop an image or when you use an image or a video, they get everything right that developers sometimes including myself don't, we talked about the image example. So my favorite example is [inaudible 00:48:16]. It'll take any notion page and convert it into a website. Guillermo Rauch: The website that it yields if you inspect it has, well first of all, extraordinary core web vitals. Every page is a Next.js page. All pages are pre-fetched so they take advantage of our smart pre-fetching system. Every click feels instantaneous, all the images are optimized and all of these things that are frankly so hard to get right even for developers. So the reason I'm so bullish on this kind of platform is I think of it as automating work. Instead of hiring a dev, sometimes you can do it yourself and it's just fantastic. So we have a lot of improvements in the pipe for making this use case even broader and more interesting for entrepreneurs especially. Guillermo Rauch: There's, I think, now 30 platforms like this on Vercel, probably even more and so I totally welcome no code, that's one way of integrating into your stack where you build certain pages in this builders then you can use Vercel to do the routing. So you can say, "Well, start with my no code provider and then fall back to my yes code." I've been using that term recently, my yes code pages. The other really cool one that I'm seeing is Next.js especially with incremental static regeneration allows you to kind of go and build things asynchronously that could otherwise take a lot of time. So a lot of customers are using it to bring representations of components in layouts from a data store and then that tool could be giving you a visual UI for laying out components. Guillermo Rauch: This is happening a lot in e-commerce where their marketing teams are constantly iterating with new offers, new promotions, Christmas special is coming up. So you want a really fast no code builder for some parts of the page. You probably don't want to touch the core essentials because those are heavily optimized by developers, the buy button might not be something that you build with a no code tool because it's so dynamic, personalized, it has to render right payment experience for each preference of payment provider. But the Christmas is special banner can be totally designed in no code local tool. So, you can import those inside your existing Next.js pages. So those two use cases I think are going to grow a lot and I'm here for it. Brian: Nice. That was a thorough answer to so I appreciate that. Okay, so this one same still from Swix but it's really about the business. And here it is, is the plan to grow in an apple vertically integrated ecosystem? Can that take Vercel to a $10 billion company? Guillermo Rauch: So we've always looked at Vercel as an open source, open platform company, right? If you fork Next.js and you build a better one, Vercel will be more than happy. Especially Vercel has this sort of perspective on end-user experience is really what we're after. Making the web that, my children, my parents will enjoy using ultimately. So we're open on every side, the platform itself is open. We're actually about to launch renewed documentation on how to integrate any framework and even on how Next.js itself is integrated into our platform. So there is no disparity on power that we have in order to integrate than you would have if you're a third party framework builder. Guillermo Rauch: And this is especially very important to enterprises that tend to come to Vercel because they already built the framework. They're interested in Next.Js because they want to offload all that work but the framework exists. So you can onboard any framework and then you can also use an extra if you so desire or you can use no code tools in our ecosystem. So we've always thought the web is a really rich environment. We take the same stance with Next.js as an all the CSS systems that exist. I think we support two dozen and I think that will always continue to be the way of the web. I think we do obviously draw inspiration from Apple in how they do things and express their brand and whatnot but what we don't take inspiration from is, "Our way, our API or no way." And restrictions all over the place. So that I'm less a fan of and we try to do basically the opposite. Brian: Okay, last question is from me and it's mostly just for fun. I saw that you asked your Twitter audience to tell you what books that they have reread. And then you put that kind of dump on your site, we'll have the link wherever. Now, my question is, were there any titles on there because there were a lot that were- Guillermo Rauch: Yeah, I'm checking them out now. Brian: Yeah. Were there any that you yourself were, "Yes, I've read that a bunch of times." That you were surprised to see or surprised to see omitted? Like I said, there's a lot to go through so I don't expect you to know them all. Guillermo Rauch: Yeah. I was surprised by a bunch and also not surprised by probably the top 20. For example, the Steve Jobs biography is there, I think that's not super surprising. A lot of things about investment and financial technology interest developers and this showed up in a lot of recommendations. And I think this is just a very interesting trend that we're seeing even in our platform of Vercel there's a lot of FinTech companies especially in the web three and crypto space and we're very excited by that ecosystem. So I think developers are becoming just so much more interested in building and using financial technology, I learned that from that. Guillermo Rauch: Factfulness is there which is awesome because one of our dear co-workers, Chibicode, his claim to fame inside the company is that he translated Factfulness as soon as he came out to Japanese and he was an early adopter of the book. And translators are very important in the distribution of books and actually, they get royalties as well. So he built amazing websites about the book and whatnot so I was really happy to see it there. My favorites, I really Sapiens, cliche I know, throw me under the bus but it's a great book. Lord of the Rings, I'm a huge fan of. A lot of the Richard Feynman recommendations. It was a really good experience and I open source how I built it. It dynamically pulls the data from my notion list of books and then it builds and pushes the space to the Edge and you never again hit the notion back-end which is very, very efficient, I love it. Brian: No, I thought it was real cool. If you're listening, check it out after Purcell, after the next then go to the book. Ben: Cool. Well, I think that's about all the time we have today but Guillermo, thank you so much for joining us. It's been awesome. Guillermo Rauch: Thanks for having me. Brian: Thanks for listening to PodRocket. Find us at PodRocket pod on Twitter or you could always email me even though that's not a popular option. It's Brian at LogRocket.