Brian:
PodRocket is sponsored by LogRocket, a frontend monitoring and product analytics solution. Don't know what that is? Go to logrocket.com, thanks.

Ben:
Hello everyone and welcome to PodRocket, I'm Ben, and we have Anthony Campolo with us. Anthony, welcome and could you introduce yourself to the audience please?

Anthony Campolo:
Hey, what's up Ben, thanks for having me here. My name is Anthony Campolo, I am a developer advocate at StepZen and I am also the core advocate for RedwoodJS, which is an open source JavaScript library, where React or where GraphQL is a very important base layer of how it all works and we get into that as we go, but I get out and I write blog posts and I do meetup talks, I do podcasts interviews such as this, I also host my own podcast, the FSJam, which actually has had, I think, it's about five or six overlapping guests between our two shows. So we have similar interests for sure.

Ben:
Definitely and we've talked about Redwood before, we had David Price on the podcast a couple of weeks or months ago, a while ago. So if anyone is interested in the deep dive on Redwood, definitely check out that episode. But today we discussed a bit, before the episode, and folks may see it in the title of the episode is we were going to talk about GraphQL and really look at this more as a GraphQL 101 for folks who have not used GraphQL or aren't super familiar, GraphQL has been out for a few years now, it's been growing tremendously in popularity. And it would be great, we can do an introduction to what is GraphQL and how does it help you build great web apps, and so Anthony, maybe you could start there, high level, what is GraphQL, a bit about the history and then go from there.

Anthony Campolo:
I'm a big history buff myself, so I always enjoy learning where these things came from, especially for something like React and all the stuff that goes around React. It all came out of Facebook transitioning into the mobile world. So you're going to frequently hear people talk about this time where Facebook bet all, it went all in on HTML5 and this new web thing that was meant to try and get us to a place where we were using native web APIs, but React was a different thing back then. And it was all about how you have a one way data flow that you can do really nice data fetching with and it also went along with this thing called flux so let's step it back and talk about what was the actual the problem here?

Anthony Campolo:
The actual problem was that, you can't just send a ton of JavaScript over the wire because it's a lot of code, our devices can't necessarily handle all of that code and can't do all the things that we want to do. So what we needed to do is we need to be able to send smaller queries for lower powered devices and this sounds really esoteric and weird and specific, but it had huge implications in terms of how we thought about what GraphQL is and how we would want to work with it. So that's the history of where it came from and this was actually almost 10 years ago now that it first started, and it eventually became a foundation and hit the scene, and most people knew about it around 2015 and now we're seeing the downstream effect of it.

Ben:
Got it. So does GraphQL pre-date React? Is that correct?

Anthony Campolo:
So it predates it in the sense that it was started around 2012 or so. And so React came out around 2011 but it wasn't really released to the public around 2013 or so. So they're all overlapping but by the time GraphQL was debuted to the world, React was already a thing and people already heard about it. And so the success of GraphQL is downstream of it because once you had this whole React thing, you're like, "Okay we know what the front looks like and we work backwards from there." So it's about saying, "Let's start thinking first from the query and then build everything around that." So it was starting from frontend devs mental model and then going from that step.

Ben:
Got it. And before we dive into GraphQL, is Relay a framework that uses GraphQL or was it just a similar architecture and maybe just a quick introduction to real... I think, some of that history is interesting.

Anthony Campolo:
Yeah. And this is a really good question because it Relay sits in between the Reacty stuff and the GraphQL stuff, because GraphQL itself doesn't really have anything to do with React or even with JavaScript. And so let's talk about that, where this is a specification of how to basically get your frontend and your back end just to agree on a schema and agree on types, and that's what makes it really unique because you could agree on those types with a Go backend or a Java backend just as well for a Node JavaScript backend. And you can do that translation and what Relay was doing, is it was handling the client side cash, because there was going to be a lot of stuff around cashing and normalization that goes along with this.

Anthony Campolo:
But the thing that made Relay really cool, is that it translated from GraphQL to React speak and this is where the historical stuff comes into play, because they all were designed together and they all fit very well together. So that's why React and GraphQL, they fit very well because you have this Relay piece that fits it all together but they're not technically coupled technologies. So it's not weird how this stuff all fit together, do they require each? They don't, but they actually do because they should philosophically fit together in this whole weird like, "Which of these pieces do I actually need and which do I don't?"

Ben:
Yeah. I mean, it's almost like with React and then Redux and they are a couple, but not necessarily coupled, but you'd need a state management layer for React and same idea here, like you have GraphQL but then you do need something to couple it to your view layer and I guess Relay solves that problem. So looking at GraphQL, we've mentioned a bit of types and schema and the ability to request just the data you need. So a couple of these disparate ideas, maybe could you give an overview high level, what is GraphQL and how do people use it and how does it help?

Anthony Campolo:
Yeah, and if you're a developer from our point of view, the way you think about it is actually it's very simple. You just think of it like a JSON object with just the keys and no values. So it was just nested objects within objects, within objects, within objects. So you see an object, it recalibrates in an object to that and then it calibrates. And so that's where it's really, really simple to write because you would just say, "Okay, I want to get movies." So you'd write movies and then parenthesis and then inside that you have, "I want the name of the movie." So it's about having nested queries inside of each other, but then it's always just a query inside of another query. So it's very recursive in that sense and that's like the whole query language, is what you optimize for if you just look at a query, it's very readable. You say, "I want these things from that or that object or whatever it is."

Anthony Campolo:
So it's really nice because going back to the schema and the types, you always have that available for your GraphQL patch server. So you'll frequently hear people compare GraphQL and REST, and this is one of the things you'll hear talked about, is that you only have docs for REST and pointless, so we sat down and wrote those docs sources. With GraphQL you're always going to able to see, "Okay, what is this excellent data, what are the things on that data that I can get?" And then you don't have to think about, "Okay, how to actually write the query to get that," because GraphQL has standardized the query language for you. So you can learn the Standardized Query Language that will then allow you to interact with any graphical server you want, because we have these agreed on specifications.

Ben:
And so would it be accurate to say that with GraphQL, instead of whereas REST, you have a whole bunch of endpoints for each type of data you want to request or send? GraphQL you have one endpoint, but then based on that JSON valueless object you send, you can request just the data you want in the shape you want it. Is that accurate?

Anthony Campolo:
Yeah, totally. There's the two pieces, you nailed it. There's the query and then there's the endpoint and GraphQL is really great because, as you say, it simplifies it to only a single endpoint so you always know exactly where you need to send the query. And then because you have the Standardized Query Language, you just have to know what is the schema and then you can figure out how to send that query.

Ben:
I'm curious to hear more about that idea of docs being generated automatically based on the schema, because certainly one of the challenges with REST is documentation and having used GraphQL, one of the things I love about it is, GraphiQL and that is spelled G-R-A-P-H-I-Q-L, basically the tool for introspection of GraphQL API. So could you speak a bit about that?

Anthony Campolo:
Yeah. You'll hear them call it the GraphQL explorers and GraphQL playgrounds as well. Yeah, I want to start and say I hesitate to refer to them as auto generating docs. I actually think auto-generated docs is oxymoron, because docs by definition is actually written by a person, that's the only way they'll actually make sense.

Ben:
Fair enough.

Anthony Campolo:
But it's the closest you can possibly get to auto-generated docs in the sense that you can know at least, "What can I actually do against this?" Can I write to it, can I read to it, can I updated it? That kind of thing, and it bakes that in to the schema and that's what's really cool about it because you're allowed to basically take any schema from any other GraphQL and just modify for your own needs because you'll always see the schema. This is what I mean about being auto generating, is that you have this GraphiQL playground thing and I would recommend people go to rickandmortyapi.com/graphql, I think that's what it is. If you also just Google that you can find that endpoint and that will take you right to one of these graphical editors. On the right, you'll see docs and schema that you can click those and play around.

Anthony Campolo:
So I always start people off just with endpoint like that, it's like you can go to this end point and they can start querying it and getting the data back and just show them how to look at the docs, how to make the query and that is a really good way to actually get people's hands on GraphQL, breaks out all this and crazy abstract stuff that we're talking about, temporary stuff as well of like, "How do I actually interface this, how do I write queries, how do I get data back?" And it's like Postman or Insomnia, these have API client tools that a lot of us, as developers, know really well and are leveraging and it's sits like a weird middle intersection between something like that, like a full fledged frontend framework.

Ben:
Tell me a bit about posting data or I guess that in a REST API you can do a post request GraphQL, I think it's some mutation. What does that look like and what are some of the ways that GraphQL mutations maybe improve upon post requests within a REST API?

Anthony Campolo:
Because you don't necessarily want to think about all of these working the same way in the REST world, because in GraphQL you only do posts. So what I mean by that is anytime you're sending something to the server, it's going to just be a post, you're not going to do gets or puts or anything like that and the reason why is because you have the schema, the language, the GraphQL, the whole thing exists. So you already have it baked into the language in terms of, you actually write literally the word query or the word mutation before you do a thing. And some people may have heard the term CQRS which is a fancy way of saying Command Query Responsibility Segregation, which is about separating your commands from your queries. If you just change command to mutation, then keep query, that's what we're talking about here. So I think the query is getting data, so reading and then anything else is a mutation. So creating as mutation, updating as mutations, leading as a mutation and with GraphQL, you're basically saying, "Okay, I'm gonna write a query." So I want to get this data back or I want to create, and then you have an input of what you want to feed it, so you can do arguments and then the whole crud is baked into what GraphQL is itself.

Ben:
Got it. And below the GraphQL layer, you have whatever data store you're using, generally assuming, there's a database backing your application. And I'm curious, when you're using a SQL data store, what are some of the synergies with GraphQL that you get, especially with regards to maybe type safety of your query and particularly we've talked about Prisma on the show before. So curious to maybe hear you explain some of those integrations between GraphQL, Prisma, or SQL.

Anthony Campolo:
One of the things that people really like about in GraphQL, is that it is very much like this mediator between the frontend and the backend. So it's not really tightly coupled to any database technology, but it does work very well with SQL because going back to this whole historical thing, Facebook was very well known for being the LAMP stack. And so they had this whole PHP stack that they were using as their backend and that's how it ended up being translated into this GraphQL thing. And so with Facebook, you had this way of basically... if you could specify the endpoint, you would be able to specify the types and then you would be able to do all sorts of really nice introspection into that in terms of being able to auto-generate stuff with the types.

Anthony Campolo:
And it's actually funny because it goes back to this, they have their own typed version or it was an extended version of PHP called Hack XHP, they had all these other language extensions that ended up turning into what we now think of today. So getting back to it being a middle layer, it doesn't have to necessarily be SQL or NoSQL, but it can actually be either. And so something like Prisma that comes into play, Prisma is an ORM and they have a long soul searching over whether they call themselves an ORM or not. I think you talked to Nico about that. And they eventually decided that people know what an ORM is, it's a tool that makes sense to people and it became the mediator between your finding your backend at the database level and then Prisma decoupled themselves from the GraphQL stuff and so this is where more of the history comes in, it's very confusing and hard to get into.

Anthony Campolo:
So it's not really that important but Prisma used to be entirely wrapped up with GraphQL and that is what was extracted out of the GraphQL and became just this database thing. And so, with say RedwoodJS, RedwoodJS they handle the schema, so you write your GraphQL schema and you also write your Prisma schema and that's how you can keep those two separate from each other, and this is what allows these tools to become a lot more decoupled than they used to in the past. Because if you want to just bring in now a whole PostgreSQL backend, you can do that with Prisma, but if you also want to switch it to, say a MongoDB with NoSQL, you can do that as well and that's really amazing and it hasn't been something that you could really do with an ORM tool in the past.

Ben:
Got it, yeah. No, it makes sense. And in terms of some of the terminology that someone getting started with GraphQL might want to understand, we talked a bit about schema, we talked about queries, mutations, there's a few other words, I think, of input types or interfaces or concrete types. So could you go through some of those and what each of them means?

Anthony Campolo:
Yeah, they want GraphQL to be extensible itself because they want it to be a full fledged language in that respect. So you have all these ways of typing it, and this also gets into this whole JavaScript versus Typescript debate and what you get out of having typing. And the real thing is just it's you got a lot of nice developer tooling around it. As you get a lot of nice auto-complete, you get error messages when you have your project that's have type aware, there's a lot of really good downstream effects of that. And so that's why you want to have your database to be tight and so you want to have those types flow from the backend into the frontend and so that's where something like GraphQL is really nice in terms of agreeing on the types as the frontend or the back end.

Anthony Campolo:
And then once you agree on the types, then you can start building all this tooling around that. And we talk about the GraphiQL editor, you can take that a step further where the knowledge you have as this really nice editor that you can write queries in, you can actually have just a click and drag and drop thing where you can just start clicking stuff and it'll write your GraphiQL queries for you and have put things into the right places for you.

Ben:
Got it. So to take this step back, curious to hear a bit about your journey and what led you to becoming such a passionate a GraphQL expert and maybe you could tell us a bit about how you fell into this world.

Anthony Campolo:
Yeah, it's a long and winding story, but the TLDR, I was originally a musician and did a lot of music teaching and worked in more performing arts environments and did that for, I would say half of my 20s. So I started as a music teacher and then I ran up performing on summer camp called Youcamps for a couple of years, and eventually just decided I wanted to get into a job that would be more creative like the arts, but also be more tech focused and would have more harder skillsets associated with it. And so I ended up trying to learn data science and machine learning type stuff.

Anthony Campolo:
This was back when deep learning was first coming out, DeepMind was this big thing and AlphaGo and all that stuff. And I didn't really get a lot of traction with that, it was just very hard to learn that on my own, and then I've actually fell into the web dev JavaScripts thing because going back, for me, this was really about getting a job and having a stable living and all that stuff. So at a certain point I reevaluated, I was like, "What am I actually trying to do here?" I'm trying to get a job coding JavaScript and especially React, it's going to be the thing to learn. And so I pivoted to the more web dev, HTML, CSS, JavaScript world, and I started going to Lambda School and Lambda School was actually in the news or recently these days, as they tend to be, it's very controversial income share agreement school where you don't pay anything before you start the bootcamp, but you sign contracts where you pledge a certain percentage of your income for two years after you get the job.

Anthony Campolo:
So the idea of doing that you don't pay a dime until you already have a job and then they get a certain cut of your income. And so I did Lambda School and learned a lot of React and a lot of just modern JavaScript stuff and as I was doing that, I started learning about RedwoodJS instead of RedwoodJS as the linchpin of a lot of these things and how I got into GraphQL, because it just fit a very specific problem set that I was learning at Lambda School which was how do you build a full stack React project, and it's this very nuanced thing because you have this weird single-page application thing going on that's talking to your backend which is going to be your express server attached to a PostgreSQL database and then you have to figure out that whole data flow and then how to manage the OAuth and all that stuff.

Anthony Campolo:
And Redwood was a framework that basically said, "Hey, we solved all this for you." It was very much what you would call a convention of a configuration idea, it's a very opinionated framework when people talk about it, and again, we can direct people to the actual Redwood episode on the show to get a taste of all of that. But I used it and immediately just got it and I was like, "This is really, really cool." And I was using GraphQL without really realizing it because in Redwood, GraphQL is the whole deal. Like your frontend React app basically is making GraphQL queries directly into your backend, which is a PostgreSQL database.

Anthony Campolo:
And so you basically create this GraphQL server and GraphQL client, have it all contained within a single project and you get that out of the box. You don't have to figure out how to actually wire that all together, and you can have these generator commands that would just spin up interfaces for you really quickly going back to [inaudible 00:23:38] nice tooling and stuff that goes along with this, when you build up these layers of abstraction, then all of a sudden you had this whole super powerful framework that you didn't have to do anything to get. You just have to understand what is GraphQL and how to use it and the mental model that goes along with it.

Ben:
Am curious, as you pointed out, there's a lot of controversy around Lambda School. So like curious to hear about your experience, sounds very positive but I would be interested to hear how you felt the program was and was it valuable and something you'd recommend to others?

Anthony Campolo:
I think with bootcamps it's always going to be hard because you can't give blanket advice on it, in general, in terms of everyone's situation is going to be so unique and so contextual. And it's going to be really hard to say what's actually going to be right for someone who just has a general case. I do think Lambda was good for me, I do think that I owe Lambda a lot in terms of me getting where I am. I hesitate to give them too much credit because I essentially ended up dropping out of Lambda to do Redwood instead, which is a decision that is one of those things where in retrospect, it worked, but it's like at the time it seemed like a really bad idea. So it's a really good if you just don't really know what direction to go and you need to just have someone point you in that direction.

Anthony Campolo:
But for me, I had to find something that was going to allow me to actually work on the code with senior developers, that was one of the biggest thing with doing something like Redwood, is that you get to actually be in the thick of it, in a way you can't in a bootcamp. You're seeing these high level discussions that are happening and you know that you don't fully understand them because all of these words that are thrown around don't make any sense to you. But as you start listening to these conversations, you start listening to conversations over the course of months, if not years, then things start to click together, then they start to make sense.

Anthony Campolo:
So I would say if you are someone who is interested in bootcamps, you're going to want to just research, what's going to be available to you and what are going to be the different financial obligations that go along with that. And then once you know that, then you want to ask them, "Hey, how do I speak to people who've been to this school, who've gone through it so I can get their honest opinion on it." The thing that just makes it hard is that because it's set up to be free and that basically anyone can do it, they have to set up the system in a way where they know half the people go through it, aren't going to make it to the end of that, they're going to give up at a certain point and that they need to have that be an option, it will also not lay that to tracking people who do us stick it till the end.

Anthony Campolo:
So there's no good answer for that and that's why you end up with this huge churn and rounds of layoffs and things like that which are constantly integrating and you're constantly trying to figure out how do you do this because no one has ever done this before. So it's not easy and I think people have a hard time really cutting Lambda some slack in terms of what they're doing and how hard it is but then at the same time, they're not perfect and you can't act like these things are perfect when they're not, because they're people's lives here you're messing with. You're giving them advice about whether to go to these students bootcamps or not. I can't give a simple, yes, this is a good or a bad bootcamp or a yes, you should go to this or not go this, because there's too many considerations that go along with it. But hopefully those considerations and knowing what those are can help people out.

Ben:
So, this week we have a couple of listener submitted questions. This is a new segment we're doing where we reach out to our audience. We say what the topic of the episode will be and people submit questions. The first one I have here is what are the most exciting new things that are coming to GraphQL this year that people should be on the lookout for?

Anthony Campolo:
There's always going to be new things coming out and new things in the scene. And when I look at the whole ecosystem of GraphQL, I think usually there's the open source world and then there's the software as a service corporate world, and I find that almost everything that was going to be interesting, it is going to be more of a bottoms up open source focused way, and that's going to have downstream effects in terms of the types of products that we actually use. But I would point people to this group called The Guild, and it's a really fantastic group of developers who have their own unique decentralized model where each individual contributor basically owns the repo of whatever project it is, and they have all these different interlocking tools that make up this greater suite of GraphQL tools.

Anthony Campolo:
And so they've got a lot of things that are coming together around, things like GraphQL Helix and Envelope or Envelope, there's a controversy over how that is being said. And that's some of the stuff that I find really interesting, it's how do we expand out beyond these base GraphQL libraries and frameworks that everyone knows about because most people when they're introduced to something like GraphQL, they're introduced to it through the lens of one of these specific tools or companies whether that's Prisma or whether that's Apollo, or whether it's Hasura or any of these companies. That's usually the entry point people get into them but there's a lot of really cool stuff happening among just the different libraries and ways of working with GraphQL.

Anthony Campolo:
So I would point people to things like GraphQL Helix and things like GraphQL Shield and GraphQL Mesh, there's a lot of these are really cool pieces of technology and going back to, I had mentioned how I worked on Redwood, on the core team and then that eventually led to a job in this company called StepZen. StepZen is a company for creating managed GraphQL API gateways and it sits at this really cool intersection between things like databases and say, REST API, so you could turn a database schema into a GraphQL schema, but you could also turn a REST endpoint into a GraphQL schema and this is where you could do with something like GraphQL Mesh, so expanding out to where GraphQL is eating the world idea, it's that you can figure out a way to start with GraphQL and then have that expand out to all these other areas and just how do we do that translation to where we want it to go.

Ben:
So next question is, who should people follow to get the latest and greatest about GraphQL? I think that that speaks to a general thing I hear from a lot of folks in the frontend world, that things move so quickly and how do you stay on top of new developments or tools? I mean, Twitter is certainly one good place if you know who to follow. So maybe we'll scope it to that, any recommendations of who to follow on Twitter to stay on top of GraphQL stuff?

Anthony Campolo:
I'm definitely aggressively on Twitter. So if you want to know about GraphQL stuff, you follow me and I'll get you a pretty decent big chunk of them. But there's a great newsletter called GraphQL Weekly, that's done by, I believe, the GraphQL Foundation. That's a really good one that I would recommend people check out. If you look to have people who have been around the scene for a while, people like Uri Goldshtein or people like Sean Grove, they're always really good sources for a lot of this stuff. And it is a very much open source focused tech so you'll find a lot of people who are just out there talking about it and doing stuff with it. I think that you're going to have a hard time figuring out who the specific thought leader you may want to be following since you have probably depend on what your philosophies around GraphQL are going to be, even within GraphQL itself, there's still not really broad consensus around certain things.

Anthony Campolo:
So I would say that things like GraphQL Weekly and then trying to just figure out what are the actual GraphQL projects that are around, what has the most stars, what doesn't? Do stars actually matter or not? It's like it's own separate question, but if you just keep your eyes up and listen, especially to podcasts, I really can't stress how important listening to podcasts such as this one, I listen to this podcast since you got started, actually I was really happy when you guys started doing it because you're interviewing so many of the same people and talking about these same types of conversations. And there's never going to be just one person to follow because you have to figure out a way to follow the sum total of the conversation, and the only way you can really do that is by being a fly on the wall of lots and lots of these conversations.

Ben:
What is the best place to start when you are hoping to learn GraphQL?

Anthony Campolo:
Yeah. There's actually a pretty good onboarding experience in the sense that you can just go to graphql.org, and they have from total beginner, total scratch GraphQL 101 just explaining all this stuff we've had, talked about, and I really recommend starting here when you're explaining this to someone or just sending people here when you want them to learn about it because they actually just visually see, they can see the querying, they see the code, all this stuff that we're talking about is very abstract and we're just trying to talk about it, but if you actually show someone the code, that's what makes GraphQL really nice.

Anthony Campolo:
The code is simple, its concise, its readable, so you can just show someone the query and show someone the response you get back from that query, it usually clicks immediately and it's like, "Oh, okay, cool. I get it, that's great." So if you go to graphql.org, that's the very basic hello world getting started. And then the docs get you a little further than that in terms of also showing you how to start to make a GraphQL server and all that. But I would then point people to how to graphql.org. It's a really great site that has larger full stack tutorials that will show you how to do the whole integration between the frontend and the back end, because there's going to be multiple layers to this in terms of how deep you want to go into it, because there's always going to be the frontend piece since there'll be the back-end piece.

Anthony Campolo:
So there's going to be a GraphQL server and there's also going to be a GraphQL client. And while you want to own that whole space yourself or if you just want to own the front or the back-end, that's going to then dictate what you need to learn and where you want to focus your time. And it's cool because it maps very well too, if you were a front-end or a back-end dev, you're going to be able to find a place that fits in and it makes sense with GraphQL because there's still that separation between what is the front-end and the back end, and that's what makes it nice because then you have a unified understanding of how your front and your back end should talk together, and that's where you avoid all this REST API superness.

Ben:
What are some common misconceptions about GraphQL?

Anthony Campolo:
Yeah, I think the biggest common misconception is that it's this really fast moving, constantly breaking, cutting edge piece of tech type situation, when it's actually all of that happening around a very stable core because it's a spec. So it's really important that people understand that the difference between something being a spec and something, just being an open source library and the differences that there actually is a specification where they've written down what it means to be a GraphQL server, like what actually goes along with that, what the requirements and restraints of that are. And so you can follow the GraphQL spec and you never have to use any of these tools or these libraries that we've we've mentioned at all.

Anthony Campolo:
You could just create with just a Ruby on Rails backend and then hit it with vanilla JavaScript from the front. You don't need to use a GraphQL client or a JavaScript library at all, and that's what I'd like to get across to people, it's that it's actually a very simple and very basic model that then you have all these other things built on top. So you want to first really get a handle on what is GraphQL before you start getting into what are GraphQL frameworks, and what are GraphQL companies, and then has all that fit together? And that's something that come later once you start to understand what GraphQL is, then you start to understand what problems come along with that, and then how are each of these individual companies and projects addressing that within the framework of what GraphQL is.

Ben:
And finally, this is not a listener question, but this is a question of ours. Outside of GraphQL, what are you most excited about in the world of frontend?

Anthony Campolo:
I am really excited about this whole new frontend build tool thing that's going on, and people may have heard of esbuild, they may have heard of Snowpack or WMR or Vite. These are tools that are meant to either expand upon or replace things like webpack and Rollup, which are your bundler type tools. For people who write a lot of JavaScript, they'll know this very well. The way we write JavaScript these days, is that you write your JavaScript project and you take that whole project and you actually run it through all these crazy transformations, through build steps and compilers and all this stuff to have that be something that can actually be shipped to the browser, and this has been a step in the chain that's gotten more and more complicated and crazy over the years and is why when you develop, your computer chugs and you hear your fans going nuts and takes forever to do anything and it's just like webpacks are run over and over, the bag is compiling 10,000 files, and doing all this ridiculous stuff.

Anthony Campolo:
So these tools are about how do we rethink all of this from first principles and not use JavaScript to do everything. The real killer idea is that why don't we just write JavaScript tools and not JavaScript? So esbuild is written in Go, and then you also have these rust base libraries that are coming out as well. And you've seen these now being adopted by things like SvelteKit. SvelteKit was originally using Snowpack and then switched to Vite and is now Vite. It is being picked up by Next and esbuild, it's in Remix, esbuilds is also in Redwood as well. So the transition is actually already happening in a way where most people aren't really even going to realize that it has happened and that it actually has already happened for the most part. And so if you're someone who finds this stuff interesting, now is the time to dig into these tools and learn about them and gain some expertise in them because they're going to be in everyone's tools very, very soon and no one's going to know how to use them.

Ben:
Well, Anthony, thank you so much for coming on the show, really enjoyed the conversation today. We will put links to a lot of the things we talked about in the episode description. So if you want to check out some of the things that Anthony talked about today, that will be there. So thanks again, and hope to have you back one day in the future.

Anthony Campolo:
Yeah. Thanks so much Ben, I've really enjoyed the show as you guys have been putting it out. I really enjoy just the content on LogRocket in general, I have been reading your articles for a while, you have some of the most fantastic content anywhere online for dev content. So thank you for doing everything that you do and happy to be here.

Ben:
Well, thank you. We really appreciate that.

Brian:
Hi, thanks for listening. Please remember to like, subscribe, email me if you want, even though none of you do, go to logrocket.com and try it out. It's free to try, then it costs money, but yeah, we'll see you next time. Thanks.