Live data from Hacker News

Django 1.10 released

djangoproject.com

111–120 of 122 posts

Re: Django 1.10 released

#111

Earlier quoted context omitted.

There is no point unless you are going to using a lot of Python's scientific computing apparatus, or you want the ability to rewrite "hot" code in Cython for better performance. If you are primarily focused on social-esque or CRUD-heavy apps there isn't really an upside vs Rails.

What could you possibly be doing that you need those things within a Django app? If you're placing CPU-intensive and scientific code directly into your web app backend, I'd rethink your architecture before you consider switching languages.

> What could you possibly be doing that you need those things within a Django app? If you're placing CPU-intensive and scientific code directly into your web app backend,

I have worked on a lot of projects that involve science related stuff and Django.

Directly in the web app backend was relevant mostly for GIS apps that could take large raster data, process it based on the user's wishes, apply the right projections, apply a colormap and return an image to be shown on a map. Python has great tools for that sort of thing and it doesn't have to take much longer than rendering a HTML template does.

Other than that, the CPU intensive science-related stuff usually ran in background tasks, with Celery or otherwise. But those would still need access to the database, so why not use the same Django models for the web backend and the background tasks.

I find that once Django is part of your Python code it tends to find its way to all parts of it, through the ORM, settings files, handy admin interfaces, management commands as scripts, and so on.

Re: Django 1.10 released

#112

Earlier quoted context omitted.

Until you hit the migrations in 1.7. But you are right. At my previous job, I spent countless hours getting from 1.4 to 1.5, but the step from 1.5 to 1.6 was relatively painless.

For others: https://docs.djangoproject.com/en/1.9/ref/django-admin/#cmdo...

This was introduced in 1.8 (which is great if you move to 1.8 or beyond), but if you are trying to go step by step, 1.7 was not a fun release to migrate to. There were also many problems with custom user model and the like.

1.7 was a very important release in the history of Django, just not a fun release to move to if you had a large codebase.

Re: Django 1.10 released

#113
post #52
post #27

Shame about Channels, but I see the logic in not including it. Django is pretty awesome as a backend, and while it's not a 'cool' framework anymore (I feel old!) it's amazing for writing back-office applications. I use it as an API backend with Django-rest-framework. The advantage is you get ridiculous amounts of packages that all integrate with Django that does pretty much anything you want. Also the ORM doesn't suc…

So does that mean we should pick a new language/framework that is "hot" now and write a bunch of libraries for it? Basically, reinventing the wheel over and over and over again?

There are some differences that one could call objectively better in other technologies compared to Python/Django.

I'm somewhat conflicted about Channels. On the one hand it's cool what you can do with it and the design cleverly avoids rewriting all of Django to be async. On the other hand it is crazy how many shenanigans one needs to pull off to achieve what comes for free with Go or Erlang.

Fashion-like churn is obviously nonsense and reinventing the wheel usually a waste of time. But when you need a really round wheel and your current tools can only make hexagons...

Re: Django 1.10 released

#114
post #53
post #27

Shame about Channels, but I see the logic in not including it. Django is pretty awesome as a backend, and while it's not a 'cool' framework anymore (I feel old!) it's amazing for writing back-office applications. I use it as an API backend with Django-rest-framework. The advantage is you get ridiculous amounts of packages that all integrate with Django that does pretty much anything you want. Also the ORM doesn't suc…

Why a shame? What would Channels buy you if it were included into the framework? I would love to see Django split up into smaller official external packages and repackaged as two or three different official starter packs (Traditional, API, SPA, etc.) with each containing a different set of packages that make sense (DRF, Channels, Models, Views, Forms, etc.). I know this goes against the current "Batteries are include…

Django isn't that big in terms of file size, and you can just turn off the batteries you don't need.

Re: Django 1.10 released

#115

Earlier quoted context omitted.

>front-end features like form generation and HTML templating were really important, but now they're arguably better to avoid. Why is that?

Not OP but I feel like it's because JavaScript has evolved enough that some of the niceties they offered before doesn't make sense. I like using Ember.js and doing client-side validations is pretty darn easy without complicated JS. Additionally, having inherited a legacy Rails project that uses `remote: true` in it's forms, it is causing more of a headache to fix these legacy issues.

Validating data should always be done on the server. You should never, ever, trust the client.

That's not to say you can't do (or shouldn't do) form rendering, processing, error/success handling, etc. on the client-side, but the server should always have the last word on the validity of what you send.

Re: Django 1.10 released

#116

Earlier quoted context omitted.

> Moving from 1.8 to 1.11 shouldn't require any changes provided that you're running with 0 deprecation warnings on 1.8. Yes, this is how it's supposed to be. This agrees with Django's roadmap (see the "I’m the maintainer of a reusable application. Which Django versions should I support?" question at the bottom): https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ However, it depends on the third party apps you…

Yeah dependencies are always going to be an issue unfortunately. Django can make as many recommendations as it likes, but you're still at the mercy of all other dependencies. Moving from 1.9 to 1.10 is different than moving from LTS to LTS. The hope is that 3rd party packages will be testing against LTS releases at the minimum, which should allow you to make the jump after packages have time to update themselves.

> Moving from 1.9 to 1.10 is different than moving from LTS to LTS. The hope is that 3rd party packages will be testing against LTS releases at the minimum, which should allow you to make the jump after packages have time to update themselves.

This is true. Good point.

Re: Django 1.10 released

#117

Earlier quoted context omitted.

Was Django ever the hot new thing? Python certainly isn't and has never been "hot." In the 2000s, it seems much more like all the attention went to RoR. Now all the attention goes to JavaScript. In the meantime, Django has steadily added new functionality while adhering to smart core principles. It really does seem to be in the sweet spot of dependability and convenience. I don't think anything else is faster to deve…

You must have been asleep 5-10 years ago when Rails and Django were repeatedly being pitched against each other by hipster developers, leaving PHP, looking for the "new thing". They were both scorching hot until somebody decided doing everything in Javascript was a good idea. (Edit FTR: Given the topic thread, I feel it important to say that I didn't mean Node et al are better than Django, just that these hipsters th…

I guess I remember all the hype going to Rails, not Django. For example, dozens of coding bootcamps used a Rails curriculum but I haven't heard of a single one which taught Django.

Re: Django 1.10 released

#118
post #104

Earlier quoted context omitted.

What could you possibly be doing that you need those things within a Django app? If you're placing CPU-intensive and scientific code directly into your web app backend, I'd rethink your architecture before you consider switching languages.

Come one, even scientific work will require a front end at some point. Not everything will be CPU intensive. And even if it is it may need some user interaction to get the task started - even if it is just uploading data to be processed offline.

But you don't need the scientific code inside your Django app—it should live in a separate process. What I'm saying is there is no need to have the scientific code directly inside the Django app.

Re: Django 1.10 released

#119

Earlier quoted context omitted.

You might as well use Flask at that point. You can use cookie-cutter to create the starter packs.

I love Flask. People say Django is easier to use but I had a much easier time with Flask. It's well documented and very flexible.

Maybe not easier to use in general, but you don't have to replicate all the daily stuff you maybe need for your project. With Flask you have to recreate many things (for example acc management) or rely on a thrid party-dev. In django you get core stuff from the core team(also with the freedom of recreating it yourself or use some app from a thridparty-dev).

Re: Django 1.10 released

#120
post #5

As a Rails dude...is there any reason for me to learn Django at all? Everything I've heard about it is that it provides a lot of sane defaults (like Rails) but has much less "magic" than Rails is typically thought to have. And if the answer to my question is yes, what books/tutorials/screencasts/courses to people recommend to get started with?

The online documentation will serve you well. I recently had to learn django for my new job and I must say that I enjoyed every bit of the learning process.
Post reply on HN