GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-12-02) - page 1 of 10
 
___________________________________________________________________
Django 2.0 released
428 points by Hangya
https://docs.djangoproject.com/en/2.0/releases/2.0/
___________________________________________________________________
 
myf01d - 6 hours ago
Serious question: is the famous bug of correctly annotating
multiple counts fixed now?
 
  lamby - 4 hours ago
  Huh, I'm a big Django user but not heard of this. Link? :)
 
    brianwawok - 2 hours ago
    Me eitherI am guessing it is one of the points where the ORM
    breaks down.. which the answer is "use rawSQL"
 
  orf - 3 hours ago
  Nope that's still a limitation and a tricky one to solve, and I
  agree it's really really annoying.I added support for filtered
  aggregates[1] in this release, if you're annotating multiple
  counts this might be useful for you.1.
  https://docs.djangoproject.com/en/2.0/ref/models/conditional...
 
y04nn - 4 hours ago
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?
 
  orf - 4 hours ago
  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.
 
    trowawee - 4 hours ago
    Seconding this. Channels was actually shockingly easy to
    implement, maintain, and expand, even at a small startup with a
    fairly small and relatively inexperienced team.
 
halayli - 4 hours ago
I really wish they merge Django and DRF.
 
  dragonorta - 2 hours ago
  DRF has stated that they don't wish to be brought under the
  Django org, as they don't want their releases tied to Django's
  release timeline.
 
  marviel - 4 hours ago
  Yeah or at least brought it "in house" as a Django officially
  supported app, like Django Channels
 
    [deleted]
 
  yeahdef - 3 hours ago
  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.
 
tschellenbach - 6 hours ago
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.
 
lima - 7 hours ago
Notable feature: no Python 2 support!
 
  PunchTornado - 22 minutes ago
  yes and it is indeed a feature. death to python2. I would pay
  money to that.
 
ergo14 - 45 minutes ago
Excellent, Django team made a really great job.
 
janvdberg - 2 hours ago
Nice! Coincidentally I had my very first Django experience two
weeks ago (and blogged about it [0]). It struck me as a very solid
and clean and lean framework. But I do think there is somewhat of
an entry barrier: you need to understand quite a few concepts,
which if you do, would open up many more options besides Django. So
it's not unique in that regard. However, I had trouble finding
QUICK CRUD app solution i.e. here is my database, please make some
forms for me. And Django: with the builtin admin/user mgmt, did
exactly that.[0] https://j11g.com/index.php/2017/11/23/django-
in-10-minutes/
 
[deleted]
 
LeoJiWoo - 6 hours ago
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.
 
  cloverich - 6 hours ago
  Kind of funny, but I had the opposite reaction. I was playing
  with Django when I was first getting into web dev 6 or 7 years
  ago. When I saw this, I thought "Oh wow, they're just barely
  getting to 2.0 and making breaking changes?"
 
    LeoJiWoo - 6 hours ago
    I'm excited by seeing support and continued development.
    Nothing worse than a dead framework, but I def see your
    point.Stability is very important too.
 
    nitely - 6 hours ago
    They always make breaking changes. There's usually a
    deprecation period though. They didn't do semver but it seems
    they will now.
 
      collinmanderson - 3 hours ago
      It's roughly semver, but if you receive warnings when using
      2.0, for example, your code may break in 2.1.If you don't
      receive warnings, your code will work fine on future 2.x
      releases.
 
  ameliaquining - 6 hours ago
  If you were already using Python 3, and your code wasn't emitting
  any deprecation warnings, then it's a fully backwards-compatible
  change and you can just bump the version number in your
  requirements.txt with no other changes.If your code was emitting
  deprecation warnings, then you have to fix them before upgrading,
  but this should be relatively rare and they shouldn't be that
  hard to fix.If you're still on Python 2, then you have to either
  migrate to Python 3 or stay on Django 1.11 (which is an LTS
  release). 1.11 EOL is April 2020, which is the same time as
  Python 2's EOL, so you were going to have to migrate your
  codebase by then anyway.
 
    reificator - 6 hours ago
    > so you were going to have to migrate your codebase by then
    anywayThat's an optimistic viewpoint.
 
  erichurkman - 6 hours ago
  If you're already at 1.11 and on Python 3, it should not be too
  bad of an upgrade. If you have to go from an earlier version
  _and_ do the swap from Python 2 to 3, you may be in for a world
  of pain.
 
    JshWright - 9 minutes ago
    Yeah, make the 2.7 -> 3 (preferably 3.5+) transition on 1.11,
    _then_ do the 1.11 -> 2.0 upgrade.
 
  [deleted]
 
  rtpg - 6 hours ago
  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 upgrade treadmill.Django
  itself is very good about offering clean upgrade paths. Very
  vocal about breakage, usually will not introduce breakage unless
  there's some good reasons to. Unfortunately third party libraries
  often take a while to update, so you can quickly find yourself
  overwhelmed with figuring out which deps are safe to upgrade and
  which aren't.I try to be a good OSS citizen and send in
  compatibility fixes for libraries that fall behind, but
  maintenance can be hard when you're only really using about 25%
  of a library.I wouldn't be comfortable with sticking to older
  Django LTS releases (there was still a lot of obvious improving
  to be had in the ORM and migrations in particular), but I think
  Django 2.0 is in an amazingly good place now. Sticking to this
  for a couple years would be fine for a lot of people.
 
    orf - 3 hours ago
    > Django only has one paid full-time maintainer to my
    knowledgeIt indeed does, but I don't agree that it is too
    limiting in that respect. A lot of Tim's time is spent
    curating, reviewing and merging PR's contributed by the
    community. It's far, far from a one-man band.Not sure if that
    was what you are implying, but that's how I read it.
 
  simonw - 5 hours ago
  If you're already on Python 3, upgrading from Django 1.11 to
  Django 2 is pretty much the same amount of work as upgrading from
  1.10 to 1.11 was. The "2" in the version here reflects the
  dropping of support for Python 2, and the switching over to a new
  versioning scheme:
  https://docs.djangoproject.com/en/2.0/internals/release-proc...If
  you need to upgrade from Python 2 to Python 3 it will likely be a
  fair amount of work.In case it's useful, here's what I did to
  upgrade my blog (a pretty simple application, though one that's
  been around for a long time and survived a lot of different
  Django versions):
  https://github.com/simonw/simonwillisonblog/pull/10
 
BuckRogers - 1 hours ago
Congrats to the team, this has been a long time coming. No Python2
support which is unfortunate, my Python3 migration strategy was to
move to C# for my main language instead. No regrets, I like it a
lot. I describe it as industrial strength. Good IDE and granted me
a larger job market with Xamarin for iOS coverage.For web stuff,
I'll probably be using a C# framework, or Wordpress with one of the
JITs. Still, a lot of hard work has gone into Django 2.0 and I'll
be keeping tabs on it, rooting for the team. It's not likely but
not barring the idea of using Django again.
 
sgt - 6 hours ago
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.
 
  Rotareti - 6 hours ago
  > 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).If I had to choose a framework for a web API these days, I
  would go with something that is async from the ground up.
 
    yedpodtrzitko - 6 hours ago
    Django Channels [1] + ASGI is exactly that. However making that
    the default would be a hit to the very good backward/forward
    compatibility Django keep having.[1]
    https://channels.readthedocs.io/en/latest/
 
    blowski - 6 hours ago
    Why? Async isn?t cost free - it?s more complicated and that
    complexity comes at a cost. If your company has only basic
    needs, you have to question whether you?re providing the best
    value for your company by doing anything more.
 
      jrs95 - 5 hours ago
      Especially when a platform doesn't have libraries that
      support it fully. Node and ASP.NET are the only fully async
      platforms I'm really aware of where this isn't a huge
      problem. Of course there are others with great but not async
      concurrency models as well. Regardless, it's definitely a
      minority of use cases where the concurrency model should even
      be a priority.
 
      Rotareti - 2 hours ago
      > Why?Because we are getting more and more CPU cores to
      utilize. I don't think this trend will stop soon. The
      software stack will have to adjust to this and it already
      does. The next generation of mainstream
      (highlevel)languages/frameworks will be those that are
      designed to easily utilize CPU cores. It may be more
      expensive for now, but it might pay out later and I think
      it's much more exciting. ;)
 
  baby - 6 hours ago
  I would rather use Flask for that.
 
    cdancette - 5 hours ago
    Flask for a CRUD ?I'd agree with you for a very simple API
    (like a simple slack/irc bot), but for a CRUD, you'll need to
    write a LOT of boilerplate code with Flask
 
      JelteF - 5 hours ago
      There's flask-restless, which removes most of the
      boilerplate. There's still good reasons to choose django over
      flask though, but easy rest apis can be achieved with both.
 
    edshiro - 6 hours ago
    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?
 
      brianwawok - 6 hours ago
      I would miss the django ORM. Depends if you like the ORM.
 
      orf - 6 hours ago
      The advantage of Django is it comes bundled with everything
      you could need. Flask is simple, but then you need user
      authentication. Which library do you use? Is it updated and
      maintained? What about an ORM, forms, templating,
      localzation. Do they all work together?Suddenly it's not so
      simple.That being said, if your app really is simple (single
      file, under 100 lines) flask is excellent.
 
        hakanderyal - 3 hours ago
        What I like most about Flask is, it provides the barebones
        for request/response handling, and gets out of your way.
        Add SqlAlchemy to the mix, and python handles the rest.I'm
        using Flask, but building my apps with Python.This
        simple/complex equation should be reversed IMHO. Want to
        throw together something quick? Go with Django, where
        everything you need is built-in. Want to build a big app?
        Go with Flask, and build your stack specific to your
        needs.As a bonus, once you have built a complex app with
        your own abstractions/magic succesfully, it becomes faster
        for you to build new projects with your own framework than
        any other alternative.
 
          simonw - 2 hours ago
          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.
 
          Walkman - 42 minutes ago
          not really. Did you ever tried to use SQLAlchemy with
          Django? Good luck with that.
 
        dizzystar - 5 hours ago
        Oh, come on. There are plenty of large websites written in
        flask. It's not that hard to use at all, and all those
        things you list are definitely a part of it. Hell, I have a
        20 KLOC website written in bottle, and no one ever said it
        was poorly done, insecure, and so on.The problem is that a
        lot of people writing Python web stacks don't know how to
        write Python at all, and no framework will save that
        shortcoming.
 
          orf - 4 hours ago
          Part of my point was that if your site is going to be 20
          KLOC then why not use a framework that is aimed at
          building 20 KLOC large sites rather than one that is
          aimed at writing 200 line sites.Flask is advertised as a
          micro framework. if you want to rebuild Django with it
          then sure you can, but I personally can't see why you'd
          want to.
 
          dizzystar - 4 hours ago
          Flask is used by Pinterest and LinkedIn, which I'm
          guessing are a touch more than 100 lines of code.Flask
          is, of course, more powerful than bottle, and has less
          batteries included than Django. Saying Flask is good for
          100 LOC sites is terrible advice, no matter which way you
          try to slice it. It isn't. It's widely-used and well-
          maintained.Don't get me wrong, I like Django as well.
 
          orf - 4 hours ago
          I've used Flask for single file sites with 10-250 lines.
          It's great (ish). What's bad about it? Your saying it's
          only good for writing large applications? How so?
 
          dizzystar - 2 hours ago
          Your contention is that it's only good for small sites.
          I'm saying it's good for any sized site as long as you
          actually know how to RTFD and program in Python.Django is
          no different. Django falls apart spectacularly in the
          hands of people who can't program.
 
        int_19h - 5 hours ago
        If your app is that simple, Bottle is probably a better fit
        than Flask (even more minimalist and non-opinionated).
 
          jrs95 - 5 hours ago
          Flask is a great fit with smaller APIs but not tiny like
          this in my experience. Great support for SQLAlchemy and
          database migrations. Better than Django ORM in my
          opinion.
 
      protomikron - 6 hours ago
      > If I were to use Flask, is there anything that I could not
      do but that Django could?No, but it might be simpler.When I
      started doing webdev in Python I used Flask (it's so slim,
      they said) and I still like it, but if you have some kind of
      DB in the back and care about user management, Flask won't
      help you.Most people then use sqlalchemy and specific
      extensions for Flask to handle the user and security stuff.
      Although this works, I would advise you to start with Django.
 
      robertfw - 2 hours ago
      If you are learning python, I would stick with Django. It'll
      get the basics up and running for you and you can focus on
      python specific code. If you go with flask you'll need to be
      piecing everything together on your own, and then you're not
      just learning python, you're learning web application
      components and flask as well.
 
      feydaykyn - 3 hours ago
      If you have little experience with backend development,
      Django may help you by forcing you to code into a predictable
      and sensible structure; Flask won't limit you in any way,
      which is great but It's easier to shoot yourself in the foot
      and its harder to keep a consistent codebase.If you're
      familiar with SQL, it may take some time to adapt to the
      Django ORM, which is really great but favors ease of use over
      power.All in all, with Django you'll fight to override
      defaults and with Flask to enforce them. I loved both enemies
 
    mcny - 6 hours ago
    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 lang or rust
    or swift seem like best bets). At least that is my hope, even
    if the person who follows in my footsteps is me!
 
      asfdsfggtfd - 2 hours ago
      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.
 
  paulie_a - 6 hours ago
  Also APIStar from the creator of DRF is something to keep an eye
  on. It has Django integrations and I believe is async.
 
    jrs95 - 5 hours ago
    It's not inherently async, but it supports async. Although
    database support for that isnt great, so I'd recommend just
    sticking to synchronous stuff for now unless you don't mind
    using raw SQL.If it were me, I'd probably use something else
    before I tried to squeeze that much performance out of Python
    at this point to though. I hope library support catches up and
    it becomes more convenient, but I don't think a predominantly
    synchronous ecosystem has really successfully transitioned to
    async before.
 
      mattgreenrocks - 5 hours ago
      AFAIK, C# navigated the sync-async transition well.
      Admittedly, this is a function of time, as it has had
      async/await for quite awhile.
 
        jrs95 - 4 hours ago
        Totally forgot about that one. Having nearly everyone on
        one the same framework probably helped a lot with that. I
        don't think anyone else really has that advantage. Except
        maybe Ruby and Rails... Perhaps some good concurrency stuff
        will come of Ruby 3.
 
    goodoldboys - 5 hours ago
    +1 for APIStar. I love Django but if all you want to build is
    an API, it can be a bit much. APIStar has been great so far in
    the one production API I've helped build even if there are a
    few pain points that come with using such a new framework.
 
  systems - 5 hours ago
  i vote turbogears for crud apps
 
  sebazzz - 6 hours ago
  One disadvantage of Django is that database providers need to
  know a lot about the internals of the framework. This shows once
  you rely on a 3rd party developed database provider, which can
  break even on minor upgrades.
 
  whalesalad - 6 hours ago
  I?d posit that a simple crud app would take an order of magnitude
  less time with Rails. I?ve been a Django developer since 0.96 and
  have built dozens of apps with it. After transitioning to Rails,
  it?s hard to justify the use unless you?re in an evironment that
  absolutely must use Python.
 
    mundanevoice - 5 hours ago
    How about performance? Bugs that might come up due to the
    implicit nature of Rails? Just curious, since you have seen
    both sides.
 
      whalesalad - 5 hours ago
      The implicit ?magic? thing isn?t a real thing. It?s a
      fallacy. I have not come across real world problems like
      this.
 
        mundanevoice - 5 hours ago
        Well. I disagree that it is not a real thing. For better
        debugging, you need to know more what's behind the scenes.
        Personally, I have seen some of my colleagues struggling to
        find the cause or better architect the thing because most
        of the decision has been hidden/taken by the framework. Not
        saying, it's true for all Rails dev but for some beginners,
        it really bites them.
 
          whalesalad - 5 hours ago
          Sure but there is magic everywhere. You trade convenience
          for the risk of not knowing the underlying mechanism in
          action. The inverse is long boilerplate code, setting up
          multiple services and factories and fooWidget stuff just
          to do a simple thing. It?s more clear, yes, but is it
          always better?Rhetorical question by the way... just food
          for thought. There is a balance. I happen to love the
          convention rails imposes and the ?magic? it offers. That
          being said, there isn?t anything about it that I consider
          wizardry or don?t understand. It?s just ruby.
 
          mundanevoice - 5 hours ago
          > The inverse is long boilerplate code, setting up
          multiple services and factories and fooWidget stuff just
          to do a simple thingAre you not talking about Java here?
          ;)Clearer code makes it easier to reason and hence easier
          debugging. Correct me if I am wrong.Also, it really
          depends on person to person on how they write the code.
          Django does not mean big boilerplate nor does Rails.My
          main question was on performance. How do they stack up
          next to each other? Python3 with Django is really working
          well these days. You can also check out the performance
          improvement  on Instagram because of it.
          https://thenewstack.io/instagram-makes-smooth-move-
          python-3/
 
    _arvin - 6 hours ago
    Python - DjangoRuby - RailsPHP - Laravelall nice choices
 
      baby - 6 hours ago
      Agree, note that Laravel was heavily influenced by RoR.I
      personally find that Laravel is less heavy than Django which
      is way less heavy than RoR. I would never use RoR for small
      projects.
 
      blunte - 6 hours ago
      And if you don't mind the learning curve (which will make you
      a better thinker!), I would addElixir - PhoenixI wish there
      was a complete Clojure - ???
 
      CraneWorm - 4 hours ago
      Scala - Play
 
        BlackMonday - 31 minutes ago
        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 are probably Slick, Quill and
        Doobie).And what do you use for Authorization? Something
        custom build? If I look at Laravel there are quite a few
        maintained authorization libs with ~1000 stars on youtube
        (even more if we count unmaintained), for play there is not
        really much (deadbolt, play4j and t2v/play2-auth, I don't
        count Silhouette since the lib is mainly about
        authentication).
 
    fulafel - 5 hours ago
    Interesting. What would you say is the biggest reason for this
    >10x development speed difference?
 
      whalesalad - 5 hours ago
      Django forces you to declare everything. Lots of manual
      boilerplate. Example, you must define every bit of a model in
      order for it to work. Rails is the opposite. ActiveRecord
      will ?just work? with the database. You can run rails on an
      existing db for example if it follows what are widely used
      conventions such as lowercase model name is the table,
      foreign keys are foo_id, etc...This is where people fear the
      ?magic? of things like pluralization of models to table name
      and introspection... but it?s all just code! You can read it
      and look at it and understand it. No magic here. Just
      convenience and a smaller mental model as an end
      developer.Also... resources as a first clsss citizen is the
      biggest reason and the reason it defeats Django for this use
      case. You define ?resources? in your routing layer instead of
      just routes that map to a function. This allows you represent
      multiple crud actions with a single controller and even nest
      them, all with a few lines of code. Then you get access
      control for free on your sub resource, knowing you?ve already
      passed the parent checks and have that context.Example:
      /users/:id/photos/:idIn this case, my Photos controller will
      already know who the user is (and if they can view these
      photos) based on work that the parent did. It?s single
      responsibility principle. You can even have a top level
      photos resource devoid of the user context and support both
      cases with minimal effort.Yes, you can do these things in
      Django. But it?s not designed to make these things composable
      and seamless. I?d argue it?s not REST-friendly. Don?t even
      get me started on Django Rest Framework which is a massive
      beast in and of itself.You get all of that out if the box on
      Rails. You can stand up extremely robust and ergonomic API?s
      with so little code you?ll feel like your cheating.I should
      probably write a blog post.
 
        knivets - 4 hours ago
        Rails is definitely more convenient to prototype, but the
        magic issue is real. You never know where a variable or a
        function comes from by reading the source -- you'd need to
        run a debugger to do that (in Python you can just follow
        the import statements). The overall Rails architecture
        feels convoluted and unnecessary complicated (Railties,
        Engines etc). I also dislike the fact that there is no
        single source of truth for data in Rails. You have
        schema.rb, but you can't edit that directly, it is
        generated by running `rails db:migrate`, so one might say
        that migration files are a single source of truth, which is
        inconvenient: I need to generate a migration, then edit the
        migration file to add any modifications not supported by
        generator script and finally add accessor and validators in
        model file. In Django we have a model definition as a
        single source of truth (data model, validations). Also,
        once I've created (or updated) a model definition, I run
        `manage.py makemigrations` and all necessary migrations
        (which capture the current data model state + what's
        necessary to do to perform a database migration
        automatically) are created automatically. I also like the
        fact that in Django data integrity is enforced by
        default.Though, when it comes to prototyping, I think Rails
        is a much more convenient option. In Rails I can launch a
        working CRUD app with authentication in 10 minutes,
        literally. In Django I have to manually create directory
        structure, manually specify each route mapping, create and
        program controllers (views), etc. Django doesn't even have
        a built-in authentication templates, only controllers
        (views), so I end up writing this boilerplate over and over
        again. The other thing is that the authentication requires
        a username and password, which feels kind of clumsy, when
        every other authentication relies on email and it is not
        very trivial to modify that (built-in admin dashboard
        relies on built-in authentication for example).
 
        bmelton - 1 hours ago
        > you must define every bit of a model in order for it to
        work. Rails is the opposite. ActiveRecord will ?just work?
        with the database.If you have an existing database, sure,
        Rails is preferred.  If you're starting from scratch, the
        Django definitions can create the tables for you.  If you
        do have existing tables though, you can use inspectDB to
        have Django create the models for you.
 
        collinmanderson - 5 hours ago
        Have you tried Django?s inspectdb?
 
  Kpourdeilami - 6 hours ago
  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.)
 
    Scarbutt - 6 hours ago
    Depending on the app, writing a SPA could be a lot of work vs
    just writing your UI as a frontend server.About NGINX, is still
    needed in both cases IMO, for the API or the frontend server.
 
    richardknop - 4 hours ago
    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 and DOM and
    AJAX or whatever.Single page web apps are often wrong choice if
    you just need some UI other than some fancy dashboard. Let?s
    say you need an admin panel where you can do CRUD operations,
    that?s perfect for Django/Rails and would be much much more
    work as SPA.
 
      mythrwy - 4 hours ago
      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 that.
 
  whatyoucantsay - 5 hours ago
  > as it's the shortest path to a win.Rails is the "shortest path
  to a win". Django is well made, but it just hasn't had the same
  level of focus on RAD or the same level of intensity of community
  support.Edit: My goodness there are some insecure, vindictive
  Django advocates here! What I wrote above is the truth and no
  level of tribalism can change it.
 
    lima - 5 hours ago
    But the trade-off isn't usually worth it.The time you save
    initially you'll later spend fighting the framework or
    debugging its internals.Python's "explicit over implicit"
    scales a lot better, especially with large teams.(personal
    opionion of someone maintaining production-critical Django and
    Rails applications)
 
      jrs95 - 5 hours ago
      FWIW I've never had these issues with Rails, though it does
      make sense that this would be more common with Rails than
      most things.
 
      whatyoucantsay - 5 hours ago
      It was worth it in the case of Airbnb, Twitter, Teespring,
      Coinbase and many, many others. Once you find product market
      fit, you can afford to rewrite your entire backend if needed.
      If you don't win round one, then it doesn't matter how well
      your stack could have scaled.
 
    jlgaddis - 4 hours ago
    FYI, I just downvoted you but for your edit, not your original
    comment. Perfectly legit, valid comments get downvoted here for
    bullshit reasons sometimes, I just ignore it and move on.
    (FWIW, I've never used Django. I'm not a developer.)
 
  Scarblac - 3 hours ago
  We use Django for large single page GIS web apps that still
  always need some CRUD somewhere (e.g. configuration is done
  through the Django admin). Parts that Django doesn't do can still
  be done in Python.
 
    methodover - 2 hours ago
    What does GIS mean?
 
      collinmanderson - 2 hours ago
      Geographic information system. Dealing with maps, etc.https:/
      /docs.djangoproject.com/en/2.0/ref/contrib/gis/tutori...
 
goodoldboys - 5 hours ago
* updates requirements.txt from django==2.0a1 to 2.0 *Great work! I
love Django and look forward to seeing how it continues to improve.
 
skshetry - 6 hours ago
As a beginner/intermediate level myself, I think new routing
syntax, which is similar to flask is itself a major feature of the
django 2.0. This really simplifies the url routing than the
regex(which is lot powerful though). For simple projects of mine,
it may well cover 60-80% of my needs, maybe more.
 
wilsonfiifi - 3 hours ago
The new URL routing syntax is one of the most welcome changes for
me (i mostly work with Flask). I just couldn't get myself to work
with regex.
 
sirodoht - 6 hours ago
Respect to the Django team that even after 12 years they have only
one major version shift (which seems to only because of dropping
support for Python 2) and the backwards incompatible changes are
minimal.
 
  bebop - 6 hours ago
  There have been lots of breaking changes along the way. Django is
  pretty good at giving developers a heads up of what is deprecated
  and slated for removal, but there have been lots of growing pains
  in the 1.x release cycles.
 
    jordigh - 5 hours ago
    I really dread upgrading Django. We have a codebase that has
    been with us since the 1.3 days and each time there's an
    upgrade, someone on the team sets about one month aside to deal
    with all of the breakage. You could say that this is our fault
    for "doing it wrong" but we just wanna get stuff done.
    Sometimes the only way to do it that we could figure out was by
    doing something that Django later decided we shouldn't have
    done.Going to Python 3 is going to be the biggest annoyance
    yet.
 
      mundanevoice - 5 hours ago
      I have been writing Django professionally since 2013, It's
      ain't that bad. Our codebase is huge & it never takes us more
      than 2 weeks to do it and lately, it has always gotten less
      and less. Wonder if the issue is with your codebase that it
      breaks so much on upgrades.Python3 upgrade is a task, agreed.
      But it actually gives good returns. The language is nicer to
      write in and we even saved some memory and CPU on the same
      load after the upgrade. So highly recommended.
 
        ngrilly - 3 hours ago
        Saved some memory and CPU after the upgrade? Could you give
        some numbers?
 
          gspetr - 8 minutes ago
          https://thenewstack.io/instagram-makes-smooth-move-
          python-3/How has Python 3 performed since then?"Ding: We
          did not have performance gain expectations for Python 3
          right out of the box.So it was a pleasant surprise to see
          12 percent CPU savings (on uswgi/Django) and 30 percent
          memory savings (on celery).It?s only been four months
          since rollout, we don?t expect to see constant 10 percent
          performance improvement, but that was a very promising
          start."
 
      trowawee - 5 hours ago
      Huh. At my last job, we went from 1.7 to 1.11 and while it
      wasn't seamless, I suspect we spent about that much actual
      work time making upgrade-related changes/fixes (120ish
      person-hours) for all of those upgrades combined. We hadn't
      jumped to Python 3/Django 2 before I left, but we were
      starting to plan for it. I knew it was going to be painful,
      but that's part of the cost of holding out for so long, isn't
      it?
 
      thecardcheat - 5 hours ago
      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 a longer legacy of surprise breakages, but I don't
      ding Django for following the intended life cycle of Python.
 
      allover - 3 hours ago
      >  You could say that this is our fault for "doing it
      wrong"Do you have decent test coverage and use tox to run
      your tests against multiple versions of Django?If not I can
      recommend this approach from experience.
 
    rectangletangle - 1 hours ago
    Given the functionality Django offers, the "cost" of the
    growing pains has been well worth it. Especially for the 1.7
    upgrade that happened a while back (when they introduced the
    new migrations framework). Relative to modern JS projects,
    where whole frameworks are switched out quarterly, maintaining
    a Django project is trivial.I really like the new URL syntax
    they introduced. I'd been relying on 3rd party libraries like
    Django REST for years at this point, because the raw regex URL
    syntax was always annoying and verbose. The new syntax looks
    well executed.I've been working with 1.11 and Python 3, so I'm
    looking forward to upgrading soon.
 
  ameliaquining - 6 hours ago
  The plan going forward is to make every third release semver-
  major, but these will still be incremental releases. The semver-
  major ones will be backwards-incompatible only in that they'll
  drop support for features that had already been deprecated for at
  least two releases.
 
    collinmanderson - 5 hours ago
    Right. It?s a change in version numbering scheme. Not any major
    backwards compatibility. It will bump every two years from now
    on.
 
gojomo - 2 hours ago
I wish they'd skip-jumped their version to "Django 3.0". That would
have allowed a simpler message about the Python dependency: "Django
3.x requires Python 3.x".
 
  collinmanderson - 2 hours ago
  Django 3.0 will be out soon enough (Dec 2019). There's going to
  be a major version bump every two years.