Normally, if you are having a hard time with Django its because you're trying to work around it the wrong way. This takes time to learn but Django can be really elegant to work around and with.
The second option is Flask or Tornado which are pretty great too. Both would give you more freedom but also less structure. I find it better to have the structure because unless your an experienced engineer your Flask or Tornado project will turn messy quick. Django projects can turn messy too, but at least there is a more training and protocols for people to follow.
I use Flask/Tornado if I want to use Python and I know my project is a small service and will probably not get big.
I use Django if I want to use Python and I know the project will grow over time or I need features from the start like a database, migrations, cache, etc.
App can be an API + another part of the site, for example.
So Django stands in my way and its' advantage is that it is easy the work around it?
If you are interested in understanding this a little deeper, I highly recommend picking up the Two Scoops book .
It scales beautifully (see the likes of Instagram, Disqus, Sentry, etc.), has a great security track record, sane deprecation schedules, and the core team keeps up with the times and new technologies but does so at a sane pace and without rushing things.
Not to mention the documentation - ohmygod, the documentation!
In a nutshell: pick Django, keep learning Python, and try to build something that your users love.
Maybe this has changed post Facebook acquisition. I know Facebook is mostly on Python 3 and modern stuff now.
* A lot of _very common_ situations and patterns are already solved for you, and they're solved in the cleanest way possible.
* The documentation is excellent, both with "guides", examples, and API reference. Django (along with OpenBSD), has probably the best documentation I've seen around.
* Clean design (of django itself) means that you can extend it, or avoid using bits that for some reason don't suit you.
* Very transparent development, and the developers are really into open source - everything is done out in the open. This last point might not be really important as a user, but it helps if you ever want to contribute (or understand) anything to django itself.
Even after years of django, I very occasionally still come across a functionality in django that I'd overlooked and saves be a bunch of my own code.
Your app does sound like it is in Django's wheelhouse (CRUD against a DB with users), so it is probably a good fit.
Can you elaborate more on this? And also for what kind of apps one should avoid Django?
Hard: Using any DB but PostgreSQL. You can use other DBs, but Django silently disables features. Doing anything with the DB that isn't directly managed by Django itself. Doing anything but basic pre-defined URL routing as supported by their routing system.
Use something else: Not using a relational DB as a backend. Not using their user management and authentication system. If you want to use something other than their built-in ORM, templating, and routing.
I personally recommend Flask in the cases where Django is not a good fit. A threading/forking fastcgi model with basic nginx caching is incredibly performant. That said, Flask is pretty terrible at most of the "nightmare" level tasks as well.
They supposed to make this sort of thing easy and straightforward. I'm still learning them, but this system seems to be well designed and makes a lot of sense.
Django + Django REST Framework + React should give you pretty much everything you need to build whatever you want, including single page apps. At least as far as I understand it.
I have high hopes from django-channels and the asgi server. Hopefully, we will get plug and play asynchronous chat apps for django in the future.
Leaving the metaphor, python in general fails at some async and cpu-intensive tasks, while other languages (or even frameworks/libraries of Python) excel at it. Whatsapp for example excelled through its use of Erlang, and would not have worked well had it been build with Django.
Django always gets a lot of praise here (deservedly) but I feel a counter-weight should also be applied to prevent less experienced, and easily influenced, developers from getting the wrong impression (though that may be a lost cause with tech hype).
No status updates over websockets, but it could be added pretty easily.
I regret not having documented what I did at the time to actually push an update to this. :(
When lots of objects are loaded then annotations usually improve performance greatly, since they avoid the "for x in y: query_database" execution, instead executing a single query with allr equired data.
The level of productivity in writing API backend you can get off it is insane.
There are some quirks that I find a bit annoying (nested serializer write behavior) - but other than that it is great.
For very simple APIs, DRF is overkill, and if I only need a couple JSON endpoints, I don't bother with it. But if I need full access to my models, you just can't beat it.
DRF fits in very nicely with Django, especially if you are used to class-based views. We use it at edX for nearly all of our APIs. We don't have many complaints.
As someone mentioned regarding Django, it is important to not try to work around the framework. If you're not making a RESTful API, you may have a hard time taking full advantage of DRF.
So I'd suggest you just some popular framework and don't worry whether it's the right one. Pick one and run with it!
1) Great documentation. Well organized, well written. Good balance between theory and examples.
2) Superb ecosystem. Coming from PHP land, I got the sense of a "anything-goes" mentality. On SO, people who help are very much interested in doing things the idiomatic way.
3) You get to practice Python!
Not really. You mostly write Django and need to go really far before hitting any non-superficial Python feature.
Its easy, it scales, use any DB and Pyramid framework has good documentation too.
Or go with web2py if you need to start simple and easy and fast prototyping. It has an ORM which supports many Relational DB and MongoDB too if you need it. It has good documentation. Its authentication and authorization system is too easy.
Stick to python3.
Really good python learning resources.
Also, "there's an app for that". The ecosystem is large and healthy.
If you don't want Django cause it's Django, then Flask and Pyramid are other excellent alternatives. There is also a swath of more specialized frameworks (eg. Tornado).
Django is mature, full-stack, flexible, has sound architectural decisions behind it, relatively good security track record. There is a built-in admin and permission systems to help with what you require. Batteries included such as an ORM, templating, routing, forms. The Django third-party apps/module ecosystem is rather large and accessible: from authentication, social media integration, payment gateway integrations, APIs, to whole apps like invoicing, helpdesk, etc.
Note I am not saying "build a new, generic framework because all other frameworks stink". Building libraries with the goal to support other projects is a neverending task.
But only building the support paste as you actually need it is not a lot of work. WSGI is a quite simple interface. I'm doing this myself and the support I currently need is only ~500 lines. The only external library I use is jinja2 templates. As database I use plain sqlite3 from the python standard lib and in some places text files.
If you don't know and don't want to learn HTTP and Web application architecture you will of course end up with a broken design. On the other hand it's very rewarding to learn how to decompose an application into independent components (templates, services, routing, database access, business logic, authorization, session management, config parsing, project directory structure, what have you).
The other big advantage is of course flexibility. If you do a good job the decomposition is better than with a framework. This means flexibility. It's easier to fix problems than with an opinionated framework.
I've been using Grails for over 10 years, my clients are super happy with what I have delivered. I've built complex issue tracking systems, e-commerce web sites, administration panels, data management tools and so on. Code I wrote 10 years ago is still working fine today! I highly recommend learning one of these frameworks, you will make new friends and good money!
I'm wondering if any of it's been upgraded to Grails 3, or if they're still on Grails 2, or even using a Groovy 1.x version of Grails.
Create your own framework - writing http headers etc from scratch which will take you forever or Use a lightweight framework like Flask or Web.py.
Either way, you'll end up creating your own ways to query the database and creating patterns to communicate with frontend.
As you write more code, you'll abstract your code to reusable methods.
About a month into the project, you'll realize that you're slowly rolling out your own framework which has grown organically.
Soon you'll realize you're better off using a polished framework like Django which has abstracted many of the details so you can focus on delivering value instead of clobbering together your own framework which will become a burden to maintain alongside your app.
E.g. what seems to be flask's most popular CMS uses mongo as a backend.
Django does a lot automatically: authentication, schema creation, ORM, default forms, admin interface. These are things useful to 95% of CRUD apps.
At a certain complexity, nearly every project would have to replace or mostly replace all of those. A full table scan is prohibitive, you want to customize indexes, you want to customize the design of everything, etc.
The Play Framework provides just that: an web MVC framework with basic routing, templating, and HTTP utilities. It's more general and will scale further in project complexity, but you should expect to spend more time figuring stuff out initially.
Other than that, there are the obvious differences between Python and Scala. Personally, I love, love, love the confidence of static verification, but there are good things about both sides.
But be careful if you intend to create a stable, heavily-used site. I have so many problems with Django in this use case that I've gotten tired of listing them each time it comes up and collected them into a blogpost: https://alexcbecker.net/blog.html#django-is-terrible
If you want to make something really professional just ignore the words of a n00b.
Lacking details, it seems like your app could be a good candidate for Django.
For me, the main appeal is the Django admin. It gives you a great way of interacting with your data with minimal effort.
I highly recommend ditching the admin page as soon as you can though - the number of things you can do with it is extremely limited.
- Ruby on Rails
- Node + Express
The major reason I have picked Django is that it is written in Python, which allows me to use an elegant and beautiful language that I can apply in any field, and utilize a huge amount of python apps, scripts, and stackoverflow examples.
Using Django has also enabled me to learn the solid foundations of web development, which I can expand upon and apply anywhere.
For example now I am experimenting with React and Express, and knowing Django helps me enormously, it makes understanding these things way easier.
I have built a bunch of projects with Django, and I am extremely happy about my choice, so I highly recommend it to anyone who is beginning to learn web development.
As others have mentioned, Django is opinionated and I think they get it mostly right.
I use Flask myself, in part because I wish for my data modelling language to be a separate part of my stack, but my use of Flask is heavily influenced by Django's philosophy.
I am the primary developer of Flask-Diamond, which attempts to adapt Django's opinionated choices to Flask. However, I would still recommend that most people start with Django.
In a more a la carte framework, such as Flask, there are packages to help with user auth, but you have to do a lot more work to get them working with whatever ORM you choose.
This means I can spend my time making products instead of wrangling packages together.
If your application fits the use case - a mostly CRUD application based on SQL, HTML-based or REST, no heavy real-time component - don't think twice about it. Of course, none of those factors are a hard limitation, but if you stick to them, Django fits like a glove.
Second, Django is batteries included, meaning it does a lot for you, allowing you to progress fast. You won't get bogged down in the weeds. You can dig deeper on specific parts after you have more experience.
Third, there is so much learning material with Django. "Tango with Django" is my favorite. If you are learning, you need learning material.
It seems it's one of those things where you have to decide: Do I want to learn or do I want to build something and optimize for that.
Not that I'd recommend this way... but 6 years later it seemed to have worked.
I had a Perl background,so it wasn't a great jump, mainly just googling "python equivalent of <perl code>"
I'd begin with learn python the hard way.
I would 100% start in Python3 and DJango personally, but YMMV.
:) :/ ??
Pros and cons to both. I guess you can find weird solutions that look better one way or the other except the ORM.. but I don't really see it.
I currently like DjangoORM like 10% better, so I would use Django. It is my favorite ORM I have ever worked with. Right balance of saving you SQL writing time, while still having a good SQL escape hatch when needed.
If you hate DjangoORM, seems silly to suffer through it though.. use Flask or something else.
What you're looking for could be Flask or even something simpler like
or its Python3 version
Now, about Django...
I inherited a Django project and after a few months working on it I wouldn't start a project of mine with it. Obviously customers can ask me to do anything :-)
Disclaimer: I might be biased against it because I don't like Python much (it looks like a badly engineered Ruby, and probably the other way around if you like Python, no bad feelings).
First problem: coming from 10 years of Rails, Django is very weakly opinionated, so you can arrange the project as you want, name the db fields as you want, etc. This is not as bad as having no framework or using Flask, but a developer joining a project might have to spend time to get familiar with the general structure of it (and the bill for the customer keeps growing, so the chances he won't be happy).
Second problem: it doesn't import automatically every model and module. It gets tiresome to do that in every file and in the shell (and the bill...) This is not a language thing because Ruby has to import modules too but somewhat Rails works around that. Surprisingly it raised problems for me only a couple of times. The sum of the time lost with Python in the last few months is greater than the one I lost in Rails because of that.
Third: the templating language is not Python but some crippled down language. Somewhat people still manage to write nice code with Web2py which uses full Python in the templates. Rails too. Why not Django? More time lost to learn one more thing.
Web2py is an alternative but it has its share of problems: the first two of Django plus a very risky approach at migrations which are automatically enforced as soon as you run the code. If there is a way to turn that off and you really like Python or have to work with it, look at Web2py.
About the nice points, it's got everything that it has to be taken for granted in a past 2005 web framework: tests, migrations, ORM. It doesn't miss any particular feature, it's got a big community so it's a safe choice and I won't steer customers away from it.
1. This gives you flexibility to structure your app in a way that makes sense for what you're doing. In addition, I've found Django's approach to modular apps to be far more manageable and approachable than Ruby's "all the controllers go in the controllers folder" approach.
2. Explicit imports is a Python thing and a huge benefit. I've looked at plenty of Rails code bases where I had no idea where different functions and variables were coming from. In Python/Django, you can always see the explicit definition at the top of the file.
3. The "crippled down" templating language is very intentional as well. Django is preventing you from writing your application in the templating logic (something I've seen too much of in Rails) All your template should be doing is specifying how the data is to be rendered in HTML/whatever.
Really Python/Django could be said to be Ruby/Rails flipped on it's head.
Ruby itself isn't very opinionated (there are usually several ways to do something), while Rails is.
Python itself is pretty opinionated (there should be one right way to do things), while Django isn't.
In general it's a matter of opinion and perspective but I personal find Python and Django to be much easier to work with than Ruby and Rails.
You can do "db = DAL(..., migrate_enabled=False)" I believe.