Live data from Hacker News

Django 2.0 released

docs.djangoproject.com

151–160 of 177 posts

Re: Django 2.0 released

#151
post #79

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…

I have never written an SPA but after writing a fairly complex ecommerce admin backend (handling orders, shipping etc), I wish I had. There are a lot of complex UI state and some of it would have been easier in React/Vue

Re: Django 2.0 released

#152

A 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.

Thanks for the reminder. Django made me like web development and find a job that I really love today. $25 given, it's nothing for this.

Re: Django 2.0 released

#153

Earlier 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…

Some things to do that could help everyone (this is what I do):

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

#154
post #17

Earlier 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…

(Channels is in the Django Github _organization_, separate repo.)

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

#155
post #96

Earlier 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.

You most certainly can. I've built several Django apps with Elasticsearch-DSL as a backend and another app with a completely custom backend (you need a really good reason to do this).

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

#156

Nice 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.

Time for Python 4!

Re: Django 2.0 released

#157
post #68
post #66

Does 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.

For GraphQL I think there is only graphene / django-graphene right now.

Re: Django 2.0 released

#158
post #67

I really wish they merge Django and DRF.

The value of the ecosystem is that each component does its part and each other component that has interaction with that component reaps the rewards. This leads to a natural evolution of components in the ecosystem (for instance, DRF evolved out of the need for better REST support, since projects like Tasty Pie were lacking thing that the rest of the ecosystem desired).

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

#159
post #27
post #21

Earlier 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?

With frameworks, the more they do for you, the more risk you will end up fighting against them if you need to do something they're not designed for.

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

#160
post #29

Earlier 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.

> (1) Write your new endpoint. (2) Proxy to it via your old one.

OR: (1) write your endpoint. (2) use something like apache's mod_rewrite to adapt endpoints.

Post reply on HN