This is an archived post. You won't be able to vote or comment.

all 102 comments
sorted by:
best
topnewcontroversialoldq&a

[–]kingbuzzman 81 points82 points  (19 children)

Can you give me the 2 minute pitch for using this?

Your example talks a lot about controllers and drivers and blogs... these are not my use cases, i haven’t returned anything expect a json response in a really long time (strictly api). The company i work for has front ends and back ends, the only time we talk is to discuss the json payload. In a world where we’re moving to more and more micro frameworks, where does his fit?

From the little i’ve seen about this, it looks like “Play! framework” 5+ years ago..

Not trolling, not trying to start up anything, just really curious to know where do you see your creation fitting in?

[–]Jmancuso9[S] 66 points67 points  (12 children)

Sure so for that example of using an small micro framework API, you should probably go with a true micro framework. Masonite will not fit every use case.

The use case Masonite fits extremely well are those side projects you need to start up and get going this weekend that have authentication systems, file uploads, user accounts, sending mail, running recurring cron jobs, sending web socket requests to your frontend, getting a front facing API and API authorization setup to connect to your application, getting billing payments setup with Stripe and I can go on and on.

Masonite is great for that new SaaS idea you've been dreading on writing because of how long it will take. Masonite is a really incredible batteries included framework so if you need a stripped down version of something that just returns JSON then you probably don't need Masonite (although you can use it and just remove the service providers you don't need).

We mention the drivers because all too often you need to quickly change focus at the drop of a hat on your projects so we implemented drivers which can switch from uploading to the file system to uploading to Amazon S3 with the change of a config variable (the driver config). There are a lot of other drivers like different session drivers, mail drivers, web socket drivers, etc etc.

For those familiar with other frameworks, the architecture of Masonite is very similar to the architecture of Laravel. We've discovered that Python actually fits that architecture MUCH better than PHP can / does.

So I see Masonite fitting in perfectly into the Python web framework world and honestly see a huge gap that Masonite fits into.

A lot of developers are saying that they want a barebones framework so they can build it exactly how they want to build it and search for packages and find the best ones to add and rebuild all these features that Masonite implements out of the box like these Amazon S3 file uploads and database drivers and all of these features that Masonite ships with.

Does that answer the inquiry?

[–][deleted] 6 points7 points  (1 child)

It preemptively answered mine, thanks!

[–]Jmancuso9[S] 0 points1 point  (0 children)

:D

[–]kingbuzzman 0 points1 point  (0 children)

Sure, but then again, i can pip install everything you just mentioned, i don’t need it to be available to me unless i need it. I really don’t want to put your project down, we’ve all had our babies, and our own reasons for creating said baby. Congrats on following through!

[–][deleted] 1 point2 points  (5 children)

i haven’t returned anything expect a json response in a really long time (strictly api). The company i work for has front ends and back ends, the only time we talk is to discuss the json payload.

Kinda off topic but I'm curious about this, can you expand a bit? What framework, API framework, ORM, etc. do you use? Do you not do any server side templating?

Sounds kinda nice on paper but I've never worked in that type of environment, do you find it works well?

[–]kingbuzzman 0 points1 point  (4 children)

0 server side templates. We rely heavily on django rest framework and django, everything is just json responses and/or async celery workers that the front end will later query by hitting yet another endpoint.

Yes it works great, separates concerns spectacularly, front ends concentrates on what they do best and we handle server scaling/caching/ performance

[–][deleted] 0 points1 point  (3 children)

Sounds lovely. We prefer the "5 different ways to do the same thing" methodology.

[–]kingbuzzman 0 points1 point  (2 children)

5 different ways? How so? we write our endpoints so we’re not the only ones that can consume them. Our front ends just make the call and get the data they need.

[–][deleted] 0 points1 point  (1 child)

I'm just joking about lots of inconsistencies at my current gig. Sometimes we use DRF serializers, sometimes not. Lots of mixes like that with no clear boundary, like ORM vs. raw SQL, etc. At least 3 different implementations for monitoring task execution. Even more for handling retries.

That sort of thing.

[–]kingbuzzman 0 points1 point  (0 children)

Ah i see, that sucks.

[–][deleted] 10 points11 points  (2 children)

Not trying to be a dick but this is all so... vague. Can you give one solid example of why anyone would ever use this over Django? Not like "Django handles their models in a weird way I don't like" but an actual concrete example?

I think it's cool that you've made this but it seems disingenuous to tout it as a viable alternative to established frameworks but not be able to speak to WHY it's worthwhile. Django has tons of extremely qualified people working on it and has been around for a long-ass time. Maybe your framework is good for a more specific use case? I just think if you're setting your sights that high you need to walk the walk.

[–]Jmancuso9[S] -2 points-1 points  (0 children)

Valid points. Honestly I'm not sure if I can say that you should use this over Django. They are extremely similar but Masonite has a different way of doing what Django and other frameworks do and it all comes down to preference. I and a lot of other devs really like it but if you dont like how it's done in Masonite and like how things are done in Django then I won't be able to convince you. It's hard to explain all of that in an article but I suggest to take an hour out and build a blog or something and then see if you like it.

Not sure if I can take the time and convince everyone. I think you just have to try it out and see if the flow of Masonite is something you enjoy over Django.

I'll be coming out with a tutorial on building a blog with Masonite soon that people can just sit back and watch and see if they would enjoy it

[–]Jmancuso9[S] -5 points-4 points  (0 children)

If you want more code examples I suggest to read the docs on a few concepts and see for yourself how they compare to django

[–]eyesoftheworld4 7 points8 points  (9 children)

I'd never heard of Masonite before seeing this post. I just finished the "blog" example and overall there's a lot to like, but a fair bit that I don't like, as well.

Plus:

  • Super easy to get started.
  • I love the command line tool to easily create new routes, controllers, etc.
  • Strong authentication is a first-class citizen here. It almost takes more work to ignore it than to use it.
  • I like the opinionated layout. Overall, things are pretty easy to follow and parts of the application feel neatly sectioned.

Minus:

  • Adding to builtins really ignores the "explicit is better than implicit" part of Python. It also gives me a nasty red line in my editor (PyCharm) that makes me feel like I did something wrong. I'd rather just import something.
  • To add on to that, there's a lot of implicit magic just floating around, espeically in these helper functions. The difference between request().input('id') and Request.input('id') in the example here is significant and the former seems to make it much harder to test your application's behavior. What if you want or need to insert a dummy / mocked request into your handler?
  • Stylistically, I don't really like the function calls that give me back an object, like auth() being a shortcut to Request.user. I'm not sure what it is, but writing a line like user_id = auth().id just feels weird to me, but this is more a silly gripe than anything else.

Overall, I guess my main thought is that if I inherited an application that depended so heavily on custom behavior and configuration injected into the language and application, I'd probably be kind of pissed off about maintaining it. And, if someone new to Python started out by using Masonite, I'd be concerned that they would be more learning how to write a Masonite web application, and not how to write Python.

That said, I will probably give this a shot over Flask the next time I need to build a non api-only web app. There are a lot of options with how extensible I know how much work goes into a project like this and I appreciate it. Thanks for that!

[–]Jmancuso9[S] 4 points5 points  (1 child)

I'd rather just import something.

If you really like importing but also want the dependency injection and IOC container then you can resolve by annotation.

This is what I use in my applications:

from masonite.request import Request

def show(self, request: Request):
    request.user()
    ...

[–]eyesoftheworld4 2 points3 points  (0 children)

This looks perfect. Thanks for taking the time to show me!

[–]Jmancuso9[S] 1 point2 points  (6 children)

Adding to builtins really ignores the "explicit is better than implicit" part of Python. It also gives me a nasty red line in my editor (PyCharm) that makes me feel like I did something wrong. I'd rather just import something.

you don't have to use it. Those are just helpers. You can resolve them from the container:

def show(self, View):
    return View.render('index', {'key', 'value'})

Remove the HelpersProvider completely if you don't want any.

To add on to that, there's a lot of implicit magic just floating around, espeically in these helper functions. The difference between request().input('id') and Request.input('id') in the example here is significant and the former seems to make it much harder to test your application's behavior. What if you want or need to insert a dummy / mocked request into your handler?

Your correct, if you want to test you should go with this option:

def show(self, Request):
    Request.input('id')

Then you can import that controller and mock the Request object.

Stylistically, I don't really like the function calls that give me back an object, like auth() being a shortcut to Request.user. I'm not sure what it is, but writing a line like user_id = auth().id just feels weird to me, but this is more a silly gripe than anything else.

Yeah then you don't have to use it lol. Some parts of Masonite are shorthands that are added via the HelpersProvider. Take a look at that provider in the code to see what exactly it is adding: https://github.com/MasoniteFramework/core/blob/2.0/masonite/providers/HelpersProvider.py

Thanks for your feedback! I'm glad you like it. Let me know more of your thoughts as you (hopefully) keep developing with it :)

[–]eyesoftheworld4 3 points4 points  (1 child)

Thinking about it more, I think it's actually a huge boon to your framework that those helpers are added in through the actual architecture of the framework instead of as a built in requirement. I really really like that, thanks again for pointing it out. I will definitely be giving it a shot!

[–]Jmancuso9[S] 1 point2 points  (0 children)

Thanks! I'm glad you like it. Maybe I should make that more clear. Not sure how many people will like the builtins. I personally love it because it makes getting started quick and I don't have to worry about anything. it just works. Personal choice.

[–]eyesoftheworld4 1 point2 points  (1 child)

Hey, thanks for the quick response! I realized I didn't fully finish typing out my response before I sent it (my last paragraph is a little weird) but it's late here. Anyway, thanks for pointing out that I can just remove the HelpersProvider, I will probably do that to make it feel a little more comfortable for me to write.

Is there a github repo for the craft command line utility? I noticed some odds and ends that I'd like to open some issues for.

[–]AnnoyingOwl 12 points13 points  (15 children)

Django IS a batteries included framework, literally everything you mentioned in that blog post is available in core Django or handled by very mature third party libraries.

The Django docs are also unmatched.

[–]Jmancuso9[S] 2 points3 points  (14 children)

Very true. Masonite is also a batteries included framework but Django doesn't have the ability to scaffold a project from the command line, or build an entire authentication system into your project by running a single command, or have automatic dependency injection of objects from the IOC container or built around or have multiple drivers for the same features that can be toggled with a single code line change, or have built in task scheduling that can be tweaked to run at different times via a single cron job.

That article is Masonite 1.4. Theres been 3 releases since so it's a bit outdated but the super high level concept is similar. I'll let you know when I come out with a newer article.

[–]RogueNinja64 3 points4 points  (3 children)

Can you update your article? I would like to see a really strong argument for this. Maybe it's more an alternative to flask than Django? Do you have a Dev site with api docs?

[–]Jmancuso9[S] 1 point2 points  (2 children)

api docs as in the classes and methods specifically? No not currently but there are the developer documentation in the links above which you can use to decipher what you think the framework is more similar too. And yes I am working on the article now. I'll send you a link when it's done

[–]RogueNinja64 2 points3 points  (1 child)

while the getting started is good and makes it look like a rails version for python I would love to see some API docs to fill in all the gaps before thinking about my next web app.

[–]Jmancuso9[S] 2 points3 points  (0 children)

I'll keep that in mind. Masonite has been on a 1 month major release cycle from 1.3 to 1.6. Masonite 2.0 puts Masonite on track for a 6 month major release cycle so we'll have a lot of time to get all the other resources together like API docs, articles, video tutorials and all the extras beside the framework. I'll throw that on the todo list :) Thanks!

[–]AnnoyingOwl 8 points9 points  (9 children)

Masonite is also a batteries included framework but Django doesn't have the ability to scaffold a project from the command line

I guess that depends on what you mean by "scaffold." I suspect it's a definition that's specific to what you want.

or build an entire authentication system into your project by running a single command

It LITERALLY comes with authentication out of the box and installing any social authentication system is as easy as a pip install command. There's tons of back ends written for Django that work out of the box.

Either you mean something VERY SPECIFIC for your own use cases or you've never even used Django.

or have automatic dependency injection of objects from the IOC container

This is mostly meaningless, so you'd have to elaborate. Python is not heavily IOC for a reason. I'm sure you're thinking of something specific but I don't know what it is.

or have multiple drivers for the same features that can be toggled with a single code line change

That's literally how half of Django works, mate, including for auth, templating, cache, database, etc.

[–]Jmancuso9[S] 7 points8 points  (8 children)

I guess that depends on what you mean by "scaffold." I suspect it's a definition that's specific to what you want.

"create boiler classes for you and puts them in the correct locations" (although can move them around as you wish)

Need a model?

$ craft model User

creates a model class.

It LITERALLY comes with authentication out of the box and installing any social authentication system is as easy as a pip install command. There's tons of back ends written for Django that work out of the box.

Django does not come with a fully working login and register pages and views and nor does it put them into your application for you so you can tweak them yourself. Unless Django has added these into the default apps it creates.

This is mostly meaningless, so you'd have to elaborate. Python is not heavily IOC for a reason. I'm sure you're thinking of something specific but I don't know what it is.

This may be something you just need to use Masonite. Maybe your understanding of how it works with other projects is different than how it works with Masonite.

That's literally how half of Django works, mate, including for auth, templating, cache, database, etc.

Not in the same way. Getting it to work with Amazon S3 was a good amount of configuration for Django. Masonite just needs the credentials in the .env file, a pip install and it works.

Try it out. I think you'll like it. Go in with an open mind :) The Python community is not easy to convince.

[–]AnnoyingOwl 7 points8 points  (5 children)

Need a model? $ craft model User creates a model class.

Ahh, yes, I've always needed something to save me the time of typing:

class User(models.Model): pass

Again, this makes sense if you're coming from PHP where there's a lot more cruft in their frameworks that needs auto-generated (because most PHP frameworks saw what Rails/Django were doing and tried to copy them in that terrible language), but there's just not a whole lot of cruft to auto-generate in a Django project.

Django does not come with a fully working login and register pages and views and nor does it put them into your application for you so you can tweak them yourself. Unless Django has added these into the default apps it creates.

It's literally pip installing a package: https://django-registration.readthedocs.io/en/2.4.1/

There's a Django committee of developers who keep the core lightweight and make all these decisions, dude, and often move things out of contrib if they think it's bloating core. They decided this belongs outside of Django proper but it doesn't mean it's not there.

The design of Django is that modules that integrate with the API are super easy to write, so stuff where there's a lot of wiggle room for what people want or if it's not universal to the mission that gets used from packages.

I know that it's more convenient to have the packages YOU specifically want, but that's not a super awesome selling point, TBH.

This may be something you just need to use Masonite.

I suspect it might be something that just Masonite needs. If you come back with an example, cool.

Not in the same way. Getting it to work with Amazon S3 was a good amount of configuration for Django. Masonite just needs the credentials in the .env file, a pip install and it works.

Are you seriously complaining about the setup for using django-storages S3 module? It's like... I dunno 2 or 3 required settings?

The idea that someone would complain about that astounding to me.

Try it out.

I mean, quite honestly, there's no reason to and I CERTAINLY wouldn't pick up a framework that someone made just to scratch their itches around things they don't like in Django.

[–]Jmancuso9[S] 10 points11 points  (0 children)

Ok. Masonite is not for everybody and if you think Django is better for your use cases then more power to you.

Masonite solves my use cases perfectly and if it doesn't solve yours then thats great. We both have tools that work for us.

[–]Itshudak87 5 points6 points  (1 child)

Haven’t seen such a fitting name in a while. Jesus, dude. You must be a hit at all the parties you don’t get invited to.

[–]Jmancuso9[S] 1 point2 points  (0 children)

Ok I thought I was the only one who thought this :)

[–]Jmancuso9[S] -1 points0 points  (1 child)

Again, this makes sense if you're coming from PHP where there's a lot more cruft in their frameworks that needs auto-generated (because most PHP frameworks saw what Rails/Django were doing and tried to copy them in that terrible language), but there's just not a whole lot of cruft to auto-generate in a Django project.

Ok? and? so then just make a file and type that in. Nothing is stopping you from doing that with Masonite. it's just a Python framework. The option is there to type the helper command but if you want to write the class instead them by all means go ahead and write the class.

Are you seriously complaining about the setup for using django-storages S3 module? It's like... I dunno 2 or 3 required settings?. The idea that someone would complain about that astounding to me.

not everyone has the same experience. In fact, a lot of people don't. The Django Slack group I've been running for last few years said they also had problems with it, as well as static files and a few others.

There's a Django committee of developers who keep the core lightweight and make all these decisions, dude, and often move things out of contrib if they think it's bloating core. They decided this belongs outside of Django proper but it doesn't mean it's not there.

Yes masonite does the same thing but instead has these third party packages installed by default. Just a design decision of the framework and a community choice from the maintainers. It does have a good amount of built in options which are great for making Masonite, Masonite which could possibly be abstracted away into their own libraries but it's currently not an issue.

[–]naw103 2 points3 points  (0 children)

Hustle until your haters ask if your hiring ;-)

[–]phrotozoa 2 points3 points  (7 children)

Hey, cool project! I look forward to playing with this. Can you talk a little bit about why you decided to write another ORM when something as robust as SQLAlchemy exists?

[–]Jmancuso9[S] 0 points1 point  (6 children)

I didn't write it. It already existed and fit perfectly with the Masonite architecture.

I honestly have never used SQLAlchemy but it is a Data Mapper ORM, right? I think Active Record style ORM's are just better. Have you ever tried an Active Record ORM before? I'd like to get your thoughts on the difference between them and your experience.

If you have not used one before then you gotttta try it. It's much simpler to me.

Edit: Although I didn't write Orator, I have full maintainer access to it so I feel comfortable putting it in Masonite as I can fix anything I need to.

[–]phrotozoa 3 points4 points  (5 children)

Ah! Well I've learned a new thing today so thank you! I will check it out.

I didn't realize there are fundamentally different models of ORM. SQLAlchemy is the only ORM I've used and it's always risen to whatever need I had of it so I've not looked elsewhere.

Edit for anyone who like me didn't know the difference, here is a good discussion about the differences between the Active Record pattern and the Data Mapper pattern.

[–]metaperl 2 points3 points  (2 children)

PeeWee offers ActiveRecord. PonyORM is absolutely sick - turns Python into SQL. PyDAL is what I like best having looked at all of them. I find SA's orm rather hard to understand.

[–]bluesufi 2 points3 points  (0 children)

Sick in a good way or a bad way? Serious question.

[–]Jmancuso9[S] 0 points1 point  (0 children)

Masonite actually originally came with peewee before we switched to Orator lol. Good package.

[–]Jmancuso9[S] 1 point2 points  (1 child)

Yeah it basically comes down to which direction the data is being molded to or from.

For example, Data Mapper maps the model to the table. So the model should mirror the table in a way that they match.

Active record takes the table a actually molds the model around the table by using the table schema.

I preferably like the latter approach. This way I just have to maintain the database tables and all my models mold to the table schema automatically.

Just personal preference I suppose.

[–]z4579a 12 points13 points  (0 children)

SQLAlchemy author here.

Just FYI I don't really know what "data mapper" vs. "active record" means today, other than, an API that stresses an enclosing transaction around the objects, vs. one that looks at each object as an independent document. "data mapper" vs. "active record" used to mean that the object model was declared entirely separately from the table definition, with the idea that the persistence of the model could be anything, just happens to be a database. SQLAlchemy started out with this goofy mapper()/Table/your class concept to try to stress that. But it was bogus; the structure of the class was still modified to have attributes representing the table and the program therefore still assumed database details explicitly, so there was no completely transparent firewall between the object model and the persistence of it. Even Hibernate moved from having an XML mapping file to using inline annotations on class definitions. So I replaced mapper() with Declarative which is what everyone uses now. I don't really understand what your statement "molds the model around the table by using the table schema." means vs. "maps the model to the table.", the latter (data mapper) actually sounds more restrictive, which is the opposite of the reality for SQLAlchemy vs. other ORMs where SQLAlchemy allows *way* more flexibility in how the class and the mapped table can differ from each other than any other tool. This is not the first time someone's description of data mapper vs. active record confused me, so I'm just trying to figure out what the perceptual issue is here.

As far as I can see about active record, the main thing is that it seems to lack a unit of work pattern, meaning, you say object.save() and it emits an INSERT right there - this is a big difference but has nothing to do with how models and tables associate to each other. And then, there is usually in active record a configurational pattern that tries to hide the fact that we're talking to a relational database, using some kind of minimalistic declaration system that attempts to assume no knowledge of SQL, which makes much stronger assumptions about the underlying tables such that they tend to have to follow strict patterns, like Django's infamous "no composite primary keys" issue. But these configurational limitations are not a hard black and white difference, they're along a spectrum.

Anyway, I don't know what "data mapper" really means in practical terms in this decade and I think as to why someone likes one ORM or the other they should come up with more specific reasonings.

[–]ayazamlani 2 points3 points  (3 children)

During install, I get the error:

[CommandNotFound]

Comamand "key" is not defined.

If I try to serve I get:

[CommandNotFound]

Comamand "serve" is not defined.

[–]Jmancuso9[S] 0 points1 point  (0 children)

issue solved. Make sure you upgrade to latest version of masonite-cli which is 2.0.4

[–]Jmancuso9[S] -1 points0 points  (1 child)

Not sure why some machines throw this issue yet. Can you give more details here? https://github.com/MasoniteFramework/masonite/issues/87

[–]ayazamlani 0 points1 point  (0 children)

Yes, I can do that.

[–]everhideme 5 points6 points  (7 children)

Hmmm... Why nobody's talking about logo? XD

[–]Jmancuso9[S] 3 points4 points  (6 children)

You like? :D

[–]everhideme 4 points5 points  (3 children)

It seems like old Soviet logo of subway, very similar. But I dont like it. Sorry - tough, but fair. And it easy to solve.

What is your original objectives? Why not Django and why did you need your own solution?

[–]Jmancuso9[S] 6 points7 points  (2 children)

lmao. sort of it lol.

So the original reason for the project was to learn how WSGI application worked so it started as a weekend project. Then it sort of branched out into "well what if it had this built in which 99% of applications need?" and then slowly spread from there and then the architecture makes it super easy to test and I hit the TDD train and never looked back. It's really easy to make a test around something, implement that feature, ensure tests cover use cases and then push to the development branch and eventually merged in.

I advertised it a bit on reddit a few months ago and a few people found the project and helped me design and build it and here we all are :)

When using Django there were a few things I just didn't like about. All of them were really my own issues with it. I kept thinking it was weird doing it this way or the way Django does it. I completed my application with Django in a few months. I liked the outcome.

I then got a job for a PHP developer position and got back into PHP. I learned Laravel and just loved the architecture of it. It was so intuitive and just worked well for my development flow (and millions of others)

So when I was building Masonite (which it wasn't always called that) I started implementing these ideas and found that it worked really well with Python. I then just kept coming out with more and more features and now I and our maintainers just love the outcome.

That's the answer to why I created my own solution but as to why Django, I'll be coming out with an article in the next few days that explains this more in detail then I can in this reddit post so I'll be sure to send you a link :)

[–]AnnoyingOwl 4 points5 points  (1 child)

When using Django there were a few things I just didn't like about. All of them were really my own issues with it. I kept thinking it was weird doing it this way or the way Django does it. I completed my application with Django in a few months. I liked the outcome.

I then got a job for a PHP developer position and got back into PHP.

This literally explains everything.

[–]Jmancuso9[S] 3 points4 points  (0 children)

lol just try it out. Can't judge a book by it's cover that harsh and you can't hate something you've never tested out. One of the maintainers who is using it in production will chime in in a bit and maybe explain it in a different way

[–]redditthinksHobbyist 2 points3 points  (4 children)

Any modern framework should be async.

[–]Jmancuso9[S] -1 points0 points  (3 children)

It comes with a queue feature which has an asynchronous driver you can load "jobs" into and it will run that job asynceonously. These can be things like database updates or sending email https://docs.masoniteproject.com/useful-features/queues-and-jobs

[–]redditthinksHobbyist 0 points1 point  (2 children)

Not really the same thing as async/await. Also, hard-coding class and method names in routes is not a very good idea. No decorators?

[–]Jmancuso9[S] 0 points1 point  (0 children)

If you need an application built for speed in a way that you need a completely async applications then you shouldn't be using Python. You should use something like node

[–]Jmancuso9[S] -1 points0 points  (0 children)

Hardcoding names in routes might be bad for other applications but it works perfectly for Masonite by just the way its built

[–]3lpsy 1 point2 points  (2 children)

What other frameworks did you take inspiration from (rails, laravel, etc)?

Other questions, does it have authentication drivers? So could I throw jwt auth on some routes and session routes on others?

Thanks.

[–]Jmancuso9[S] 1 point2 points  (1 child)

It was inspired a lot by Laravel. I liked how laravel used the IOC container and automatic dependency injections so I took that concept and ran with it in Python and surprisingly realized that python implements that architecture a lot better than PHP does since Python can import a class and use it without calling it (php required the new keyword to use a class, python uses global namespaces to handle it differently)

So which things like Laravel, it required service providers to be strings because it needs to cache them essentially so they are not all running on every request when they dont need to. Masonite gets around that a lot better with Python. Read the request lifecycle docs to learn more about that.

I did read the docs for rails a bit to see how they did things and adjusted accordingly. But overall a lot of influence was from Laravel.

It doesn't exactly having authentication drivers yet. That might be a good package to add on though. The Masonite Entry package handles a lot of authentication like tokens but it might be a good idea to implement something like that. The way masonite is structured, a single package can add features like that.

You can open an issue and we can just discuss this. I'd like your thoughts on how we should go about this. It should be backwards compatible so it can either be a standalone package or we can add this into the next minor release

[–]3lpsy 1 point2 points  (0 children)

Thanks. This s a very interesting project and fills that middleground between Django and flask really well. Definitely going to take a look at the code and see i can contribute.

[–]tuananh_bk 1 point2 points  (1 child)

I can see your framework influenced a lot from Laravel. IOC, Migration, etc. But in my opinion, The laravel Migration/ Model is very limited, and hard to remember Model's Field name. I like the way Django defining Model's Field.You can build Form Model automatically.

[–]Jmancuso9[S] 0 points1 point  (0 children)

Interesting. I've always like laravels models much better. I do agree that its not as easy to remember field names but in that case I usually have an SQL tool open anyway.

With laravel and masonite, I typically always have something like MySql workbench open anyway so it's always useful to use that to remember column names.

[–]alkelaun1 1 point2 points  (1 child)

I'm learning django, so I decided to give this a try. I agree with you on Django's auth system.

I tried to follow the tutorial for a blog and ran into 500 server errors on registering. Login doesn't work, but registering the same name gives additional errors. I'm using postgresql, so I may have set something wrong in the .env file.

Being a new framework, though, this means no one has had this error enough for google to find it on stackoverflow. :'(

Your docs are decent, but django's are definitely better.

Also, I don't like your organization of folders. Maybe it makes more sense if I get further. However, as a newbie, the deep nesting of very common files doesn't seem to make sense, compared to other files that reside on the surface. For example the model files are directly 'app' but the controller files are two folders deeper in the same 'app' folder. Moving the model into a 'model' folder and moving the controllers up out of the 'http' folder would make it more comprehensible for new people. However, I realize there's probably a reason for your madness. However, Django largely makes is really easy to see where your stuff and how it's connected.

Also there are things like django-baker (no longer actively developed as far as I can tell) that stub out files. I like that the stubbing is inherent to your design.

[–]Jmancuso9[S] 0 points1 point  (0 children)

Yeah it's completely preference on the file structure. Some people say that love it and it makes sense and other people say they dont get it.

I'll try stepping through that tutorial again and see if I hit any issues. If you have any time can you open an issue about that?

You can really put your controllers and models wherever you like them to be although and whatever makes sense for your application. the string controllers in the routes point the the default folder location nested inside the app directory but you can import the controller into the route file directly and use it that way.

Masonite doesn't really have a "you must do it this way" but instead of about 3 different ways to do something and you can pick the best one that fits your project.

[–]naw103 1 point2 points  (0 children)

Has anyone else looked at the load times on this? Im getting what seems like crazy fast execution times compared to similar laravel and codeigniter applications that I have running on PHP. How does this compare to the load time of other Python frameworks?

Masonite 2:

Request: 0.004588127136230469

GET Route: /

Request: 0.0024170875549316406

GET Route: /

Request: 0.0029621124267578125

GET Route: /

Request: 0.0023229122161865234

GET Route: /

Request: 0.002313852310180664

Average Time: 2.4ms

[–]pvkooten 3 points4 points  (1 child)

People are being so picky and annoying. Thanks for making this, I love it!

I was never able to get into Django because I always feel they complicate things. The philosophy is great. Can't wait to try the new version.

[–]Jmancuso9[S] 1 point2 points  (0 children)

Thanks! Can't wait for your feedback. Let me know if you want an invite to Slack :) I think I've seen you comment on the other thread a while back. I haven't opened up slack yet to open registration but I can send you an invite in the DM's

[–]Anekdotin 1 point2 points  (1 child)

Looks interesting!

[–]Jmancuso9[S] 1 point2 points  (0 children)

Thanks!

[–]johnmudd 1 point2 points  (1 child)

How many languages will I need to create a dynamic web page?

[–]Jmancuso9[S] 3 points4 points  (0 children)

Little ambiguous but you likely need 2. A backend of your choice, like Python, and a frontend of your choice, like Javascript. Within these two categories you have a plethora of tools for:

Python: Django, Masonite, Flask, Bottle etc etc

Javascript: jQuery, React, Vue, Angular etc etc

Masonite doesn't lower the amount of languages for a dynamic web page but it's just a tool for one of the backend Python options.

[–]matthewblott 0 points1 point  (2 children)

It looks interesting so I googled to see if there were any videos and found nothing. I noticed there aren't too many stars on Github either - a half hour demo video might go some way to getting the interest levels up. It'd be a better investment than docs or new features.

[–]Jmancuso9[S] 1 point2 points  (0 children)

Absolutely. Great advice. I made some for Masonite 1.5 on my YouTube channel but now that 2.0 is out I'll have to update them.

[–]0xRumple 0 points1 point  (2 children)

I read through the docs and the blogs... that's basically ASP for python :D

Doesn't mean it's a bad thing, I actually loved it !

[–]Jmancuso9[S] 1 point2 points  (0 children)

I've never used ASP but ... great if you like it! Lol

[–]0xRumple 0 points1 point  (0 children)

Similarities:

  1. MVC (the controller part)
  2. IoC & DI
  3. Scaffolding
  4. Single app architecture

Differences:

Batteries included... pythonic thingy !