I'm working on a project that lets you build your Django app like you normally would with templates and views but you get a React app and all the benefits of a single page app. You don't need to write any APIs or use redux etc. It will have a bunch of components built in and if you don't need any more then you don't even need to build the javascript yourself, you just include the already built file. At the moment I have a sort of Django Admin equivalent example working and I'm looking for some feedback. If you or anyone else has any ideas about it I would love to hear, feel free to PM me (email in profile).
Curious how you feel your project fits in at this end of the ecosystem.
This is basically web 1.0. It's like we've come full-circle:
web 1.0 > web 2.0 > web 1.0
I'm not saying this is bad at all. I'm just amused that we are back to building web pages the way we did 10-15 years ago.
I worked with Django full time for about 6 years. It scales up and out pretty well, too.
There was a peer comment about Rails. I'm a big fan of Rails, and Ruby is one of my favorite languages. But one thing I've noticed is the lack of magic inside the Django codebase vs. Rails' codebase. Spelunking in the codebases feels night and day different: I found Django very intuitive and Rails... less so. I think that was a combination of my lack of skill with Rails' internals, and the different in languages and communities. Python (and Django) try to follow the Zen of Python. Rails felt like every other method was monkey-patched and reduced to a single line or two. It was odd: I think the expressiveness of Ruby was actually a negative at large scale (sort of like Lisp vs. Go)
For 99% of use cases, you never need to get to this level of the frameworks, but it was an interesting experience.
One major reason is that a central tenet of Rails since its inception seems to be to eliminate any and all boilerplate or glue code. But boilerplate and glue code also serve a purpose of showing you how things are hooked up. And they tend to have very tiny one-time costs whereas abstracting them away may incur rather heavy costs of knowing the abstraction exists, how it works, where in the Rails code it's actually implemented, and always remembering all of this whenever you touch Rails again in the future even after a long hiatus.
Without glue code, you have to just know how everything works: How does the router know to route GET /users to UsersController and its index() method? You never see an invocation. And there seems to be middleware code that runs before my index() method is called. Where is it defined and what makes it run before my code? How do I get a list of all middleware that might run before my code? Oh, libraries can install their own middleware code? etc, etc.
You end up doing a pretty deep dive in the abstractions of Rails and your gems to understand these questions and all questions like them. You basically become a Rails expert when you truly hold all of this in your head. Meanwhile, you don't need to deep dive on any code to understand what `router.get('/users', UsersController.index)` might be doing.
To Rails' credit, I remember how much it was compared to things like Spring in its early days and I imagine the sort of XML config nightmare you could get with old Java frameworks is what DHH must have had in mind when he sought to improve the state of web development. I think Rails represents an interesting experiment in the timeline of software development where we played with zero boilerplate. And I think since then the ecosystem's views on boilerplate and glue code has swung back to a less squeamish middle ground.
I think this is really what people generally mean by "too much magic". DHH has a twitter thread (https://twitter.com/dhh/status/1226296264469336064) where he attacks the idea of "too much magic", but I think it's obvious to anyone who has used Rails that there is definitely a spectrum of magic and Rails certainly ranks towards one pole more the other.
And to defend DHH's twitter thread, he's always been kind of a harsh speaker like that. And you also have to keep in mind how long he's had to deal with the "ugh too much magic" dismissal. I would expect him to generally agree with this post.
Regarding the page loads, have you looked at Turbolinks? https://github.com/turbolinks/turbolinks/blob/master/README....
It's basically a drop in upgrade, makes the whole site feel like an SPA with none of the work. Lovely.
Another tip would be to give django-admin a try when building dashboard projects (you can customize the look and feel quite a bit, ours are usually unrecognizable).
But you can always switch it for Jinja2, just a line in the settings file.
Startups in my area are actually doing better than they are in our main tech hub despite most of them using what Silicon Valley would call fairly boring and extremely old tech stacks such as ASP MVC.
Hope more people discover (or re-discover) this.
DjangoREST is also a very solid framework if your use case is not a website and you get all the rest of Django for free...
I have recently stepped out of the seemingly never-ending spiral of using React/Vue for everything frontend, and also discovered Django along the way.
For building prototypes, Django is the fastest framework I've ever used. After building out prototypes in Django I've come to a realization that at most 10% of my websites need to be truly reactive to user interaction without page reload. Turns out when I dropped this requirement when building something, I can actually finish the projects I start. And also turns out for the end-user, they don't even notice page reloads for most sites.