The Changelog: Software Development, Open Source - The terminal as a platform (Interview)

Episode Date: October 21, 2022

This week we're talking with Will McGugan about using the terminal to not just build software, but also to deliver software. Will is a few months into his journey of building Textualize, a company he started around his open source projects Textual and Rich. When combined Textual and Rich give you a Python framework to build beautiful full-featured TUIs for the Terminal. We talk with Will about his big idea of the terminal as a platform, how he got here from first principles, what it takes to build Textual apps and whether or not they can replace not so good web admins, building, launching, and distributing Textual apps, why Python was his choiice of language, the big picture and business model behind Textualize, and why he's building this as open source and in public.

This week on The Change Law, we're talking to Will McGugan about using the terminal to not just build software, but to also deliver software. Will is a few months into his journey of building Textualize, a company he started around his open source projects, Textual and Rich. When combined, Rich and Textual give you a Python framework to build beautiful full feature two ways for the terminal. We talk a little about his big idea of the terminal as a platform, how he got here from first principles, what it takes to build textual apps and whether or not they can replace not so good web admins building, launching and distributing textual apps.

Why Python was his choice of language, the big picture and business model behind textualize and why he's building this as open source and in public. A massive thank you to our partners and friends at Fastly and Fly. Bandwidth for ChangeLog is provided by Fastly. Learn more at Fastly.com. And our friends at Fly let you deploy your apps and your databases closer to users. Check them out at fly.io. This episode is brought to you by our friends at Square. Develop on the platform that sellers trust. Here's what you can do with Square. You can bridge more experiences. You can build online,

mobile, and in-person commerce experiences that connect more customers and sellers. You can build custom booking solutions. You can create and track orders. You can accept payments. You can manage and curate inventory. You can organize customers. You can manage employees. You can extend Square gift cards to your app.

You can use Afterpay. And all this is powered by the world-class Square APIs and SDKs that enable you to build full-feature business apps for yourself or millions of Square sellers. So much is available as a Square Solutions Partner. Learn more and get started at changelog.com. Again, changelog.com. so will one of the things that you say right on the website textualize.io is what motivates you is the realization that the terminal is a platform.

Can you just take that sentence and launch off from there and tell us more about what it means? So I did some research a while back about developers' attitude to terminal. And what I found was that it was 90% of people had a terminal open at least half of the day. 90% of developers, rather. Many developers get up in the morning and they open up a browser,

and they open up a terminal, and both those apps stay open the entire day. So all these developers have this window staring at them in front of them, and often they're using it. But people haven't seen it as a tool for delivering software. They see it as a tool for building software, as kind of an archaic tool for doing things to create the software, but they haven't seen it as a delivery mechanism for the software itself. And I think we can do a lot more with it. And I've been experimenting over the years to see what you can do with a terminal,

and things have moved on so much. Terminals can do 16.7 million colors. They've got lots of Unicode characters, which you can use to build various kind of graphics. And they're remarkably fast. Most terminals will use your GPU, so it can deliver fast updates at 60 frames a second, which is crazy to me. You know, it's because 20 years ago it was just simple green text that you typed into and then you got a few lines of text back. But now it's using the same technology as video games.

So there's very little code and projects out there to build sophisticated applications. You know, Curses is the most popular one. It's been around for decades. But that looks very rudimentary. I mean, it's very much rooted in technology of 20 years ago. So I figured, what can I do to use all this power that's available in the terminal

and maybe bring some of the improvements which have occurred in the web world, see if I can bring it to the terminal and then build applications inside the terminal. And it turns out that you can do quite a lot. And what we built is Textual, which is a Python framework, which creates these applications inside of a terminal and they look a lot more like web applications.

So when you say that it's a tool to build software, but it could become a tool to deliver software, are you speaking to the same people? Meaning, do you think it could be a tool to deliver software to developers, or do you think it could be a tool to deliver software to the general population? Initially, developers, because it's kind of strange

and it's a piece of software which is installed on virtually all desktop computers. And almost exclusively, it's only developers and maybe some other technical people that are aware of it. So initially, we deliver software to other developers. But another thing we want to do at Textualize is have a bit of magic where you can flick a switch and you can take those applications,

which were running inside the terminal, and put them in a browser. So now you can build these applications and regular people, not just developers, can use them. When did you have this realization? How long have you been working on this stuff? I started working on a library called Rich. That was nearly three years,

about two and a half years ago now. It started off from first principles. I just wanted to get colored text on the screen. And then I kept adding various other types of data and formats where I could display, I could render tables and progress bars. And I started tinkering with various other ways of rendering more sophisticated content than you're used to in a terminal.

So it kind of built up from there. I realized that there's lots more you can do in a terminal, but it does require a bit of work up front. It's not like a browser where you can just say, you know, give me a table, a browser render table. You've got to build it up from all the individual characters. But once the tools are there, you can do so much more with a terminal. When you talk about these rich applications, for the web, in the browser, you have HTML, you got CSS, and you got JavaScript. What is behind the scenes of rich and textual that is similar? Is there a similarity in terms of a markup language,

a style language, and some sort of smarts like JavaScript is? A little. So most of the code is Python, and that's one of our selling points, because there's so many people coming to Python these days whose background isn't software development exclusively, or they don't have any web development experience or desktop experience. So we want them to build apps that are exclusively within Python.

But the type of Python I've created is inspired a lot by JavaScript frameworks, like React and Vue, and it borrows some of their techniques. So you can write applications using fairly web-like technologies. And we've also built in CSS, because that's one thing that I don't think you can replicate with pure Python. So you can have a CSS file which affects how the terminal application is rendered. So you can set colors and background borders.

You can set animation and layout just via CSS. So it's a very hybrid approach of Python plus web technologies plus CSS. It's interesting to consider this as a delivery vehicle for software. Because I mean, I guess the first thing that comes to mind is like, one, how do you build it? Because we talk to builders, right? That's the show we talk to developers.

But then the same people are the consumers, potentially, as Jared said before, like who's the end user of these things? I just think about how do you launch these applications? And maybe this is sort of part of the bigger story. Maybe you're just sort of, how do you build them right now? And how do you display them and make them rich and usable? But I think about how do you, like a browser, if you're similar to a browser, what a browser might do for delivering applications, that's pretty easy. You type in URLs and you get to applications

via the web. How do you you get to applications via the web. How do you get to the applications via the terminal if it's going to take some of the market share away from browsers, for example? Yeah, so eventually the first stage is just to build a framework where they can build these applications. Initially people would probably distribute them like they do other Python libraries, through PyPy or possibly on Brew, etc.

But pretty soon we want to build this web technology where you can serve up a text application from another box. So it's just like typing URL, there'd be some sort of command. Text will run, you give it a URL or a URL-like string, and then it would serve up that application. So you can have access to all these applications that run within the terminal, as if they were locally installed,

but they wouldn't be, they'd actually be running somewhere else. Are you there yet, though? Are you still at the building stage? How do you get access to them stage? Yeah, we're still at the building textual stage. We've got a release coming up in a couple of weeks. 24th of October. A couple of days.

Yeah, not very far away. I'm hoping that that will take off and people will start creating applications. So the time when we do have this web service available, they'll be able to flick a switch and those applications that they've built will suddenly be able to be shared amongst other people

without actually having to install the software. I'd assume that would serve as well as distribution mechanism, but also discovery mechanism. Because one of the things that every good platform usually has is some aspect of a marketplace or a community or a way of discovering tooling or marketing your tooling. And so is that part of this long-term plan?

Because if the terminal's going to be a platform, it has to have more than just execution of apps, right? Yeah, so I guess it would have some kind of store, ideally a 2E of its own. Like an app store. Like an app store. I wouldn't call it that though. You might end up in litigation. I'd probably get sued.

But in principle, same idea. You can call it the terminal store. Yeah. Probably a landing. The 2E store. I've been perusing your Twitter feed, and I got to say that the things I'm seeing are very interactive, very browser-like even, very similar to a web application.

There was one where you were showing off the design system behind, I think it was behind Textual's design system. And it's got a sidebar, and you can click, and this is not normal terminal behavior. Terminal is more like key commands and things like that. Keyboard related things, not so much mouse related things. But you're clicking a sidebar and you're scrolling fast and you mentioned 60 frames a second.

When you think about the underutilized power that is in terminal, what kind of applications do you envision? What kind of things do you think will come about with that kind of frame rate available? So there's animation in there and I think that just can make the user experience a bit nicer. There's kind of a range of animation.

There's animation from helpful to gratuitous. So some of the stuff I post on Twitter is deliberately in the gratuitous side in that it doesn't really add much usability but it looks kind of cool. But the other end, you've got things like smooth scrolling which does aid usability. If you scroll

it's nice to animate that so that your eye can track position. It can go from the bottom to the top. So there's all sorts of other kinds of animation you can do. You can do blending, so you can fade something in to show it's more important, and then fade it out. So various other usability things you can do with animation

that people have been doing in the web for years have brought to the terminal. So you're obviously a fan of the terminal, as are we. So we're all here enjoying terminals. I'm one of these people, I have a terminal open right now. I didn't even realize I did because it's just always open on my computer all day long for whenever I need it. So I'm curious from your perspective, Will, what's virtuous about the terminal? What makes it so special or interesting?

Why do people love it so much? And then on the flip side, once you do that list, what's lacking, what could be better, et cetera? I think you're in a kind of a context where you have all this power at your fingertips and it's very focused. There's no extraneous details you've got to worry about. Like the browser.

I mean, I love the browser, I love the desktop. I come from a web development background. But I don't think that switching and moving windows about and hunting for things to click is always the most productive. But in a terminal, everything's there at your fingertips. When you get good at it, you can power everything with a keyboard. Which is what we want to do with Textual, even though it can look a lot like a web application

which makes it accessible and explorable and you can find things ultimately that want these applications to be keyboard powered so you could be in the terminal, stay in the terminal but launch this app, operate it with a keyboard and then return back to the terminal and you never have to context switch. I think you can be more productive doing it like that.

No distractions of Twitter or Hacker News or Reddit. Well, we might have a Twitter client one day, I don't know. Yeah, I mean, won't you just put Twitter in the terminal then? And then our context will be just as fractured. Because we won't have a browser tab, we'll have a terminal tab. I think people go to Twitter because in that case you do want to be context switched. I do it to get my head out of the code.

Sometimes you're switching to your browser because you need to Google something. And you have Twitter in the open tab and you're like, oh, what's this? Oh, this cat is stuck upside down on a thing. And then all of a sudden you start scrolling. That's not coffee, that's a cat. But yeah, so a lot of times we're doing it

because we would like the distraction. But other times I feel that just getting out of the terminal and into the browser, there are so many tabs there that just grab my eye. Yeah, but the terminal's like your old little world that you have control over, and you can be more focused. At least that's my experience.

Well, it is one, you know, command W away, at least in terminal app on my Mac, it's command W, similar to a tab in Chrome, so similar experience, at least, in terms of how it tabs and stuff like that. But, you know, this is something that should be obvious to some degree, but I'd imagine that the terminal has a different

kind of access to the file system, you know, control mechanisms, operating system APIs, etc. than the browser does. What are some of the trade-offs and differences when it comes to the platform itself and its access? Yeah, so on the terminal it's kind of native code,

so you can do anything that any other application can. You don't have to go through a JavaScript API that someone's decided that you can have access to. So obviously terminal apps, they may look like the browser, but they can do more system-related tasks. Anything that involves editing configuration files, you can run them with sudo if you wanted to.

You could do any sort of tooling and configuration type of things. The ultimate power. Yeah. Given you have sudo access or administrative access, configuration type of things. The ultimate power. Yeah, yeah. Given you have pseudo access or administrative access, if you're not a guest user of sorts, then obviously you have limited powers. But if you have the power, then you have the power.

Exactly, and that brings me to a segue that you can run these applications on SSH, over SSH, so that you can get a full GUI, even though you're connected to a web server somewhere, which would be harder to get up and running with a web application. You would have to install lots of software, configure firewalls and routers, etc.

But these terminal-based applications can just be launched very easily, and they can be served over SSH. You know, there's a lot of explosion happening in home labs. I think the Raspberry Pis really helped this, Arduino has helped this. People that have not typically been curious on a developer or terminal or kind of like geekery

that developers, software developers tend to be in. Like people who are not typically a software developer are tinkering and being more and more curious. Do you see how this kind of platform can aid in, say, PyHole, for example, rather than going to PyHole on the web or PyHole.lan or whatever it might be, going to some sort of SSH application to tinker with PyHole or do different things that home labbers tend to do. Mess with home automation, for example.

Rather than a crappy browser, maybe a more powerful terminal GUI. Yeah, so it can serve up a nice GUI that you can explore. They tend to be more accessible to people who aren't experts. We all use a whole bunch of command line apps where we've used a lot, and then we can become very proficient in them. But it takes quite a while to get there. But a good textual user interface,

you can explore it quite easily. So yeah, you can run it on a Raspberry Pi. We test on that, and it runs very well, actually, because it's a low footprint type of thing, so you can serve up a nice GUI from a tiny little Raspberry Pi to do whatever you want it to do. What about forms? Are forms easy to do in Textual?

Is it, for example, a password change form for example if i wanted to do you know profile stuff i'm just thinking like rather than like some of these things like uh portainer or different things that home labbers tend to kind of mess with with virtual machines or doc or whatever rather than going to you know a web application could you do these things in in textual in a tui change your password do different things like security related stuff to a web application, could you do these things in Textual and a TUI, change your password, do different things like security-related stuff, 2FA stuff, even can you render a QR code, for example, in Textual?

Yeah, absolutely. We've got a text input that does passwords. We've also got a checkbox control and buttons, and scrolling windows. So yeah, you could easily do a password change type dialogue. That's interesting because a lot of self-hosted client server

software has web UIs. Going all the way back to PHP My Admin or AWStats. I'm showing my age now. Great Perl scripts with a web admin that was ridiculous to use. Even to today's things, like I've been setting my pie hole,

thanks to Adam and his beating of the pie hole drum. I got a Raspberry Pi now and I've got it. And so you set it up, you get it going, it launches itself and it's like, hey, go hit our web admin. And you have a local host, not local host, but a local network IP address you navigate to. And it's fine. It's a web browser.

It does the trick. It's got cool little charts and stuff. It's got all the configs and blah, blah, blah, blah. And yet, I'm like, this thing has to have a separate web server. It has to have an open port listing on 80 and 443. And all because we can't have like a cool, I mean, I can SSH and do all the same things via config files. I can't do the charts and stuff.

I can probably find a way to get at the raw data. But how cool would it be if like PyHole shipped with a 2E that was like full featuredd like their web admin, didn't have to have a separate little part of their infrastructure that's probably not their expertise, is probably building web apps. I don't know the Piehole folks, but they seem like they're firewall people.

They probably have IP tables memorized and stuff. And so now they've got to build a web admin, which could be a security problem. A lot of times their interfaces are poorly made just because of the mismatch of skills it would be so cool if there could be a terminal based fully featured admin for PyHole that you just SSH in and run it

yeah, I think that's a very good use case for it, because you can run it you can run textual apps anywhere and it'd be quite sophisticated. And for things like an admin portal, it can do almost anything you would need. You can even do some kind of graphs. You can have sparklines and some basic plots.

The only thing that I think 2Es can't do very well is images or video. But for most admin interfaces, you don't need glossy images or videos. You want text inputs, you want text, you might have sparklines and checkboxes, other kind of things. That could cover 99% of what you need. You have that software running on a router or a tiny box or Raspberry Pi. Hey friends, this episode is brought to you by my friends and potentially your friends too at Fire Hydrant. And I'm here with Robert Ross, founder and CEO of Fire Hydrant. And Robert,

there are several options out there for incident management, but what is it that makes Fire Hydrant different? The reason that we think that FireHydrant is on to something is because we're meeting companies really where they are. We face the same problems that every company in the industry that is building and releasing software is also facing. So where you want people to be able to sign up for FireHydrant and immediately be able to kick off an incident using the best practices that we've built and we've experienced and have gathered through the other amazing customers that use our tool. It really is a very quick time to value. And we want people to have a long jump from where they are to where they want to be in incident management. I love it.

Thank you, Robert. Small teams up to 10 people can get started for free with all Fire Hydrant features included. There's no credit card required to sign up. They are making it too easy to get started. So check them out at firehydrant.com. Again, firehydrant.com. so well you got my attention but what's step one if i'm let's say i'm on the piehole team right i i don't mind the web admin, maybe I don't like it, maybe I like it, whatever. What's step one? If I'm, just to use them as an example,

what would be step one for someone like them to take up Textual, to build a 2E4 or an admin for PyHole? How does it work? So from the development side, it's a Python API. It should be quite familiar to Python developers. To create an app, you import textual.app and you extend the app class.

And that's your two-way there. It won't do much at that point. But then you implement a compose method, which returns widgets. And widgets are like self-contained components. If you're a web guy, essentially it's a div with some elements in it. You can nest these widgets, so you can have containers and put widgets inside them and create a hierarchy, which is very much like the DOM, the document object model

in web development. So you can build up your interface with these widgets that contain other widgets and then have leaf nodes for controls like text and checkbox and text input. And then you create a style sheet. And that style sheet applies styles to these individual widgets. And that works just the same way as the web does.

It's kind of like a simplified dialect of CSS. So you can create quite really beautiful looking interfaces with maybe a page or two of CSS. So that'll create something which looks very nice, looks like an app. And then you write event handlers. Event handling, again, is quite similar to JavaScript because I do come from a web background. So you write these event handlers for things like clicking, for text input, and you can update the state of the app accordingly. So the code to generate a fairly complicated app, I think, is very readable.

And it's also quite terse. I don't know if you've ever written any Curses applications, but they're quite verbose and somewhat technical. The textual is kind of like, it's quite high level. You kind of stand back and you just say what you want on screen, what you want it to look like, and then you connect up buttons and things. There's plenty of docs. We've been working quite hard on the docs for the last few months. So if you do want to get started, all the information's up there. So you've got to know Python, or you've got to be willing to write some Python. And I think that's a great choice of a language in terms of trying to reach more people. You mentioned earlier in the show

that there's a lot of people who know some Python but aren't like capital S software, capital D developer on their job titles. But I'm just curious about Python as a choice, both for yourself personally and in your work and then also for Textual. We don't talk Python too much here on the podcast, so talk some Python to us, Will. Why Python? I came to Python through video games. I was a video games developer.

And a while back I was writing a game engine. That's a long time ago. I was looking for scripting languages. And I looked at all the scripting languages at the time. I didn't know much about them. I looked at Ruby, I looked at Python, and I looked at Lua. I don't know if you guys have heard of Lua.

It's quite popular in video games. And at the time I at Lua. I don't know if you guys have heard of Lua. It's quite popular in video games. And at the time, I chose Lua because it was perfect for video games. But I found myself dipping into Python a lot for tools and for small scripts. And I also found it influenced the way I wrote C++. I was writing C++ and making it look more and more like Python. And at some point, I figured, well well why don't I just work with Python

because clearly that fits my brain better. So I kind of engineered my career to be more focused on Python. And my first 100% Python job was working for the Internet Chess Club. I was writing a chess interface for them. So I got to write Python all day. And that was a long, long time ago. And since then, that's what I've been doing in my career. Well, it makes a great choice for you then, for Textual. The one question that I would have about it, we had Toby Padilla from Charm on the show about eight months ago now. They're doing some similar stuff to you all. I'd love to hear your thoughts on their work

and your work and some of the overlap. Definitely spiritually aligned efforts. They're doing it in the Go space. And one thing that Go has going for it, pun not intended, is that distribution is really nice and straightforward. And I've never found that with Python as an outsider who uses Python tools.

I just am using stable diffusion command line last week, and so I had to dip my toe back into pip and all these things. It worked out just fine. It was good. But it wasn't like, hey, here's a binary. Throw it in your path and execute it. Curious your thoughts on Python from that perspective, just distribution, et cetera. Yeah, that is a problem in the Python world.

It's kind of strange because Python itself is such a very accessible language, but the answer to distribution isn't that great. It's not so easy to send your code to a non-developer and expect them to be able to run it. There are some solutions these days which are much better than they used to be and you can take a Python project and bundle it up

and turn it into an executable and then for all platforms and send that around. So there are solutions. And one of the things we want to look at is that model of distribution where you can bundle things up and just send when executable. Something like, I forgot the name of it,

the popular app framework where you can bundle JavaScript apps with a browser. You're talking about Webpack? You're talking about bundling JavaScript for the browser? Browser-based applications. I forget what the framework is. Electron. Electron, yes. I think we can build an Electron-like solution

because you can embed a terminal in a browser and then you can bundle that with the Python code and then you could actually send a terminal app to someone who might not even have a good terminal installed but you could just send it to them and they wouldn't have to know it was a terminal app if they're a non-technical developer. To them, it would just look like a web

app that's maybe got a slight retro appeal. Okay, that'd be interesting. What about the pre-installation of Python, say on Linux or Mac OS or Windows? Is there any sort of uphill battle with the pre-installation choices?

For example, I think it's 2.7 for Python on macOS. And they suggest Python 3, but you have to install it yourself. So this is back to non-developers, developers, and software distribution. Is Python 3 now on macOS, I think? A recent update. I think there's two different executables. I think they're both there.

There's a Python bareword, and there's a Python 3 command. It has its own... Either that or Homebrew did that for me, but that's how it's on my machine. So that's either stock or Homebrew installed Python 3 separately. I don't know. I think they're either both there. Python 3 is definitely there. It may not be

just the Python command, though. When I wish Python 3 on my terminal, I get a Homebrew path, so I don't know. Okay, so Homebrew might have done that. It is a problem getting started, especially for complete beginners. There's quite a lot of hurdles before you can even write Python. I mean, the Python interpreter is just the first one. There's lots of software you've got to download to get up and running.

So that is a big problem. And I think as far as textual is concerned, we have to overcome that. You can't distribute this stuff to your mother. Maybe your mother isn't a software developer, but maybe you could send her an installer.

So I think if we can solve that problem that will make these type of applications accessible to just the general public. Well, the good thing is that it's not a today problem for you. It's a maybe problem. It's successful, then it's a problem, right?

Because initial audience is developers, and I think developers are willing to deal with those hurdles. That's right, but if it's just developers, it's a fairly big niche, to be fair. But a far bigger niche is everyone else. Yeah, I mean, we're probably like 1% or something. I don't even know the general population. 8 billion people, how many are developers?

Probably not 1%. Small percentage. Back to building the, I guess, the TUI, the initial textual application. You know, I'm familiar with, you know, index.html. I'm familiar with, you know, some of the paths that you can have in an application. How does that work with textual? Is there an index? Is there a path that you can, you know, traverse, so to speak, when you move around the application?

How does it work? There isn't. You mean like a URL where you could... Right, like you've got a route for a website, for example, and then slash new is creating a new user, slash sign in is sign in, slash admin is the admin, for example. Is there a path interface, so to speak,

to a textual application? How does it work? There isn't that kind of speak, to a textual application? How does it work? There isn't that kind of similar concept to a textual application. It's more like a mobile app. So you might have modal dialogues where you can go back and possibly forward, but there's no URL layer yet because they're not truly web applications. They're stateful,

so they don't have a URL as such. But when we have the version which does run in the browser, maybe we would want to respect the URL so you could pop in the URL and return to a particular state. It's more like one-page applications, you know, view and react in that respect.

Right, so this text will have its own state management tooling for you? There's kind of, there's reactive variables. So you define a reactive attribute on your class and then you just modify that state and then the UI updates accordingly. Okay. But in terms of persisting that state

through different sessions or I don't know, like you just plug I mean you're a Python programmer so you just plug in SQLite and some Python stuff or is there actual inbuilt or even plans to provide some state management stuff for people using Textual?

Or is that like, get another package for that? No, I think we should have an answer to that. We've got a very basic layer of reactive variables, but we'd like to have a state object, almost like JSON, where you could just modify a dict or a list and then have the whole interface update accordingly. I think it would be a really good thing if we had an answer to that. Yeah, I think so.

I mean, so there's two sides to that. And what we see in the web world has been like a thousand state management libraries blossom, you know? And then it's kind of like, well, we try this one. Is that one? What's this idea? How's that idea? There's a redux, there's flow, there's blah, blah, blah. And then finally like over time, like something starts to shake out. It's kind of like, well, everyone's pretty much doing it this way right now and here's why it has, why it's virtuous on the other side of that is like, well, the vendor,

in your case, Textual, just provides state management for everybody and it's just a solved problem. Maybe we can mumble and grumble about Textuals. Maybe we can swap it out and say, well, I brought my own. But then you have something there that everyone uses and it kind of standardizes around that. Yeah, there's both approaches. There's the batteries included approach

and then there's the approach where you can just slot in your bit of technology. I'm not keen on the approach where you can just plug in lots of little bits of technology because they tend not to work harmoniously together. So at the moment, we're building all the widgets. We call it a large widget library. But we do want third parties to build

widgets. But I think for something like a core bit of technology like managing the state, if we do that at all, I kind of suspect that we should do it. Hopefully after we got feedback regarding how people actually want to use it

because these are they're not web apps they're kind of web app like um but they're more like desktop apps in the way you operate them so i'm not sure that that's um that's something i'd you know revisit in the future after people have a chance to to play with it well if you look at desktop apps and we just focus it on macOS because that's just the platform that I know the best, you have the core frameworks and they provide their own layers

like core data for instance. I'm sure there's newer ones that Apple provides. And then they're also like, man, you can just have a SQLite database. And so then you can just manage it yourself. Plug this one in, plug that one in. This one provides two-way data binding or whatever. This is the textual way of doing it. But of course, since it's in the spirit of open

and open source and stuff, making it batteries included, but swap those batteries if you want, or here's a different place to come in, I think is a nice balance where it's like you don't have to bring your own, but you can bring your own if you are just disgusted by what Will and his team has come up with. It is a Python application and you do have all these

Python libraries at your disposal. Oh yeah, there's this huge community. You could attempt to plug anything in and some of these things will fit in very nicely. Python has a built-in SQLite interface, so I can imagine people wanting to use that. So we have a launch of sorts coming up for October 24th, a couple days away.

But is there any textual applications in the wild that are not built by you? Who's using this currently? What's out there that we may have seen? What's the state of usage so far? Okay, so the version that's in master has been in there for quite a while.

And I started building the CSS technology, but I had to leave the version master for people to use. I didn't want to break it and people have been using it. There is a lot of applications out there. We created a gallery which you can find on textualize.io. And there's lots of apps already.

And they're using a much earlier version of Textual. We've got things for managing Apache Kafka. We've got a to-do app. A static website generator. We've got a to-do app, a static website generator. We've got a machine learning monitor. Yeah, there's quite a lot of applications out there and they're growing already. But we hope that once the CSS stuff is in there,

then that'll really explode. So the CSS stuff is what's dropping on October 24th or is that a new project? What's going on with that? That's the big feature of the next version. Once that merges, you'll be able to use CSS and all the other features we've been working on. We've got tree control, we've got a nice data table,

we've got text input, checkboxes. So already there's quite a number of widgets that you could use to build some sophisticated apps. And we're really excited about that. So let's say I'm browsing your gallery and I'm like, you know what? TipTop looks pretty cool. It's a version of Top, but it's not Top. How do I go there and be like, I like that thing. How do I use that thing? What's step one for that? Is it like a developer where you have to develop textual applications? How do you differentiate between creating and using?

If I want to just use TipTop, for example, do I have to do the developer steps to build textual applications, or can I just use? It depends whether the developer has gone to the effort of packaging it already. I mean, at the very basic level, if it's on there, then yes, you could go to the repo, you could check it out,

and you could follow the instructions and run it. For this one, in the readme, it's pip install tiptop. Yeah, and if you have Python, then that'll put the tiptop command in the path for you. Other projects might use brew or Chocolaty or one of these other package managers, which puts a command away. Gotcha. Okay.

So in most cases, there can be some sort of readme, either in the future gallery that might get more sophisticated if this becomes a not app store app store, a textual store, something like that, to instruct the user on how to get the thing, essentially. And in most cases, it's probably pip or homebrew or some sort of package manager that's pretty familiar, pretty well known.

Yeah, familiar to Python devs, certainly. Hopefully in the future we'll have an answer to a much simpler way of getting access to all these apps that doesn't require you to go into the repo and read the instructions. And doesn't require you to have the right version of Python and sort of dependencies and all that. It would be cool to have some sort of universal package binary

in this way that you talk about that could be the textual platform. Similar to Homebrew, where it's like, like once i have homebrew it unlocks for me a whole list of other things i can do right so you the first step is you get textual and then textual is a 2e which is a way of discovering and installing other 2e apps like wouldn't that be that would be beautiful now beautiful. Now you could also sideload. I don't know, maybe we'll get that into the business model. There's no sideloading, no. You can also sideload and just install them with pip or whatever,

but that would be a really cool way of providing that right there in your terminal. And so people would just say, oh, do you have textual install? Yes, well then just pop it open and find TipTop. Textual install, yeah. Hit enter on it, it installs it for you, manages all your Python dependencies,

makes sure your environment's all set up and blah, blah, blah. If not, then you got to do your own Python. Pip install also works. But that would be a really cool end goal, realizing, Will, that you're like 10 yards off the starting line of this sucker. And building the foundation is like 80% of the work. And then there's the other 80%.

But that would be neat. Yeah, that would be fantastic, yeah. I like that, Jared. It's similar to like homebrew lists. You know, you list the things you've installed with homebrew. Why couldn't you do the same thing with textual list or textual install? Homebrew could have a really sweet TUI if it used something like this. That's better than just Homebrew list

where it's like, here's a vertical list of things. You could actually write a textual TUI for Homebrew. That would be cool. They have a GitHub repo where you've got all the Homebrew projects and it's open source so you could write a TUI

which just basically browsed that repo. Yeah. I have a hard time with Homebrew sometimes because BrewSearch basically is your interface into, unless you already know the package exists, sometimes, for instance, we've been

building some ID3 based stuff and I'm like I need some ID3 tooling out there. I'm just going to BrewSearch ID3 and then there's casts and there's these and maybe it wasn brew search ID3. And then there's like casts and there's these, and like, maybe it wasn't called ID3. So like, it's literally just searching the title of the packages, right? In homebrew. It would be cool to have a homebrew portal or discovery platform where you could actually browse, you could type in ID3 and these people could provide non title

based tags or whatever topics that allow you to just find things and discover better. That would be a cool standalone textual app. It would be like Homebrew Browser or something like that. I'm just describing that, Will, because maybe somebody will build it for us. That's why. That's kind of what formula.brew.sh is

because you've got search there and a lot of the data is in a web application. I'm almost like thinking like will the, you know, if textual does take off and become you know, really usable, easy to distribute, easy to install, you know, will

packages like Homebrew migrate to TUIs rather than this web-based version? They can maybe, you know, have the database and an API maybe or something like that where the data can live in both places. And I think, Will, you said that you'd have textual on the web. Did you say that? Yeah, definitely, yeah.

Okay. So the web will eat you and you will eat the web, right? It does seem like a more natural place to be able to search for the software that you're going to install in the command line. If the interface for searching had a button that said install and you just clicked that and it ran a process that would be nice wouldn't it?

Right, and another one that says rate and review and then the other one says in-app purchases and then I'm getting ahead of myself. And I get 10% off the top. That'd be amazing. We're just trying to come up with business models for you. No, it's 30%. Well, it's 30%. Come on. You have to be

an oil baron. An app baron. What's up, friends? This episode is brought to you by Sourcegraph. With the release of Sourcegraph 4.0 and the Starship event just a few weeks behind us, it is super clear that Sourcegraph is becoming not just code search, but a full-on code intelligence platform. And I'm here with Joel Kortler, product manager of Code Insights for Sourcegraph. Joel, this move from code search to code intelligence

is a really big deal. How would you explain this feature, Code Insights, if you're just talking to folks in the hallway track of your favorite conference? I would really start with the technical because before I was product manager, I used to be an engineer as well. And it's really cool and exciting just to be able to say, we're going to turn your code base into a database. And the structured language that you

need to interact is just the ability to write a code search, you know, literal search, that's totally fine. Regular expression, you know, that'll give you a few more advanced options, even a structural search. But the number of long tail possibilities that unlocks truly the journey of building this product was just saying, well, we've just unlocked, you know, an infinite number of possibilities. We got to figure out some immediate use cases so we can start to, you know, invest in this product, build it and sell it. But we're only getting started in terms of the number of uses that we're uncovering for

it. The story I told you about discovering like version tracking turned out to be a really important use case that wasn't even on our roadmap six months prior to discovering that as we were already planning to launch this product until we talked to enough folks, realized this was a problem and then found, well, oh, that's like a simple regular expression capture group that you can just plug right in because we really built this system to not limit the power of what we built. We don't want to give you like three out of the box templates and you can only change like one character or something. It's truly like the templates are there to hold your hand and get you started.

But if you can come up with anything you want to track in your code base, you can do that with Code Insights. I love it. Thank you, Joel. So right now there is a treasure trove of insights just waiting for you. Living inside your code base, your code base is now a queryable database thanks to Sourcegraph. This opens up a world of possibilities for your code and the intelligence you can gain from it. A good next step is to go to about.sourcegraph.com slash code dash insights.

The link will be in the show notes. See how the teams are using this awesome feature. Again, about.sourcegraph.com slash code dash insights. Again, this link is in the show notes. So well, I've been pitching you business ideas. We just won. I've just been repitching you an app store idea over and over again until you launch it.

But we are curious because you have raised money. You're making a real go at this thing. And whenever you convince somebody to part with their hard-earned money, they have some sort of an idea of what that money could turn into in the future, which is more than what it is. So surely you've put some thought into what Textual could be, not just as an open source platform framework, whatever you're calling it, for building these 2Es, but also so much more. So can you give us some version of that pitch? Like what's the big picture idea? Yeah, okay. So I'm in the business of what you call openCore. It's where you've got an open source project

and then you have a commercial add-on to it. So textual will always be open source and you use it like you would any other open source project. But then we're building this web interface where you can flick a switch and then you can take those applications which you'd built for the terminal and all of a sudden they're web applications. And from there you can send a URL around and people that are not

particularly technical could use it and they might not even know that it's a terminal application. So once we have this service there'll be a very generous free tier, but if you're an organization you might want to have authentication built on top of that. And that would be a service that we could charge for. And also if you have a lot of users, at some point, you know, you'd be using a lot of bandwidth, and then that would go into a tier where we could charge you.

And there'd be additional services on top of that. Payment gateways, file serving, anything, the kind of services which web developers will pay money for. We'll carve out this little niche where we're building these 2Es and

other people are building these 2Es and we provide various services which they will need if they want to use their apps for some kind of critical infrastructure. They might want to install it on all their servers for some sort of web application and then they can use a TUI to configure and monitor it. So there's a fairly broad market there for people that want an interface, they want to build it quickly, and then they want for us to take over the managing, that kind of thing.

It's different than what your initial pitch is, which is long live the terminal, essentially. It seems like it's the backwards version of that, which is long live the terminal, but also the web. Yeah, if you imagine it, it's kind of like a Kindle. People think that would kill books, but for me the book isn't the device which is running on. It's the words. So these twoies, they may not be running in a terminal, but they may be running in the web,

but they're still twoies. They still work like the web. They still have the similar kind of keyboard-focused interfaces. I guess I'm just surprised that you're, if I'm being completely honest, I'm surprised, I guess, that your business model is built on the other side of it, which is going to be an uphill battle to get people to build TUIs. I think people want them, but whether or not textual is the best way to get there remains to be seen.

And that your business model is built on taking those TUIs that people might build and turning them into web applications that have services. That's a surprise to me. Well, if you think of it, I'm enabling people to build TUIs, but the TUI part is almost incidental. I'm enabling people to build 2Es, but the 2E part is almost incidental. I'm enabling people to build user interfaces with Python without requiring web development skills.

I'm a web developer by trade, and I know that to do even an adequate job for a web application can take some time. There's quite a big maintenance burden and it requires quite a lot of skills to do. But I'm saying you can be a Python developer, know nothing about web apps, know nothing about desktop apps,

and you can use just your Python skills to build sophisticated user interfaces. And the fact that they run in the terminal is almost incidental. Because you might want to run them in the terminal and the web and desktop. You can install them as PWAs. So the pitch is, I'm going to let all Python developers

build user interfaces by lowering the barriers. So it's as if Textual will have two rendering destinations. It's not like you're putting a terminal UI into the web. You're actually having the web

as a separate deployment target. Is that what you're saying? Yeah. So you can distribute, you can build an application and distribute it through PyPy

or Brew. That's fine. If that's all you want, that's terrific. We're doing a lot of work with that. But you can serve it so that it runs in the browser and you can distribute it to other people. And they won't even know that it's a terminal-based application. I think they look so good now.

You might notice it's a bit retro. They do have a distinctive look about them, but in general, they've got scroll bars, buttons, check boxes. If you're not a developer, you could be forgiven for thinking it just actually was a web application. So you're letting developers who know Python build terminal apps, and then later you're going to say, this is also a web app. Surprise.

Yeah, pretty much. Well, we're talking about it now so hopefully people will know that in the future. Well, you know what I mean. Yeah, they'll have an idea of that future, but the surprise was just kind of like the it's not a flip of a switch but it's like a happy ending. I don't know what you call it, Adam.

I don't know. A curveball. Yeah, a curveball. There you go. A curveball is a surprise unless you know it's coming. It's like you yell at him, hey, I'm throwing a curveball, but then you still throw the curveball. Well, you know the pitcher's throwing the ball. That's interesting.

That was a curveball for me. I didn't see that one coming. Yeah. Well, I guess instead of letting my inability to see your vision be the conversation, why is that the best business model for Textual? Why is that route the way you build the empire? It's quite difficult. It started off, I didn't have a business model.

I was just building some technology that I wanted to build because it was cool. Right. some technology that I wanted to build because it was cool. I had to come up with a commercial add-on. For me, I was a web developer and I often wished I had a UI which I could use to navigate the file system, click a file, edit configuration, and have a button to restart a server or something. So that's what I was thinking of right at the start,

that I could build that and distribute it. And I realized that those type of applications are going to be useful to quite a lot of people. So I wanted to come up with a way of not just building tools, but also getting them into the hands of non-technical people, which is where this web service comes in. Yeah, that was my initial question, I think, in section two, which is how do you distribute these applications?

And I said it's okay to punt that for a while because we don't have that problem now, but your business model assumes the problem and that's the solve for the problem. Well, I think that people will really start building applications with textual. I did a poll on Twitter about what people would use Tuis for if they existed.

It was for everyone's little pet project, pet problem that they want to solve. When they build it, they're going to want other people to use it. That is the problem with TuEs and these kind of packages in general, and that they're only for developers. But I'm hoping that there'll be a market out there for non-developers. What's the size of this market? What's the total market for this? I know it can be big, but how...

8 billion. Well, I suppose, yeah. I mean, everybody who's not a developer could be using this. Well, I guess every internet-connected person. Well, I guess, how will 2Es, or how will this play into mobile? Because mobile, for the non-developer, mobile devices obliterate a desktop for the most part. Yeah, I mean, they will be able to run on mobile devices obliterate a desktop for the most part. Yeah, I mean, they will be able to run on mobile devices.

You can't have terminal-like experiences running on mobile. You could put it on a tablet, and you'd still have touch and gestures and things. We can build an interface for that, so it would run quite well, I think, on a tablet. So if you're enabling developers to build user interfaces with Python and not have to deal with the difficulty of web app development, but then you're building in CSS,

wouldn't they also have to know web app development then? Or is it just some basic CSS stuff, it's not that much? It's a much reduced dialect of CSS. I mean, CSS in the web is enormous. You have to know a lot of skill to wield it. It's much more reduced because the rules are much simpler. You've got color and border and some other styles, link colors, et cetera.

So it's much easier to learn than it would the entire of web CSS. There's a lot to be embraced, I would say, from the web platform and even what it uses to get built. Did you consider, I know that you said widgets and containers or I can't recall the exact terminology you used were similar to divs and you have CSS and whatnot. Did you, because I'm thinking there's a lot of front-end web developers out there

that know HTML, CSS, and JavaScript and can build full-feature web applications, but would also love to build TUIs. And now they have to essentially abandon a lot of that direct skill set and learn Python and unlearn web to build TUIs in Textual's world. I don't think, well, the thing is the people whose job it is to write web applications,

I'm not worried. They shouldn't be worried about losing their job or being forced to work on Textual. It's for the people that... Well, I mean to use it. I think it's really cool. I think more people want to build with it. And I think a captive audience

would be the ones who are most fluent with interface building, and that's front-enders. They're going to know those skills, but you can't take HTML, CSS, and JavaScript and apply it to Terminal. Well, I think they have options. Because I know there's a tool that builds,

Inc maybe, builds Terminal apps I think they have options. I know there's a tool that builds Ink maybe, builds Terminal apps with React and stuff. I think that market has people building tooling for them to do, to take their front-end skills over. I think there's another large, large community that Will is a part of, which knows Python and doesn't know Web and would love to build some UIs. I think of these textual applications not as replacing

what people use web applications for, but I think because it lowers the barrier, there's applications which simply weren't being built because it would take too long with a web application or they didn't have the skills. I think a lot of these could be built with textual because you just need Python skills, which a lot of people have,

and it's just easier and quicker to build them. So I think they'll be not cutting off a part of the market, but creating a new market for applications which just were never built in the first place. I wrote Python for about six months a decade ago and I had never written any before. And it took like six to 12 hours of just dinking around to where I could do some basic,

having already known how to program, right? Like I was a Ruby programmer. Moving from JavaScript over to Python is not a leap. Of course Python has this huge breadth of things you can do, but we're talking about just core functionality. I don't think it'd be a big leap for somebody if they wanted to make that leap. But like I said, you probably don't have to.

There's probably JavaScript tooling for this exact kind of thing. But to get into the textual world, if you wanted to, Python is a very, Will was talking about earlier on, it's a very approachable programming language, which is kind of a weird, ironic thing with it not being approachable from a distribution perspective, historically. So I don't think Python's going to hold him back.

I think, yeah, getting people interested in text applications in general is probably a bigger selling point. How long do you have, Will? Do you have a runway calculated out with your current burn rate? Startup stuff. We can work on this for

N years or N months before I need to have some sort of income? We've got five employees, including myself. Assuming that level of staffing, we could keep going for three plus years, which is great, yeah. Nice.

Because Scottish people don't like to spend money. So I'm using that money wisely. So they're all Scottish, the whole team? One's Portuguese. Okay. He works remotely. Okay. Are the rest of you all co-located? Hanging out in the same office and stuff?

Yeah, we're all in Edinburgh apart from the Portuguese guys. That's cool. We probably will be more remote in the future but I kind of like having people in the same office that you can bounce ideas off of. I find things move a bit quicker if you've got a

core that is physically near each other. Are you still hiring? Are you capped? Not right now, but probably will in six months. What kind of skill set do you think you'll be looking for in six months? What kind of ideal candidate

comes to your table? At the moment we've hired some very technical people, the type of people that can get involved in nitty-gritty and design APIs. I think the next phase will be developer relations. So we want to sell textual as a serious proposition for building interfaces. So I imagine it would be people that are particularly good communicators. People that could produce videos,

could write blog posts, that kind of thing. So I think they call that developer relations. That would probably be the next hires we'd have. Very cool. Speaking of public relations, we should mention a thank you to our

friend Simon Wilson who gave us your name, Will, and said that you're a person we should definitely talk to. One of the things he was praising was how you're building everything out there in public. You're probably the lead dev rel at this point for a tech school. Do you want to speak to your philosophy around that, maybe even the way you go about it or anything with regards to your constant stream of output? Sure, yeah. So I mean, when I started doing this kind of thing nearly three years ago, I had no idea that it would turn into a funded startup.

I just wanted to share what I was working on and it turned out it was quite visual. Rich was quite visual, you know, so I could create a screenshot and I could post that and I could discuss it. Initially I didn't have many followers, I might get a few likes here and there, but people did seem to appreciate that kind of content. So I kept it up. Well before the funding I was already posting videos and screenshots and that's probably what got me noticed um by the venture capital firm that i went with and was the fact that i had built up an audience these projects got a lot of stars and that was in part due to me just sharing what i was working on you know i'd share

successes if i was really proud of something i'd post a screenshot and i'd share fails um if something didn't work out and it was all garbled. I'd share that as well. And I'd share technical information. Just whenever it came to my mind, it's kind of cathartic. Software development can be kind of like a solo activity, especially if I wasn't working with a team at that point. It's just me.

And I liked the idea that people were interested in following along um so I kept doing that and built up uh an audience that way and it seems to be beneficial I mean we're still a small company I haven't got an advertising budget I'm not going to take out adverts on buses or the news or anything. So this is how I reach my audience and potentially customers in the future. And I quite enjoy doing it. Yeah, I think obviously what you've done has worked so far to reach an audience. You've got the attention of folks with money and have a shared vision, obviously,

because you wouldn't have taken their money otherwise. And you got Simon's attention, because I think Simon's a pretty smart fella. He's terrific. I always appreciate his perspective and his take on software. He's got a good eye for what good software is and who's building good software.

So we took his suggestion of having you on the show very highly, of course. I appreciate Simon doing that. I love his content. He shares everything he learns. He puts it on Twitter or on his website. He's got a huge corpus of various articles on little technical details and big issues.

So yeah, there's lots of terrific stuff on his website. Is there anything that we haven't asked you as part of the show today? I know Jared and I had a couple different angles that we came to the show with and some investigation, but what may we have not asked you that you want to share here as we close out? I guess I could share, I don't know if I said, but this is my plan B. So plan A, I was working on Textual and realized it was got a bit of a following. And I had this idea for the web application.

And at the time, I was a bit down on my day job. And I figured what I'd do is I'd take a year off. I've got some savings. I would just live frugally, live off my savings and some income from sponsorship, which I was getting at the time. And, you know, that would have happened if it was this point. It would have been like running low on money. But that's when the venture capital firm got in touch with me. And we discussed it and I discussed my plans and came up with a business plan and a pitch

deck and turned everything around. So it was as much of a surprise to me as anyone else. So your current trajectory was a plan B. You were just expecting to take some time off, live off of savings, and just enjoy your craft, essentially. Yeah, it was just going to be me. And I would be happy to tinker, write some code over the year.

And then if I did come up with something at the end of the year, which was, which is good enough, I could take that and then try and build a company or income out of that worst case scenario. Um, I would just return to my regular day job. Um,

but things turned out quite differently. What's the most exciting thing and most scary thing, I guess, of this unexpected turn for you? I guess I'm excited by what people are going to build with it. If I can enable people to build things which they weren't building before, that's exciting to me. You know, if there's a lot of applications that exist in the future, which wouldn't have existed without Textual um i get quite a lot of buzz about

that um scary i guess is the amount of work you know um plan a um was to allow me to reduce my stress levels um i could just you know focus on myself and write some code catch up on my reading get a bit of exercise but now we've got so much going on. Life's a bit crazy. I'm working quite a lot and my stress level's a bit higher, but also I'm enjoying things a lot more, so it kind of balances out. Yeah, the unexpected plan B of venture capital and the possibility of building something

that can be a business around this, it does have the struggle because you're the one with the idea, you're the one with the vision, you're the one with the responsibility in a lot of the cases here. So you are carrying almost, if not all, the burden. Yeah, and having employees, that's not something I'd thought a great deal about in the past um i want to build a company um which works for them which you know they enjoy working

for and can help them meet their goals and i can kind of build the company that i would have want to have worked for earlier in my career um so that's you's a whole load of things which I hadn't thought about even a year ago. So that's all kind of exciting. Yeah. Well, Will, thank you for sharing that part of your journey and that part of your story as well as all the details around TechShule, how you got there, what the future might be.

Really appreciate you being courageous to take that step. It's one thing to be able to create and then one thing to put it out there like you have. Building in public is, you know this because you see it every day. You put something out there that's a bad or a good thing. It's hard. That's hard to be vulnerable with the world and you've done that. Yeah, it's also quite cathartic.

I would actually recommend it to people. If you can get over that phase where nobody seems to be paying attention to you and just post things, eventually people will actually find your content and hopefully follow along. So it does kind of lay yourself bare. Sometimes you get criticized sometimes,

but most times you don't. People appreciate your content. So yeah, I'd recommend it to anyone who's building something to just tell other people about it. There you go. All right, well, thanks so much. Thank you. Yep, thanks.

It's been great. Cheers. This show is done. Thank you for tuning in. Hey, what do you think about the terminal as a platform? What do you think about TUIs? What do you think about building TUIs instead of web admins? Was Python a wise choice of language?

What about the big picture and business model? What do you think about that? Let us know in the comments. The link is in the show notes. Once again, thank you to our friends and our partners at Fastly and Fly. And those beats are banging. Thank you, Breakmaster Cylinder. You are awesome. And, of course, thank you breakmaster cylinder you are awesome and of

course thank you to you our listeners thank you so much for tuning in we appreciate you but that's it for this week we will see you on monday Thank you. Outro Music