This is where people fear the “magic” of things like pluralization of models to table name and introspection... but it’s all just code! You can read it and look at it and understand it. No magic here. Just convenience and a smaller mental model as an end developer.
Also... resources as a first clsss citizen is the biggest reason and the reason it defeats Django for this use case. You define ‘resources’ in your routing layer instead of just routes that map to a function. This allows you represent multiple crud actions with a single controller and even nest them, all with a few lines of code. Then you get access control for free on your sub resource, knowing you’ve already passed the parent checks and have that context.
Example: /users/:id/photos/:id
In this case, my Photos controller will already know who the user is (and if they can view these photos) based on work that the parent did. It’s single responsibility principle. You can even have a top level photos resource devoid of the user context and support both cases with minimal effort.
Yes, you can do these things in Django. But it’s not designed to make these things composable and seamless. I’d argue it’s not REST-friendly. Don’t even get me started on Django Rest Framework which is a massive beast in and of itself.
You get all of that out if the box on Rails. You can stand up extremely robust and ergonomic API’s with so little code you’ll feel like your cheating.
I should probably write a blog post.
Though, when it comes to prototyping, I think Rails is a much more convenient option. In Rails I can launch a working CRUD app with authentication in 10 minutes, literally. In Django I have to manually create directory structure, manually specify each route mapping, create and program controllers (views), etc. Django doesn't even have a built-in authentication templates, only controllers (views), so I end up writing this boilerplate over and over again. The other thing is that the authentication requires a username and password, which feels kind of clumsy, when every other authentication relies on email and it is not very trivial to modify that (built-in admin dashboard relies on built-in authentication for example).
Someone still had to create that database with those tables in it. It didn't magically pop out of the aether. Your complaint, then, is not "you must define every bit", but with where you do it, since you have to define things no matter what.
And if you have an existing database you'd like to use with Django, 'manage.py inspectdb' will reverse-engineer a set of model definitions from it.
If you have an existing database, sure, Rails is preferred. If you're starting from scratch, the Django definitions can create the tables for you. If you do have existing tables though, you can use inspectDB to have Django create the models for you.
My Rails projects have always been the ones that felt the most done on their initial release. That extra time not typing and configuring goes into caching, validation, UX, and making nice solutions to project specific problems that fit nicely and don't become pain points as time goes on. All these things that can feel shortchanged in other projects get more of the polish they need sooner.
Ruby - Rails
PHP - Laravel
all nice choices
Elixir - Phoenix
I wish there was a complete Clojure - ???
Elixir itself is an excellent language that leveraged the strengths of the Erlang VM, and Phoenix is like a massively improved, blazing fast and reliable version of Rails.
It will be the logical successor to Rails. It already is.
That said, I use a good mix of Elixir+Phoenix and old-school cron launched Python utility scripts, and that works nicely. Anything that's difficult (probably because I am still a newb) in Elixir I can easily do out of band with a Python script.
But your point about difficult to hire experienced people is the reason for my reply. This is the mentality that is ruining IT and development. Yes, having someone with hands on experience in all of your tools is nice - a rare luxury in fact. But it's really not necessary. I would be quite happy to have someone that has willingly built something in Rails, Django, and Nodejs with an "Oh I can learn that" attitude. Especially if you come from a modern MVC framework, Phoenix itself is easy. Elixir is the part that requires some real effort, imo.
I personally find that Laravel is less heavy than Django which is way less heavy than RoR. I would never use RoR for small projects.
btw: what do you use for the database access? Slick, Quill, Doobie, ScalikeJDBC, Anorm, Squeryl, jOOQ, Relate, Activate or something else? There seem to be gazillions of sql libraries for scala (although the big three and most relevant are probably Slick, Quill and Doobie).
And what do you use for Authorization? Something custom build? If I look at Laravel there are quite a few maintained authorization libs with ~1000 stars on youtube (even more if we count unmaintained), for play there is not really much (deadbolt, play4j and t2v/play2-auth, I don't count Silhouette since the lib is mainly about authentication).
Rhetorical question by the way... just food for thought. There is a balance. I happen to love the convention rails imposes and the “magic” it offers. That being said, there isn’t anything about it that I consider wizardry or don’t understand. It’s just ruby.
Are you not talking about Java here? ;)
Clearer code makes it easier to reason and hence easier debugging. Correct me if I am wrong.
Also, it really depends on person to person on how they write the code. Django does not mean big boilerplate nor does Rails.
My main question was on performance. How do they stack up next to each other? Python3 with Django is really working well these days. You can also check out the performance improvement on Instagram because of it. https://thenewstack.io/instagram-makes-smooth-move-python-3/
Generate dynamic HTML on the server, that still works just fine. And codebase will be way simpler as you just generate HTML on page refresh. No need to fiddle with event listeners and DOM and AJAX or whatever.
Single page web apps are often wrong choice if you just need some UI other than some fancy dashboard. Let’s say you need an admin panel where you can do CRUD operations, that’s perfect for Django/Rails and would be much much more work as SPA.
My personal preference (for most use cases) is a combination. Some things are easier done in static templates but JS is needed to really bring a page to life IMOP.
Lately there is too much SP-appage around where there are simpler alternatives though, with that I'll agree. I guess it keeps people employed screwing around with webpack so there's that.
Yes. But for 90% of business UI cases, you have some sort of collection of pages (i.e. website = collection of pages not a single page with everything crammed into it) with navigation menu. You use the menu to navigate to different pages with HTML forms that submit POST data and do GET redirects.
Trying to cram an entire business logic into a single page is often detrimental, split it into multiple pages. Highly interactive apps that fit into a single page model is maybe 10% of use cases or less I have seen in my career last few years.
This is all just my opinion obviously but I just think SPAs are a fad that will hopefully go away.
About NGINX, is still needed in both cases IMO, for the API or the frontend server.
If it were me, I'd probably use something else before I tried to squeeze that much performance out of Python at this point to though. I hope library support catches up and it becomes more convenient, but I don't think a predominantly synchronous ecosystem has really successfully transitioned to async before.
https://docs.djangoproject.com/en/2.0/ref/contrib/gis/tutori...
If I had to choose a framework for a web API these days, I would go with something that is async from the ground up.
Because we are getting more and more CPU cores to utilize. I don't think this trend will stop soon. The software stack will have to adjust to this and it already does. The next generation of mainstream (highlevel)languages/frameworks will be those that are designed to easily utilize CPU cores. It may be more expensive for now, but it might pay out later and I think it's much more exciting. ;)
With 30 workers threads in Python Django, I should be able to make very good use of 6 CPUs even if the workers only run 20% of the time.
Like those: https://docs.djangoproject.com/en/2.0/ref/databases/#using-a...
They are, indeed, quite complex.
I'd agree with you for a very simple API (like a simple slack/irc bot), but for a CRUD, you'll need to write a LOT of boilerplate code with Flask
(1) Write your new endpoint. (2) Proxy to it via your old one.
Or for a full re-write you might want to do things the other way.
(1) Wrap the whole old app with a skeleton of the new one - just proxying the endpoints for now. (2) Start replacing the endpoints.
OR: (1) write your endpoint. (2) use something like apache's mod_rewrite to adapt endpoints.
If I were to use Flask, is there anything that I could not do but that Django could?
Suddenly it's not so simple.
That being said, if your app really is simple (single file, under 100 lines) flask is excellent.
The problem is that a lot of people writing Python web stacks don't know how to write Python at all, and no framework will save that shortcoming.
Flask is advertised as a micro framework. if you want to rebuild Django with it then sure you can, but I personally can't see why you'd want to.
Flask is, of course, more powerful than bottle, and has less batteries included than Django. Saying Flask is good for 100 LOC sites is terrible advice, no matter which way you try to slice it. It isn't. It's widely-used and well-maintained.
Don't get me wrong, I like Django as well.
Django is no different. Django falls apart spectacularly in the hands of people who can't program.
I'm using Flask, but building my apps with Python.
This simple/complex equation should be reversed IMHO. Want to throw together something quick? Go with Django, where everything you need is built-in. Want to build a big app? Go with Flask, and build your stack specific to your needs.
As a bonus, once you have built a complex app with your own abstractions/magic succesfully, it becomes faster for you to build new projects with your own framework than any other alternative.
There are tradeoffs of course: you give up the Django admin and a bunch of other things, at which point we might as well have used Flask. But our shop has a number of other "normal" pure-Django apps so it makes sense for us to use Django as a common base.
Awhile ago there was a book called "Lightweight Django" in which the authors showed how to use Django in a stripped-down Flask-like manner. Ultimately Django is just a big bag of parts that you can use or not use.
It's exactly the same situation: either you luck out, and someone already wrote all the conveniences and utilities and integrations with components for you exactly the way you want them with exactly the set of other components you wanted, or you do it yourself.
Also, you could make a similar argument about swapping major components into, say, Pyramid. Most of the alternatives people promote to Django are not really some paradise of trivially-swapped-but-tightly-integrated components. They just do exactly what Django does, with a different set of "use these or lose the integration" components chosen up-front for you.
But yes, with Flask (or similar frameworks/libraries), you need to do the integrations yourself with the components you want to use. Advantage of Flask in this regard is, you don't need to fight with Flask to make it happen. That's why I'm saying it's better suited for complex apps that you want to build with your own abstractions.
The real problem is the cargo cult thinking when it comes to frameworks, instead of doing a cost/benefit analysis and thinking about trade-offs.
Following statements like "Django for complex apps, Flask for 100 lines of apps" without researching the reasons behind probably will result in more problems in the future.
Really? So you got all the things you get in Django -- ORM, forms with validation, etc. etc. -- from "a few lines of code"?
Somehow I think that's not true.
If you're familiar with SQL, it may take some time to adapt to the Django ORM, which is really great but favors ease of use over power.
All in all, with Django you'll fight to override defaults and with Flask to enforce them. I loved both enemies
No, but it might be simpler.
When I started doing webdev in Python I used Flask (it's so slim, they said) and I still like it, but if you have some kind of DB in the back and care about user management, Flask won't help you.
Most people then use sqlalchemy and specific extensions for Flask to handle the user and security stuff. Although this works, I would advise you to start with Django.
Django isn't particular bad at this (it has some escape hatches to allow you to e.g. write custom SQL), but it is overal still quite a big framework and it's certainly harder to bend to your will than Flask.
So, you need to know the extra things it gives you and figure out if they will be helpful for your website.
Loosely, Django is: routing + HTML request parameter handling + HTML rendering + templating + user sessions + lots of database read/write help, assuming simple CRUD access patterns.
Flask is: routing + HTML request parameter handling + HTML rendering. Then, if you want any of the other things, you go and find a library for them.
The time you save initially you'll later spend fighting the framework or debugging its internals.
Python's "explicit over implicit" scales a lot better, especially with large teams.
(personal opionion of someone maintaining production-critical Django and Rails applications)
The parent comment being flagged to death is enlightening on both counts. I also appreciate your telling me you'd comment and vote on a thread about a Django release even though you've never used it and aren't a developer. That's simply fascinating!