17 ms·
Django 4.0
- theomega 5y agoGreat news! Just for reference: The latest release for Django Rest Framework is not compatible with Django 4.0 yet. At least my first attempts failed due to a missing `pytz` dependency. This is fixed in the `master` of DRF on Github. Installing `pytz` explicitly again to your project fixes DRF for now.
- mch82 5y agoThe transitional USE_DEPRECATED_PYTZ setting might help. Saw this in the extended release notes: https://docs.djangoproject.com/en/4.0/releases/4.0/#zoneinfo-default-timezone-implementation https://docs.djangoproject.com/en/4.0/releases/4.0/#zoneinfo... > The Python standard library’s zoneinfo is now the default timezone implementation in Django. > This is the next step in the migration from using pytz to using zoneinfo. Django 3.2 allowed the use of non-pytz time zones. Django 4.0 makes zoneinfo the default implementation. Support for pytz is now deprecated and will be removed in Django 5.0. > … > To give time for such an audit, the transitional USE_DEPRECATED_PYTZ setting allows continued use of pytz during the 4.x release cycle. This setting will be removed in Django 5.0.
- midrus 5y agoI've used Django for a long, long time (since 0.96). Django is great for backend stuff, but nowadays for full stack applications (if you're not doing an SPA) I find Laravel and Rails a lot better. In particular Laravel's templates (blade) and asset handling is awesome.
- naveen_ 5y agoThanks a lot..
- nanna 5y agoI must learn Django, it's got everything I'll ever need. No, Rails will make me happy and it's better for lonely devs like me. No I must learn a Modern Web Framework (TM) to prove I'm not stuck in the past. No way, I'm not a fashionista. Have you seen that Phoenix demo where the guy builds Twitter in like 4 minutes? That's the future. Hold on a minute, enough of this magic. I need to learn to build everything in Common Lisp and own my code 100%! Wait I don't actually have the time for that. Django is the way, it's so solid, just that it won't bring me joy....
- melling 5y agoYep, web solutions change too fast, with lots of legacy, and every solution is a compromise.
- agumonkey 5y agoparadogm of choice
- hellbannedguy 5y agoYea--I don't want to waste my life learning frameworks either. The less time googling a new framework, the better. Now learning Lisp is something else.
- myth_drannon 5y agoThat's me. Once a year I get burned out from all the new languages and frameworks and decide to learn Common Lisp again for the 10the time.
- exdsq 5y agoHahahaha you've just described my life too
- chespinoza 5y agoSame here :/
- ac130kz 5y agoNah, Django makes you sad: async support is not full, migrations engine is pretty poor, not all database features are present, any kind of typing is hacky, very slow and so on
- geewee 5y agoWhat other migration engine have you used that's better? Anything non-django I've used makes me wish I was using Django
- WayToDoor 5y agoWhile it doesn't seem like a major update at first glance on this news piece, the changelog is available here : https://docs.djangoproject.com/en/4.0/releases/4.0/ https://docs.djangoproject.com/en/4.0/releases/4.0/ Of note, in my opinion : - The new AddConstraintNotValid operation allows creating check constraints on PostgreSQL without verifying that all existing rows satisfy the new constraint, meaning that one can now create constraints on big postgres tables without a waiting period. - Async methods are coming, to cache for now but hopefully soon to the ORM. They are prefixed with a `a` in the name - DeleteView now uses FormMixin, allowing you to provide a Form subclass, with a checkbox for example, to confirm deletion. In addition, this allows DeleteView to function with django.contrib.messages.views.SuccessMessageMixin. This is a big thing if you use DeleteViews, as you can now easily show a message post-deletion to the user.
- fleetfox 5y agoDo you know if the ORM solution have the same `a` suffix for async interface? I really hope there is more elegant solution for all this.
- cdrx 5y agoORM will use the same `a` suffix, yes.
- deckiedan 5y agoYes - it's kinda ugly at the moment, having all the `a` prefixed functions - but I think it's intended as a kind of long-term-intermediate step - since the whole of django isn't async at the moment, and needs to have separate versions for everything. I (wildly) speculate that once the ORM is async too, and all the rest of the bits fall into place (maybe django 5?), maybe django 6 will drop the `a` prefixes and integrate it all back together somehow?
- samwillis 5y agoI believe they chose the 'a...' pattern as it matches other apis in the standard library - it also makes it explicit but concise. I can't see it being dropped any time the future, Django will always have a sync api, that won't be dropped. And there is no way in (current) python to combine a sync and async api into a single method.
- ilovefood 5y agoCongratulations on the release!! I'm looking forward to give it a go and see what's new for myself.
- avinassh 5y agoI recently upgraded [0] one of my project [1] to Django v4, from Django v1. The changes from Django 3 to 4 were fairly simple, just one line change in my case. The change log is extremely detailed, it was easy to upgrade. Also, I found a tool called django-upgrade [2] which makes some changes automatically, rest I made manually. [0] - https://avi.im/blag/2021/rc-day-20/ https://avi.im/blag/2021/rc-day-20/ [1] - https://github.com/avinassh/della https://github.com/avinassh/della [2] - https://github.com/adamchainz/django-upgrade https://github.com/adamchainz/django-upgrade
- fernandotakai 5y agothat's super nice to know -- i need to upgrade a django app from 1.11 to 4 over the next couple of weeks!
- spapas82 5y agoIf the 1.11 project is in python 3 then it would be a piece of cake. If it's in python 2 then it will need a little more effort to convert to python 3 but but not much really. Django have hasn't changed that much since 1.11!
- Majestic121 5y agoWe went all in on FastAPI with my team, but we're hit the issue that the projects of Tiangolo (FastAPI, SQLModel, Typer) seem to be turning pretty much unmaintained : https://github.com/tiangolo/fastapi/discussions/3970 https://github.com/tiangolo/fastapi/discussions/3970 We've already been hit by multiple bugs with fixing PR opened, but left to rot, and missing documentation : the 'tutorial' documentation is great, but if you want a reference you have to go read the code. I guess that's the issue when you pick projects maintained by one person, so for my next projects I might get back to something built on stronger grounds, like Django. How is Django this day with modern Python constructs like typing in general and Pydantic models integration ?
- rglullis 5y agoNot to single you out, but are you or your business supporting the project (financially) in any way?
- Radim 5y agoI sometimes get these almost angry emails about Gensim, my open source library. How come I'm not responding faster, merging PRs, fixing issues? For this critical popular project??! Meanwhile, sponsorships are at 13% of the (not terribly ambitious) goal of $6k/month [0]. Yeah, that's why. [0] https://github.com/sponsors/piskvorky https://github.com/sponsors/piskvorky
- Sinidir 5y agoThanks for creating Gensim!
- dr_zoidberg 5y ago> How come I'm not responding faster, merging PRs, fixing issues? For this critical popular project??! > Meanwhile, sponsorships are at 13% of the (not terribly ambitious) goal of $6k/month The answer would then be: "because I have to keep another job to pay the bills" then? Hope you can get to your goal ASAP. Going by stupidly quick math, you have 12k stars for gesim alone, and that boils down that if every star on github payed 50 cents you'd already be there. I know that starring doesn't mean anything other than "hey, this looks interesting!", but then again 50 cents is probably cheap enough for a majority of those "stars" that they wouldn't even notice. Also: thanks for creating and maintaining gensim!
- clement_b 5y agoI enjoy coding with Django. It's the framework that helped me make a smooth move from PHP/Symfony to Python-powered web apps. Not that I dislike PHP... just wanted to focus more on Python. Many thanks to everyone involved in the project!
- alberth 5y agoOff topic: I wish NIM had a Django-like web framework.
- _tardigrade 5y agonowadays most people use Django to create REST API. I wish Django would merge DRF into its codebase.
- mrweasel 5y ago> nowadays most people use Django to create REST API I doubt that's true, but yes, having DRF merged in would be rather nice.
- PhoenixReborn 5y agoThere are quite a lot of apps that do a JS frontend and Django backend these days, I myself have done quite a few.
- mrweasel 5y agoAbsolutely, I just question the premise that “most” Django applications are like that. My best guess, and I have nothing but my own experience to back this up, is that for every public facing Django based website, there are at least three used internally and at least one of those use nothing but the build in admin interface as a UI.
- dralley 5y agoAt this point I disagree - DRF is a verbose and somewhat dated architecture. I wish they would provide something like Django Ninja / FastAPI. Plus it already has decent async support. https://github.com/vitalik/django-ninja https://github.com/vitalik/django-ninja
- rlawson 5y agoDjango has allowed me to enjoy some side entrepreneurship. I have released three products as a solo part time dev that I would never have been able to do in a reasonable time using Java/Spring (my strongest stack). My first project went nowhere, but the second generated 1k+ a month and sold for 50k, and the third one is following a similar trajectory. My advice - keep it simple - function based views - centralize access to the ORM (avoid fat models, use a service layer) - responsive bootstrap template with crispy forms - minimal js - 12 factor type setup - django-environ or similar - be aware of n+1 select problem (I use django debug toolbar but looking into django-zen-queries) - plop it on heroku, AWS lightsail, Digital Ocean or if containerizing use AWS Fargate - avoid celery unless you are at a scale you need it - use django-cron, django-db-queue or similar - use a managed database and managed email service I have had zero scalability problems. People say Django is slow but it handled 10k active users on a small EC2 instance without any issues (static stuff served via cloudfront)
- kaba0 5y agoI’m sorry but I don’t buy that. Spring Boot is very highly productive — I really don’t believe any other stack would fare better by a significant margin.
- karolsputo 5y agoI recommend this post when thinking about fat models/service layers https://www.b-list.org/weblog/2020/mar/16/no-service/ https://www.b-list.org/weblog/2020/mar/16/no-service/
- 5y ago
- nickjj 5y agoIf anyone is interested I updated my example Docker Django app to use Django 4.0 at: https://github.com/nickjj/docker-django-example https://github.com/nickjj/docker-django-example It pulls together Django, Docker Compose, Postgres, Redis, Celery, Webpack and TailwindCSS. It's all set up for both development and production. It's also been updated to use Django 4's new built in Redis cache back-end instead of the django-redis package.
- slig 5y agoThank you very much! I've been running my own clobbed together version of a Django + Webpack configuration, and I'm very interested in learning from your code how you manage to run only one container with both Django and Webpack on dev mode.
- nickjj 5y agoNo problem. I have things split out where the Webpack dev server runs in its own container only in development. It uses the Docker Compose override pattern to skip it in production along with Docker's multi-stage builds to ensure production assets get built and digested with collectstatic when DEBUG is set to false. I gave a talk this year at DockerCon on a whole bunch of patterns I use with Docker Compose and my Dockerfile to get dev / prod parity without duplication and overall best practices. The video and blog post of that is at: https://nickjanetakis.com/blog/best-practices-around-production-ready-web-apps-with-docker-compose https://nickjanetakis.com/blog/best-practices-around-product... It walks through a live demo (0 slides) going over a Flask example app but it's 100% the same for Django.
- slig 5y agoFantastic, thank you so much!
- unixhero 5y agoWhere are we on the whole Django versus Rails debate? (Not cannonfodder, I am genuinely curious)
- z3ugma 5y agoAs someone who's used both - Rails packaging and environment maintenance has been so much less of a headache. Gems and Gemfiles and Gemfile.lock vs having to choose a Python package maintainer (Pipenv vs Poetry?) and deal with that has been worth it to me. In terms of how they "feel" to develop with? About the same. Similar ideals - skinny models, service layers, REST-first but you can make it RPC-style if you want...
- hairofadog 5y agoA couple of comments here have talked about the benefits of “skinny models”, but that runs counter to the advice I’ve seen. How come skinny models? Is the idea to put most of the business logic… where?
- deleted 5y ago[deleted]
- samwillis 5y agoI'm unconvinced by the "skinny models" and "service layer" arguments. Django's ORM is an active record style ORM, its at its best if you use it that way. If you want to have a service layer type architecture, use SqlAlchemy with implements the data mapper scheme. I follow this general rule of thumb, in order: If it's a complicated business logic touching multiple models or external apis, put in in a `utils` module (keeping this sensibly organised by model/role/activity depending on what you are building, i.e. utils.{model_name}.{methods} or utils.{e.g. order_processing/email/accounts}.{methods}). You can add a shortcut to it as a method on the model if this makes sence. (some may argue this is a service layer) If I'm only doing something once in one place (in one view), then keep the logic there. If it's a custom create method, stick it on the models manager class. If it's something you want to do to a set of objects (from a query set), put it on the manager class or a QuerySet subclass (to make it chain-able). If you haven't put it elsewhere put it on the model class, as a method or a property if it seems cleaner (don't do get_... and set_... use a property)
- b-lee 5y agoGreat to see they have managed to reach their funding target. Donated anyway!
- the__alchemist 5y agoDjango is the nicest framework I've come across! For some context, my favorite overall programming language is Rust. Despite Rust having several web frameworks, I use Python the server due to Django being so nice. In Python, there are micro frameworks like Flask, and whatever new ones claim to be "Blazingly fast!", async etc. Once you get over the learning curve, Django seems the nicest to use, due to including features like an auto-updating ORM, email, authentication, admin page etc. None of the Rust frameworks, in contrast, come close to feature parity. Django's feature base is vast, and I admit I don't understand much of it. You can choose the feature sets you need. The template language is inflexible, but you can smooth this over using JS instead A/R.
- ehutch79 5y agoYou can also replace the template system with something else like jinja2.
- deleted 5y ago[deleted]
- pantulis 5y agoBefore Django there was Zope in python-land. I don't think I overstate the relevance of what Django did by saying that Django almost single handledy advanced the state-of-the-art of web deployment in Python forward a decade.
- stdbrouw 5y agoZope hails from the era when Python was trying to appeal to programmers by showing that it, too, could be a Serious Enterprise Language. Everything had layer after layer of abstraction and the code looked more like Java than Python. The Zope ORM was kind of nice in its own weird way, though.
- VectorLock 5y agoZope had some things like the Language Is The Database trope that sort of remind of the things described in those Bank Python blog posts that have been floating around recently.
- dukeofdoom 5y agoI still have a project that runs on Django 1.6. Can't imagine trying to migrate now, when it relies on so many old packages. Would probably be better of starting from scratch.
- selcuka 5y agoI would start by replacing the dependencies that are not maintained anymore (i.e. that don't support a relatively recent Python 3.x) with more modern alternatives one by one instead of rewriting it. The migration of the Django application itself should not be that hard.
- slig 5y agoI had a project running on 1.3 until very recently. The was a lot of issues with the TZ datetime fields, migrations, Python2, etc. It was a lot easier to start a new project from scratch.
- raihansaputra 5y agoI've always followed Django as Python is my first language and still my 'natural' way to think about code. The more I look into it, the more I feel like the learning curve is a bit like a camel's back. Easy for some stuff. Hard to figure the middle part (usually because not understanding "how" Django really works). And easy at the ends after knowing how you can "mould" Django in certain ways. It feels like a great multitool for the professionals who need to create project after project. I believe the middle part of the learning curve can be easier, but with the "social cruft" of all the Django tutorials out there, it's a game of luck to encounter what's good and what are the different, sensible, approaches to handling growing/big Django apps. What can make this easier is a document/discussion of some sort that provides clear, complete, approaches. Here are some aspect that needs to be considered. I believe with the combinations defined, and describing the tradeoffs will be a very great start for any team/person looking to jump into Django, or improve their next project. - Postgres seems to be default. SQLite + Litestream is there but still bleeding edge. - Packaging is the hot topic, for sure. Pipenv, poetry, venv, etc? - Traditional Serverside Templating + JS enhancement (HTMX/Hotwire/etc), or JS based SPA (React, Vue, Angular, Svelte, etc) -- This also includes the asset compiling story (Tailwind JIT, Sass compilation, Babel/webpack/rollup/etc) - Fat models, Fat views, or Service layer? To which extent? - Single app (Doordash) or Multiple apps (Thread with >500 apps)? - What's the theoritical limit to using Postgres + Disk/Memory Caching (so no external Redis/ElasticSearch/other services needed)? -- Search, queues/async job, scheduled jobs, reports, emails, etc EDIT: A view additional points - Documented limits about using whitenoise to serve static assets, and when & how to move to S3. Also Cloudflare/CDN fronting - Cloud storage story (uploading to S3 api from FileField and Rich Text fields, and also async jobs) -- Proxy story to enable <a download> from cloud? (Maybe a bit far, but I think this is a common request) - Deploying/Serving optimization (is gunicorn the best option for now? how to scale w/ regard to vCPU counts to avoid the 25% CPU Max utilization?) - How to debug between inefficient query/app code/templating/serving/caching? I'm sure there are more points, but it would be great if there's a documented sensible approaches to evaluate. I know there are templates, but great discussions about the tradeoffs of complete "packages" are rare.
- polote 5y ago14 days ago https://news.ycombinator.com/item?id=29303611 https://news.ycombinator.com/item?id=29303611 76 days ago https://news.ycombinator.com/item?id=28609188 https://news.ycombinator.com/item?id=28609188 3 month ago https://news.ycombinator.com/item?id=28566044 https://news.ycombinator.com/item?id=28566044
- marcus_cemes 5y agoDoes anyone know how Python/Django compares to something like Elixir/Phoenix?
- Daishiman 5y agoDjango has more features, a _much_ larger ecosystem, excellent documentation. Elixir is dramatically more performant and will scale better. A lot of people enjoy Elixir more or find it conceptually more interesting than Python. IMO the number of packages and facilities provided by Django will outweigh Phoenix's performance for 95% of users.
- dyeje 5y agoDjango, Rails, Phoenix, Laravel, etc are all pretty similar at a high level.
- princevegeta89 5y agoPhoenix is on a much better performance level compared to the other two.
- aej 5y agoPhoenix has a much smaller footprint than Django. I would put Phoenix closer to Flask in terms of how much work the framework does for you. Phoenix has lots of generators which make hooking into the database layer very easy and bootstrapping new endpoints is also fast in Phoenix. Django makes more decisions for you (authentication, permissions, admin, the ORM to name a few). In the Phoenix ecosystem you bring each of those pieces in as you please (auth generator, Ecto + other libraries etc). So I would say if your really want to move fast, you will still get further, faster with Django - but the trade-off (as other posts here have alluded to) is that once you need to implement custom features or optimisations you will often fight against Django (or need to wade-through half a dozen classes in some inheritance tree to find the right hook). Another big difference between Phoenix and Django is that building websocket services in Phoenix is an absolute breeze. The Elixir runtime maps perfectly onto any type of messaging service.
- appliku 5y agoThank you Django. that’s a great news. 14 years ago someone helped me discover Python and Django. I started from django official tutorial and never changed the framework of choice. It was my hobby, my career, my tool to put the food on the table. 12 years later I have started building a way to solve deployment question. started from bunch of scritps. today I have made cost effective tool to deploy Django projects and pretty much any python app on AWS/Digital Ocean https://appliku.com/ https://appliku.com/ it is like heroku but uses you own cloud account and not expensive at all.
- robomartin 5y agoLove Django, yet the transition from local development to deployment, in my opinion, continues to be just plain ugly and painful. I've written about this before. I think the stock Django dev configuration needs to change to something that is equivalent to a reasonable deployment on a common VPS, whatever that means. The development server is a nice trick, but the things you have to do to move to a real server are painful. Same with SQLite. Why not come up running PostgreSQL by default? I am sure there are varied opinions on this. All I have to say is that, over the years, I developed a document to help with deployment on standard hosting platforms, like Linode. It is staggering when compared to the experience of deploying something like a Wordpress/PHP site on the same or similar platform. This, from my perspective, is the weakness for Django, everything else I love and enjoy.
- strzibny 5y agoWhat do you find hard in particular? systemd service + gunicorn is not that bad, I think. You can have simple deployment and graceful restarts[0]. [0] https://nts.strzibny.name/gunicorn-graceful-restarts/ https://nts.strzibny.name/gunicorn-graceful-restarts/
- reducesuffering 5y agoThere is a huge doc[0] for a standard "deploy decent prod setup to VPS." What happens after you make some changes, something goes wrong with the server, and you have to go through all these steps again, only that it gets you to Day 1, not Day 90? It leaves a lot to be desired for quick, reproducible deploys. Ime, adding a docker-compose and a couple Dokku commands on the server is the best experience I've seen so far. [0]https://www.digitalocean.com/community/tutorials/how-to-set-up-django-with-postgres-nginx-and-gunicorn-on-ubuntu-20-04 https://www.digitalocean.com/community/tutorials/how-to-set-...
- robomartin 5y agoNot sure that your link is an answer to my comment. Whatever the case may be, I can take a single VPS and multi-host a bunch of domains, each with it's own Wordpress installation, DB, etc. Virtual hosts makes this possible. It's stupid simple. Getting a single Django application running under a single domain on a VPS is a nightmare. Particularly when you consider everything you have to do to migrate from the development environment to production. This is why we do not do any Django development using the standard installation and go right wo running it just like production on either virtual machines or a dedicated on-premises Linux server. The development environment is as close to an exact match as the production environment. No SQLite, no runserver, no nonsense with static files, etc. This is what I think the Django project needs to really think about working on. There is no reason to have a crippled development environment at all. The base installation ought to be setup to migrate to a standard Linux host (not something purpose-built like Heroku) without much friction. If you are doing a more complex site with multiple servers, load balancing, etc., you are on your own. I truly think adoption would be far greater if the deployment experience was sensible. I have talked to people who absolutely gave up on Django because going from development to production was a nightmare without spending money on far more expensive servers and services they should. This is an application (Django) that should easily run on any Linux server. The fact that companies were created to facilitate deployment says it all.
- ralmidani 5y agoDjango made me fall in love with programming. I built 2 decent-sized side projects with Django. They didn’t gain traction, but I loved using the framework. Then I went through a couple of (depressing) years of using Java/Spring professionally, and recently I made the choice to move to Elixir/Phoenix. It’s going great, and I don’t think I would go back to heavy OOP if I didn’t have to. Some things I really miss from Django: - Models with more centralized validation logic. In Phoenix (and somewhat similarly in Rails), you need to edit your migration, schema, and changeset. In Django, you edit your model and the migration can usually be made automatically with no need for a 3rd-party package. - Django REST Framework. You can get pretty far with an app just by leveraging ModelSerializers and ModelViewsets. It’s ridiculously elegant, simple, and powerful. - The Admin layer is fantastic and unparalleled. Some things I wish Django would add/enhance: - Making it more clear when you’re going to hit the database (explicit is better than implicit). - True async up and down the stack. Not a small task within the Python ecosystem, but I think for folks who are not already invested, looking at Elixir/OTP/Phoenix is too tempting. If you don’t have kids to transport with you, a Lambo looks much more fun than an S-Class Sedan.
- WD-42 5y ago> - True async up and down the stack. Not a small task within the Python ecosystem, but I think for folks who are not already invested, looking at Elixir/OTP/Phoenix is too tempting. If you don’t have kids to transport with you, a Lambo looks much more fun than an S-Class Sedan. This has been in the works for a few years. Everything in Django works with async except the ORM at this point. Which in practice, means it's not really async. But hopefully they are getting close.
- privacyonsec 5y agoI'm working on bringing async to Django orm: https://github.com/rednaks/django-async-orm https://github.com/rednaks/django-async-orm
- number6 5y ago> Making it more clear when you’re going to hit the database (explicit is better than implicit). You might like https://github.com/dabapps/django-zen-queries https://github.com/dabapps/django-zen-queries Gives you fine grain control about database queries
- strzibny 5y agoCongrats the team on the release. Now I have to go and check what to update for Deployment from Scratch :D
- peterth3 5y agoCongrats to the Django team! Adding support for a Redis cache instead of only memcached is awesome.
- buro9 5y agoMaybe this will be the moment I upgrade. Let's see what version I'm running: Django 1.5.9 This is going to be very painful isn't it. I wonder how long until the bitrot makes it unbuildable and undeployable. I should clarify, there is no database attached to this and it talks to a secure API that is maintained really well. So this is just views and templates, where the views talk to the API.
- kolanos 5y agoFeels more like a Django 3.3 release than a 4.0 -- was expecting Django 4.0 to deliver the promised ORM async support.
- mypresences 5y agoAgree, doesn't deserve the 4.0 tag. I was hoping for some progress on async ORM as well. Is there any word on when this is coming?
- wartijn_ 5y agoDjango releases time based and a version 3.3. was part of the plan. 4.0 is released right now because it is December 2021. The versions after that will be 4.1, 4.2, 5.0, 5.1 etc. [0] It's different from how many other projects work but not unique, Ubuntu works in a similar way for example. And although it might be different form what you're used to, I really like it. If you check their documentation, you can see exactly when they'll make breaking changes and features will be deprecated and removed. [0] https://www.djangoproject.com/download/ https://www.djangoproject.com/download/
- _xnmw 5y agoAnyone have deep experience with both Django and Laravel and can offer a comparison of the two?
- midrus 5y agoI have a lots of experience with Django, and a few months experience with Laravel. I think Django is good at pure backend solutions. When you're not doing the frontend in Django itself but instead doing a separate SPA. Also the admin is a great tool as an internal CMS. Django rest framework is awesome too. Laravel is a real "full stack" framework, it has a very powerful templating system (one of the best I've seen!) where you can do components instead of just includes. It has a powerful assets bundling pipeline, great integration with alpine, Vue, inertia and the super awesome livewire. Laravel documentation is TOP. As I'm not a fan of the SPA approach and still like frontend and building applications, I much prefer Laravel nowadays.
- Dowwie 5y agoIs there a possibility of the cache stampede / dogpile problem?
- sam_goody 5y agoOT, but considering the audience... I have a side project / website that I want to work on. I have over a decade experience with PHP and JS in various forms, but am willing to try something new. The idea of compiled languages don't appeal to me, so am not really interested in Go, Rust or Dart. It looks like either Django, Elixir, or PHP - but am open to other ideas. Anyone with enough experience to tell me confidently that it is worth Django or Elixir? Anyone can give a five line overview of the differences vs PHP or Node? And along the way, am I the only one who is confused by what seems too many environments and package managers? (from venv/virtualenv[1] to pip/easy_install to wheels/eggs) [1]: https://stackoverflow.com/q/41573587/87520 https://stackoverflow.com/q/41573587/87520
- jph 5y agoIMHO, Elixir & Phoenix are such a breath of fresh air, plus power, plus adaptability, and I love the functional capabilties. On the other hand, if your want lots of numeric computation tooling, AI/ML, stats, etc. then Python & Django have better/more math-adjancent integrations.
- bgdkbtv 5y agoNo difference, it is just a matter of preference and selecting the best tool for the job. Often times the best tool for the job is the one that you know how to use really well. If you’re good with Laravel for example, no need to switch to Django or Elixir and vice versa. Stick with what you know and you’ll be a happier developer.
- midrus 5y agoDjango: Great if you are building only a backend or rest API with a separate frontend (an SPA in React, etc). The templates system is terrible, has no asset pipeline built in and frontend on it feels like developing in the 90s. You'll miss php a lot here. Elixir: Technologically "mind blowing", although all the nice things come from the Erlang VM and not from Elixir itself in my opinion. You will likely not find any job using Elixir, if you do it is going to be full of people just learning the language so the codebase will be very likely a disaster. You will miss a lot of libraries and you will have to write code for things you'd take for given in the PHP ecosystem. Be ready to fight your editor plugins (depending on which one you use, and the degree of IDEisms you're used to). I understand you want to learn something new, so the most "radical" one here that will teach you more new things is clearly Elixir. But other than learning purposes, If I were to build something for real, I'd stick with PHP and Laravel, it's an incredible productive, well documented and well thought out platform to develop in.
- alanwreath 5y agoDjango for me has been a solid API gateway. That said I would appreciate an API-centric iteration of it. Something like how Laravel has Lumen. Even if they would make Django ORM available as a separate library it would make me glad. I can’t say I’m overly enamored by the red wave that has passed over python. The only things I really like it for (so far) are when I wish to make concurrent http calls. For whatever reason, I don’t enjoy it as much when I’m trying to serve multiple requests. I prefer keeping requests read only or at most job launching.