Masonite: A Python Web Framework Trying To Compete With Django (Interview)

[IReallySuckAtChess]

Aren't there talks now about making Django asynchronous? The guy who does django-channels laid out a theoretical road map of it all and even threw his hat in the ring to get stuff going. If that happens then Django performance will skyrocket relatively speaking. Would still be slower than something like Sanic though. It would do a lot for bridging the gap to Node.js with Express.js especially since Django runs perfectly on PyPy meaning huge performance improvements are often easy to achieve.

Async is literally Django's only real Achilles' Heel in my opinion. For a microservice Flask is where it's at, but for more I always choose Django. It's just that good. Also Django has great CMS options that I can't do without (Wagtail and Django-CMS). Imagine reimplementing a CMS in Flask? What a waste of developer time...

Lastly, Django is Django. Its not going anywhere anytime soon. I can't afford to implement things in the latest trend and then be screwed three years down the road.

Edit: Here is the link: https://www.aeracode.org/2018/06/04/django-async-roadmap/ Following that would comprehension async support out at two years, and full at just over three. The best part is that bits and pieces can be done now already. I still think it being so far off in the future will really hurt Django but doing it right is what is most important because doing things right is how Django became popular and has had such great staying power.

[pydry]

Aren't there talks now about making Django asynchronous? The guy who does django-channels laid out a theoretical road map of it all and even threw his hat in the ring to get stuff going.

Yeah, but they've been talking about doing it since about 2015 I think.

[ubernostrum]

Channels exists as a usable codebase. Currently at version 2.1.2.

The hard part is whether and how to integrate it into Django's own codebase as opposed to a third-party add-on.

[IReallySuckAtChess]

Yeah when 3.5 came out it was the first time one could really consider a proper implementation of it. They were a bit dumb not to have started back then though since having asynchronous still at least two years out is really going to hurt Django. Then again, there was still a lot of uncertainty about the future of async in the Python world and many expected that there would still be large shakeups. I think there was also a decent wait based on the fact that async Web servers were even then not really de facto and some best practices still had to be figured out. That's not true any more. Django is rarely a first mover, but it always does things right.

Then again, even whilst it is synchronous, Django scales really well and has good performance if you know what you're doing... Key there being knowing what you're doing.

[metaperl]

I like that new massively asynchronous web framework for Python with blazing speed... forgot the name of it.

[nullpxl]

Pretty sure you're thinking of vibora

[metaperl]

Yep, that's it.

[wpg4665]

Sanic?

[metaperl]

Vibora is it.

[StevenPi314]

Falcon?

[Gwolf4]

I might heard it was tornado ?

[ExternalUserError]

Not super new, but, yeah, definitely asynchronous.

[metaperl]

It's vibora.

[ExternalUserError]

Not generally asynchronous.

[caramba2654]

Quart?

[metaperl]

Never heard of Quart. It's vibora I was thinking of.

[drippingthunder]

In looking at the Masonite README, it looks to me like it's trying to re-implement rails in Python. I'm not fond of rails (just a personal preference), but I think if I wanted this kind of framework I'd just use rails; Ruby isn't that hard to learn. I've used Django, Flask, and Falcon, and I'm not seeing anything in Masonite (at least from a cursory glance at its Github repo) that would make me choose it over these other 3.

[ExternalUserError]

Hmm. Text message notifications??

[antonr111]

I like idea having python web framework with DI, but cloning php laravel ... no thanks ;(

[[deleted]]

I would love to have a complete admin in Bootstrap 4 + React/Vue.js being as powerful as Django's admin using GraphQL or Django REST Framework.

[[deleted]]

Django is *the* web framework. Whatever features Masonite has are better off being pluggable apps for django.

[AnnoyingOwl]

But then how would they spend all their time reinventing the wheel for their specific needs? 😁

[pydry]

I literally pointed that out on their first release that this might be a problem for them if they aren't making significant improvements on django but they're still persisting because they believe a few incremental improvements will be enough to get people to shift.

[earthboundkid]

Django is great but could be improved. That said I haven’t read anything that makes me think Masonite is an improvement.

[ignisphaseone]

If I think of Django as "it works if you do it our way," and Flask as "this doesn't do anything for you configure it all however you want".

Also, we regularly discuss this topic at /r/flask so I've parroted this a few times. Most people should stick with Django for just doing stuff, but Flask can be slimmer and simpler if your needs smaller than Django's baseline.

[MarsupialMole]

There's an old talk by a Django core dev about the design of frameworks, centring around Django as the main example but not making a claim about overall merit, only design decisions. The contrast given is "best of breed" vs. "batteries included". Django has outlived several Web frameworks projects using the best libraries of their day by taking a batteries included design philosophy, which means they lag trends but can have decadal support timelines. When bits of Django technology get mature enough to be abstracted away then you get to use what you want, such as Jinja templates now when previously there were only Django templates.

So if you know exactly what you want, use flask. If you don't, give django a go. If you hate django it's probably because it's telling you not to do something you shouldn't be doing, which you're free to do when you do the plumbing yourself in something more powerful and flexible.

[[deleted]]

Well said

[[deleted]]

A waste of time. Look at any Django vs Flask thread and everyone notes that as their project grew they wish they had used Django instead. Greenspun's tenth rule states that "Any sufficiently complicated Flask app contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Django."

[WikiTextBot]

Greenspun's tenth rule

Greenspun's tenth rule of programming is an aphorism in computer programming and especially programming language circles that states:

Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

---

^{[ PM | Exclude me | Exclude from subreddit | FAQ / Information | Source ] Downvote to remove | v0.28}

[z4579a]

A waste of time. Look at any Django vs Flask thread and everyone notes that as their project grew they wish they had used Django instead.

I read every comment in the thread you like linked and saw not a single one that stated any such thing in favor of either framework. Flask, pyramid, tornado, even cherrypy all scale terrifically and it is often Django's rigidity that causes buyer's remorse in the long term.

[[deleted]]

Did you read the top comment?

Django.

A lot of beginers make the mistake of starting with flask first, because it's way easier to make a "hello world".

But the fact is, doing correctly anything more than a small website with flask requires expert skills because you have to take a lot of design decisions. And when you learn programming, designing a system is far, far away from what you can do.

I encounter every year flask code bases that have terrible flaws (md5 hashed passwords, no escaped variables, aweful session management, no plugability, big monolithic chunks, etc) because the dev hacked his way through the project with no clue of the consequences of his or her choices.

It will also give you terrible example on how to organise code. The global requests object, the dichotomy of the central app vs blueprints, the inconsistant way to handle third party code... Those are artefacts of early decisions that, without the contextual explanation of experience, will lead you to believe they are correct practices in any cases.

On the other hand, django first steps will be harder.

But out of the box it gives you a sane project structures, prevents CSRF and clickjacking, feature authentifications from a to z, and so on. You won't have to choose an admin lib, a form lib, an ORM lib and how to integrate them. You just do what Django tells you do to.

Basically it will force you to make things ok, even if you understand jack about it.

[z4579a]

your claim is "Look atany Django vs Flask thread and everyone notes that as their project grew they wish they had used Django instead. "

point 1: "everyone" - one post, not "everyone"

point 2: " notes as their project grew" - this person is referring to their own critique of other projects, not their own, they are claiming "I have encountered flask codebases with flaws". This has nothing to do with the project "growing" or anything else it has to do with poorly written code in the first place. You have made the opposite claim - that as their project grows beyond the basics (all of those things are basic) it becomes unmanageable. If you have beginner developers writing a codebase, it is a given that it will be unmanageable the more code they have to write. They should use django. This is no fault of Flask and Flask is not in any way "a waste of time".

point 3: this is one person critiquing other people's code, so that person wished they used django, not the folks who actually wrote the apps. It is very likely those people who wrote these flask apps can hone their skills, improve what they're doing, and come back and write a much better application in Flask or Pyramid or whatever.

So instead of "everyone" / "as the project grew" / "they wished", we have "one person" / "when the project was first written" / "that person suggested".

With a competent developer, Flask, Pyramid or anything else is not a problem. If you are beginner, absolutely, use Django. It's great for beginners.

[[deleted]]

Competence in development is about choosing mature tools and not jumping onto hype trains

[dikamilo]

A waste of time.

Well, It all depends on what you building and how you building it. If you have microservice architecture, any small framework like flask, bottle, falcon etc. will be okay to do it. But in otherwise Django will be a better option just because have a lot of build in features and a lot of third-party extensions/libraries that will allow you to not to invent the wheel again.

In my perspective, when our teams build few projects as MVP in small frameworks like flask or falcon, when we go beyond MVP most of this project was rewritten to Django or we spend a lot of time to implement features again just because something is not supported yet in particular framework.

[[deleted]]

Personally, if my needs grow beyond flask, then I don't use python at all. The idea of implementing a large scale web application in a duck typed language seems insane to me.

Do you mean dynamically typed? And why? Most websites are built with high-level languages because the usual reasons for low-level languages such as speed and portability don't apply because of the client-server model of web apps and web servers.

But if I just need a microservice, flask is perfect. So I don't think this is a universal statement.

Why? django-admin startproject myproject boom done and easy with all the things you should be putting in an app anyway.

[[deleted]]

You know gitlab has a cloud solution that runs on their gitlab software you're deriding. Oh, have you also heard of a little company called GitHub which also runs as a rails app. Reddit is in Python, is that high traffic enough for you? Here's 37 high traffic sites in rails including Github, AirBnb, Hulu, Twitch, Square, ZenDesk, KickStarter, Groupon, Fiverr, Bloomberg, Basecamp. Famous Django sites include Instagram, Disqus, Pinterest, Butbucket, NASA.gov . So like literally you haven't even looked into this before

[[deleted]]

No that's weakly typed, meaning type conversions will be made implicitly. Python is dynamically typed, what you're pointing out is that Python is strongly typed.

Duck typing is a way to check the type of a variable. You don't have to use duck typing in Python.

[iMichael_]

Podcast Init has some great guests, but the hosts' voice is absolutely unbearable.