21–30 of 173 posts
Eh a lot of these seems like strengths of Django. Rails chasing the SPA dragon has been a source of endless pain.
Could you elaborate? After a ~10 years hiatus I revisited Rails last year and whipped up a CRUD app with auth in no time. No SPA in sight.
Earlier quoted context omitted.
Could you elaborate? After a ~10 years hiatus I revisited Rails last year and whipped up a CRUD app with auth in no time. No SPA in sight.
They've been mucking with the asset pipeline every single version and their forray into webpacker has been a disaster. Turbolinks and ActionCable have been attempts to compete with SPAs while still being SSR but both are just glitchy and a source of endless Heizenbugs. Thankfully Rails7 looks like they've restored sanity.
But you don't need to use Actioncable at all. But I do use it, to have my C/C++ clients communicate with the SaaS. Haven't experienced anything flaky there yet and I am glad a Websocket option was included.
> I mean, Instagram server is still a big Python codebase. It's Django at the core, I mean, it still runs through the Django request handling stack, and the middleware and views and URL routing, all of that is still Django. It looks familiar to any Django developer. Just very big, lots of views, lots of URLs, lots of code. There's a lot of, I mean, obviously, the ORM we don't use anymore, the admin is very much based on the ORM, so that's not in use anymore. And there's a lot of components, where Django provides kind of pluggable back ends, like sessions and authentication, and for all of that stuff, we've essentially rewritten the entire system. But we're actually still using the sort of Django API for those things, because it's pluggable. So I would call that a success story, I mean, in that we've been able to very smoothly migrate away from the components that that no longer worked at our scale, in many cases without even having to change the client code touching those subsystems because Django provides this ability to swap out the back end. So yeah, and you know, the Django core requests support that we still use, we're 100% async now, so already a few years ago, we kind of forked and modified a bunch of that to support async, or concurrent handling of multiple requests using async IO. So there have been some changes.
Django's postback model might not be a model of what front end developers want to use for their backend, but it's definitely a model of how I like my frontends to behave - sparse and minimalist with a limited number of possible behaviors.
What’s better?
Rails. Switched from Django two years ago and never looked back. Having worked with both, Rails is more polished and pleasant to work with. Side note: if you're building a business and already know Python/Django, stick with them!
Earlier quoted context omitted.
Flask? Maybe FastAPI.
I second FastAPI! In my mind it's, "Flask, but better." The killer feature in my mind is that it leverages type hinting and dataclasses, using Pydantic, to take away a lot of the grindyy, boilerplate parts of writing an API, like type checking, dependency injection, generating good error messages, generating API documentation, ... Even when I'm not using FastAPI now, I use Pydantic everywhere. Types in Python, while…