5 ms·
Bumping into ORM limitations + moving to Jinja for templates --> one word: Flask ...really, what advantage does Django provide at this point in this project an
by nnq 14y ago
Bumping into ORM limitations + moving to Jinja for templates --> one word: Flask
...really, what advantage does Django provide at this point in this project anymore?
- megaman821 14y agoThere are still a lot of Django apps that work fine in this scenario. Plus I don't think the slides imply that they are just blindly replacing ORM calls with raw SQL, just that they have profiled and replaced the hot spots. Also Flask is a micro-framework and Django is a full-stack framework. Flask can be used as the backbone of a full-stack framework but figuring out a good project structure and finding out what third-party apps to use can be daunting for a person without Flask experience. If you really want to get people to switch, package up a Flask-based framework with the features of Django.
- pyriku 14y agoMiddlewares, context processors, forms, (class based) views, and tons of third party applications. The CTO of a startup where some friends are working thought the same you did, and 2 years ago rewrote everything to Flask. Now they're going back to Django. Django is much more that an ORM and templates.
- jokull 14y agoDjango middlewares is a poorly designed system. Flask has all of the things you mentioned except for forms. For that you can use Flask-WTF, but these libraries are becoming outdated anyway because they’re HTML based and don’t work so well for JSON validation.
- pyriku 14y agoCould you please explain why do you think that? IMHO it's a really clever approach.
- simonw 14y agoI've found Django forms to work extremely well for validating non-form-based data - the API is a neat way of representing a set of validation rules and running them against a set of data.
- jokull 14y agoHi Simon - I greatly appreciate your work and opinion! The reason I think HTML forms libraries are insufficient for the problem domain: JSON is richer, both in datatypes and structure. We’re working on a forms library of sorts that is better suited for API serialization/validation and having one central place to define models for multiple internal DB’s. https://github.com/plain-vanilla-games/schematics https://github.com/plain-vanilla-games/schematics
- plorkyeran 14y agoI've found Flask-WTF to work quite well for validating JSON. It looks a little weird at first due to the naming scheme mismatch, but I haven't encountered any actual functional problems with it.
- emidln 14y agoI don't write much HTML anymore (it's all frontend templating and API calls), but I use Django Forms everywhere. For instance, tastypie supports using a Django Form to handle validation in your API[1]. [1] - http://django-tastypie.readthedocs.org/en/latest/validation.html http://django-tastypie.readthedocs.org/en/latest/validation....
- Alex3917 14y ago"what advantage does Django provide at this point in this project anymore?" Documentation. I use Django but without any ORM and with Jinja2, so it's basically just Flask but with more stack overflow threads and more third-party software. Is there any actual advantage that I would be getting by using Flask instead?
- SPSteinbeck 14y agoI also use Django without any ORM and with Jinja2 and I'm taking baby steps towards completely abandoning Django and moving to Flask. For me, the primary benefit is that Flask being so much smaller and simpler than Django means you can understand the entire codebase without an extraordinary amount of effort. I'm curious as to why you stick with Django (other than having projects already begun relying on it)? Without the ORM and with the templates, there's is not much I get out of Django.
- Alex3917 14y ago"I'm curious as to why you stick with Django (other than having projects already begun relying on it)?" I'm still a relatively new developer, so it was just easier to learn.
- hcarvalhoalves 14y agoThe advantages aren't really in using Flask, but being able to use a better ORM (or no ORM at all, just SQL abstraction) and template engine. After working with Django ORM for a large project, I started to rethink the usefulness of models. It turns out just treating data as sets lends to a functional style and is simpler down the road.
- tomsthumb 14y ago> It turns out just treating data as sets lends to a functional style and is simpler down the road. Could you elaborate on this or point in the direction of something that does? I'm pretty sure I get the gist but having some more meat to chew to make sure the perspective is fleshed out fully would be awesome.
- andybak 14y agoIn addition to the other replies I have to add - the goddamn Admin. The amount of time it saves me is beyond belief.
- SoftwareMaven 14y agoIf you aren't using the ORM, what does the admin bring to the table? I agree with the value of the admin, and is one of the reasons in my latest project I kept the Django ORM, even though some coworkers felt it was limiting (it is, but it isn't all about a single component of the system).
- SoftwareMaven 14y agoCompletely replacing the template system with Jinja is silly (no idea if this is what they did) since it significantly reduces the value of the Django ecosystem. Far better it to use jinja for your work, but leave the Django templates for Django and all the other apps you integrate to use. I do with Django would reduce their stance on no expressions in the templates. Sometimes it saves a lot of work to just be able to call a function or add two numbers together without needing to build a filter or tag every time. I've been happy with django-jinja[1] for that purpose. It replaces the context processors so it will load jinja templates if they have a .jinja extension and Django if they are .html. It also includes the django filters in jinja-land. The ORM is more problematic. I just started a project a couple months ago and thought a lot about ditching the default ORM in favor of SqlAlchemy. I decided not to, for the reason of expedience and, as the TFA mentions, it already leaks. So, I stuck with the Django ORM and will drop to SQL directly if need be (need being defined by the ORM making the code confusing or there being performance hotspots). 1. https://github.com/niwibe/django-jinja https://github.com/niwibe/django-jinja
- naithemilkman 14y agoIn addition to what everyone else has mentioned, the amount of libraries written for Django is staggering. You almost never need to roll your own app -- someone has already done it! Also, geodjango.
- antihero 14y agoIt has an entire ecosystem and tool chain to sort building websites/webapps. When I used to use Flask, before moving to Django, I found myself essentially creating a whole bunch of stuff that Django already has, and is better written.
- bmelton 14y agoTo throw a completely different wrench into the mix, I mostly just use Django to provide an API anymore, and for session handling. I love and use Django, and have built large projects where I haven't really run into any limitations with it[1], but for the most part, nowadays my workflow is to pip install django, south, tastypie, then load in a template with Backbone and Marionette, then get to town. Templates are either Mustache or Underscore, depending. [1] - Yeah, it could be faster, but if you have a large, confusing database schema that you inherited, the Django ORM is great for getting things stood up, and then just tune the queries after the fact. It's still a huge timesaver vs. writing every query by hand.