The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.   So now your modern data stack is set up. How is everyone going to find the data they need and understand it?   Select Star is a data discovery platform platform that automatically analyzes and documents your data. For every table in select star, you can find out where the data originated, which dashboards are built on top of it,   who's using it in the company, and how they're using it, all the way down to the SQL queries.   Best of all, it's simple to set up and easy for both engineering and operations teams to use.  

With SelectStar's data catalog, a single source of truth for your data is built in minutes even across thousands of datasets.   Try it out for free and double the length of your free trial today at pythonpodcast.com/selectstar.   You'll also get a swag package when you continue on a paid plan.   When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So check out our friends over at Linode.   With their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,   including simple pricing, node balancers, 40 gigabit networking, and dedicated CPU and GPU instances.  

And now you can launch a managed   MySQL, Postgres, or Mongo database cluster in minutes to keep your critical data safe with automated backups and failover.   Go to python podcast dotcom/linode   today to get a $100 credit to try out their new database service, and don't forget to thank them for their continued support of this show. Your host as usual is Tobias Macy. And today, I'm interviewing Sam Willis about Tetra, a full stack component framework for your Django applications. So, Sam, can you start by introducing yourself?  

[00:01:54] Unknown:

Sam,   I am a full stack developer. I've been working with Django and Python for 15 years.   Spent the last few months   building a new framework for Django called Tetra.  

[00:02:07] Unknown:

And do you remember how you first got introduced to Python? I found it at the same time as finding Django.  

[00:02:13] Unknown:

So it was probably about 2, 006,   and   I had   kinda grown frustrated   with   PHP   and ASP, which were the 2 things that I'd   I'd mostly used up till then was looking around for something new, and there seemed to be at the time big debate going on about the strengths   of Python and Django or   Ruby and Rails. And   I picked up Django first,   and it was my first introduction to Python.   That was it, really.   Worked well.  

[00:02:51] Unknown:

And in that decision making process, did you end up actually trying out Ruby on Rails and trying to build anything with it? Or was it just you tried out Django, and that's the 1 that stuck and you never looked back?  

[00:03:03] Unknown:

Exactly. Picked up Django first and thought, this works well. I don't need to try the other 1. I'll just keep going.   Yeah. And it's been a really good toolkit. It's been my go to for anything for the last 15 years, really. It's kept me busy with all sort of work and side projects.   I'm   somewhat unusual in that I'm as well as a   full stack web developer,   I'm spent big chunk of my early career doing physical product design,   so I've kind of jumped between the 2 back and forth.   I've been firmly on   software for the last 10 years   on web development.  

It's been a good tool to use.   So back in   2006 when I first picked it up, I was working not web development, and I built a kind of as a side project in my evenings. I built a social media aggregate   social media aggregator.   It was called Flutterbox,   and   that was my first big project with Django. And I I ran that for sort of on the side for   a couple of years until   it kinda just   fell to the wayside.   Carried on with the day job   about 10 years ago.   I   started   a online business built on Django with my wife, and   they did well. And   we got to the point where we could both leave our our day jobs to run it full time. And   I said, the rest is history. We've been running that for for 10 years. And for the last year or so, I've been doing sort of freelance development as well. So yeah.  



[00:04:40] Unknown:

Very   cool. You mentioned that you built your own business, and then you did a bunch of freelance work. And now you have started building a new open source framework. I'm wondering if you can just describe a bit about what it is that you're building with Tetra and some of the story behind how it came to be and why you decided that this was something that was worth spending your time and energy on?  

[00:05:00] Unknown:

So I had been spending   quite a lot of time doing kind of front end development   with front end frameworks like Vue, and   I was   growing frustrated   with the disconnect   between   the front end and the back end.   The fact that you have to constantly code   APIs, REST APIs, or whatever you want to use to connect your front end to your back end,   and it really slows down the sort of velocity at which you can work. It provides it's a forms of barrier.   Every time you want to try something, you've gotta swap back to the other project to implement the bit that you need to bring   bring extra   state to the to the front.  

So I sort of started looking around to see what other people were doing, and I came across,   Laravel Livewire   PHP ecosystem.   And the the guy behind Livewire built,   a project called Alpine JS,   which is a front end JavaScript toolkit for   providing   really   quick and easy front end interaction   without having to set up a full   node   toolkit   to have it run.   And it looked really smart, especially coming from Vue. Js. There's so many it we're kind of very much inspired by Vue. Js. It's got very much the same syntax in the way you have directives that   you decorate your   HTML elements with to indicate what you want to do.  

And   it also uses the reactive core Vue JS as well   to provide its reactive state management.   And so   I was thinking how best to combine these 2   things together, and that's sort of where the thought process   for Tetra came from. So   I would describe Tetra as a   full stack reactive component framework.   It sort of provides the glue between the the front end and back end.   And   the kind of 2 key features   are it has this   public   shared state   that it passes down to the browser for your components   that   forms   the Alpine JS   state in the browser,   and it has a private   state for each component   that is   serialized   and   encrypted   and also sent down to the browser   on each vendor,   which allows the components to be resumed   when   you call any of the kind of public methods   on the component.  

So that's very much inspired by   things like LiveWire.   But the other thing I wanted to do was bring in some of the kind of concepts of single file components   from Vue JS.   I think it's a much   better way   of working. I think it's 1 of the kind of great successes   of front end   frameworks of the encapsulation   of   your front end JavaScript with the templates, with the style sheets all in 1 place.   And I wanted to try and find a way of doing that   with   Python, with Django.   And so that's where it kinda sorta started from, really. So   I started building it about   first, started tinkering with the idea back in January, see how it could work,   build a couple of side side level test projects   to see what,   see what could could work.  

1 of the kind of the first   versions   was much closer to   Vue. Js   with the way that Vue. Js had these single file components,   which looked like a HTML file   where you've got a script tag with your JavaScript in it, a template tag with your template in it, and a style tag with your style files in it.   So I started off trying   to build something based around that using   Python's   import hooks to have a custom file type that you could import your components.   It was getting quite complicated.   It felt like it needed a lot more to make it work, and   it would need much more integration into people's editors   to make it work. So for VJS, there's a massive   Versus Code plugin, make that work.  

So I kinda went back to the drawing board, and   it occurred to me that with Python multiline strings and   type annotations, you could build a system that allows you to do syntax highlighting   of   multiline strings in a Python file.   So that's 1 of the first things that I I I built for it, and it's a separate project for for other things as well.   So it's sort of 2 parts   Python,   Python package you can call source types that lets you just do type annotations of different languages   for your mushline strings,   and a Versus Code plugin called Python inline source that   looks for those type annotations in your Python files   and sets the syntax highlighting of multiline strings.  

So built that and then kind of got stuck into building Tetra   and building it up from there. I sort of made a little bit of noise online saying, look what I've built. It's early days, but   would love some feedback   and had good feedback. So gonna keep building it.  

[00:10:49] Unknown:

Absolutely.   And in terms of   the overall kind of problem statement for it, it seems like it's basically   building full stack web applications is harder than it needs to be. Here's a way to reduce the friction. Let's just put everything in 1 spot, and then you don't have to think about, you know, building 2 different projects and then building the interface between them and trying to keep all of that in sync.   And I'm wondering how you've approached that overall problem prior to using Tetra and some of the points of friction that are kind of inherent in that full stack application development cycle.  

[00:11:23] Unknown:

So the plan is to build something   that allows you to   simplify   the process of building   websites and web apps.   I wanted to make it so that people didn't need to install Node. Js,   didn't need   to set up a full   stack of   front end tooling just to build a simple website, which seems to be the default now. It seems that   everyone that's learning to build websites now are told to start with React, install,   JS, and to get their heads around webpack   and all sorts of other build tooling, which just makes it so much harder.   So the plan is to sort   of combine that all into   Tetra.  

So   in the near term, it's a component framework that has the glue between front end and back end. In the longer term, I want it to become   a way of   managing   the full stack of JavaScript as well within a Python   app.   So if you want to   introduce   other JavaScript libraries,   I want to provide   tooling that enables you to do that   without having to   fall back to using Node. Js.   I want it to be a kind of a just work solution. I think that's the thing that I particularly like about Django   and Vue. Js is the 2 kind of things that I've used the most. They're opinionated frameworks.   They   have everything that you need built in. They make all the decisions for you. You don't have to go off looking for   different ways of doing things or different libraries to install and make those decisions.  

So Tetra's aiming for that is aiming to be   a opinionated   framework.   And 2, there's another project called HMX,   The creator of that has been talking about a term that he's just called locality of behavior.   This is the concept. It's better to   have the code   related to, say, a   button click   actually on the button rather than some of the files somewhere else.   So the example he uses is   with h tmx   rather   than, say, with jQuery   back in the day,   setting in a JavaScript file somewhere your event   listener for the click event on button   and it being completely disconnected.  

With HMX, you set the click handler there   in your HTML on the button element.   I think that's 1 of the things I'm trying to do with Tetra, is trying to bring everything close together.   So although he's using the term Lacarte of behavior, I'm   I think that's sort of saying stick things on top of each other,   whereas   I think there's still something to be said about some level of separation.   So although   with Tetra, everything's in the same file, they're just next to each other. So I'm kinda calling it close proximity of related concerns   sort of   indicating that you're putting your things that are related to each other next to each other   so you know they're there.  



[00:14:43] Unknown:

Yeah. It's definitely a trend that has been growing in how, in particular, front end work has been evolving, where it used to be you had your JavaScript file that had some logic in it. You had your HTML file that was separate that designed   the structure that the JavaScript would latch into. And then separate to that, you would have your CSS file that needs to know about, you know, everything that the other 2 are doing to be able to work effectively.   And each of those 3 things would typically kind of grow and evolve in its own way, not even always in line with each other. And so you would end up with these large and convoluted files that had lots of conflated logic that wasn't really constructed in a way that would actually compose well together to be able to scale kind of logically into larger applications.  

[00:15:29] Unknown:

Yeah. I think it also results in code rot in that Ossobald style   where because of that disconnect between the different aspects of a single sort of function,   it's very easy to lose track of code that's no longer being used, whether a classic 1 is CSS.   It's so easy for CSS files to become bloated with   styles that you're just not using anymore.   Whereas if your styles   are   defined   on the component themselves,   it means that   you don't lose that connection   if you then stop using the component. You stop using those styles.   I think it's 1 of the big reasons why   Tailwind   and other   utility first style and CSS frameworks have been so successful because   you're bringing   the styles   to the component   rather than having them somewhere else completely.  

Now I'm not completely convinced by the extent to which   Tailwind goes with its class attributes,   but I could see   Tailwind working well with   Petra in that you'd use Tailwind classes to build up   components, but then you can also apply some additional   CSS   in your style definition on the component.   And 1 of the things that I'm hoping to add to Tetra soon is post CSS support.   So the intention is to be able   to have,   Sass or less   as preprocessors on your styles within a Tetra component,   In which case, you'll be able to use the the extend   operator to be able to   apply, say,   palewind styles   to a component within the the CSS   definition rather than on the component itself. That's 1 of the next jobs in a very long to do list.  



[00:17:24] Unknown:

In terms of actually   putting the different kind of logical elements that go with this particular piece of functionality where you've got, in the case of Tetra, the Django view code and the JavaScript code that is going to manipulate the HTML content and and the CSS that's going to be applied to it.   I'm wondering what are some of the sort of   design challenges that go into figuring out how to find the appropriate scope for those components   and make sure that they will be composable into kind of larger objects and larger applications?  

[00:17:57] Unknown:

I think well, firstly, on the sort of style and JavaScript side,   I think   it's anything that is directly   on the component that only used by that component, it makes sense to define   in the component file next as part of the component.   But because I would say with, say, JavaScript,   because Tetra is using   ES build to build the JavaScript   package afterwards,   you can import   any   JavaScript file into your component.   So for reasonable   functionality, you can import it into each of the components in which you are using it.   And then it's all built together into 1 package   with the Versus build.  

On the CSS side, again, I think it's just the styles that are only on a component you'd want to define within the component.   The plan is on that to copy what   Vue. Js is doing eventually, and they will use to have scope styles,   which is a clever trick where   it automatically   places an attribute on every   DOM node that's created by that template on that   component   and scopes the styles for that component based on that attribute   so that your styles can't leak into   other parts of your front end. It can't leak into other components. So there's a plan to do that.   On the sort of structuring your   components of where to break the functionality   between   different areas of functionality,   I think   if we take the to do list example,   classic app,   each line of a to do list wants to be a component, but you don't need to break that up into a component for an input box, a component for the delete button. The component is encapsulating   the behavior   of that line.  

So   if you think of it from the perspective of your Django models from your database.   Each   model probably wants to be a component,   and   each   query set   that you are displaying on   a page probably wants to be   a model.   So   that's probably the kind of the general rule of thumb that,   yeah,   model instances probably want their own component, and you might have 2 or 3 different components that display that   model instance in different ways depending on where it is.   It's encapsulating a single line of functionality   or a single   list of functionality   in a reusable way.  



[00:20:44] Unknown:

And so as far as the   overall landscape of being able to develop full stack applications,   you mentioned HTMLX   as 1 of the libraries that's very popular and trying to maybe kind of pull back on the reins a little bit of everything being a single page app with a full on JavaScript UI framework such as React or Vue.   And I'm wondering what you see as some of the kind   of broader landscape of how people are addressing these problems, you know,   in the absence of a framework such as Tetra, where you do still have the separation   of, you know, the JavaScript on 1 side and the application on   the other. You mentioned the LiveWire framework for Laravel. Wondering what you see as some of the other kind of sources of inspiration or kind of   states of the art for addressing this problem of kind of the rampant complexity that has come in for, you know, the general web application   development cycle.  



[00:21:41] Unknown:

You said Laravel   LiveWire is a big inspiration for this.   In the rails world, there's Hotwire, which is very similar, although I've not not spent much time looking at it. There is another   project for Django called Django Unicorn   that takes the Livewire concept   and brings it to Django.   But it's very true to the Livewire concept.   It doesn't try to provide an answer   to encapsulating   your components,   JavaScript, and CSS.   And it doesn't sort of provide an answer to   doing more   than just the glue between   simple user interactions and rerendering on the server.   So   1 solution   is to use   Alpine   with   Django Unicorn,   which would be very much like what people do in the the Livewire ecosystem where they would use   Alpine with Livewire to bring that extra to functionality to the front end. I've kind of gone the other route, and I've started from Alpine and then worked backwards and said, how can we build a back end for   Alpine that really takes advantage of its strengths,   rather than having it kind of layered on top as an afterthought?  

So that's where kind of the fundamental   idea came from   for having the public attributes on Tetra component to become   the data model for a   Alpine component on the front end   and Unicorn, which is a brilliant brilliant project and is far further ahead than I am with Tetra. So if you want to use something now, then Unicorn is a great 1 to use.  

[00:23:30] Unknown:

Need to automate your Python code in the cloud? Want to avoid the hassle of setting up and maintaining infrastructure?   Shipyard is the premier orchestration platform built to help you quickly launch, monitor, and share Python workflows in a matter of minutes with 0 changes to your code. Shipyard provides powerful features like webhooks,   error handling, monitoring, automatic containerization,   syncing with GitHub, and more. Plus, it comes with over 70 open source low code templates to help you quickly build solutions with the tools you already use. Go to python podcast dot com/shipyard   today to get started automating with a free developer plan.  

So in terms of the actual   implementation and how you have approached this problem with TETRA, I'm wondering if you can just talk through some of the design and architecture and implementation details of what you're building and how you're weaving this into the Django framework and integrating the Alpine library and just the overall   thought process that went into how to construct this into something that was kind of internally cohesive and made sense for somebody who's building on top of it? It's quite complicated.  

[00:24:39] Unknown:

So components   are kind of the center point of Tetra, and   they   all are rendered on the server   using Django templates. But whenever   a Tetra component is rendered and sent down to the client, it's actually serialized   that that state is saved.   So   1 of the differences between   Tetra and some of the other frameworks   is that rather   than confining   the resumable state   to   objects that can be JSON   serialized.   With Tetra,   I'm using Pickle,   the built in Python serialization   tool.   So   almost any   Python object   can be   saved as part of that state.   Now, obviously, with Pickle, there are all sorts of security concerns because if someone was able to modify that state   and send it back to the server, you've potentially got   a pretty bad exploit there.  

So   the state is actually encrypted   and signed using,   FIRNET,   which is an encryption standard using AES,   and the the key is derived from Django secret key and the user session ID.   And that ensures that the state can't be modified when it's sent back to the server for resuming that component on any public   method calls.   And I've done a bunch of work to kind of make that state efficient.   So   Django model instances   are   saved as just a reference to   the   the database,   same with the query sets. So it turns out that in Pickle framework, there's a built in system for being able to do this. It's called the system ID,   and it allows you   to hook into pickle and   for specific   object types,   be able to replace   the reference   pickled reference with your own reference   to recall your object from wherever.  

I've done that with sort of database things, but I've also done it with template blocks.   So   when you're using a   component on a page, you can   nest them, can have other components within them or other content.   So   in in the kind of the front end world, JavaScript front end world, think of these call these slots.   Django with Django templates has blocks, which pretty much are the same thing.   So Tetra components can take additional blocks.   If we naively just serialized and pickled   the component,   you'd end up pickling a bunch of templates into that state, which bulks out the the saved state massively.   So   Tetra tracks down where all the blocks that have been fed to a component were defined   and keeps track of that   so that when the state's resumed, they rebuilds back to   to its initial   state. As well as the kind of the private state, there's the public state, which we talked about before,   that serialized JSON, but an extended version that using that   also supports dates and sets, anything that there is a corresponding   standard   JavaScript type in the browser to the   type   on the server   will automatically   match.  

Tetra has these public methods   that are made available   to   the Alpine JS JavaScript code on the front end.   And when you   call   a public method   from   the front end, it   picks up the state of your component,   post it back to the server.   It's unpickled.   And any   parameters you've passed to that   public method are then called on that method   on   the component on server.   It can then rerender the template with the updated   state, any updated data from other sources,   that is sent back to the browser,   and   the DOM is morphed   to the news the   new representation from the server.  

So it uses Alpine JS's morph plug in to do this. So it effectively takes   the new HTML that's been   sent, temporarily   makes DOM objects out of it,   compares that to the DOM that's mounted on the page, and morphs the DOM mounted on the page to match the state that's been the DOM that's been sent from the server.   And this allows the so for example, if you are in the middle of typing in a text box,   it doesn't just dump the text box out the way, bring it back, and you don't lose your cursor position   inside the text box.   So any local state is maintained.  

The other thing that you can do from public methods is a callback queue that allows you to call   front end JavaScript   methods that you've defined as part of your component   from the server.   So   if, for example, you have   a   a to do list and   you   having modified an item in your to do list, you want it to resort the to do list,   you can   call a a front end   method that fires an event that can then   travel up to your parent component, which can say, I need to resort   this because we've changed   the text of this to do list item, and it needs to be resorted into alphabetical   or priority list or or something.  

Each component   in Tetra   is   part of a component library.   And   all of the JavaScript   and CSS for each component within the library are bundled together into a single   JavaScript and CSS files. And this is done with ES build,   which is a brilliant project. It's for building JavaScript   and CSS. It's 10 times faster literally than   webpack and   some of the other JavaScript build tools. It's written in in Go.   And so   although not quite yet, the intention is to bundle it with Tetra. So if you read docs right now, it'll tell you you need to install Node. Js and   install, yes, build using Node. Js. That's definitely not the plan going forwards.  

The plan is to bundle ES build with Tetra so that it just works and you don't need to think about upfront end   Node. Js tooling. When the JS and CSS is built,   also create source maps for those files.   So when you are   developing   your website using Tetra, if you have any   JavaScript errors or you're trying to track down where the CSS property on element was defined,   the source map files will   enable your dev tools in the browser to show you exactly where in the original   Python file   those things were defined.   So that makes the development process easier and   helps to mitigate   some of the concerns I think people would probably have about putting JavaScript and CSS in their Python files. It   brings that visibility to the front end   dev tools in the browser.  



[00:32:28] Unknown:

As you're talking about, you know, having the JavaScript and CSS in with the Python files, 1 of the things that comes to mind is that this is definitely very conducive to a   full stack engineer's workflow, but I'm wondering what your thoughts are on   the kind of approachability   of this framework for when you have somebody who is more front end oriented but wants to work on a project that's built using Tetra. And just some of the ways that you think about being able   to accommodate people who have maybe   more expertise in 1 direction or the other, a front end versus back end, but want to be able to collaborate in a kind of full stack approach?  



[00:33:07] Unknown:

I think the advantage here is that Django   is such a good   framework, and the documentation with Django is so strong   that someone that has never touched the back end has only ever done front end development.   Very first thing you say when you come to Tetra is if you've not done any Django, go do the Django tutorial. The Django documentation, the Django tutorial is some of the best tutorials that you can get for any of these frameworks, I think.   I'm confident that anyone that's battled through and   got the hang of using   React and   Webpack   and all of the other front end tooling that you need,   coming to Tetra and coming to Django maybe for the first time, I think they'll find a breath of fresh air. I think they'll find   their productivity   increase, and they'll pick it up pretty quickly.  



[00:33:55] Unknown:

And so in terms of   the overall kind of design   approach of how you thought about what are the pieces that I wanna pull in. You mentioned that you used Alpine. Js. You mentioned HTMLX as an alternative.   I'm wondering   what were the kind of deciding factors that made you go with Alpine JS and how you thought about   the level of integration that you wanted to build into Django of, you know, how much you wanted to actually get into the guts of the framework and how much to just keep it kind of componentized and just a layer that gets added on top of what Django already provides.  

[00:34:30] Unknown:

Choosing Alpine over   HMX.   HMX and Alpine are taught together basically anytime you see them mentioned online,   and they   can work really well together, but they're filling 2   fairly   separate   roles.   HMX,   from my understanding,   is very much geared towards   calling   server side functions,   which return   HTML fragments   to patch into   your page.   I could very well have built Tetra on top of HTMLX,   but it doesn't have an answer to the   kind of front end only interaction   that   Alpine has.   So   you don't have to call back   to do a change   on the front end   with Alpine JS. You can just do the change on the front end.  

It gives you more strength on the front end than just HMX.   And in alternative stack, HMX and Alpine JS, I think work very well together.   Tetra is kind of filling the role of HMX   for Alpine JS with Django.   It kind of acts as that glue in the middle.   So far with what's been built, it's just a component   framework, although I have had to go quite deep into the templating system to make it work.   But the plan is to   eventually   be able to   take over more of   your   Django app. So   I want to enable   a more SPA   type app to be built with Tetra   by having   client side routing between components.  

So the plan is to   reuse   the   Django   URLs, but make it available on the front end as well   so that   you can construct a website just out of Tetra components   that can either be rendered entirely on the back end on the first view, but only the subcomponents   would then   be rendered and patched   as you navigate through the rest of the site.   The plan is to reuse as much of Django's   own   own tooling as I can.   2 reasons, really, to keep it simple, but also to make it easier for developers coming to Tetra to know what to do. If they've   got 10 years experience with Django, I want to make it easy to transition to Tetra as possible.  



[00:37:15] Unknown:

As far as the   syntax element, you mentioned that you have support for being able to provide highlighting of the different languages embedded in the Python files.   I find it interesting that that was 1 of the first things that you tackled, and I find it very encouraging because that definitely speaks to a concern for the overall developer experience and the ergonomics around it because   having worked in many different, contexts where you have multiple different languages or syntaxes jammed into 1 file, it's perennially frustrating trying to figure out which is which, and I'm wondering if you can talk to just some of the   challenges or complexities that go into being able to provide that level of support and how you think about maybe being able to support that across different editing environments so that you're not necessarily tied or locked to a given editor to be able to get that level of support.  



[00:38:08] Unknown:

You're quite right. I started that because   my entire   kind of motivation   is developer user experience.   I want to build something   that is optimized   for   developer happiness,   and   convincing anyone to put HTML in their Python file   in a significant way or JavaScript even in their Python file.   You've got to work quite hard to make that a convincing argument.   It's only the first stage of what I want to do there as well.   So I've only done Versus Code so far. I haven't it's the editor I use. I don't use any other editors.   I'm kinda hoping that someone else kinda picks up the mantle and goes, this is a good idea,   and says I'll contribute   support for another editor, really.  

It's partly also why I built it as a separate project because I could see the potential   use of it outside   of   Tetra.   The other day, I was looking at,   Rich, which is a brilliant   Python toolkit for doing   really clever UIs, but within   the terminal. So it gives you all the usual   UI widgets that you would get in a normal   desktop toolkit, but it uses the terminal to render it all.   And the rendering and layout is all defined using CSS. And so   you are writing CSS in a Python file with Rich to lay out your components.   And using   source types,   my Python inline source Versus Code extension,   you'd be able to get syntax highlighting   for your   CSS in your rich components.  

And   they don't need to even add specific support for that to the library. It's just a type annotation, which is actually just an alias of string.   So   it can just be put in on anything.   Long term, the thing I really want to tackle is   IntelliSense   or autocomplete.   At the moment, we get syntax highlighting for the inline   source,   but no no auto complete, and   that's gonna require a significant amount of work. That's a few months ago that I was last looking at this. The APIs   available in Versus Code to do it   aren't quite there.   So   jumping back to what we talked about at the beginning with Vue. Js and their single file components,   their   Versus Code plugin is enormous.  

They've basically had to completely reimplement,   I think, the HTML   renderer, and and Versus Code has something called a language server   to provide the autocomplete and and other sort of language features.   And that's a big project on its own, just the Vue. Js   Versus Code extension.   So, again, my hope is that if the inline source   highlighting   project is successful on its own, then we can expand that and add those sort of features later on, and hopefully in an extendable way. Because what I would really like to do with Tetra   for developer user experience   is to provide   cross language   autocomplete.  

So when you are   coding, writing in   a server side   public method,   you can write self.client.,   and it will also complete with   your   front end JavaScript   public methods so that you don't need to sort of track of what's there. It just does it for you. And then the other way, I'd quite like it, when you were   coding in your JavaScript part of the component if you got autocomplete   for your Python server side public methods. I think that's a very big wish.   Little way off yet. Need to   build the rest of Tetra and get people using it first.  

[00:42:05] Unknown:

As to that kind of longer term goals that you have for the project, I'm wondering if you can go over some of the maybe sort of grand vision that you have for it, you know, where you would like to take it going forward, some of the   potential roadblocks you see along that way, and how you are considering   the overall   sustainability and longevity of the project?  

[00:42:27] Unknown:

The problem, I think, that all large ish toolkits sort of come up against when they start off, To become sustainable,   they need to be used and grow a community   around it that helps contribute back and helps maintain it and support it.   But in order for people to commit   to   spending time   in that community   contributing to a toolkit.   They need, to some extent, believe it's sustainable and going to be around for the long term.   So it's kind of that initial stumbling block now, which   Tetra needs to get over. It needs to get to that initial   little step where there's enough people interested in it   that are   going to push it forward and keep it running.  

I'm a 100% committed to it. I think it's   well, I'm obviously biased,   but   I think it's the best solution for Django going forward, and   I want it to be the   de facto first choice full stack framework for Django. I want people to be deciding to build   with Django   because of Tetra.   And   so I'm planning to spend my   free time working on it and getting it to that point. As I said earlier, the plan is to get to a stable V1 release this summer so that at which point, I would very happily tell people to   build production   launch production   systems on it.  

And they had long term for me personally.   I would love it to become an important part of my own kind of day job. I would   as a freelance developer, I   love to get to the point where I was being   paid to   work on projects that were using Tetra or even on Tetra itself.   But I think it's got legs. I hope other people do too. It's early days, but we'll see where it lands.  

[00:44:24] Unknown:

As far as the current state of the project, I don't know how much usage you've seen around it. You mentioned that it has gained some attention. I'm wondering what are some of the most interesting or innovative or unexpected ways that you've seen it used? Or, conversely, some of the interesting   discoveries that you've made along the way of kind of maybe accidental benefits of what you're building and how you're able to use it? I would love to be able to answer that question.  

[00:44:50] Unknown:

Ask me in about 2 months. I think that's probably when I'll have a better answer for that 1.   I haven't seen   much yet of what people have built. It's only a month out of the door, and   it's gonna take another month or so before I think I really see any projects launching that may have used it. Maybe I should come back in a month's time and tell you the answer to that question.  

[00:45:11] Unknown:

In terms of the experience that you've had building it so far, I'm wondering what are some of the most interesting or unexpected or challenging lessons that you've learned in the process?  

[00:45:20] Unknown:

Most challenging thing probably to solve   was tackling the Django template system.   It is complicated.   It is   very clever, but very complicated.   Said earlier, 1 of the things I needed to   tackle was track, a way of   tracking   template blocks,   and I had to go fairly deep into the template system to work out   how to do that. And in fact, I've had to patch   Django's template system slightly to enable that, but it's an important part of Tetra to be able to do that. So, yeah, a challenging thing was getting my head around the templating system.  

[00:46:00] Unknown:

So for people who are interested in the idea of being able to have a tightly integrated   way to work with their Django applications and the front end interaction,   what are the cases   wrong choice? And maybe they're better suited with, you know, using something like LiveWire or just using HTMX or some of the other options for solving some of that problem of managing the complexity across the front and back end?  

[00:46:26] Unknown:

I think if you are building something that's in production right now, I think then something like HMX is probably the right choice if you are trying to   apply just a small amount of   interactivity.   My my hope is that in 2 months' time, the answer will be don't use ACMx, use Tetra.   I think also Tetra is probably the wrong choice if you are trying to build something that's sort of   desktop   class, trying to be   a full on   single page app with   maybe even offline support,   Tetra   is not going to support that level of   functionality.   And that's where sort of front end tooling that's around now with Vue and   React is the right choice.  

So I've never pushed people to use Tetra if there are better options, because there's a lot of options out there. This is just another 1.  

[00:47:20] Unknown:

And you mentioned a little bit about what you have planned going forward. I'm wondering if there are just any other elements of what you have on the docket for the near to medium term or any   areas of contribution or feedback that you're particularly looking for?  

[00:47:33] Unknown:

So in the near term, there's a few sort of built in components I want to make. The plan is to   to have a model component that ties in   nicely with the Django   ORM, so   kind of bootstraps   standard instructions for a component,   so gets rid of even more code that you would have to write.   So   the to do app example that's on the Tetra home page, the to do   item component there, rather than write it the way it is, you would write it with the model component and   probably end up with only about a quarter of the number of lines for that component that you currently have.   So there's various components like that all to tie in with the Django Form Framework to bring forms and validation from Django to Tetra.  

Longer term, I want to   bring some sort of WebSockets   and service end events maybe to Tetra.   I want to be able to enable people to do   real time updates based on   service date change elsewhere.   So if a model changes in the database   because another user has updated it, I want to provide a solution to update   a separate user's   session   so that   they can see that that update happen   in real time. And I've got a few ideas how to do that. I'm hoping to have maybe a draft of that for v 1 this summer. We'll see how that goes.  

[00:49:00] Unknown:

1 of the things that I didn't ask yet that I just realized is curious where the name came from and what your process was for figuring out what to name the framework.  

[00:49:08] Unknown:

It's called Tetra for Tetrahedron,   the idea being that a component   Tetra component   has   4 faces. It's got its server side Python. It's got its front end   JavaScript. It's got its HTML template, and it's stylesheets and CSS.   So you've got an object with 4 sides, and an object   Are  

[00:49:36] Unknown:

Are there any other aspects of the Tetra project or the problems that you're solving with it or your overall vision for it that we didn't discuss yet that you'd like to cover before we close out the show? 1 thing I want, and I would love your readers to do is go and have a play. Give it a go, and I want feedback. I want people to try building things and  

[00:49:54] Unknown:

tell me what didn't work or what they need. 1 of the kind of mentalities I've got going into this is,   to some extent, keep it small, keep the API   small, not too big, and   only add things when people ask for them.   It's very easy to get carried away thinking about all the possible ways of that people might want to use this and build everything possible,   but you end up with something that's unmaintainable and too big. So the plan is keep it small, build when people ask for things. And so, yeah, go build stuff, and let me know how you get on. Yeah. Keeping the YAGNY principle in mind is always hard. You ain't gonna need it.  

[00:50:32] Unknown:

Yeah.   Alright. Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us into the picks. And this week, I'm going to do some shameless self promotion and announce the machine learning podcast that I'm launching. So for anybody who is interested in that area of engineering and endeavor, definitely recommend taking a look at that. It's kind of a natural outgrowth of the data engineering podcast that I've been running for the past few years, so   definitely excited to bring that into the world. I just primed the feed, and I'll be having episodes going live   any day now and should be a roughly weekly release cadence for that. And so with that, I'll pass it to you, Sam. Do you have any picks this week?  



[00:51:17] Unknown:

My pick this week is   Slow Horses on Apple TV.   It is a brilliant TV show based on a series of spy novels, and it's starring Gary Old man and Christian Scott Thomas. It's well worth a watch. It's based on the idea of a bunch   of disgraced   Mi 5   operatives who get sent off to Slough House.   And for the non British listeners,   Slough is a rather rundown and not particularly well liked area of London.   So the implication being that they've been sent out to do not real work, and they get caught in   a situation.  

[00:51:55] Unknown:

And, yeah, it's good watch. Very good TV. Alright. I will have to take a look at that. So thank you very much for that recommendation and for taking the time today to join me and share the work that you've been doing on Tetra. It's definitely a very interesting project. Definitely excited to see it progress and potentially thinking about using that to build an application that I've got in mind. So I appreciate all the time and energy that you've put into making that a reality and continuing to support it, and I hope you enjoy the rest of your day. Thank you very much.  

[00:52:24] Unknown:

Thank you for listening. Don't forget to check out our other shows, the Data Engineering Podcast, which covers the latest on modern data management, and the Machine Learning Podcast, which helps you go from idea to production with machine learning. Visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes. And if you learned something or tried out a project from the show, then tell us about it. Email hostspythonpodcast.com   with your story.   And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.