The Masonite Web Framework With Joe Mancuso

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.

When you're ready to launch your next app, you'll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 200 gigabit network, all controlled by a brand new API, you've got everything you need to scale.

Go to podcastinit.com/linode

to get a $20 credit and launch a new server in under a minute.

And visit the site at podcastinit.com

to subscribe to the show, sign up for the newsletter, and read the show notes. Your host as usual is Tobias Macy. And today, I'm interviewing Joe Mancuso about Masonite, the modern and developer centric Python web framework. So, Joe, could you start by introducing yourself? Yeah. My name is Jo Mancuson, like you just said. I'm a developer for about 10 years now. I started out as a kid when I was 14 years old. 24 now. And, yeah, I just have a love and a passion for developing software and

projects.

And do you remember how you first got introduced to Python? So I started out when I was 14 with the normal HTML, CSS, you know, the whole front end stuff. And then I got I introduced myself

to PHP,

and I've been into that for,

pretty much until I was I joined the military and all that at 18 to 22. And

when I was 22, I got introduced to

Python and Django.

Python, I just wanted to learn Python just to learn Python, so I went to the whole Codecademy thing and kind of introduced myself. And then I've learned I knew,

PHP so well at the time that learning a new

language was just became natural.

So and Python is so beginner friendly and and intuitive that it only took me like a month to sort of master it, and then, I got into Django. I did that for about a year,

and that's how I got introduced to the Python world. And you recently

started the Masonite project.

So I'm wondering if you can talk a bit about what it is and what was your motivation for creating it in the first place.

So what

Masonite is, it's

a batteries included Python web framework that's going to rival Django. So

a lot of the time they kind of compare Mesa and Django and how Masonite might fit in, but

I'm kind of designing it to compete directly with it. So I mean eventually hopefully there'll be

maybe Flask and Masonite and Django could can be 3rd. We'll see. But,

That that's an ambitious goal.

Yeah. It has to be. I mean, when you when you're trying to

to overtake the unmoved movers in the Python community, it's you you you gotta put Masonite

somewhere and then just try to achieve,

and try to get it to that place.

So but but the thing is that it's

it's kind of redefining what batteries included is. It's more of a batteries included, like, Laravel is a batteries included.

So Django might not have things that you might need, so you might not have,

for example, s 3 might not be built in.

You might not have,

notifications

built in like text message notifications

or email notifications or database notifications.

So all that sort of being built into the Masonite framework.

So you really just

do what you need to do and use the semantics of Masonite itself.

So for and that's something else I want to explain about Masonite

is sort of where I see Masonite fitting in. Like I said before, where I'm sort of putting it in a place and trying to get it there.

I'm sort of picturing how

Django is like an IBM

and then Flask is like an HP, right, in like in the seventies and eighties, and Masonite is like an apple. So you're trying to move these unmoved movers and trying to liven up the community at the same time. So that's that's sort of where I see it. So Masonite

the reason why I compare Masonite to Apple is because

the word Masonite comes from masonite board, which Masonite board is what artists use to put their artwork on, so it sort of like flattens it to create like a hardboard.

And so that's where I want to think of masonite framework is that the framework is

a place where you could put your artwork on and sort of

just like a normal framework, right? We're building this art and we're using these tools to build this art, and

so with that

kind of artsy

and creative feel it has things like craft commands

which

are used to basically scaffold the application for you,

And with the craft command actually

when I originally started Masonite,

we

found or I found this

or this developer found me, who is like an artist, I think. I don't even think he was a developer. I think he's an artist, and he wanted to develop a logo for it.

So I was like, great. So we did a call, and he showed me, like, these concepts,

and they're all, like, of cauldrons

and, like, brooms and, like, witchcraft.

That's what he thought when he thought of craft commands whereas these, like, witchcraft commands, like, you're you're crafting something. So but the way I want it to for people to look at Masonite and using these craft commands is that you're crafting

a controller, you're crafting a class the same way like

a blacksmith might craft a sword

or a chainmail or something. So

that's sort of where masonite is and

sort of where it

should fit into the ecosystem and and what I'm trying to achieve

by creating it. And when reading through the documentation, it's clear that you put a lot of thought into

the architectural principles

and software design with things like the

inversion of control containers and dependency injection built into the core of the framework. So I'm curious

what your

inspirations

were for,

other projects or frameworks

that you were looking to for trying to see what would make for a,

reasonable

and,

robust target for being able to

use as a foundation for your new project?

So the

architectural

design principles that I I sort of took

from other projects was

Laravel.

So Laravel obviously has the,

IOC container,

and the entire framework is kind of built around this IOC container, and they have this, like, auto resolving dependency injections.

They have all these, like, design principles and and the manager,

pattern and stuff like that.

So when I originally

the original foundation of the project was

I just wanted to learn what the heck a whiskey was, so I basically started

going way back to the beginning and the build up to the architecture was I built everything

let's go back a little bit more

so the way WSGI works is

you have this

entry point So it could be gun of corn, it could be waitress, so you have this entry point where it

passes basically a dictionary into

whatever function that you want. So inside this function to be called the app function

is all the kind of all the logic for it. So it could have the route parameters and it could have the cookies and all this stuff, and inside that function is where you put all your magic or not your magic, your your framework stuff or

your guts

and

you can sort of abstract it away, you can import classes into this, and do whatever you want there. So what I did was

to learn all of this, I put every single thing

inside this function. So this function was like maybe

500 lines long

and that was the framework,

and to make modifications, you had to make modifications to this giant function.

And I thought it was cool. I mean, it was doing cool things. It was just completely unmaintainable, and

it was actually inside the project itself. So if I needed to, like, upgrade the application, you had to make a whole new application.

So there were sort of these learning principles, but I thought it was cool. So I put it on Reddit,

and it was called, like, version

0.3,

and it got completely demolished. Alright. Everybody hated it because it was sort of cool. I got some cool feedback, but everybody said like it's completely broken and it's it's it's never going to be a thing, which stuff like that drives me, So what I did and 1 of the 1 of the recommendations and feedback I got was that it wasn't modular at all,

and I really didn't understand the concept of modular.

So I went to

other frameworks for inspiration, so I went to Laravel, Django,

Rails,

and I just previously came from the Laravel world. So I had that mindset of

service providers and IOC container and a provider's list or an array, right, from Laravel.

And so I sort of built like these principles and it was actually turning out into something cool.

So that went up to like a 1.3 release was the first time it actually had like an IOC container. And the reason why I wanted to do that and put it there was I saw as I'm developing something, right, the best way to learn something, I think, is to actually develop it from scratch.

So then you know exactly how it works and you know exactly where things will break and where's the strength and what the weakness is.

So,

as I'm developing

all this stuff, it's like slowly turning out to be awesome, and I'm starting to see the power of it, and I'm starting to take little pieces of the application and test it.

So that's why it went from like 20% testability to like now I think we're at like 92%.

So the framework is really really well tested it's actually really really stable,

and it's at the 2.0 release, which is really good. And so yeah, so I learned that like the IOC container is extremely testable because you could load things into this container.

And for these those of you that don't know what an IOC container is, should I go in to detail on that? I can add links in the show notes for people who wanna dive deeper on it, but, if you wanna just give a quick overview of sort of the principle. Okay. Sure. So a brief overview and and how at least it works in Masonite is

there's a class called it's called the app actually, but it's actually a container. That's what it's called, but it is a container. So

you have this dictionary

inside this class that has every single class that you need inside a dictionary.

So now you could use this container

to fetch things out of. So say you want to you loaded

an upload driver for loading things onto the file system,

so you have your

sort of your API that you use for that, but if you wanted

to do maybe Amazon s 3,

you simply just take it out and put in an s 3 driver and you just swapped out the whole functionality of your of your code. That simple.

So, yeah, just a container is you just load things into it and then you fetch things out of it when you need it. Now

what's even more powerful was what I saw was the dependency injection, which is doing the exact same thing, but all it's doing is before it calls your controller method, it's just reading your parameter list and then just fetching things for you. So you basically load it into your parameter list, so you might like in django, you have a request.

Right?

So with Masonite, you would put the request there,

but Masonite is actually injecting it for you into that. So you could put anything you want there. So you could put an upload driver there, you can do whatever you want, and it'll inject it for you, and it knows exactly what you need. It's more powerful than just simply importing classes because it's swappable now.

So you could add a service a service provider from a third party package

that kind of adds functionality to your framework or swaps it out or adds methods

to a driver that's already there.

So,

it's 2 really, really powerful concepts, and and I really think it's a superior architecture

for frameworks

just because there's such a reliance on testability, and and it's almost harder not to test Masonite than it is

to test it. So,

like, it's it's just so easy that you have to do it. Django, it's a little bit harder. It's it's not built in a way that's testable, right? It's like it was built in 2, 000 what, 6 I think or 2003 or I think 2006 and, it just kind of evolved and it uses some strange principles. So it's just kind of evolved over time into this

thing that I don't think is

good. I mean, it's great. I mean, Django is really good, but I think Masonite has the potential to overtake that spot. And people that use it have nothing but good things to say about it. Like, so once you use Masonite, you you're kinda hooked into it. Everything sort of makes sense. And so

as you mentioned, 1 of the aspects

of Masonite that makes it appealing is this,

easy pluggability

and extensibility.

And

in general,

1 of the things that has helped Django maintain its momentum and its,

relative lead in the,

web framework space for Python is

the community contributions and community modules.

So I'm wondering

how much engagement you've seen from the general community as far as creating new plug ins or some of the interesting uses that people have put Masonite to?

So I've been,

so I I fully understand that, and I know

that a framework is really only as good. There's 2 things that make it make a framework good, I think. 1 is the community around it. Absolutely. So someone who has a really good community for someone who has a really bad community, the project that has a really good community always wins no matter what. And the second thing that makes a framework good or a package good, in my opinion, is

that nobody cares

how many features are in your framework. Nobody cares what your framework can do.

Nobody cares.

The only thing that people care is how they're how are they gonna interact with that framework.

So if they get to a certain part on the framework

where

it's too hard or it doesn't make sense, they're just gonna revert back to, like, what they know, and it's it's almost harder to learn something new than it is to not learn something new. Masonite has a really, really simple API. So once you're going through each step, everything just feels natural

and it just falls into place and you you're knowing how things interact with other things and you're abstracting things

by its very nature,

just because it's very, very easy to do to abstract things in Masonite.

So yeah. So the the pluggability of the framework is actually really big. When I develop a new package, it really only takes me, like, a day

to do what I have to do just because I could literally

basically code a project and then create a a single entry point for that project calls called the service provider, and then anybody can plug that into their application.

And all it's doing is all you have to do to develop a package for Masonite is load classes into the container.

Like, that's it. That's all you have to do to connect a project to mace or a package to Masonite.

Everything else, like the user in your documentation, you could tell the user, okay. You have to take this out of the container,

use it to interact like this, and

so on and so forth. So,

like, recently I just created a a notifications package,

and I just implemented a Nexmo, which is a text message

service.

So now I can send texts right from my project,

And

it took me like a day to implement the entire thing for text messaging, for

and I only code at night too, so it really only took me like maybe 4 hours

to code these packages. So it's really simple. The documentation

is

super

super extensible from the beginning of the project from, like, 0.03.

I knew I knew I knew that

documentation was huge. Like I needed to have a really really well documented package.

And so if you need any like questions or how to implement things,

you can just read the documentation. If you have any questions I'm super super active in the community

you can join the slack channel

which is a slack.masoniproject.com

and you can join there and you can ask any questions. The community is pretty active when it's active, right, so when everybody's sort of on.

We have 2 maintainers, me and

this developer named Abram, and we answer pretty much any questions that that come in. And that's 1 thing that I definitely noted as I was researching for this interview is that, as you mentioned, the documentation is

very complete

and reading through it was very well put together so it was easy to try and see how you might use different aspects of the project.

And some of the features

that stood out as being somewhat unique, at least within the Python landscape,

is the

built in support for

the,

asynchronous

tasks for 1, but also for,

WebSocket

support using things like Pusher.

Whereas for a lot of the other web frameworks, there is additional

dependencies required for being able to have some of that dynamic

bidirectional communication within the framework.

Right. And I think that's why Mason and I I kind of coined the, the term of the modern developer

Python web framework and developer centric because, I mean, things like that. I have a principle that

things should be taken out of a framework

rather than put into a framework.

So if you don't use something since Masonite is so extendable, all you have to do is remove the import of the provider and you don't have it in your package in your project.

So I'd much rather take things out than sort of take maybe an hour to implement things, and and I'd rather have it there and then be able to add more to it than for it to not be there and you have to implement it in the first place. As for the documentation, I have this

concept early on that there's a developer on YouTube named

Matthias Petersen, I think it is,

and he's the fun fun function guy he just took over

dev tips, I think, and he has this concept of no commits without tests.

So if you're trying to implement tests in your project and your team,

the best way to do that is

to say don't commit this code until you have a test for it. So what my ideology is

is that you no pull requests

without documentation.

So I try to make it extremely extensible. So I have, like, a basically a staging branch

where I list all the features as, like, what I call a running change log. And right next to each feature, I have a little checkbox that says documentation.

And once I document something, I'll check it, and once everything has checks, then I'll merge it in. So that makes things

super easy and everything is there. Like, every single part of the framework,

should be documented just by that very

nature. And I also noticed that Masonite only supports Python 3. So I'm curious if there are any particular features

of the 3 dot x releases that you're leveraging in Masonite that you found particularly useful as you were developing and evolving it. So Mason originally started out trying to support as many things as possible, and I realized that it was actually really hard to do to do that and because if I tried to support 2.7

and 3.3 plus, let's say, once 4 comes

out, then I'm in, like, a predicament. Like, the peep the projects that started out, you know, a decade ago

are facing those problems today because now you have 3.7 coming out, you have

all these new Python versions coming out. Mostly most of them are pretty

backwards compatible, but trying to support,

2 completely different major versions was going to be too much. I figured if anybody's going to use this project today, might as well start out with the best technology.

So I started out with 3.3 plus

just because the packages I was using those were supported.

Those are the minimum supported versions. So as I'm adding

packages, I have to ensure

that it also supports the minimum of Python versions I'm doing. So it started out with 3.3 and then I added, I think, a cryptography

package, which only supported 3.4.

So the sort of ideology we're coming from is

support at least 4 packages in a row. So when 3.8 comes out, we're going to drop support for 3.4. Not saying that the code will break on 3.4, but we're not gonna intentionally we're gonna remove it from the Travis tests essentially

and just do 5678.

So there's nothing

as for what it's using in 3,

it's just using the normal

standard packages

in 3. I mean nothing crazy that

might break in 2. I mean the major difference between 23 is really renaming of various built in packages and

and package support external package support. What it is using

what it is using is,

annotations

that's actually a huge, huge part

of Masonite is not a huge part, but it has

so basically what you for automatic dependency injection going back a little bit you can put so say you have your method class, right, which is starts with self and then you have comma,

and then whatever you put there needs to correspond to a key of the dictionary in the container. So if you have request, it looks for the request key

in the dictionary in the container and injects that class that's attached to it. For so basically right? So let's look up by key. To look up by value, what if I don't know the key? I could look up by the class itself. So if I want to get a an upload driver,

I can use an annotation where I have request colon and then normally you have like a string annotation.

What you could do is you could just put a class there so it'll look up that class. So that's actually a huge part of Python 3. I think that was introduced in annotations, I think, was introduced in 3 0. So we're using that and that's huge. But what's also huge for dependency injection is that it seems a little bit weird

to me at least to

to fetch by class or by key. So what's even more powerful is what is she what if you fetch by, like, a base class?

So all upload drivers inherit from

a upload contract, which is just a class really,

like an interface almost if you're coming from

PHP.

I don't know if Ruby has it or not, but

an interface. So you're inheriting

from that class. So if we

basically annotate

a upload drive or upload contract, it'll give me the upload driver.

So

I could basically take out all drivers from the framework, replace it with any class I want, and as long as I'm uploading from or inheriting from the upload contract,

it'll give me a class that can upload. So we're using, we're leveraging,

Python annotations a lot, but you don't have to use it. It's just a feature. And for somebody who is

starting a new project,

if they don't necessarily

have Python

as their

sort of decided language implementation if they're just shopping around for a given framework? What are some of the features of Masonite that might make it,

stand out and help drive somebody to use Masonite as a framework

and Python as a language versus some of the other available options that they might be considering?

So the major difference between

a Django

selection and a Masonite selection is that they're really coming from

2 completely different worlds, which is weird to say because they're they're basically implementing

the same thing, right? They're basically django is to build, you know, software applications

on the web and Masonite is to build software applications on the web

and but they're coming from 2 different paradigms where

you should really pick

the 1 that makes sense for you and not necessarily the 1 that's that's better or it just if you're building an application, it needs to make sense what the heck you're doing. If you've ever used Django and you're

sort of like it seems like a little too magical for you, it's your you ever ask yourself why are we doing it this way? This seems weird to me. Then you should definitely try out Masonite.

If you're coming from a different language, like,

I get a lot of developers from

Ruby and Laravel,

And if you're coming from those languages,

everything sort of just makes sense to you because it uses a similar architecture. The ORM,

every other Python web framework,

uses a data mapper ORM,

which basically means

you're going to specify

your attributes or your columns

on your table as attributes on your class. So you're basically the way I look at it is you're mapping a data mapper ORM is mapping from

the model to the table, so you make the model look like the table essentially.

And with Mason, I kind of went on a limb here

and I'm using a active record style ORM, which in active record style makes the the method or the sorry, the model

sort of replicate the class of the table.

So because of that, we can separate

the

model from the migrations completely, so

which which we do. So you could basically remove the ORM if you want to

and sort of replace it with your own ORM.

There's no reason to do that. I think Python developers, once they get a taste of

active record,

they're gonna love it, and then I think they're gonna like it a lot more. As with migrations and stuff, migrations are completely separated.

Django uses

the MTV

structure for MVC, their their own interpretation of it. Masonite maintains the traditional

MVC,

so maybe a quick

sort of similarity would

be Masonite has what's called controllers, right, in the c and MVC,

and

Django has

function based views and class based views.

That would sort of be the C, right, so

there's

for those listeners that are sort of getting into it, there's 4 if you've learned this in college there's 4,

architectural concepts of any application.

There's

business logic, presentation logic,

data accession logic, and data storage.

So

the developer community sort of took those data session business and presentation logic, and they sort of created this MVC structure

and various

libraries and frameworks and and you got Vue and Node and all that. They sort of

took it and Swift. They sort of took it and they they kind of ran with it. So now you have things like MVVM,

MVT,

MVVC,

like all this kind of crazy stuff. So it's really just a different

paradigm. And to give a little bit of a better example

for those of you I'm sure a lot of listeners are familiar with Django, so I keep on going back to Django.

So with Django, you

have function based views and class based views.

So a class based view

is basically like an abstraction

of a function based view. So a function based view is just a function. It takes a request to return the response and a class based view has does sort of the same thing, but it has like a lot of framework hooks you could tie into it and inherit from and different template views and all that stuff and mix ins.

So with Masonite, it's actually a lot simpler than that. It's really just a class.

That's it. Just a controller. A controller is just a class, and inside this class there are these methods

and these methods return various views. So a class based view might work on a single template

where a controller

itself works on an entire feature. So you might have like a setting controller, which works on all your your settings and your various methods and a class based view might be like get and post, but in

Masonite your methods will be

show store

delete.

Right? On these settings it might be

show profile, it might be show

show leagues if you're creating like a some sort of like a sports based thing,

show teens, and you're sort of encapsulating

all your feature logic into this 1 class and you could abstract out as many classes as you want.

Django sort of does a

higher level where they have like apps you can abstract out entire apps which have their own models and stuff like that,

And if that, like, makes sense to you, I mean, more power to you, it's

it's

it's weird to me and a lot of other developers, so a lot of people that use Masonite,

everything just clicks to them. So if you're coming from

if you want something different,

then you should definitely try out Masonite,

essentially. Yeah. When I was looking through

how the applications were architected, it reminded me a lot of Rails because that's what I have experience with.

I haven't used Laravel to be able to have that comparison in mind, but the whole idea of

the conventions

being,

very strong for being able to structure your application, rather than having to define a lot of configuration

to tie things together,

and having the easy scaffolding commands for being able to create different

portions of your application,

to help get things moving quickly. And then also the active record style ORM to make it very,

sort of, literate style in terms of when you're interacting with your model objects and the traditional MVC structure. So,

anybody who's coming from that type of application environment and wants to experience it in Python, it definitely seems like it would feel very natural and familiar.

And

for somebody who has decided that they want to use Masonite for a new project,

what does their workflow look like for getting it started

and iterating

on the development?

And how does that differ if they're coming into an existing project and want to add new features to Masonite?

So from the beginning so the installation is

fairly straightforward. I mean, you're the the workflow is a little strange, so,

not strange, but it's, it's different than probably what a lot of Python developers using Django or Flask are familiar with.

So you're basically installing a command line tool to your computer,

which has like 3 commands, which has like a new command, an install command,

and a package command, I think. So

once you have this tool it's going to be your best friend.

So I'm sure those of you that are coming from

Laravel or Ruby or

Rails is probably a little bit different because the command line I believe is attached

to your actual application.

So

like in Laravel has like an artisan command, right, and that's in like an artisan dot PHP file or or something like that

in the base of your directory.

So

can you can kind of execute it using a PHP

command, so PHP artisan.

With craft,

you're installing the command line to your computer, so you could do craft new in any directory,

right? And

you're installing it there. I think I

think Laravel actually even has their own command line application,

but you're always going to be using it. So you're never going to do like so if you're using like a Laravel new and then you go into your application, you do like a PHP artisan,

you're always going to be using craft with Masonite. So you do a craft new, and then when you're inside an application

directory it's actually going to pull in commands from that application itself,

so so it might be different depending on what

application you're using and the commands might be different depending on if the developer who built the package

added those commands to begin with. I mean, you have all your basic applications, right? All right, you have your all your basic commands and then so that's a little bit different.

As for an existing project,

I've actually a developer in the community built a what he called Masonite forums,

and it was basically a Quora

type q and a and so I was like, you know what? I'm gonna build some some features onto this

application that he built because it's super cool.

So I, you know, git cloned everything and

and I

did like a it comes with a craft install command, so I craft installed, which installs all the dependencies and generates a secret key, and

I got his project up and running in

maybe a minute to 2 minutes. So when you're coming from an existing application, it's actually

super it's the exact same thing, right? You just have your application there

and you could switch between them easily.

I always do it inside a virtual environment, which makes things a little more simple. So as for the

the actual workflow,

normally if you're coming from, again, from Django, you might create

a class that you inherit from a class based view. You might create an actual function. You might go in and create a route, and then once you do that, you'll create a template.

So

for the workflow when starting a project and

for

sort of developing the project, you're

using this craft command

to actually scaffold your application.

So you're probably really annoyed at, okay, now I have to go create a class based view. So let's create a class, name this, let's inherit, let's import this.

So with Masonite, you're just doing crafts controller

and then you give your controller name. So crafts controller dashboard controller

and it'll create a class for you and put it in the correct folder and you can move it wherever you want after if you need to.

But,

so it sort of

makes

developing applications

quick

and things start happening quickly, and and that's actually the feedback I got a lot was, wow. This this makes things happen fast. That's sort of the feedback I get.

So if you need to create a so in any route, right, you create a route, you create a controller, you create a view or a template if you're coming from Django. You create a view, and

you kind of sort of connect those 3.

So with craft you can create a template

super easy create a view

same thing.

You can create your controller, which adds a little method for you that you could start developing.

And as for your route,

all you have to do is really just create that route or connect that route to the controller.

That's it. That's all you got to do. So it makes

things happen quickly so you don't have to be like, I don't know, where was I again now that I have everything set up? Oh, right. I wanted to create a dashboard.

So it's not, so it's really, really easy

to get started. And also Masonite has

which this is really subjective. I know a lot of Python developers

might not like it, but they don't have to use it, so they can remove it from the application if they want to. But

there is a service provider that ships with Masonite called a helpers provider.

And what these helpers

actually connects

with

the Python built ins

and actually adds built ins to your application.

So

just like you do a print statement, right, print parentheses,

you would do a view parentheses.

You don't have to import. It's sort of coming from a little bit of a magical place,

but it's super fast to like scaffold something. So if you just wanna just do view and then you return a view and just make sure it works,

then you're good. And you create all the logic around it and it works, and then you can sort of, you know, a minute after, you can go back and

and restructure

and rescaffold it or

refactor it and all that stuff. So it makes things

happen really, really quick, and that's a lot of the feedback I got. And

as you continue to work on the Masonite framework,

what are some of the plans that you have for it in going into the future, both for the core project itself and for any additional plug ins that you plan to incorporate into it or provide sort of, in addition to it. So the future of the framework, like I said, I I see it at the top right next to Django

or before Django, actually. Right? Django would be after. And Flask, I don't care where Flask is since it's sort of a microframework. So to compare

Masonite to a microframework is a little unfair,

but, they're both batteries included framework. So once I see it there and I'm working on it every day,

I add issues to the GitHub

repository, I create articles for it constantly, right? I'm huge into the documentation part, and the future for it is

creating various applications with it. So I'm only creating packages

when I need them. So, like, the notifications package, like, I needed that in my application, and it's super, super simple. It's like to send an email or a text is, like, 5 lines of code, and it's only 1 line of code in your controller. So, especially with the craft command, I can, you know, craft that notification, and it'll create the class for me and I just add my logic and then that's it, and then I resolve it from the container.

So for

packages like I built an API package, but I am not a big fan of it just because I haven't actually used it yet so it's never ever good to create a package when

you're not personally invested in or you're not personally using it. But when I put it on Reddit a while ago, like, that was huge. Like, everybody needed an API package, but what I was working on at the time

didn't need 1.

So so if anybody is huge into APIs, there's a couple people in the community that are and they're they're going to, you know, work on developing it. And once I start building a package that requires an API, it'll be

much better. So

So I'm very so anytime I come across

my code where I'm like, man this is super bulky, this is

not good, this is ugly,

I

try to abstract it into a package. That's all it is. So maybe

it was just like the notifications. Like the email class, I'll admit, is a little bookie, so I abstracted that email class into a notification class, sort of transformed it, and now it's super awesome.

So anybody coming in that sees like man this is weird,

The API is a little off

definitely needs to

let me know and we can definitely work on it, like,

for hours, I will just stare at a single line of code and work on refactoring out and making it smaller and more intuitive.

And I have this since we're I'm trying to picture

Masonite as, like, an apple, I'm I'm huge into I've always actually been huge into Steve Jobs and how he does things. In 1 of his talks, he says

that you can't take a technology

and give it to a customer,

right, and make them use it. You have to start at the customer

and work your way backwards to the technology.

So all features

that I write start inside the controller. So I create exactly what I want it to look like, and then I work backwards to the implementation because, like I said before, nobody cares what features you have in your framework. The only thing that people care about is how they're interacting with your user experience

and your UI, and that comes with anything. I mean, Trello is

is I mean, there's a 1, 000 things that do Trello, but Trello is so simple. Like, it's just it's the user experience of you interacting with it. Things that should be clickable are clickable, and and it sort of also works with packages. Like, sort of things that should work

should work, and you have to kind of work your way backwards to that. So so that's been my my lead thing, and it's sort of always weird to

like, do I spend my time working on

a service for me

or do I work or do I spend my time working on Masonite itself?

So it's all it's sort of like a sort of weird battle where, man, I could be building this, but I could also be building more features onto core.

And as for,

I mean, as for any ideas, like, I'm I'm completely up I'm completely open to what Masonite can be,

and I love the feedback that I'm getting from the community so far and the Slack channel that we run. And, yeah,

that's sort of the future of it. It should be,

in December. We're gonna really every 6 months, we do a release.

It uses

instead of.

So romver right now it's at 2.0, December will be 2.1,

and then June well, I'm looking to shoot for a 2.2 release that's a LTS.

We're gonna try that out,

so hopefully it'll sort of force a lot of businesses to sort of my or, sort of get into Masonite. Because once developers start using it, they they love it. So I just need to

get them to use it, and then that's it. I I have them hooked. Alright. And are there any other aspects of Masonite

or any of the related work that you're doing with it that we didn't discuss, which we should cover before we close out the show?

No. I think I think we covered everything. So with that, I'll have you add your preferred contact information to the show notes for anybody who wants to follow-up with you or get involved with Masonite. And so with that, I'll move us into the picks. And this week, I'm going to choose the,

YETI brand coffee mugs

because

I was

searching for 1 for a while and found those, and it does a phenomenal job of keeping things nice and hot for quite a long time. So,

been taking advantage of that daily, and,

if anybody's

on the lookout for a quality mug, it's definitely worth checking those out. So with that, I'll pass it to you, Jo. Do you have any picks this week? So there's

2 picks that I'd like, and the first 1 is,

gitbook.io.

So what gitbook is is a it's what Masonite uses to to host documentation,

and it's actually a really, really awesome service. It makes documentation simple. They actually just reversed the, released the version 2,

which

is buggy, I'll admit.

I think they prematurely released it,

a little too soon, but

I'm a I mean, I'm a huge fan of just releasing things. Like, I I released version 0.3 on Reddit, and it got destroyed.

So, but it's a really awesome service. They're coming out with new features all the time and it it's like

a a really good user experience of building documentation.

My second pick would be

dev.2.

I'm sure a lot of your listeners are familiar with that but I actually recently got into that,

like a month ago

and dev.2

is

a it's like a medium and you but it's for developers, so everything is developer oriented.

You

write articles in markdown

and their syntax highlighting is just phenomenal,

and that's where I'm

sort of putting all the

the

additional

documentation for Masonite where I basically take a section of the documentation

and I extend it out into a more

me talking to you type of experience.

So if you wanna check out,

dev.2, that's that's really awesome. Those are my 2 picks. Alright. Well, thank you for taking the time to talk to me about your work on Masonite

and for your efforts to build a viable competitor to the,

long standing Django

supremacy.

So good luck with that. Yeah. And, I hope you enjoy the rest of your day. Thank you for having me.

The Python Podcast.init

Summary

Preface

Interview

Keep In Touch

Picks

Links

The Python Podcast.__init__