Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Django 2.0 released

docs.djangoproject.com

Post reply on HN
Print view View original

141–150 of 177 posts

Re: Django 2.0 released

#141

Post by ubernostrum »

rtpg wrote: post #17
LeoJiWoo wrote: post #3

Wow, I remember being curious about Django a year ago. Now it's at 2.0 ! It already felt overwhelming then, but now even more so. I can't wait to check it out more. On a sidenote, I feel bad for the developers who have to migrate to Django 2.0. Hopefully it's not too much work, I know a codebase review and full update can't be fun with the business managers and customers at your throat.

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…

The policy of only supporting two releases + LTS predates having a paid person handling releases.

Source: before we hired Tim, I was doing most of the releases.

Re: Django 2.0 released

#142

Post by hakanderyal »

ubernostrum wrote: post #139
Walkman wrote: post #108

Earlier quoted context omitted.

not really. Did you ever tried to use SQLAlchemy with Django? Good luck with that.

Ever tried using SQLAlchemy with Flask? 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 p…

I've used SqlAlchemy with Flask. You only need a few lines of code to integrate them.

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.

Re: Django 2.0 released

#143

Post by [deleted] »

BlackMonday wrote: post #109
CraneWorm wrote: post #75

Earlier quoted context omitted.

Scala - Play

I'm not sure about that. Compared to Django, RoR and Laravel it's not opinionated enough. No resources like RoR and Laravel, no buil-in database mapping, no built-in authorization etc. 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…

[deleted]

Re: Django 2.0 released

#144

Post by richardknop »

mythrwy wrote: post #79
richardknop wrote: post #73

Earlier quoted context omitted.

One reason would be because you don’t know react or angular or whatever the latest js framework is. You have known Django for a decade and it still works so why waste time learning some js framework which might be out of fashion in 2 years. 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…

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

Re: Django 2.0 released

#145

Post by sgt »

Kpourdeilami wrote: post #15
sgt wrote: post #4

This is probably your best bet if you're just going to build a nice CRUD frontend for a business app, possibly with an API (via DRF). I am doing this right now on a project as it's the shortest path to a win. The API however is written in Java 8 / vertx.

Just out of curiosity, if the API is already being built in Java, why not just build a single-page-app to utilize the API instead of Django? I'd assume the deployment and overhead of maintaining a single-page-app would be way lower than Django. (i.e. uploading to s3 and setting up CDN vs. setting up a VM for Django with nginx, uwsgi, etc.)

As someone already suggested, writing an SPA comes with a lot of work to get going. This is a side project I need to write, and then hand off to an external development team at some point. Then it helps to simplify the equation as much as possible.

Re: Django 2.0 released

#146

Post by nielsole »

yeahdef wrote: post #91
halayli wrote: post #67

I really wish they merge Django and DRF.

seconded, it's amazing how many people claim to make "REST APIs", but they fall so short in a lot of aspects. DRF makes it almost impossible if used correctly.

Could you elaborate what you mean? Looking at https://en.wikipedia.org/wiki/Representational_state_transfe... I would think that esp. ModelViewSets are pretty RESTful

Re: Django 2.0 released

#147

Post by OOPMan »

At this point in time for me, having worked with a couple of Python web frameworks, I would recommend Django hands-down every time.

For me it comes down to one simple thing though: Migrations

Django has, far and away, the best migrations system I've used in a Python framework (although I won't claim to have used them all).

Compared to Alembic it's vastly superior also beats most jerry-rigged solutions.

Re: Django 2.0 released

#148

Post by maxerickson »

mcny wrote: post #118
PunchTornado wrote: post #110

Earlier quoted context omitted.

yes and it is indeed a feature. death to python2. I would pay money to that.

just yesterday someone at cuny sps told me a professor is teaching them flask using python 2.6... sigh

It'd likely be better to use Python 3, but the actual differences in syntax are pretty small, it's big Python 2 code bases that present a problem, not the switch over to using Python 3 syntax and names for new code.

Re: Django 2.0 released

#149

Post by bluewalt »

No Python 2 support, good thing. I understood that the Django codebase is lighter thanks to this, but I'm asking myself if it has any implication for the developper? (I was already using Python 3.6)

My guess: - The Django codesource is easier to read - Maybe error messages are cleaner? (just a supposition.. I don't know)

Re: Django 2.0 released

#150

Post by collinmanderson »

bluewalt wrote: post #149

No Python 2 support, good thing. I understood that the Django codebase is lighter thanks to this, but I'm asking myself if it has any implication for the developper? (I was already using Python 3.6) My guess: - The Django codesource is easier to read - Maybe error messages are cleaner? (just a supposition.. I don't know)

The documentation is a little cleaner too, with fewer “except on Python 2, it’s like this..”

Also, this will eventually allow type hinting in the future.

Post reply on HN