Ben: Hello, and welcome to PodRocket. Today, I'm here with Meredydd Luff, who is the co-founder and CEO of Anvil. How are you? Meredydd Luff: All right. Great to be here. Ben: Yeah. So I was checking out Anvil a bit before the episode and very excited to learn about it. So can you give us all a quick introduction, what is Anvil and- Meredydd Luff: Yeah. Ben: ... why is it interesting? Meredydd Luff: So Anvil is a web framework. It's a way of building web applications quickly and easily. So instead of having to wrangle five different programming languages and a ton of different frameworks to get anything deployed, you can instead go to a visual editor, drag and drop to build the user interface you want on your page, write Python that's going to run in your browser. So when you click a button or in otherwise interact with a page, you can call server side Python, that you can also write in this in browser editor, set up databases, and then there's a built-in hosting platform. So you can deploy your application, just choose a domain name and ship it. So the idea is that anybody who can code a little bit can build and deploy a real working web application. Ben: Got it. So I have a lot of questions. The first and the biggest question that comes to mind, in a world of seemingly everything web related, kind of going to JavaScript, why Python? Meredydd Luff: So I think the real answer is first to talk about why all one language, because that was the first decision. Because if you are sitting down to build a traditional web application today, think about it from the perspective of your data. Your data is probably going to start as row in some database access by SQL, which is a programming language. And then you're going to pull it into something on the server side, and there's quite a lot here. Some people use JavaScript, lots of people use Python, lots of people use Ruby, but it's going to be objects in your programming language on the server side, and that's accessed by methods and attributes. And then you're going to turn around and you're going to re-render this data as JSON, over HTTP endpoints, which is a different thing entirely. It's this weirdly limited format over this weirdly limited interaction paradigm with only like four verbs, get, post, put, delete, but on the other end of that connection is JavaScript code that's reassembling that data into objects on the client side with their own methods and their own attributes and then it's going to turn around, it's going to re-render to those into HTML DOM, which is its own thing and then style that with CSS, which is a completely different programming language again, to get the pixels. Meredydd Luff: And for most people who do web development their day to day is the transformation of their data between these different representations and back. And this is the primary source of friction in web development, and it's also the source of the churn because people keep feeling that friction, they feel the amount of work it takes to like put a button on a screen that sticks something in a database when you click it. I mean, it's insane. Five different programming languages, and yeah, that's before you start the frameworks of the React, the Redux, the Bootstrap, the Flask, SQLalchemy, webpack. I haven't even started on the DevOps stuff and they feel this friction and they go, "Well, this bit isn't quite working, let me build a new web framework, this will solve the problem. Meredydd Luff: And of course, what they do is they swap out one of the frameworks, that's helping them with one of the transformation. So you invent React and great, you may have made the transformation of JavaScript objects into HTML DOM a little bit easier, but you haven't actually changed the number of different representations you are having to drag your whole program through, and you haven't really changed the fact that you need to understand each of these different representations really well and understand how each of the frameworks work in order to use it properly. Like you need to understand how your ORM works to tickle it right. You need to understand how React works to drive React well. Meredydd Luff: And actually the churn just makes it worse, because it means you keep having to learn new frameworks in all these places as well, and it just makes the cliff harder to climb for anybody whose job, whose career is not full-time web development. So the central thesis, if you like, of Anvil, is this is silly. You should choose one representation and then have it all in that one representation as much as possible. So have one programming language the whole way through. Now we chose Python for a few reasons I can get to in a moment. But the idea is, if everything is in Python, then to put something on the screen, you're not generating code in another programming language that gets styled by a second programming language to create pixels. No, you instantiate a text box object, and you add it to your page of the appropriate place. Meredydd Luff: And then you manipulate it by driving a Python object in a way that will feel quite natural to you. And equally the Anvil's built in database is actually an object database, and you will pull a Python object out of that database and then you'll return it. So every time you communicate between clients and server code Anvil, you're not mashing everything into JSON. You're making a function call because you know it's Python running in the browser. You know it's Python running server. You can just make a function call and that function call can return this object, which is a database row. And you can take that object all the way to your UI. You can data bind like a column from that database row into a text box. And all of a sudden, you no longer have to mash your data through these five or so different representations in order to build a web application. Meredydd Luff: And that means to get that right, to be able to do that at all, you need to be doing it all in one programming language. Now the question then is which language and we chose Python for a couple of reasons. One, is that it's one of the world's most popular languages, it's as valid as any other. Two, is that it is the language that is spoken the most by the people who are suffering the most deeply with the problems of the web platform. Because if you've learned JavaScript, you probably learned it to tangle with the web platform, which means you've already invested a whole bunch of your career capital in being a web developer. Whereas Python is what you speak if you are a data scientist and your main career capital is being really good at statistics, but you are still going to want to put something online so that somebody who isn't you can use it. Meredydd Luff: You don't want to make your boss drive your Jupyter notebook for you, no. You want an interface with a button or dropdown to query your data or your model or whatever. Or you're a mechanical engineering person, you want to build like a test system for the machinery in your factory. You want to put a user interface on that. You are probably scripting this stuff together in something like Python, you do not want to spend two years becoming a full stack web developer just to put a UI on there that technician can click a button on. And so a lot of the people are feeling the pain most acutely, already speak Python. And the third of sort of the most... So the least important, but real design criteria in there was, if you are speaking JavaScript, if all of your advice is about how to do something in JavaScript, then when someone gets stuck, they are going to go to Stack Overflow and ask, how do I do such and such in JavaScript? Meredydd Luff: And the answer they will probably get, is going to lead them to pull in a DOM node or start touching some CSS, and now all of a sudden they've broken the abstraction and they've accidentally possibly without realizing it brought in all that complexity we were trying to save them from. And so it's not that Anvil doesn't have good interrupt with the standard web platform. Obviously, the web platform is huge. It would be like hubristic in the extreme to think that we can abstract over everything the browser can do, so obviously you need an escape hatch and Anvil has great JavaScript interrupt, you can just import Anvil.js and Anvil.js.window.something. You can interact with those things as if they were Python objects, but you do have to know you're climbing out of the escape hatch. Meredydd Luff: And one of the benefits behind having everything in this Python ecosystem is that, you know when you are climbing out the escape hatch, you know when you are getting some of the web on you. But let's say that is less important, the most important thing is that it's an approachable language, it's the world's favorite beginner language. And it is the language spoken by the people who are suffering most acutely from the problems of the web. Not everybody, I mean, we have a ton of people who are experienced web developers who go, "Oh my goodness, right? Well, I've timed myself. I can do this stuff literally 10 times faster if I don't have to mess with all this web stuff, give me, give me, give me." But if you want to pick the people for whom it's going to be the most obvious slam dunk, you do it in the language that they're likely to be speaking. Ben: Got it. Yeah, no, it all makes a lot of sense. I guess, what are your thoughts on some of the more modern JavaScript frameworks that attempt, I think, attempt to solve some percentage of the problems you mentioned? Like I'm thinking of Next.js and Blitz and Redwood, like the frameworks that take a more full stack approach, that leverage something like a GraphQL to improve on some of the things you were complaining about that are kind of more ref. specific, that use TypeScript across the full stack with types going all the way from your ORM to your frontend. I do feel like it's maybe not completely fair to say that the JavaScript ecosystem hasn't attempted and is not currently attempting to solve some of these problems in a really meaningful way. So I'm curious, like what your thoughts are there. Meredydd Luff: Yeah. So, I mean the front to back stuff, I regard that is a huge, possibly the biggest improvement of anything you mentioned, just the fact that... We finally have, I guess, not just JavaScript frameworks, open APIs is big here, that you could actually, finally in 2021, you can autocomplete what your backend API is doing. I mean, we had that in the '90s with Visual Basic and it's taken the web this long to get like the basic affordances of programming tools, but we're getting there. If you wear it all together just right and if your schema generation is working and your webpack tool chain is all wired together correctly, you can get to that place. I would still argue that you do have to crawl over quite a bit of broken glass to get there and you're still... Meredydd Luff: As with everything in the web, you're going to be dealing with a pretty leaky abstraction, in that even if you are using Next.js, which by the way, I have nothing against. It is great for like, for the reasons you can probably guess from the rant I just gave. You're going to encounter something where the abstraction slips and you are going to have to understand that your data is being mashed through all these different layers of stuff. Like GraphQL is a perfect example. GraphQL it's not how JavaScript thinks of things. It's not even quite how SQL thinks of things. It's done exactly what I talked about previously, it has swapped out one of those layers for something arguably better in exchange for which you've got to relearn a whole bunch of your web development stuff. Meredydd Luff: And also you are still having to think about how to express what you want to do in GraphQL, from code, and then how to interpret that into a query on the server side, and actually do something sensible with it. So I think my overall opinion is that it is the incremental improvement, it's a genuine improvement, but it's incremental and it doesn't actually get rid of most of the problems of the web. Sorry, that sounds extremely dismissive. Like it is genuine very cool, it just doesn't solve the same problems Anvil's looking to solve. Ben: Got it. No, totally fair point. I want to understand more how Anvil works. So could you take me through the stack, what does it look like to kind of build a basic application in Anvil? What are like the parts of that application? How does a programmer interact with Anvil? Help me understand all that. Meredydd Luff: Okay, right. So I can give you two versions of this and maybe I'll do them in sequence. I'll do like the stack from the programmer's eyes view of somebody who is building application with Anvil, and then the stack of, okay, what's behind the curtain? What is making that go? So, from the programmer's point of view, the easiest way to build an application with Anvil is you open up the online editor at anvil.works, it's free to use, so I would encourage you to give it a go. Blatant like that, let's go for it. You are in an ID. So this ID has... It's a classic ID, you can look through all the modules that make up your application. You will start with a form, which is a chunk of web UI. You'll be looking at a designer. Meredydd Luff: You can drag and drop from a toolbox of components onto that page and then you can flip between, at the top of the page, between design and code mode. And when you go to code mode, you are editing the Python class that represents the chunk of UI that you are editing. And so when you create a button and then you say, "Hey, I want to respond to the click event on this button." That will create a method in that Python class that gets called and it's Python, that Python is going to be transpiled to JavaScript. It's going to run in the user web browser when they launch the application. Meredydd Luff: There's a bunch of API surface, some of which we provide a lot of which is batteries included with Python available there, but of course a real application is going to need a bit than that, so you can also go to your application structure view and add a server module. And a server module is a Python module that will run on the server side in Anvil's serverless environment. So that is just an ordinary Python module with ordinary modules, classes, functions, what have you, but you can decorate a function, any function @anvil.server.callable. And what that says, is this function is something I should be able to call from the browser. So then you can go back to your browser and when the button gets clicked, let's say you want to do so something on the server, you could do, anvil.server.call. The autocompleter will pick up, "Hey, okay, you defined this server function, you want to call this one." And then you pass in arguments like an ordinary Python function call, you'll get a return value, like an ordinary Python function call. Meredydd Luff: And then on the server side, of course, well, world is your oyster. You're not compiled to JavaScript anymore, you want to do some machine learning, import TensorFlow, go. You want to do some data process, import pandas, go. You want to connect to some remote database, import call MySQL, go for it. In practice of course, a database is something people ask for a lot, so you can also add data tables to Anvil, which is a built in database. You could... There's a visual schema editor, you can create your schema, columns, tables, links between tables, and then you can access those. Meredydd Luff: It's an object based database so you could do app_tables.users.search and that will give you a lazy Python iterator of objects each of which represents a row on the user's table. And it's like a Python dictionary, you can live update those things. You can return one of those objects from your server function to the client. And then you can display the row from the database in your UI. You can interact with it. You can have text box that changes it, or you can use data bindings or the usual stuff that you'd expect for editing data in a user interface. And you haven't had to sort of serialize this stuff. It uses a capability model so if your server code has returned one of these objects to the client, that means the client has access to reed the thing. You don't have to do a lot of configuration. It is mostly just writing vanilla Python. Meredydd Luff: Then on top of that, you can add a bunch of services. So there's built in user authentication for... "I want users in this application. I don't want to implement this myself for the 13th time." You know, secret storage, integration with APIs like Google or Stripe or Facebook or Microsoft, or what have you, but that's the basic of it. And then when you have built your application, you can hit a run button and the application will launch live in the IDE with a live console where you can execute code inside it and see the printout and so on. If it's working, you can then hit publish, choose a URL, and your application is live on the internet. There is, of course, if you want to carry on editing it, then you might want to publish a specific version of your apps, so you'll pop open, the version control history, which is actually an interface to Git because of course it's a Git repository. Meredydd Luff: And tag this particular version is what's deployed on this URL, or even this version is deployed on this URL, but that version is deployed on staging URL and they use two different databases. It just the ordinary stuff you would expect from deploying an application. So that's from a programmer's point of view, what using Anvil is like, you open the editor, you construct your user interface, you write your code, you write your service side code, you can call them as an ordinary Python function call. You can build a database, you can access that database. You can throw those live objects around, and then you can publish it. Ben: I'm curious to hear more about, I'm just really digging deep, I guess, on the technical side of things like that transplantation that happens in the browser. So my first question is, how does that work, is that something you built or is that something you leveraged that existed in the open source world? And I'm curious like, are there any limitations to what you can do in Python that is transpiled to run in the browser like, can you pull in anything off a pip or third party modules or are there some limitations to be aware of? Meredydd Luff: Oh yes, you asked the right person about this. So not only am I one of the original authors of Anvil obviously, I am one of the maintainers of the Skulpt Python to JavaScript compiler, which is what we use. So before I dive into that particular thing, let me give you sort of overall architecture of the sort of the implementer's eye view of how Anvil works. So if you want to investigate further, like it's on GitHub. So everything that I'm waving my hands at is something you could go inspect. So the Anvil runtime operates as a web server, you will go to it, it will serve up your application. So Anvil uses the Skulpt Python to JavaScript compiler to compile your server side, sorry, your client side code to Python so that any forms you have and also any modules you've written that can be imported on both client and server. Meredydd Luff: That will then run in your browser as JavaScript, and then the server also takes care of feeding of this serverless environments of when you make a call spinning up the Python interpreter with all of your code in it, and then directing the calls from the browser, which go down our WebSocket to running the appropriate piece of service side code. It's all sort of an RPC mechanism for, the function call is the primitive of an Anvil application. So to walk into the client side code specifically, so skulpt was an existing open source project when we started, I mean, when we started playing with the project that would eventually become Anvil and we sort of ceased it with both hands and went, "Oh, this is great." And immediately started contributing to it, which is why I'm one of the maintainers one of our engineers is also another of the maintainers and we've worked with many of the others. Meredydd Luff: So there is... Obviously, you're going to be limited in what you can do in the browsers if you're transpiring to JavaScript. This is one of the funny things about Python actually, because Python as a language and as an ecosystem and as a community prioritizes simplicity, which means that the average Python programmer writes, doesn't really push the language to which edges very far, it doesn't use any funky meta programming magic. It generally sticks us straight and narrow and does stuff, but the Python ecosystem is bananas really. You will find them doing all sorts of fun things. In particular, Python makes very heavy use of native code in a lot of its popular libraries, which is obviously a problem if you are running in the browser, because you can't just like import a module written in C. We have had the usual sort of the spit ballings at conferences about, "Hey, we could totally implement a pipeline for like cross compiling this stuff into WebAssembly and then implement the Python foreign function interface in the browser. Meredydd Luff: And that would be pretty cool. But at that point, you are kind of converging on the Pyodide design, which is if you haven't encountered, it's a great project originally out of Mozilla, which is like a Jupyter notebook, but it's running entirely in your browser. So you go to the thing, it will download a Python interpreter, full C Python interpreter in WebAssembly, and a whole bunch of your classic libraries, your Panther, your SciPy, your Pyona, your TensorFlow, and then SideKick. Whats the one? No, come on. The graph plotting one, that's alluding me because I'm on a podcast in my brain has stopped. Meredydd Luff: And that is really, really great. But the load and pass time for a Pyodide instance is like, is measured in seconds you may or may not be able to count on both hands and if you are doing data science in an environment you don't mind loading, that's fine. If you're trying to build a web application for civilians to use, that's not really fine. And so that's not really a direction we particularly want to go, like if you are doing heavyweight computation in an Anvil application, the right answer is to take it to the server, do the computation there, take the results back. And because it's just a function call, that can actually be really, really easy. So the short version of that rather long answer is that, it's really easy to write the sort of ordinary Python code that you might write in the browser in Anvil. But if you want to use a lot of the ecosystem, well, that's what the server is for, because it turns out that they use all sorts of hairy, interesting things that don't really make a lot of sense in a web browser. Ben: So tell me a bit about building GUIs. If I saw correctly, Anvil kind of helps you on the GUI side, constructing like an interface. So yeah. What does that look like? And because that's obviously always one of the harder parts of kind of... When you're trying to build an application quickly, the UIs generally one of the slowest parts. So how does Anvil help there? Meredydd Luff: Okay. So how does it help drag and drop user interface builder, but like what is it actually? So what we implemented was a UI toolkit in Python. So you can of course build this stuff entirely from code. There's no need for you to use drag and drop designer. You can say, "Hey, I would like a grid panel with these column spacings and I would like to add it to my page and then I would like to add a text box from columns one to two, and then a label underneath it from columns three to four" or whatever. And you can absolutely do that. And for some applications that does make sense, especially for very regular user interfaces that you might want to create programmatically, but for a lot of your ordinary work a day, I would like something here, the drag and drop editor really does help, but because... Meredydd Luff: The drag and drop editor doesn't produce anything you couldn't have produced with the UI framework. It's an accelerant rather than a replacement for Dewey programming, per se. There's a few things that we have built into the editor specifically for speeding up. For example, a common pattern is, "Hey, I want to display a collection of things on the screen." And so there's a repeating panel, which is a thing that you can give, like any Python iterable object, and then you tell it what form, what chunk of user interface it's instantiating, and then it will instantiate one of those for everything in that list. And that part can, again, can be configured visual so if you want to do, "Oh, hey, I would like a data grid to display rows from this database." Meredydd Luff: That is like a two line of code operation, get it from the database. Chuck it into the item of the data grid and you can define the rest visually. But again, when you define the rest visually, I'm talking about data bindings. And again, what Anvil calls data bindings are very straightforward assignment expressions, right? This is the equivalent of self.text_box_1.text = self.row()name. And you can write that code very happily in the Python that's going to run the client or you can use the user interface to accelerate building that stuff. But I think the key principle here is no magic. Ben: So Anvil is open source, correct? Or is it entirely open source or only parts of an open source? Meredydd Luff: The Anvil web framework is open source. The hosting platform at anvil.works is a freemium product. So you could use the builder for free, but if you want to deploy applications with it and you want us to host them for you, then you can use it for free up to a certain amount, or you can pay us for hosting capacity. The framework itself being open source, means of course you can opt out of all of that and say, "Actually, no, I'm going to use my own server for this." You can even build your application with the online editor, just git clone the repository onto the machine, and then launch a standalone server, which you can get with pip install Anvil App Server, anvil-app-server--app. Launch of current directory as an Anvil application done. Meredydd Luff: And we tried hard to make that process as seamless as we possibly could so the Anvil app server bundles the Postgre database that serves the applications data tables, it bundles the traffic, a reverse proxy so if you bring it up and say, "Actually, my origin is HTTPS myapp.com." It will go and letsencrypt and fetch you a HTTPS. Oh, sorry, a cell certificate for that domain. So we really do... This is not the unwanted cousin of the ecosystem. We do in fact, try to make this process very easy. So you can, pip install it. You can host the application yourself, or you could go to GitHub and grab the library that is the Anvil run time, and then build what you want to do on top of that. We have a hosting service that's obviously, that has a whole bunch of stuff that's like multi-tenancy and integration with our hosting environment and with the editor and so on. That is not open source, but what we are is basically, that is a commercial development environment for the open source framework. That is Anvil. Ben: Curious to hear a bit about your long term plans. What are you most excited about for the future of Anvil and what can Anvil not do today that you feel like is important that you're excited to launch maybe in the shorter term as well? Meredydd Luff: So something that I'm particularly excited about right now, is that as our customers, as people who've used Anvil to build products, and by that I mean been both sort of startups launching new product and companies building internal tools that are gaining greater adoption within that company, as they grow and become more sophisticated, they have a bunch of desires that really aren't shared by people who are prototyping. Anvil is already and has already been for some time, a great environment for prototyping. We are really excited about a bunch of stuff to make life in production a little bit easier. So possibly by the time this podcast goes out, in fact, we are looking to launch some features around observability. So just like going and seeing, "Hey, my app running in production, what's it been up to? What has been running? What has been taking the CPU time? Where have my problems been?" That's going to be very exciting, and again, a lot of what we do is we take something that is possible, if you put your career capital into being that kind of engineer and making it just a single click accessible to somebody. So like configuring a tracing engine for a deployed web application is like, it's a little bit of a ride. Again, it's got a lot easier in the last few years, but still a little bit of a ride. Whereas the idea with the hosting service is it's just there for you. And we are tracing your application at all times for you so that you can do some sort of interesting features on top of it. Meredydd Luff: So that's one thing I'm really excited about. The other direction I'm really excited about is working on those users who are just taking their first steps and the experience for them. There's a lot we can do still to make it easier to go from, "Hey, I've learned to code a little bit." To, "Here is this application, it's live." And that's a big jump even if you have a framework that's giving you a lot of help. And even if you're only having to learn one program language and all this stuff. And we have some fun things, we be doing a lot of proper user research. And I mean, my PhD is in building usable programming systems and I co-founder Ian's Is it Human Computer Interaction. Meredydd Luff: This is, we get to sort of actually crack our fingers and break out the power tools on this one. And we have some things that should be able to make that process an awful lot easier. The final one is I think going to be in design, because you were absolutely right in honing in on like the difficulty of building a GUI and this is inevitable. This is something I've come back to a few times in this, that you can't abstract over everything. People are going to want to do the advanced thing that the platform permits and if you stop them, you've just killed their project. So everything that is dragged onto the page or created in code, you can of course access as a DOM element. Meredydd Luff: You can, of course go into the CSS that styles it, like Anvil has a theming system and the themes that you can apply to your applications are defined with HTML and with CSS. And that is like, it's great. And we've been really impressed by the things that we've seen people create. And the thing that warms the cockles of my heart most is when we see somebody who started as, "Well, I know a little bit of Python." Swears up and down they're not a developer really then goes to, "Okay, I have a app that's actually running in as a prototype. Okay. Actually, it's running in production. We have customers using it. Okay. We want to Polish this up." And they like go, "Okay, well, I better investigate the CSS thing." And then you look back on them a month later and you see the screenshots of their application and you go, "Whoa." Because if you make it possible to do the basics with a very small amount of knowledge, you haven't restricted them from gaining more knowledge, you've just made it so that they didn't have to do that just to get on the bus. Meredydd Luff: And that is really exciting to us, but that step still did involve like learning a new programming language effectively. And we would really like to do two things. One is to make that process a lot easier, like the on-ramp to, "Hey, you're about to tangle with some of the lower level of bits of the web platform. Here is a better experience than what we're currently giving you." And the other is to kind of push that boundary out a little bit further to increase the number of things that you can do, style and design wise, before you have to throw in the towel and learn CSS. And obviously, that is a constant battle. It's one that you will never win completely because the browser is an incredibly complicated platform, but we are really excited for what we can do to like to push even further what you have to do before you start taking the next step, not as a way of preventing people from scaling up, but as a way of enabling people to get something done without having to stop and do that work. Ben: So you've touched a bit throughout our conversation on kind of the... It seems like one of the goals of Anvil is to make it easier to build web apps, make programming more accessible. So why is that something that's so important to you and why invest in solving that problem? Meredydd Luff: So this is a little bit of a hobby horse of mine, because back in the '90s, I got my start in programming with like QBasic and Visual Basic. And it was incredible. I mean, programming is magic at the worst of times but with those tools, you could learn a little bit of code and you could be producing applications like everything else on your system that were Textured Graphics and DOS or that were windows with menus and buttons and so on, in Visual Basic. And you could get going so fast and I think that's what really kindles this, "Oh, my goodness, this is the best toy ever. This is what I want to be when I grow up." And since then, as a species, we have built the best application delivery platform on earth. I mean, it's astonishing. Meredydd Luff: You can build something and anybody in the world can use it right away. Like that is jaw dropping. But as well as doing that, we just lost everything we had in something like Delphi. We set up this barrier and you said you must be this tall to ride this ride. And this tour is like five different programming languages, five different frameworks, a whole bunch of DevOps. Did I mention Git? Did I mention Docker? Oh yeah, you need to have UX system administration, because from time to time there's going to be a big fire alarm, like we've had over the last week or two with log4j, and you're going to have to know an awful lot about what's underneath your stack. And if you don't, it's going to bite you. And the magic is there, but we're making people climb a mountain to get there. Meredydd Luff: And this is like, as someone who had such an easier ride into development, I feel like it's a bit of a stain on our profession and it a thing that's bugged me forever. And at a certain point, Ian and I just snapped and said, "Okay. Well, someone needs to fix this. It might as well be us." So it's really about accessibility. And it's about accessibility in the full sense of the word. If I went out into a conference and I asked, "What does accessible developer tooling mean to you?" They might say, "Oh, it's easy for novices to get started with." And they wouldn't be wrong because that is important because it is kind of embarrassing that the novices can't actually do anything that looks like a real application for a really long time. Meredydd Luff: But those aren't the only people who are getting a disservice. If you build something that's only for novices, this is where a lot of this low-code stuff falls down really hard. If you build something that's only for novices, if you chuck them into a playpen in the corner, then you don't give them the scope to grow their powers, because today's novice is tomorrow's intermediate, is a few years down there going to be the wizard, that's how they get in there. And so if you make the Duplo bricks for them, you're doing them a disservice. But you're also doing a disservice to the experienced professionals because just because I can write five different programing languages doesn't mean I want to, and it doesn't mean anybody wants to wait for me to do it. And again, the real accessibility is something that's simple enough for novices and powerful enough for the seasoned professionals. Meredydd Luff: And again, this is where maybe the Python background helps because anybody who works in Python knows this in their bones because they work in a language and an ecosystem that is the first thing you give like an eight-year-old with their first raspberry pie, "Here, try this Python Program. It'll make an LED flash." And by the time that kid gets a few years older and they're on Instagram the entire time, "Hey, guess what powers the entire backend of that Globe, describing service. It's great big Django app." And it is possible to be powerful enough for seasoned developers while being simple enough for novices. And again, like it's not like that's an impossible goal, it's just something the web doesn't do yet. So yeah. Accessibility, it's important. Ben: And why the open source business model? Like, I mean, it's certainly one that a lot of developer tools adopt, but I'm curious like what crystallized that decision for you to build open source with a paid component on the side? Meredydd Luff: So, I mean, fundamentally developers are control freaks. Part of the magic is that we have this machine and we can make it do whatever we want. And so like if Anvil was, and like when it first launched, that was what it was. If it's this hosted only service that you could interact with, but you can't really get into the guts of it. And if it goes away well, that's it, you're out of luck. That is something that's going to not fit very well with the way that a developer wants to interact with their computer. And so that's what we would want to do. As I said before, I'm sort of building this in part for the imaginary me who was just getting started. I want to give "past Meredydd" as good an experience getting into this development thing and becoming productive quickly as he got, because he happened to have been born at the right time to do this in the 90s. Meredydd Luff: Imagining myself back then, I would want that control. That's what I, as a user would really want, is to have, "Hey, I have all this power, but it's actually all under my control." Really it's open source. A meteorite can strike Cambridge and we will be fine. I know I can grab it off GitHub and whistle and carry on going. And that, I think that part it's yeah, it hits the control freakery at the heart of software development. It's what I would have wanted back when this would've been a really great product for me. I mean, heck let's say if I didn't build Anvil today, I would probably use it. And the Meredydd today would absolutely demand an open source solution. And it feels good from the inside, the company we really want to build is the one that builds commercial development tools for an open source framework. That feels like, it feels right in that intuitive sense that governs so much of the design of everything a developer deals with. Ben: Meredydd, thank you so much for joining us today. It's been fantastic to learn about Anvil and to hear about not only why you built it but the philosophy behind it, how the importance of making coding accessible. So yeah, really appreciate your time. For anyone out there that wants to learn about Anvil or check it out, the URL, I don't want to get this wrong, anvil.works. So anvil.works, go check it out, or imagine you can search on GitHub and find it that way as well. And we will put some links in the episode description as well. So yeah. Thanks so much, Meredydd. Meredydd Luff: Thank you very much for having me. It has been great fun. Please do go check it out. Please do jump on the forums. Tell us how you found it. It is free to you use. Thank you so much for having me. This has been great. Brian: Thanks for listening to PodRocket. Find us @podrocketpod on Twitter, or you could always email me even though that's not a popular option. It's brian@logrocket.