Tetra: A Full Stack Web Framework That Doesn't Make You Write Everything Twice

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Unknown (00:13):
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,

(00:37):
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.

(01:01):
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.

(01:27):
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?

(01:54):
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.
And do you remember how you first got introduced to Python? I found it at the same time as finding Django.
So it was probably about 2, 006,

(02:17):
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

(02:38):
Ruby and Rails. And
I picked up Django first,
and it was my first introduction to Python.
That was it, really.
Worked well.
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?

(03:02):
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

(03:24):
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

(03:54):
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

(04:16):
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.

(04:40):
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?
So I had been spending

(05:02):
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,

(05:28):
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,

(05:51):
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

(06:14):
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

(06:34):
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

(06:55):
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

(07:16):
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

(07:37):
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

(07:58):
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

(08:19):
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,

(08:41):
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

(09:03):
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.

(09:24):
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

(09:45):
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.

(10:07):
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

(10:28):
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.

(10:48):
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.

(11:11):
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.
So the plan is to build something
that allows you to
simplify
the process of building

(11:32):
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

(11:53):
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.

(12:14):
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.

(12:34):
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.

(12:59):
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.

(13:20):
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

(13:40):
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.

(14:02):
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

(14:23):
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.

(14:43):
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.

(15:07):
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.

(15:28):
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

(15:49):
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

(16:11):
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,

(16:34):
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.

(16:55):
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

(17:16):
definition rather than on the component itself. That's 1 of the next jobs in a very long to do list.
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.

(17:42):
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?
I think well, firstly, on the sort of style and JavaScript side,
I think

(18:02):
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

(18:23):
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.

(18:51):
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

(19:11):
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

(19:32):
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.

(19:54):
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

(20:17):
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

(20:38):
or a single
list of functionality
in a reusable way.
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.

(21:05):
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

(21:31):
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.
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

(21:52):
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,

(22:13):
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

(22:33):
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

(22:55):
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

(23:15):
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.
Need to automate your Python code in the cloud? Want to avoid the hassle of setting up and maintaining infrastructure?

(23:36):
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

(24:01):
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

(24:26):
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.
So components
are kind of the center point of Tetra, and
they
all are rendered on the server

(24:49):
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

(25:10):
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

(25:37):
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.

(26:00):
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

(26:23):
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

(26:44):
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.

(27:05):
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,

(27:25):
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

(27:45):
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

(28:07):
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

(28:28):
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.

(28:50):
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

(29:15):
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,

(29:36):
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

(30:00):
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

(30:23):
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

(30:44):
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

(31:04):
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.

(31:26):
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

(31:46):
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

(32:07):
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.

(32:27):
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

(32:55):
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?
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.

(33:20):
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

(33:41):
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.
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.

(34:08):
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.

(34:29):
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,

(34:51):
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

(35:12):
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.

(35:34):
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

(35:54):
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

(36:15):
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

(36:36):
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

(36:58):
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.
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.

(37:26):
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

(37:51):
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.
You're quite right. I started that because
my entire

(38:12):
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.

(38:36):
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

(39:01):
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.

(39:26):
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

(39:46):
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

(40:09):
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

(40:29):
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

(40:52):
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

(41:18):
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

(41:38):
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.

(41:59):
Little way off yet. Need to
build the rest of Tetra and get people using it first.
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

(42:22):
the overall
sustainability and longevity of the project?
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.

(42:43):
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

(43:06):
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

(43:27):
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

(43:53):
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.

(44:18):
But I think it's got legs. I hope other people do too. It's early days, but we'll see where it lands.
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

(44:38):
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.
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

(45:01):
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.
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?
Most challenging thing probably to solve

(45:22):
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

(45:46):
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.
So for people who are interested in the idea of being able to have a tightly integrated

(46:07):
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?
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

(46:35):
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

(46:57):
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.

(47:19):
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?
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

(47:42):
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

(48:03):
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

(48:23):
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

(48:45):
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.
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.

(49:08):
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

(49:28):
Are
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

(49:54):
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,

(50:16):
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.
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

(51:01):
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?
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

(51:32):
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

(51:53):
a situation.
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.

(52:24):
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

(52:47):
with your story.
And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.

All Episodes

Summary

Announcements

Interview

Episode Transcript

Popular Podcasts

United States of Kennedy

Dateline NBC

Stuff You Should Know

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Tetra: A Full Stack Web Framework That Doesn't Make You Write Everything Twice