Programming Throwdown - Episode 113 - Full Stack Web Apps Using Only Python with Meredydd Luff

Episode Date: June 2, 2021

In this episode, we’re excited to have Meredydd Luff, the founder of Anvil. Anvil is a powerful tool that allows you to build full stack web apps with just Python. Without the need to be fluent in Javascript or other languages, Anvil is easy enough for beginners, but robust enough for professional work. We talk to Meredydd about Anvil and its features, as well as delve into the importance of making programming more accessible to more people.This episode touches on the following key topics and ideas:00:00:17 Jason introduces Meredydd and Anvil 00:01:06 What is Anvil?00:09:27 Web hydration00:11:00 Jupyter Notebook00:12:49 The Uplink00:14:02 GraphQL00:23:06 How Anvil works00:24:19 Skulpt00:28:09 Brython00:29:04 Pyodide00:32:46 Javascript daisy chaining00:37:11 GRPC and protocol buffers 00:39:03 “Anvil is an abstraction.”00:40:09 Escape hatches00:43:10 Anvil and Webpack00:44:35 “Learn Python and build a website.”00:45:02 Accessibility00:47:16 Meredydd’s personal background, and Anvil’s beginnings00:52:56 Putting your work out there00:56:01 Logging and capturing what people want01:01:06 Ad: ConfigCat01:03:04 Anvil’s parent company, The Tuesday Project Ltd. 01:05:22 Meredydd’s take on venture capitalism on developer tools01:08:42 Working in Anvil01:17:02 Contact details for Meredydd and AnvilResources mentioned in this episode:ToolsAnvil https://anvil.works/Python https://www.python.org/Jupyter Notebook https://jupyter.org/GraphQL https://graphql.org/Skulpt https://skulpt.org/Brython https://brython.info/Transcrypt https://www.transcrypt.org/Pyodide https://pyodide.org/en/stable/VideosMeredydd’s Lightning Talk in PyCon 2017 https://www.youtube.com/watch?v=IHUw3N15v38Turning a Jupyter Notebook into a Web App with Anvil https://www.youtube.com/watch?v=yh0B4HjQxOUPodcastStories from the Workshop, Anvil’s podcast https://anvil.works/podcastCatch Meredydd on Twitter @meredyddAnvil’s features are offered completely free for teachers and educators. Send Meredydd an inquiry through email at [e-mail] ConfigCat: https://configcat.com/Get Audible: http://www.audibletrial.com/programmingthrowdownIf you’ve enjoyed this podcast, you can listen to more programming news and updates like this one on Programming Throwdown’s website: https://www.programmingthrowdown.com/, or send us an email at [e-mail] can also follow Programming Throwdown on Facebook | Apple Podcasts | Spotify | Player.FM You can also help support Programming Throwdown through our Patreon. ★ Support this podcast on Patreon ★

Hey everybody! This is a super, super exciting episode. using only Python with Meredith Luff. Take it away, Jason. Hey, everybody. This is a super, super exciting episode. I can't tell you how many times I've gone into Google and typed in like Python GUI because as most people know, I do a lot of machine learning. That's my day job. And I do a lot of it on the side too for fun.

And I always want some way to visualize things. I'm always looking for new ways to do that. And so I'm really excited that we have Meredith here, who's the founder and CEO of Anvil. And he's going to talk to us about how Anvil, how you can use Python kind of all the way through the full stack. So thanks.

So glad to have you on the show, Meredith. Thank you very much for having me. Cool. So yeah, there's a lot to unpack here. Why don't you kind of talk about what Anvil is, and then we can dive into a lot of the details. All right. So Anvil is a development environment for building web apps quickly and simply. And it does that by letting you use Python everywhere. So if you jump into the Anvil editor, you'll get a drag and drop UI creator where you can build like component based UIs. And then if you double click a button, now you're editing the Python code that runs in the web browser when you interact with that UI. And then you can also write some server code and build the database and add all sorts of external integrations, user authentication, that sort of thing.

And then, you know, click and publish it in a kind of serverless sort of way. So maybe the best way to think about it is if you think about those old school rapid app dev tools we had like at the end of the desktop era it's like visual basic and delphi it's like that for the web oh i see so so the um if i remember those tools basically you had this kind of whizzy wig like editor and you could kind of drag and draw buttons you double click on them and it kind of takes you to some partially auto-generated code? Yeah, exactly that. So what it means is that you can build your user interface without having to get down and dirty into the HTML and CSS instantly. It's real programming. This is not one of those no-code things because you're actually writing real code in a real programming language, Python, that runs in the browser. We compile that to JavaScript, and we can talk about how we do that later if you like. And then rather than having to

deal with the HTTP and routing and REST endpoints and all that stuff, you can just say, okay, I'm going to define a Python module, it runs on the server. And then I'm going to tag these functions as something we can call from the browser. So what we've done is we have taken the web stack, which is actually really, really complicated and forbidding. And we've turned that into all one representation. So if you think about an ordinary web application, if you've built these before, if you think about your data, like an ordinary database-backed web application, your data starts out as rows in a table in your database. And then the first thing you do is you take them out and you transform those into objects in your server-side code, whatever language that's in, maybe Python.

And then you immediately turn around and represent those objects, which have their own methods and attributes. You turn those into JSON served over HTTP with this really limited set of verbs like get, post, put, delete. And on the other end of that HTTP request is some JavaScript that immediately transforms that JSON into a JavaScript object with its own set of methods, its own set of attributes. And then you turn around and you represent, re-represent that data as HTML DOM. And then you use CSS to re-represent it as pixels. And that is the day-to-day work of web development, is shoveling your data and your application's state between these different representations. And we thought, it's not difficult to work out that this is way, way, way more complicated than it needs to be.

Have you ever looked at one of those? There's this really great chart on GitHub, like, you know, these are the basic technologies you need to know to be a web developer. And like, it's just like pages and pages and pages and pages of stuff. And it's all kind of wired together, and you need to fit these, you know, 20 different components together. And we thought, well, if it were all just a Python program, if you could just, if getting from the server to the client wasn't a matter of mashing things into JSON, it was a matter of making a function call. If putting something on the screen wasn't a matter of generating source code in one programming language that templates a different markup language that is then transformed into pixels by a third language, and they all kind of work together,

and you squint and you get something on the screen. If we could replace that by put a button there, and then make its text be such and such. If we could replace the process of standing up a machine on AWS and setting up a web server and setting up the front end and standing up a database with, well, hey, here's this serverless hosting. If we could do all of that, suddenly creating a web application is no more complicated than writing a Python script. And frankly, that's where it should be. There is no reason that the greatest application delivery platform on earth should have the bar set that high for, like, you must know these five different programming languages before you can ride this ride. You must know HTML and JavaScript and CSS and Python and SQL and React and Redux and Bootstrap and Flask and SQL Alchemy. And that's before we've even got to the DevOps stuff. That is not

necessary complexity. A web application where you click something and something happens ought to be as simple as writing the equivalent Python script. And we set out to make that happen. Yeah, it totally makes sense. I think a lot of the open source libraries, and this is true in general, but especially for web, they're built by companies that have gigantic websites. I mean, I have websites that are, you know, the code base is enormous and the throughput, the QPS is enormous.

And so, yeah, if you have a gigantic, you know, massive organization of people, then it kind of makes sense. You know, we'll have sort of people design a sort of GraphQL server, and that's going to be, you know, whole teams of people working on that. And then there's a whole bunch of other teams of people consuming that. And it's all sort of decentralized, right? But the problem is nothing starts that way, right? Like nobody goes into the first iteration of their company, and they're trying to find product market fit, and they have three customers. And they're, they're, they're like, you know, stressing

about their GraphQL throughput, like, it just doesn't work that way. And there's not that much visualization for people who are, you know, wanting to get started quickly. I totally agree with you. But I would take that analysis even further. Even those huge high throughput guys, the web isn't the architecture they would have chosen. You just mentioned several different technologies that are actually about taking the primitives that the web gives you, which basically they were organic. They kind of grew up over the early 2000s. Now we're stuck with them and turning them into something that these hyperscale people can use. Things like GraphQL is literally a solution to the problem. Oh, wait, REST is not a good way of representing our server-side APIs. Guess we're going to have

to build something else on top. React is HTML DOM is not a good way of representing our server-side APIs, guess we're going to have to build something else on top. React is HTML DOM is not a good way of representing our UIs, guess we're going to have to build something else on top. All of this stuff is patching over the web, patching upon patches upon patches to try and make it a usable development environment. And that is as true when you are these incredibly high-scale people building funky GraphQL backends as it is if you're a data scientist who just wants to be able to select from a dropdown and then draw the appropriate graph on the screen. Actually, almost everybody who's using the web is suffering from these problems in some respect. Having said which, of course, you're absolutely right that these are the core customers we're starting with first, like the sorts of people

who go, well, I just want to put a button here and draw a graph on the screen, or I want to prototype my product. And those are the people we can really say, hey, there is in fact a better option. Here's how you can do it 10 times faster. Yeah, it makes sense. I think you really hit the nail on the head that the whole HTTP invention was for just server-side rendering. It's for just dropping almost like a printing press, right? It's sort of like we just give you this sort of structure and you just drop it onto your screen. And then obviously the web is totally different now. Now things are sort of hydrated and the hydration for a lot of websites is everything. Like there's some websites that

if you don't have JavaScript on, you just get a blank screen or something, right? Yeah. And there's nothing wrong with that architecture, right? It's just like your classic thick client architecture. You have this runtime so you can have fast responses and fast interactions on the device you're actually using. And then it talks to a server and that server talks to a database. None of that architecture is actually bad. What I would assert is unnecessarily difficult to use is the particular way the web has evolved around that. Because just like, yeah, exactly what you said, because it's evolved over this document-based substrate, it's kind of, at every point, it's done like the minimum required to hack this

next piece of functionality on. And so you end up with this mess that's really, really difficult to approach. And, you know, there's no reason that a beginner or a data scientist or someone whose experience is somewhere else, like, you know, manufacturing engineer should have to learn all this amount of stuff just to be able to, you know, produce an interactive screen. Yeah, exactly. I think, you know, this is even true for, and this is going to be a bit of a tangent, it was even true for desktop. I think this is one of the reasons why, you know, at least for data science, you know, this Jupyter notebook has been so popular because, you know, it took all the painstaking time and effort to do that. But then you're kind of limited to whatever

supported, you know, by Jupyter. Ideally, you would have, as Anvil is, a programming environment which is much more open-ended. Well, funny you should mention that, actually. Because yes, absolutely. Jupyter is a fantastic piece of technology. And the way that it's got back this kind of cell-based interactive programming is a really great fit for a lot of data science tasks.

But as you say, it's fundamentally just a Python script. And so there's limits to what you can do in terms of interactivity. We actually have a library that can connect a Jupyter notebook to an Anvil UI. So because this is a problem, again, that keeps recurring, because there are a lot of problems for which actually, you know, just writing a Python script is the right answer. And then you go, oh, well, true, but I would like to connect this to a web UI. So in your machine learning work, I'm sure you will have done a lot of this, right? You are in there, you've got your nose in a Jupyter notebook, you are training, designing, training, refining a model. And then you go, okay, okay like i've got this thing working i'm at the point where

actually i've gone as far as i want to go by interactively typing python into a programming environment now i want someone else to be able to use it i would like to you know be able to put some interactive visualization on it i'd like to stick it up there so you know i've got an image recognizer and i'd like someone else to be able to come along and take a picture with their mobile phone or upload something from their computer. And what we've actually got is something called the uplink, which is a library you can pip install anywhere you're running a Python script. And it makes a connection up to the Anvil servers. And then your Python interpreter, wherever it is, say inside your Jupyter notebook, it's like it's part of that app. So you can access the data tables in your Anvil app with exactly the same API as you could if you were running in our serverless environment.

You can call functions in that serverless environment. You can even define those callable functions that can be called from the webpage. So, we have a neat demo, perhaps we can drop a link in the show notes, of taking a Jupyter notebook that does an image recognition task, and then going, well, okay, now I want to turn this into a web app, import the library, take the function that takes an image and returns the classification, tag it as, hey, this is a function we want to be callable from the browser. And then just going into the browser, having a file uploader, when a file gets uploaded into that widget, anvil.server.call, classify image, pass the file in and get the return value. It's just a function call. It's just Python. It just works. So yeah, we have something for that.

Yeah. Yeah. I think that that makes a ton of sense. So I'm trying to think like, I think you did a good job explaining kind of the sort of traditional web development, right? And just just to kind of reiterate, actually, I didn't really explain what GraphQL is, and rest. So let me cover a bit of terminology. And then we can dive into into how Anvil, you know, works, right? Yeah, so typically, if you're on a website, your browser's running this engine called JavaScript. Programmers can go in and write things like change colors of buttons, add content that wasn't there before, things like that. And the way that it does that is by running this JavaScript engine in your browser, but

often it needs to go back to the server and get more information, right? Maybe someone sends you a message and you have some, you know, IM thing on your, some IM website that needs to be interactive. So, you know, it's constantly going to the server and saying, hey, is there something new that I need to know about? And the way it does that is by basically visiting websites that are just meant to return data. So if you go to google.com, you're going to get this rendering, but there are other websites. If you go to them, you're just going to get a batch of data. And most of the time, people are doing JSON as the transport. So you're going to get some actually human readable, I guess. I mean, it's usually like a mess, but you're going to get something in characters that

you can see that's going to represent some structured information, right? And so if you were to build a, you know, let's say, I don't know, old school, if you were to build an old school kind of interactive website, you would have a bunch of, you'd have your main website, you know, mycoolwebsite.com slash, you know, index.html. But then you'd also have, and you'd also have your images and all of that. Each of those would be URLs and the server would know where to go to get those. And then you'd have all these other URLs that just return data. And presumably they have logic behind them. So they're going to return different data when you call them, depending on the context. There's something else called cookies,

which is think of cookies as like a really small database that your computer and the server are sharing for your connection. And so the cookies are a way so that when you go from one page to the next, you're still logged in every time. But this was a huge pain. It's like I have to make a URL for every piece of data I need. Like, give me the current time. Tell me how many friends I have. Tell me all my friends' names. Well, and crucially, when you clicked to go from one of those things to the other,

your whole page refreshed. You were staring at a little bit of white screen while the next whole page downloaded. Then it showed the next whole page to you. And the web was advancing and we wanted to be more interactive. Yeah, that's so true. So then we get to the sort of single page apps where, you know, it's even fetching not only just data and HTML, but it's actually kind of fetching new HTML and kind of building as it goes. And then, but you're having all these URLs just because it becomes really cluttered. So this GraphQL was this idea that let's just have one URL,

but you'll pass in, you know, a specification that says what you need. Kind of like when you, you know, write SQL queries, there's only one SQL engine and the query just tells the engine to do different things. So with GraphQL, there's only one URL that you go to for all your data. But by passing in different, almost like different queries,

you're going to get back different pieces of information. And so that was better, but it still has this challenge that Meredith talked about where GraphQL does everything in this thing called JSON. And so if you want to pass an image, for example, in GraphQL, you actually have to convert that image into letters and then send it to the client and then turn it back. And so it just becomes a huge hassle to represent everything in this way and then just to turn it back into something that you're going to render well and also the the fundamental structure of a web application is that your browser goes to a site and your site serves up the source code for

an app that will run in your browser this is is how it mostly works these days. And then the browser is running an application that's built with JavaScript and HTML. And then when that app running in your browser wants to get some kind of data from the server, it will make an HTTP request to the server. And there are various conventions for how we use those requests to get data instead of HTML. There's sort of, you could have a URL for everything, which is the REST pattern, or you can have something like a GraphQL where you have one URL that you post this complicated query to, and it gives you back some complicated response. But all of this is being squeezed over HTTP requests, which is exactly the same thing that your browser is using to fetch the

web page in the first place. And HTTP is a great protocol for fetching web pages. It's not necessarily a great protocol for doing what your application actually wants to do, which is that the part of your code that's running in the web browser wants to talk to the part of your code that's running on the server and do something that's, well, do something that's part of your application. And if this were an old school desktop application, you'd just make a function call. And you'd be modular and expose a certain API. Oh yes, the GUI section calls the backend engine for these things. And these days on the web,

whether you use something like REST or whether you use something like GraphQL, you're kind of twisting the way your app thinks about the world until it's shaped like the way that HTTP thinks about the world. And that's just an amount of stress that as a programmer you don't need. And this is why in Anvil we have,

you can still use those. So if you already have an API that's built in REST or GraphQL, you could absolutely use it with the standard HTTP stuff. But the usual way of communicating between the bit of your app that's running in the user's web browser and the bit of the app that's running on the server is just to make a function call.

And you can pass arguments to that function call. You can get return values to that function call. Unlike a classic JSON API request, you're not limited to just dictionaries and strings and numbers and lists. You can, I mean, in the image recognition example, you can just pass a blob of binary data that was uploaded as a file from the computer. You can just pass that as an argument to the function and Anvil takes care of taking all that large lump of binary bytes from your browser to the server and putting it into a form that your server-side code can easily

deal with. And this is just one example of how twisting your application's logic into the shape that the web stack expects is just making you do unnecessary work. And we've done the same in the client, where instead of generating HTML, which is kind of programming language all of its own, you can say, well, actually, the thing I want to do is I want to add a UI component. And so we have this object oriented thing where you could just construct an object in Python. You could construct a button object, set its button one dot text equals blah, self dot add component button and put a button on the screen. And that's, again, it's not making you twist what your application is doing into the shape of what the web platform is expecting. And so that is, I think, the crucial theme that runs all the way through

AML's architecture from top to bottom. And doing function calls instead of REST or GraphQL is just one example of that. Yeah, it totally makes sense. I think too, if there's this extra benefit where if you're already using Python for a task, if you have some Python program and you want people to see it on the web, or you want to write a web visualizer, then without using Anvil, everything you want to see has to be represented in JavaScript. So now it's like you have to have sort of your Python representation of all this knowledge. And then you have to have this JavaScript representation, and you have to constantly be converting from one to the other.

And so, yeah, that ends up taking a huge amount of time. And it can actually be really difficult. I mean, JavaScript wasn't designed to handle binary data. Now they have a whole bunch of cool things for it. So, I mean, it's definitely evolved to meet the demand. But yeah, it's evolved rather than being designed is sort of the point. Exactly. But yes, exactly that.

So yeah, let's dive into the magic here. I mean, it seems pretty magical that someone, you know, we just told people that you can only write JavaScript in the browser. So somebody, you know, so someone's writing some Python. And so I think you said that they're annotating some functions and saying, oh, these are server endpoints. And I guess there's maybe like some Python files that are running in the browser.

Some are running on the server. Like how does all of that come together? All right, yeah. So here's what happens. When you open the Anvil editor, you've got, you know, it's a standard IDE type layout. You've got a list down the left of your modules. And there are two sorts. There are client modules, and then there are server modules. And whenever you're editing client code, which

includes these pieces of a user interface that can appear on your page, there are also client side Python modules. They're just Python classes, actually. Everything is a Python object. We try not to be magical about this part. But when you write code that runs on the client, Anvil will actually translate that from Python to JavaScript. So when someone visits your application, what they load is actually a Python runtime written in JavaScript. It's called Sculpt, S-K-U-L-P-T. It's a really cool open source project. We contribute heavily to it. And that is the kind of the translator that allows you to run your, turns your Python code into JavaScript code that does the same thing. And so when you click on that button, what's actually happening is that a JavaScript function is running, but that JavaScript function

was created from the Python code you wrote. And when you call something that's on the server, so you say, if you do anvil.server.call, which is our library function for this, that's Anvil's queue to send a message to the server. And it then goes and talks to Anvil servers, which then spin up your server modules, which are the Python modules that you created in the section that's, no, this doesn't get sent to the web browser. This only executes on the server and loads all of those modules. And then any functions that you have annotated with at anvil.server.callable are accessible. And so when the request comes in and says, I want to call the classify image function, then we look up and say, yes, there's a function called classify image. Yes, it's tagged as accessible. So we run that function. And then when that

function returns something, we will send a message back to the browser saying this function has completed and here was its return value. And the Python code that's running in the browser gets that as the return value from anvil.server.call. I see. I think I get, so let me, let me see if I can reiterate it and I'll, that'll figure out if, isn't that one of the, what's the, what do they call that? They say, if you can reiterate something, then you understand. I don't remember the word for that. But yeah, so... Okay, so the idea is...

Actually, so what is getting sent to the client then? Is it Python files that then are being executed by this virtual machine? Or is it being compiled somehow? So it is actually... What gets sent to the browser is a Python source code and a Python to JavaScript compiler and runtime. So it actually gets compiled when it's opened in your user's browser.

Okay, what's the reason for that? Like what's the reason for not compiling its server side? Oh, I see. That is a speed optimization that we will make at some point. Remarkably, actually, when we profile it, that's not our current limiting factor in terms of performance. So one day we will compile it ahead of time and just serve up the compiled JavaScript when your user accesses your app. We just haven't got there yet.

Got it. Okay. Makes sense. Since it's compiled on the client side, can people write Python interactively then? So people can write Python fairly interactively. We don't have an interactive Python console in the Anvil editor yet, but watch this space. Actually, by the time this episode goes out, we might have that interactive console might be released. Very cool. Okay. But yes, if you go to sculpt.org, you can actually get a demo of the Sculpt Python JavaScript compiler. And that is like a live Python console

running in your web browser. It is very cool. Wow, it's amazing. And so they actually wrote a Python VM in JavaScript, like from scratch. Believe it or not, they did. And they're not even the only ones. There are about five different projects, I think, that have tried to put Python in the browser.

And there are really good reasons for this, because a whole bunch of people who are used to the ease of using Python have looked at the web and gone, oh my goodness, this needs to be simpler. How can we make it simpler? Well, I find Python really easy to write. Let's make it so you can run Python in the web browser. And there's a few of these. So there's something called Brython, which is, it kind of replaces JavaScript with Python. So you still write your script tags in your HTML, which is where you'd normally put your JavaScript, but you write them in Python and then the Brython compiler jumps in and compiles them to JavaScript and executes that JavaScript instead. You've got, there is something called transcript, which is,

it compiles something that's mostly Python. It doesn't quite behave exactly like Python, but it compiles it into really clean and fast JavaScript. And that happens ahead of time. So you feed it a bunch of.py files and it generates a bunch of.js files, and then you load those.js files in your web application just as normal. And that's kind of cool, although it doesn't really have a particularly good fidelity to exactly how Python behaves. Like if you're used to, you know, messing around with objects at a low level, then that's not going to work for you. There's also a really cool project called Pyodide, which is out of Mozilla. And that has taken the, rather than writing a new Python VM in JavaScript, it's taken CPython, the standard Python interpreter and compiled it to WebAssembly, which is a kind of fast compiled virtual machine that runs in your browser. And so if you go to the Pyodide page, you can get something that's kind of like a Jupyter notebook. And it's got all these standard data science libraries,

only it's running in your browser. It's mind bending. What is that one called? Pyodide, P-Y-O-D-I-D-E. Wow. So they ran the entire Python source code through Nscripten or something? The entire Python source code and a bunch of the classic libraries. I think you can actually use TensorFlow in your web browser. It's nuts. Wow. Amazing. I mean, of course, it takes like a minute to start because it's downloading the entire Python ecosystem when you open the page in the web browser. So it's not going to be that great as an application delivery platform, which is what we're looking for Anvil for. But as a technological achievement, it is spectacular. Yeah, I wonder if that can be cached somehow. So this gets starting to get to my limits on what I know about the web. But I think there's like CDNs that cache things or something, right?

Is there any way to speed that up? There are ways to speed it up. And you could, if you really worked at it, you could get it down from that many seconds to only only a couple of seconds, but it's never going to be like an instant snappy response. Got it. So it's great for what it is, which is loading a Python environment in your browser where you're okay with it taking a few seconds to start up, but it's not going to replace JavaScript for what JavaScript is really used for, which is driving the page in your browser and making it interactive. Yeah, totally makes sense. Okay, so someone goes to the website, they get the default HTML, you know, that whatever hasn't been hydrated yet. So whatever the server is rendered,

and they get a bunch of py files, and they get this virtual machine. So they grab the virtual machine, they grab the py files, they run the py files through the virtual machine. So they grab the virtual machine, they grab the Py files, they run the Py files through the virtual machine, and that executes some logic. And then part of that logic says things like, call this function on the server. You're on the client, you don't have that function, but there's some way where it knows to take the arguments, I guess, pickle them on, there's like maybe a pickle in the browser. It's kind of like that, yes.

Yeah, okay. So the server runs, the server, you know, unpickles it. Pickle is just, by the way, if people don't know, it's just a serialization library in Python. So the server, you know, deserializes it back to those objects, executes the function on the server,

you know, packages up the return value, sends it back to the client. And so the client then keeps going. Is there support for asynchronous calls? There has to be, right? Otherwise it'd be kind of stutters, right? Watch this space. In short, we're working on that on an ongoing basis. But actually, so when you make a call that takes a long time, it doesn't freeze the browser, but you do get a loading spinner, which is just like you get with most other web applications while they're loading some data from the server. We started with this synchronous programming model where you call a function, then you get a return value, and then you carry on executing.

Because actually, that is what most people want most of the time. Yep. Yep. And one of the reasons, one of the things that makes JavaScript so unfriendly to use is that it's not like that. Its default mode is asynchronous, where you say, well, do this task, make this request to a web server, do this other thing, and then call this other function when you're done. And so you end up kind of daisy chaining, pretty simple, what would otherwise be pretty simple logic, like, okay, well, they've clicked the button, call this function, then call that function, then do the other. You end up like daisy chaining them with a series of callbacks. And then you have syntactic sugar, like as async await if people are familiar with that with

javascript but what that is is actually just syntax for daisy trading a set of functions and you still end up if you want to use something like async await at an advanced level you end up still needing to know oh this is producing a promise, and this promise object will invoke its callbacks if you do such and such. And that's, again, an example of the problems caused by, well, we, you know, building this application delivery system out of kind of the bits and pieces we had lying around in a web browser. And so we wanted to start with this very straightforward programming model where if you wanted to get something from the server, you could do, you know, x equals, call this function, and then use x on the next line of code without having to understand everything about async programming in order to get

Hello World to work. I see it. I think that works because of the VM, right? So I think, correct me if I'm wrong, but with JavaScript, I'm pretty sure the machine is only single threaded. So actually, there are web workers, but we'll put that aside. So basically, you kind of need everything to be asynchronous, because you can only be executing one line of code at a time. And if that line is waiting for the server to come back, then nothing else can get done. But here, because you have this VM, I don't think you're limited in this way, right? Absolutely. I actually gave a lightning talk at PyCon in 2017. And if you still have any space in your show notes, I'll send you the link to that, where I take apart the Sculpt compiler

and I show exactly how we did it. You're exactly right. It's because we control the compiler, we can turn this really simple synchronous logic into highly asynchronous JavaScript. So I can summarize it, but really go watch the talk for all the diagrams. But the way the compiler works is it walks over the source code it's been given. And it breaks that up into a tree of syntax. We call it an abstract syntax tree.

And that's things like, well, this is a function definition. This function has these three statements inside them. And one of them is a function call and the other one's an assignment and the other one's a return. And you end up with this tree of things in your language, like assignments, function calls, function definitions, if statements, and so on.

And then there's another stage, which is the compile stage, which walks over that abstract syntax tree, spitting out the compiled representation. In Sculpt's case, that's spitting out JavaScript. And because we control that compile phase, we can say, actually, every time you're calling a function, call a function. And if that function signals that it's blocked, that it's waiting for something, then suspend all execution and wait until it gets back. And then when the result from that function call returns from the server, restore, go back to where we were, nested inside however many function calls

and resume execution. And because we control the compiler, we can save all your local variables, what functions were on the stack and so on and resume it. It's really, really cool. Watch the talk. Cool. Yeah, that makes sense.

Yeah, I think this is a really powerful model. You know, it's, it reminds me a little bit of like protocol buffers and gRPC, where you could kind of like, this actually supports cross language too, but even just focusing on, let's say Python, you know, you would kind of define your, your, you know, server calls in this sort of IDL. And then it would package all the arguments for you and all of that. I think about gRPC and protocol buffers is it's just, it's a huge pain to be, you know, auto generating all of this code all of the time. And so info kind of avoids that really messy step. Also, you have to get protocol buffers, which now with like Chocolatey and some of these things,

it's not too bad on Windows. On Linux, you can always apt-get just about anything. But yeah, just having the protocol buffers runtime and compiler and putting it in your code and all of that, it just adds a huge amount of overhead. Absolutely. I suppose that's another example of something, you know, that's Google, a very big company.

A demonstration like HTTP requests aren't actually a helpful way of transmitting stuff around inside Google. And Google turns everything from HTTP into protocol buffers as soon as they can because the web, it doesn't fit any size. It's not a great answer. One size fits none is the web. Yeah, that's right. Like it's not a good fit for those hyperscaler uses and it's really hostile to beginners. Anyway, you can tell that like, this is a rant I just keep sort of circling back to.

Yeah, so actually one question about this, I mean, what the, I wouldn't say what the web is good at, but what the, let's say the ecosystem is really, really powerful at and what the real sticking value is in the components. So if I need a really nice calendar component, I can find just about anything on NPM. on npm right and so there's going to be you know an audience of people who want to do the the client you know the design part in something like react is there sort of a way to do maybe like the business logic in anvil and and does that does that then make you susceptible to the problem we talked about earlier right well so obviously if so obviously, if you want to

use something lower level and gritty in JavaScript, you're going to pay the price of doing something in JavaScript, but we don't want to stop you. And actually, this is another big point. Anvil is an abstraction. It takes something complicated, the web, and it gives you an easy way to manipulate it. And the problem with abstractions is that they don't always exactly match the underlying reality. And for example, every abstraction fails like this. Google leaky abstractions. Every abstraction kind of reaches its edges and it fails. I'm thinking of those, the thing where it's a website, but they tried to make it look like an

app. I think it's Cordera or something, but these always look terrible, right? So yeah, I'm thinking at a higher level than that. Anytime you take something and you try to make a simpler abstraction for it, there are going to be limits to that abstraction. Anvils, Python APIs are not going to cover every square inch of what the browser can do. I mean, the browser is a mind-bogglingly huge platform. It's just not going to happen. And so rather than lock you in and say, well, tough, you're using Anvil now. You can't use any of that JavaScript goodness.

We have escape hatches everywhere. I've already talked about one of them in a different context. The uplink is an escape hatch. Serverless computing is great. It means you don't have to host anything, but I have a Jupyter notebook sitting here on my physical computer with a physical graphics card in it, and I want to run my code right here, not somewhere off in your cloud. Well, that's okay. We have an escape hatch that says, that's fine. You can run your code right there on your computer and you can plug it into your app and it's just as good as our serverless code. And in the same way, we have escape hatches to use things in HTML and JavaScript. So if you have a funky calendar component that you really want to use, it's better for your

uses than the Anvil's built-in calendar widget. What you can do is you can drop down to HTML and JavaScript. You can drive that JavaScript from Python. And then, and here's the cool part, you're not stuck in JavaScript thereafter. What you can do is you could drive that calendar component from Python, and then you can define that as a custom component. So the Anvil form in which you've included this calendar widget, you can say, use as custom component. And then you can take your app and say, make this app as available as a dependency. And now you or anybody else can, in their own Anvil applications, add your app as a dependency and into the toolbox in the

drag and drop editor alongside Anvil's built-in buttons and date pickers and so on will be your calendar widget. And somebody else can drag and drop it onto the screen. And you can define the properties and the events in your Python class. Because remember, the form you've created is just a Python class. And so you can define properties and events so it behaves like any other Anvil component. And so you've taken this piece of external JavaScript, you've wrapped it up as an easy to use Python class that can then be used, slotted right into other people's Python code, and even the drag and drop editor. So yes, we are religious about making escape hatches for

anywhere where our platform doesn't quite eke it out. And actually, there's a cool example of this. We're recording this just before Christmas 2020. And we're doing an advent calendar of a web app every day till Christmas. And the one we did a couple of days ago was a 3D Christmas tree. And that 3D Christmas tree is built using 3.js. We don't have native 3D support in Anvil, but that's okay because you can go from anvil.js.window.import3, and you can actually drive the 3JS JavaScript API from Python because we've got that bridge. And then you can wrap it up and use it as a drag and drop component somewhere else. That makes sense. Does this play well with Webpack? Probably not, right? That would be... The thing you would do would be you'd use Webpack to generate your JavaScript and then you would

import that JavaScript. At that point, you'd be dropping down to JavaScript interfacing with those modules. And then you would do the bridge to Python. Like you're going to have to write that bridge. If you want to drop down to the low level technologies like JavaScript, you're going to have to, you know, to get some JavaScript on you at some point. Right. Right. The thing that we're concerned about is that we don't force you to drag the rest of your app into JavaScript as well. Yeah, that totally makes sense. But like, does it, I don't know too much about Webpack. I assumed it would kind

of mangle all the names and everything. The answer is that you tell Webpack your public APIs, and so Webpack knows which names not to mangle. So for example, with 3ds, all this internal stuff is going to be mangled. Sure, it's going to be minified. But the actual APIs you're using, like create this mesh, render this here, those names remain unmangled so that they can be used. Again, you do it just how any other JavaScript programmer would, because that's exactly how any other JavaScript programmer interacts with these libraries. Yeah, totally makes sense. So yeah, this is awesome. I mean, everyone out there should try this out. There's a lot of people who are using Python. I mean, that's the language I recommend people kind of get started with. And it's really cool to see that there's a

way to, you know, Patrick and I always tell people like use it. Well, actually this, this fits in perfectly with our advice, which before was pretty schizophrenic, which was, you know, learn Python and build a website. That's what we would tell people. It's easy to build a website. You don't have to write an installer, but you should learn Python and don't tell us how you're going to do those things at the same time. And this episode actually completes our advice for once after, what, 11 years or something. Well, I mean, the thing is you're not the only people giving that advice because like when you are facing someone who? Well, I mean, the thing is, you're not the only people giving that advice because when you're facing someone who's just starting to program, use Python is absolutely the right advice.

You do not want the first thing they do to be exposed to unshielded JavaScript and HTML and DOM. They'll run away screaming. But yes, exactly. That's where everyone starts. And a web app is where everyone wants to finish. And there's the underpants gnomes, like step one, learn Python. Step two, question mark, question mark, question mark. Step three, build a web app is where everyone wants to finish. And there's the underpants gnomes, like step one,

learn Python. Step two, question mark, question mark, question mark. Step three, build a web app. And bridging that is explicitly what we're about. So tangentially related to this, because what this is really about is making building web applications more accessible. And accessible has two meanings here, really. Because, of course, if you have something that is difficult and complicated, the thing you want to do is to make it easy enough for novices to pick up. And absolutely, if I went out onto the street and asked three people, what would accessibility mean? That's probably what they'd say. But that's only half of it. Because if you just try to make something easy, what you make is like it's a children's playpen. You make something that

is kind of a toy. And that does your users a disservice for two reasons. I mean, one, it's that the people who are just starting, they are just starting, they're not finished yet, and they need room to grow their powers. And if they're stuck in the kiddie section, then they can't grow. And that is doing them a massive disservice. But it also does a disservice to the rest of the world because just because I can write five different programming languages and five different frameworks to build a web app doesn't mean I want to. And it doesn't mean that anybody else in my company wants to wait for me to do it either. And so to be properly accessible, you have to be simple enough for novices and powerful enough for seasoned professionals because that's

how you give the novices space to grow and that's how you actually solve problems for the professionals rather than only solving problems for beginners because professionals have problems too yeah that totally makes sense yeah um so one kind of question is a little bit different like what inspired you you know you give us a little bit different. What inspired you? Give us a little bit of background on yourself. This is an enormous undertaking. And what inspired you to say, we're going to do this? I mean, you could tell me, but there's got to be at least, I know, several people years worth of effort here.

And what inspired you to really buckle down and build this? So my personal background is I started programming with QBasic back in the day. And I came up using these tools like Visual Basic as I was learning. And it was great because it meant that I could build real applications that looked like everything else on your system, whether that was in DOS, it looked like any other DOS program, or whether it was on Windows, it had Windows and buttons and menus and so on. And that is what got me into programming. And I have an old university friend called Ian, and he came up very much the same way. And we ended up, I took a detour via biology because I already knew I loved computers enough that they would always be somewhere in my life so I could go do something else that was fun

at university. But I eventually came home and did a PhD focusing on building usable programming systems. And Ian was actually in the research group next door, also working on human-computer interaction. And he has exactly the same experience. He also came up building things in Visual Basic, tinkering stuff together with soldering irons. He's much better with his hands than I am. And if you have two people doing with that sort of professional expertise, it's not about the professional expertise. It's people with that experience, people who knew how simple it was and get them looking at the web. There's going to be a lot of ranting about who,

like how this really unusable programming system possibly came to be. And, you know, having PhDs in it just means that we have the fancy vocabulary in which to phrase those rants, but like we would have given those rants. And at a certain point, we just said, well, like we complain about this so much. Somebody should just build

something like Visual Basic or Delphi for the web. It would solve so many problems. And like, I still have sort of trapped in amber, the Google Hangouts message I sent to Ian, like one, you know, one afternoon saying, this is a thing that really should happen. Just got like, yes, in all capitals. And so like, amazing. That's how it started. It was like, once we knew it was a thing that we could do, we couldn't not do it. Yeah, that makes sense. So you were at some point a software engineer and you saw firsthand how painful this was. And how did you sort of make that leap to...

So actually, well, let me step back. Are you doing Anvil full time? Oh, yeah. This is like, it started as a project with a friend. Like it's now, you know, a startup with nine people and growing nicely. Thank you very much. And profitable and all that fun. Yeah.

And so how did you take that leap? I mean, it's such a leap of faith, right? To say, I'm going to quit my day job and we're going to build Anvil. And obviously in hindsight, it's going amazing, but how did you kind of muster up the courage to go do that? So I do think one of our greatest privileges being in this industry is that there was less courage than it would have required for many other people. I have friends who are professional actors. That was huge courage. They're working without a net. Fundamentally, if it has turned out that nobody would have been interested in Anvil,

I could have come and knocked on the door of a bunch of employers and got a job fairly soon. And all that would have been would be a bit of missed earnings. I do think that the... I'm not sure courage quite covers it, or maybe it's risk doesn't cover it. As it was, I was contracting at the time. Ian was working as a postdoc at the computer laboratory here in Cambridge. And so we already, like we would meet up and work on projects in got more and more excited about yes this could be a real thing and so eventually we started you know we we went down to like four and then three days a week because you know because we could work part-time because you know we were young fresh out of phds not a lot of living expenses um and then we eventually just thought well this is probably good enough uh to see what the world thinks.

And we put it up on Reddit. And Reddit just sort of bit our hand off. And we went, ah, okay, right. People really are interested in this thing. We weren't imagining it. Okay, well, time to jump in. And so we cranked ourselves up to full time. And we were just, I think we were lucky because we worked in this industry that we had the savings.

We had the ability to go to part-time work and build up the business until it could support us. Yeah, that totally makes sense. Yeah, I think that's great. Yeah, the part about Reddit too really resonates. I think one thing a lot of people should be more encouraged to show things off. I think a lot of people are afraid. I remember when I was in university, I had some some side projects that were terrible. And so I think I think if you Google my name, there's there's some I don't remember if it's Reddit or some forum, but there's some forum

posts where I introduced some game engine that was in hindsight, absolutely terrible. And it got completely torn up, but it was, I learned so much, you know, from that experience. And to this day, I mean, we posted about eternal terminal on, on hacker news and all of that. And I think, you know, being in those communities is actually something we didn't mention earlier, but that's another thing that I think beginners really should do is, is get kind of uh you know get yourself enrolled in some of these some of these uh eternal terminal is you that's

awesome i didn't realize that awesome really pleased to meet you it's a really cool technology cool yeah i'm thinking about replacing ssh entirely which would you know it would be adding a lot more to it but uh a lot of people, the biggest complaint is that you have to open another TCP port. So yeah, we'll see where it goes. Awesome. But anyway, yes. And I saw it because you put it out there. And yes, I mean, we honestly, we should have put Anvil out there like a year sooner, probably. Yeah. Yeah. Makes sense. Yeah. I think it's hard to do because you feel like, oh, if I make a bad first impression, but no one ever says, I put it out too early and I gave up on it. You always hear things in the other direction. I do think anyone who wants not to believe that will believe that their case is special. I think Anvil is a little bit special because it's a development tool.

And a development tool is kind of useful for everything or useful for nothing. And so there was a minimum level that we had to get it to in all of these areas. I mean, Anvil is a massive platform. I mean, we haven't touched on a lot of the stuff underneath the surface, but it's a serverless app hosting environment. It's a drag and drop designer. It's a web-based UI toolkit in Python. It's a Python to JavaScript compiler.

It's like off-the-shelf user authentication. It's got integration into Google APIs, Facebookis facebook microsoft what have you stripe uh you know it's a task scheduler because of course you've got to be able to run scheduled tasks in your apps it's got the uplink it's got i mean i'm sure i'm missing stuff out and we had this vision for this is like this is the end state we wanted to be this is what an ideal platform would look like it would have all this power and be this simple. And we kept measuring the difference between what we had and what it could be or would be. And instead, we should have been measuring the difference between what we had and what people were struggling with already, because that would have got it out the door a lot faster. That is, you know, such a good point, actually, the whole, you know, logging and capturing what people want. I feel like we desperately need to do a show on this. You know, you build something, all of us, when we build things, we build it

ultimately for other people, because there's, if a thousand people are going to use your program, 999 of them aren't you, right? And so you're building an app for other people and you're making a lot of assumptions about what they want, right? So for example, for Eternal Terminal in the first versions, it had a way of, it basically slowed down the delivery of contents that you could hit control C. So if you goofed up and, you know, tried to cat a binary file or something, you could still punch out. But then it turns out people just didn't want that. And there was just a bunch of issues, people, a whole bunch of people were upset about it or complaining about it. And so I took it out and people were much happier, but it's, it was just a lot of kind of trial and error and listening to issues and feedback.

And there really wasn't any analytics. I mean, there's nothing that reports back from Eternal Terminal. And I think that that is such a missed opportunity because there's just so many things that we have to learn the hard way. That is a huge advantage of running a hosted service. And that's, I mean, one of the many advantages. It also means you can upgrade, you can ship upgrades, and you can ship rollbacks very quickly.

I should mention, by the way, that there are disadvantages to being a hosted service as well. And if you think, oh, yes, this would be great, but I couldn't possibly rely on someone else's hosted services for that, we've got you covered, don't worry. The answer is pip install anvil app server. All of the anvil app server all of the anvil runtime stuff is actually open source so you can just you can self-host an app you can

in fact you can build an app in a text editor and self-host it and never touch anything owned by us at all if you really want to but otherwise you can build an anvil and then you can just get clone it out of our repository onto your disk and then host it locally. But yeah, so local stuff is important. And I guess Eternal Terminal is one of those things that kind of, that wants to be a local application. And something like Anvil kind of wants to be a hosted application. Because again, it's all about the escape hatches. You want to have the escape hatch so that someone who says,

oh, I'm running this on a Raspberry Pi. I work at a TV station. We need to be able to carry on broadcasting if the internet goes down, this has to be running on a computer in the building. True story. That's fine. You can do that. But the 95% use case is, I don't want to worry about servers. I don't want to worry about hosting. I just want to click a button and have it there. And so Anvil kind of naturally gravitates to being a hosted service if you want to solve the problems that we're solving. Whereas something like Eternal Terminal gravitates to being something

that's running on your own computer. And I think people's perceptions about telemetry change drastically because it's impossible to interact with a hosted service without creating logs and i mean we ah yeah that makes sense we are very privacy conscious with logs uh check out our privacy policy we we really do not we really put effort into if you looked over our shoulder and you saw everything that we could see you would not feel violated that's the thing that's really important to us yep but But the bar for people's

expectations for a downloaded program is somewhat different, I think. Yeah, it totally makes sense. Yeah. I mean, in any case, you need to be very diligent about anonymization and you're really trying to look for macro trends. Everyone who creates the button widget in Anvil, do they create it once and then never again? That would be a sign that either there's something wrong with it or people just were discontent with it. And creating that basic telemetry in a way that preserves people's privacy, I mean, that could easily be a whole show. I mean, there's a lot of content there. Yeah, we started. So part of the starting anvil story I kind of elided is that when it was just the two of us, we were getting started, we actually, we were able to work out

of an office in the computer lab, which is Cambridge's computer science department. And one of the real benefits of that is being able to just walk down the corridor and, you know, ask people in the security research group about problems like this. And that's something that was really valuable to us. Yeah. Yeah. That's awesome. I think that was good. I think the, yeah, basically the nutshell is, and I don't know if there's good sort of standardized libraries for this. I mean, I know there's, there's like segment and some of these things for, for collecting analytics on the web, but I don't know if there's sort of standardized libraries for this. I mean, I know there's like Segment and some of these things for collecting analytics on the web, but I don't know if there's sort of something generic there. But yeah, basically, you know,

you want to try and get some kind of feedback to improve your app and pay attention to all the issues and all of that. I guess that's the sort of mantra. Yeah, I think that's fair to say. Hey, everybody. We have a new sponsor, and that is ConfigCat. And I'm going to tell you a little bit about what ConfigCat is.

It is a feature flag service. You can easily use flags in your code with ConfigCat libraries for Python, nine other platforms. Toggle your feature flags visually on the visual dashboard. Hide or expose features in your application without redeploying your code. Set targeting rules to allow you to control who has access to those new features.

ConfigCat allows you to get the features out faster, test in production, and do easy rollbacks. With ConfigCat's simple API and clear documentation, you'll have initial proof of concept up and running in just minutes. Train new team members in minutes easily so you don't have to pay extra for growing teams. With a simple UI, the whole team can use it effectively. Whether you're an individual or a team, you can try it out with the forever free plan.

Release your features faster and with less risk with ConfigCat. Check them out today at ConfigCat. Check them out today at configcat.com. Cool. Yeah. For people who don't know what feature flags are, it's, you know, imagine you have something out in production and you want to change some kind of behavior. So you might say, you know, now use this other database, but then you do that and then it's broken and now you've broken it for everybody. And that's, that's kind of a nightmare. nightmare. So what you want to do instead is you want to try something out on like a few people and then slowly kind of add more and more and more people.

And one way to do that is to have a feature flag, have a flag that says, if this is part of my test group of people, then switch to the new database, otherwise use the old database. And slowly like that if becomes true for more and more people. And so ConfigCast is a service that kind of handles a lot of that for you. So they can like handle deciding like who gets the feature and who doesn't. And then you can go in

their UI and change all of that and slowly, slowly get it to 100%. And they take a lot of that burden off you. So check them out. They're great. Yeah. So let's dive into the company. So is the company called Anvil? Oh, the company is called the Tuesday Project Limited because Ian and I used to work on Tuesday and we had agreed many, many, many years ago that if a startup ever came out of this, it had to be called the Tuesday Project. And so it is. The Tuesday Project. Very cool. So does the Tuesday Project have internships? There's a lot of folks listening who are in the process of trying to find a place to intern at or find a place to work at. So the wonderful thing about living on a startup's timeline is that if you're recording an episode that's going to air in three months time,

I genuinely don't know exactly what the state of our hiring is going to be at that point. But I would strongly encourage anybody who's interested to sign up. Anvil is free to use. It's a premium. If you sign up for a free account, then you get a banner on the top of your apps and basically that's it. If you sign up for an account and if you're on our mailing list, we will mail you when we are hiring. So that is the eternally true thing that we are expanding. We are growing nicely and very happy about it. So if you are based in the UK and you are interested in fixing web development and being part of the team that does that, then do hop along and sign up for an account. You can also go to anvil.works slash jobs. And if we have a hiring window open at that point, then you'll see that.

Otherwise, sign up for an account, we'll let you know. Yeah. And so what's a day in the life of... Actually, how many people work on Anvil? You said it's about nine people? This is, again, one of those pieces of information that's likely to go out of date very quickly. But yes, there's currently nine of us. We're entirely bootstrapped. So we have not at this stage taken any venture investment. We are funded entirely by happy customers, which is a really great place to be from the perspective of one's blood pressure level heading into a global pandemic, for example. Oh my goodness.

Yeah. Turned out to be fine, actually. It turns out that a massive change of working causes a whole bunch of people to need to build new processes really, really quickly. Yeah. view processes really, really quickly. Yeah, actually, you know, well, so yeah, maybe a bit of a bit of a tangent, but what is your take on, you know, venture capital, specifically around things like developer tools? I feel like in that area, I mean, I'll give you my take up front, and then we could talk about it. I feel like the market is not really known well. And so it's not clear.

Some of the venture capitalists want, they have really, really big ambitions. And so for developer tools that might, going to venture capitalists might be a mistake because the market might just not be that big and then you'll end up in kind of a bad spot. Yeah, I don't think insufficient market size is our problem. There are just shy, I think, of 10 million Python developers out there. And many, if not most of the rest also do web

development. So I think we're fairly comfortable that the problem we're solving is sufficiently huge. I think it changes your distribution of outcomes. Taking investment can also really help you if you are not as lucky as Ian and I were, and you're not able to slow burn work on this part-time until it's something that's ready to show to the world and start selling. I'm not religious about this. I don't think that venture capital is a bad thing, even for development tools. Although I think the VC ecosystem writ large has swung and missed a few times on models for developer tools, and some of them have been more successful than others. I would say MongoDB was a win, Docker was a miss, despite the fact that

Docker has completely transformed its target market. It's, yeah, heralds of open source business models there. Yeah, I think Kubernetes kind of took all the actual economic value. Yeah, I mean, well, this is, okay, tangent to the tangent. Yeah, it's true. Okay, This is a reason that developer tools are difficult. If you're starting a company and you are thinking about releasing your company's main product as open source, and developers basically demand that at some level for a lot of the tools that they will take seriously, you have to answer the question of, what do I do now I've given my whole product away for free?

Somebody once, I'm blanking on his name, once said to me that if you open source, you no longer have a product. You have two products. You have one you sell and one you give away and make sure the one that you're selling is actually worth something. This has actually worked out really well for us because we do have the two products. We have the Anvil runtime for running your applications and we have the editor for building them. And so we have open sourced the runtime and we still have something that is worth people paying for premium features on. But I do think that from the last few

years, we can take the lesson that if you are infrastructure that will be built on top of, you'd better have a really good story for why the fate of Docker is not going to apply to you. Yeah, that's really well said. Rewinding, where were we before the tangents? Oh, yeah. So, okay. So we were talking a little bit about VCs. And then I think the question I was going to lead into is, what is it like to work on Anvil? Like, you know, I mean, okay, we can talk pre-COVID, right?

So, you know, how is it different than, you know, people have this vision, especially folks in maybe university, have this vision, you know, you come into the office, there's a bunch of cubicles. Everyone just sits down. No one talks to each other. You just write code. You all go home. It's sort of like the office space kind of model, right? And so one of the things we try to do is ask people, what is unique about the sort of work environment and sort of the workplace that you've set up and just,

you know, make it a little human, you know, for folks out there. To be clear, we are in the middle of a pandemic. We are working entirely from home. I desperately miss the office because I really like the people I work with. And I like being there to hang out and have lunch with them and have interesting conversations. I think something that is, I suppose, two things that make this company to be a particularly fun one in terms of how much I enjoy being around the people is that because we make tools for developers, everybody in the company writes code. Whether they are showing people how to use Anvil

or working on the core product or both, everybody is writing code. And so everybody, we sort of speak the same language and we all understand like at a sort of deep visceral level, the problems we're solving and what isn't a good solution. And so it's really great fun. You know, we pull everybody from the, you know, CEO to the newest developer advocates into the design meetings. And that's really, that part is really fun. Yeah, I think it's great that you all can speak the same language because at my job,

half of us are speaking JavaScript, half are speaking C++. It's just, it's just the best. Well, and we all speak Python. Of course, I mean, a bunch of our team speak JavaScript because we build the Anvil editor and the runtime, which means that we spend an awful lot of time, honestly, pounding our head against the desk and saying, when some corner of JavaScript or browsers or HTTP bites us, we bash our heads against the desk and say, I am doing this so that hundreds or

thousands of other people won't have to for whatever little feature we're working on. So yeah, that part's really great in that kind of alignment. I think also, kind of because Python has a... Both Python, the language, and the problem domain we're looking at, and the sorts of people who are likely to know a little bit of Python, but not much else, and they are firmly within our sort of targets, means that we get to interact with a really interesting variety of people. So talked about, you know, people who arrived in a steaming hurry having to build something. The microbiological diagnostic unit in Melbourne, in Australia, suddenly sometime around the beginning of 2020 acquired a really, really, really urgent need for a system they can just

toss gene sequences of viruses into and have it be a genetic tree of like okay that sequence matches something that came from the other end of australia check you know where did that person come in check that flight trace it to other people you know uh are our infection control measures in school working like all of this really really cool stuff and i got to end i got to talk to this bioinformaticist uh at the mdu about like how are people doing tracing in the in the pandemic and like you know what is what does he use python for what you know what tools is he building you know how does their how has their work been changed by the fact that it's all just sequence it and now it's all data science you know it's not so much bench biology it's toss it all into the sequencer and throw python at it is now how they

how that lab works and like that's one example of thousands where people are doing interesting things that aren't you know that they're a little bit off the beaten track. Because if you build something that enables the people who are, for whom building a web app wasn't accessible, if you make it accessible, just a bit more accessible, you will suddenly pull in all these people who are doing all sorts of non-traditional things and you will meet them and you will have a great time doing so. You also get to pull in like non-traditional stuff and you will meet them and you will have a great time doing so you also get to pull in like non-traditional stuff so you know we have everybody from like uh one of our uh developers who's sadly just gone on on maternity leave i mean you know great news for her uh sad for uh sad for us she's great uh just switched careers from financial services because she reckoned that

programming was more fun. And we hired her, I think like six, nine months out of bootcamp. And she hadn't really written Python before she got to us. And that's actually great. We love hiring people like that because those people are our customers, right? She really deeply understands what it's like to be starting out on Python and web development because that was her very, very recently. And now she gets to be at the leading edge of building the developer tool that solves that problem for everybody else. Yeah, that's awesome. Yeah, I think that would be so fascinating to meet the people who are,

you know, because it's like the people who already have a website, they have that inertia, right? They would have to, you know, even using the things we talked about earlier, they still would have to deconstruct to some degree their website. But it's the people who are just starting

who are looking starting who are looking at this whole ecosystem and saying, okay, you know, where should my first line of code go? And so, you know, a place like Anvil gets a lot of those people. And I think that could be so exciting to see the next generation of web developers, right? I think that's awesome. Absolutely. You said like the number of people who type Python, Python, GUI into Google, and then keep typing variations on that because they've learned some Python. Everything so far has been really straightforward.

This next step, there must be a way that's this straightforward for the next step, right? It can't possibly be this difficult. Yeah. What about for desktop? Do you have an integration with Electron or something like that? We don't. It's something that people have periodically talked about. It hasn't risen to the top of our list.

It's not like the thing that most affects people. Going back to these people it's awesome to meet, I will take the opportunity I've resisted so far to plug our podcast because what we do is... Oh, go for it. About once a month, we get on a phone call with somebody who does something really cool and talk to them about what they do so we've had like interviews with like tv broadcast engineers because you know it turns out they were they

shifting shifting to broadcasting over the internet they needed to completely rebuild the system that you know when you when you're like when your satellite box isn't working and you call up the customer service center and they go sort of tap, tap, tap, tap, tap. Ah, yes, sir. It appears that that thing, it can't reach the Wi-Fi. So, you know, let's move it to a better place with better signal. That whole system that collects and presents those diagnostics needed to be rebuilt because they were shifting to internet streaming. And, you know, the great Anvil story in this is that a TV broadcast engineer, who's not a web developer, was able to pick up and plug a web front end into the backend systems that run their TV broadcasts really easily without having to learn five different programming

languages. But the really fun story for us is that I then got to interview him and I got to learn about how TV broadcasting works, which is something like I hadn't encountered in a million years. Yeah, the real programmers, right? The ones who are setting up the program for tomorrow's show. Yeah, absolutely. So yes, it is really, really, really great meeting this huge variety of people who do all sorts of stuff. It's really fun. Yeah, this is awesome. So how are ways that people can kind of get a hold of you and get a hold of or learn more about Anvil? Right. Well, the first thing to do is to go to anvil.works and hit the build link because it's free to use. We have a bunch of tutorials. Try it out and see what we mean about how our development ought to be. So that's the first one. If you want

to find me, I am Meredydd on Twitter. That's M-E-R-E-D-Y-D-D. You probably want to click the link in the show notes for that one. What nationality is that? Is that Irish? Welsh. Oh, Welsh. Okay, got it. Welsh is one of these languages. It's like Polish. It's 100% completely phonetic, but you show the letters on the page to an English person and they make the most amazing face. Yeah. Cool. I think, so this is going to show my total ignorance of geography here, but Welsh is, it's Southwest, right? Of the whole UK. Yes, Wales is on the Southwestern end of the UK. Most people who live there speak English,

but a lot of them are also bilingual in Welsh. And that includes my family. Oh, very cool. I feel like I've slightly earned the right to make everyone suffer through spelling my name. Yeah, that's right. Yeah, I think, yeah, we'll definitely put links to the show notes and everything. And so, you know, definitely check out, you know, anvil.works. Oh, one thing we didn't cover that I want to circle back to really quick

is, you know, especially for students, you know, what is free and then what costs money? Right. Okay. So what is free is pretty much everything I've talked about. So the design, the hosting, the serverless Python, the uplink, all of that stuff is free. If you're using a free account, there are two limitations. One is that you'll get a banner on the top of your app saying, made with Anvil. And the other is that there are going to be some limits to the libraries you can import in the serverless environment in your server modules. And this is just because we're hosting code from random strangers from the internet on our servers. So you're saying I can't train my neural network using your serverless functions and have you pay for it?

Correct. You can't train your neural network on our servers. But if you want to bring your notebook up and connect it to the uplink and train your neural network there, you can absolutely do that on the free plan. Oh, interesting. So yeah, the idea is you can do everything. And of course, you can use the open source app server, you know, wherever you are, whatever you're doing. So you can use everything in Anvil for free. What we do offer is paid plans that make life easier for you, that take some of the sting out of the hosting. If you want to run a neural network in the cloud without having to worry about, oh, this computer with a Jupyter notebook must stay up at all times, then you're welcome to

take out a plan with us, that kind of thing. You work on a team, you want to collaborate with your colleagues, that kind of thing. We offer that. The goal is that anyone can use it. It's a real development tool. Rock up and give it a try. Something else I should mention, by the way, for all the educators listening, if you're using Anvil to teach a school or university course, all of the features are completely free. Just drop us a line at education at anvil.works. Oh, very cool. Good to know. Yeah, we'll have a lot of that. And we'll have students asking their teachers to do that. Absolutely. Well, bring it on. Cool. So what is the name of your podcast? Oh, Stories from the Workshop. You can get it at anvil.works slash podcast.

Cool. Okay, so we'll have all of this in the show notes. We'll have Meredit's Twitter. We'll have Anvilworks links. So check out the show notes. If you're in your car or something, wait till you get home and then check out the show notes. But we'll have links to everything over there

and there's a ton of information. For folks out there, if you build anything with Anvil, even if it's your first Hello World, drop us a line, send us an email, programmingthrowdown at Gmail, send Meredith an email and come back to us. Yeah, we love to see that.

It is so, so satisfying to see, hear stories from people and to see the things people have built. It really fills our bucket. So definitely don't hesitate to reach out. And again, if you are interested in Jobs, Careers, Internships stuff, again, sign up and just stay on our newsletter

and we will let you know if, as, and when we are next hiring yeah and in the meantime you'll go to check out these things like uh was it sculptor is that right the the python thing sculpt yeah yeah check out this technology if you want a survey of python in the browser stuff a colleague of mine actually gave a talk at pycon uk last year it was you know last year that conferences were a thing. So 2019, there's a webpage write-up we can also put in the show notes that's like comparing Sculpt and Brython

and Transcript and PyAdide and PyPyJS and like why we chose what the choice, made the choices we did for Anvil. So you can go check that out as well. And please do a Sculpt project. We always love getting more contributors. So yes, check us out. Submit a PR. Yeah, I mean, there's no

better signal than I mean, the ideal interview is where someone just sits with your team for a week. That's my take on it. And so there's no better proxy for that than someone who contributes. I know personally we've hired people who have

contributed to our open source projects. So I have firsthand experience with that. And yeah, it's super important. So I said that Bridget, one of our developers, just went on maternity leave. And her maternity leave cover, who has now been made permanent because he's so good, is somebody who was on our forums, contributing to stuff, maintaining open source Anvil components for other people to use. And so by the time it got to the point of hiring,

we just sort of took a look at him and went, yeah, yes, yes, we definitely want to hire him. We have worked with him. We know exactly what he can do. Sold. So that's a really good routine. And yes, he was also contributing to Sculpt as well by the end of it.

He's a really good chap. Wow, very cool. Awesome. Hey, Meredith, this is amazing. I really, I'm super motivated to try this out. I actually have a project that I can try it out with even today. Promise me you'll send an email with the link.

I really want to see it. I will actually, yeah. I'll definitely do that. I hope to share everyone the next sort of thing that I'm trying to cook up. And I think Anvil would be perfect for it. So thank you so much. I think that this taught me a lot. I think it taught the audience a lot about the web and about this new way of programming

for the web. So this is super exciting. I really appreciate you coming on. Well, I had a great time chatting to you. So thank you very much. Cool. Thanks a lot. And everyone out there, you know, thanks a lot for all of your support on Patreon and

by supporting us through our Audible subscriptions. And everyone stay safe out there. I think by the time this makes it to to the air maybe we'll have like the vaccine in many people's hands i really don't know it's all speculation at this point started dosing here in the uk and i cannot wait to get back in oh wow and hug people and get back in the office and you know stuff yeah exactly yeah well so everyone stay safe out there and we'll catch you next episode thanks very much. Music by Eric Fine-Mallory.

Programming Throwdown is distributed under a Creative Commons Attribution Share-A-Like 2.0 license. You're free to share, copy, distribute, transmit the work, to remix and adapt the work, but you must provide an attribution to Patrick and I and share alike in kind.