Earlier quoted context omitted.
Static pages and full refreshes really limit what a page can do though. 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 th…
> Static pages and full refreshes really limit what a page can do though. 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 s…
Django 2.0 released
151–160 of 177 posts
Re: Django 2.0 released
#152A good time to remind that Django has met all milestone, bug fix, and security fix release targets since the introduction of the Django Fellow which can only be funded with donations. https://www.djangoproject.com/fundraising/ I’d like to encourage everyone that uses Django in a commercial setting to speak to their company about donating to the DSF to continue getting timely bug, security, and feature releases.
Re: Django 2.0 released
#153Earlier quoted context omitted.
That's surprising to me as I have updated a large production Django code-base on my own for every version from 1.5 to 2.0 and it has never taken me more than a day, with an equal or lesser (typically lesser) amount of time dedicated to deprecations when I updated to the previous version. Any blockers past that point have always been due to slow-to-update third-party libraries. The Python 3 update took longer and had…
> That's surprising to me I'm surprised you're surprised. Have you seen the size of the breaking changes documented with each release notes? We typically hit about 10 of these changes per release, sprinkled all over our code. https://docs.djangoproject.com/en/2.0/releases/1.10/#backwar... https://docs.djangoproject.com/en/2.0/releases/1.9/#backward... https://docs.djangoproject.com/en/2.0/releases/1.8/#backward... An…
If documented stuff changes, Please report it (though that likely means testing against the alpha / beta versions (or just master). Keep Django honest.
If you find yourself using undocumented features, consider documenting them; that way they’re held to backward compatibility.
Also, follow the development of Django and comment on the intentional breaks if you think they’re not worth changing.
Disclaimer: Core dev now, though I had this attitude before that too.
Re: Django 2.0 released
#154Earlier quoted context omitted.
The biggest challenge with upgrading Django is making sure all your Django-related dependencies have fixed things up. Django only has one paid full-time maintainer to my knowledge (Tim Graham). So given the team's limited peoplepower Only the last two releases (+LTS releases) get security updates. This means that Django 1.10 (released 18 months ago) won't get updates, so if you use any new features you're on the upgr…
I can't agree more with you. That's the one and only reason I'll stick to the 1.11 version. Garanty of compatibility between Django and ALL my external packages is a lot more valuable that a responsive admin panel and a new syntax for urls. I would love "important" (yeah it's opiniated) packages move to the official Django repo (like Channels), to help reduce this risk when migrating. It's actually surprising how oft…
Though, in theory, I don't think there's any actual difference in support having it under the Django _organization_.
Re: Django 2.0 released
#155Earlier quoted context omitted.
I've ever understood this argument. Any library you can pick and mix into your Flask app you could just as easily pick and mix into your Django app. It's all just Python.
not really. Did you ever tried to use SQLAlchemy with Django? Good luck with that.
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.
Re: Django 2.0 released
#156Nice this release will be the final push that tips over the balance towards Python 3. With Django taking the lead I think more projects will drop Python 2 support. Well it sure took a while, but glad the ecosystem is standardizing around 1 language again.
Re: Django 2.0 released
#157Does anybody know if there is better support for WebSockets? If I remember right, with Django(1) it is not easy to do it. And is it possible to use GraphQL?
With Django Channels there is great support, with some quite interesting things you can do. GraphQL can be handled by a third party package, there are a few out there at the moment.
Re: Django 2.0 released
#158I really wish they merge Django and DRF.
The idea that anything of value has to be nationalized and assimilated by the framework is a misguided effort to prevent chaos in the ecosystem, but the end result of trying to maintain order in an emergent ecosystem is usually disaster.
Re: Django 2.0 released
#159Earlier quoted context omitted.
I would rather use Flask for that.
I am learning Python right now and want to build a website using this programming language. Django and Flask seem to be the best frameworks for this purpose. I understand that Django has steeper learning curve and comes with "everything", whereas Flask is more modular and compositional. If I were to use Flask, is there anything that I could not do but that Django could?
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.
Re: Django 2.0 released
#160Earlier quoted context omitted.
To me the beauty of a restful API in flask is that you don't need to commit to anything. As far as the user is concerned, as long as /api/v1/user/15 gives back the user details for user number 15 (after checking authorization if necessary). The person who follows in my footsteps should be able to rewrite things one end-point at a time (as long as we clean things up after every transaction) in any other language (go l…
This can be achieved with any framework. (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.