1. 12
  1.  

  2. 3

    Should I continue learning Django or is it better to move to the likes of Rocket and Actix? (0 experience in Rust , btw)

    And what’s the consensus on SSR vs REST + SPA?

    1. 6

      Play with rust and see if you like it first. No sense in discussing frameworks if you don’t even like working in the language.

      1. 4

        Should I continue learning Django or is it better to move to the likes of Rocket and Actix? (0 experience in Rust , btw)

        It depends on what you want to achieve. I can tell you billion dollar companies out there running on Django Python (e.g. Clubhouse). Rust itself has a higher learning curve and requires almost a rewire if you are traditional programmer, but gets a lot of things right, and makes you think through a lot you used to ignore. So pick what you want.

        what’s the consensus on SSR vs REST + SPA

        It’s hilarious that we keep doing these cycles between server heavy vs client heavy views. I’ve seen it 3 times in my life already. So learn it but don’t make it a religion.

        1. 2

          I’m late to the party, but if you’re familiar with Python it’s probably worth starting here. If you’re not very experienced with webapp development Django is pretty nice (at least last few times I’ve used it).

          I haven’t tried any of the web frameworks for Rust, but I imagine that the learning curve is steep with a new language, a new framework which is in heavy development and isn’t as well known as say Django. That means searching for help when running into problems is a lot harder.

          1. 1

            And what’s the consensus on SSR vs REST + SPA?

            I’m not sure there is a consensus, but in the React world there seems to be solid momentum around “why not both?”. Next JS (and Gatsby?) will let you mix SSR, static, and client-side/SPA fairly seamlessly. Making a page static or SSR is often just a matter of moving your query to a specially-named function. Combined with Typescript it’s a pretty nice place to be. But, as with many things in JS-land, there can be rather a lot of complexity under the hood.

          2. 2

            The release notes say you can now make these expression-based constraints:

            indexes = [
                        UniqueConstraint(
                            Lower('first_name'),
                            Lower('last_name').desc(),
                            name='first_last_name_unique',
                        ),
            

            But looking at the postgres docs, it seems like these expressions can only be part of the CHECK constraints on the fields, not the indexes. How does this new UniqueConstraint map to SQL?

            1. 1

              Your example will create a composite function based unique index.

            2. 2

              The new default argument for built-in aggregates allows specifying a value to be returned when the queryset (or grouping) contains no entries, rather than None.

              A nice addition in Django 4.0 👌so far I had to either use COLESCE which complicated the expression, or fetch aggregated results into a defaultdict.