I love Django and have been using it for many many years. Lately, however, I’ve been finding it increasingly difficult not to be annoyed by some aspects of the developer experience. For example I’d choose React + Typescript over Django templates any time of the day.
You shouldn't be downvoted for saying this. As a server-side developer of 20 years the server-side templating languages have a lot to learn from the frontend experience. And I say this as a user of Smarty, Jinja2 and now Twig & nunjucks. Template inheritance is fantastic. But...
Being able to develop and test standalone HTML components using Storybook is a whole lot nicer than splitting a server-side template into components (which Twig certainly doesn't support cleanly), building a tool to render them and then maintaining your own component library. So normally we end up with HTML bits in Storybook which are copied and pasted into Twig templates, placeholders added and then you can guess they get out of sync.
I appreciate the argument that I should "use JS server-side and render ${js_fe_framework_of_choice} server-side" and it's valid. But I'd also like to be able to run components in _any language_ and get the same DX. Note none of this is talking about hydration - I'm wanting to leverage the JS FE frameworks as clever templating engines which output dumb HTML.
I'm talking entirely out of my rear end, but I'm curious if there is any validity to some of these projects that let you run pythonic code in the browser, either through Webassembly or brpython. For example, this projects https://github.com/stefanhoelzl/vue.py claims to let you write Vue.js in Python in the browser, which then gets turned into regular Vue.js components. I imagine a performance penalty, but a developer performance benefit of allowing something else to run on top and make a more composable experience.
Up the wrong tree :) Vue.py gives you a way to write Vue to run in the browser using a Pythonic syntax. I'm talking about running actual Vue code (or anything else in that style) server-side as Django templates.
> For example I’d choose React + Typescript over Django templates any time of the day.
What's stopping you? I use Django Rest Framework to write views and React + Typescript for the front end. Using templates is often way simpler, though.
But that means throwing out a large part of Django and writing lots of "interconnect" code. At that point I think it's better to choose a different backend, one that will generate typed Typescript client code (or use Typescript on the server and some clever metaprogramming).
The thing is that there's no TypeScript backend that gives you as much stuff out of the box as Django. You're either going to spend time on how to communicate between Django and TS, or spend time on how to recreate Django functionality in TS.
Not a Django person, but I've used a few server-side templating languages, and I agree. I'd love to go mostly/entirely server-side, cut down on boilerplate AJAX calls, and ship smaller/less JS-heavy sites to the browser. But I'd also like to write my view logic in a full language, with typechecking and a solid developer experience. I'm hopeful React Server Components will help with at least some of this.
I disagree with that. They are fine for regular forms, tables (as in grids), etc. I usually have a few views using plain old Django templates (with a couple of template tags for additional functionality), and then maybe one view with a full blown SPA in it. No need to build your login page etc in React.
I disagree. The way you can extend sections of other templates without creating an inheritance chain works very well (and I missed in template systems, for Java, for example)
To be clear, I use them as well. And every time I come to regret it unless it's on a site I absolutely do not touch once it's finished.
Templates make it harder to find and debug issues. They have extremely little tooling to give assurances about what they're compiling, whether the syntax is correct etc. This requires you to build massive, flaky test suites.
I'll take react and typescript any day over even one tenth of that.
Well, It is more of a design problem than a Django template problem. If you add more and more logic in the template itself instead of dealing with it in the views context or templatetags, you are bound to find yourself in such position that you have very hard to test code.
The tooling is fine and almost always lets you know where you are breaking stuff. Also, comparing react tooling with it is not fair, it is a much modern ecosystem that has pitfalls of its own.
I have been writing Django professionally for 10 years and React + Django together for 4+ years, so I really know what I am talking about here.
I basically agree. Templates are basically strings, while jsx is in the end a full programming language (js).
It has the downsides you mention (the error reporting is okayish I think). On the other side, you can write html directly (no classname, etc), and there is no transpiling/build tools/server-side rendering to add.
String templates are also side-effect free.
For spa I would prefer React (with Typescript): for a request/response old-fashioned app, or something like htmx/hotwire text templates can be very productive. I see your point though.
Wouldn't all of python have that problem? What you're saying is that there's very little static checks until the code is run, but all of python has that problem too, doesn't it?
Either you write big test cases covering everything, or you live with the knowledge that very unexpected things can be passed in to your methods without you getting notified.
It's less about static checking than it is runtime debugging. When you have a syntax error in a template, Django's error reporting is super opaque about the problem, usually just raising a TemplateSyntaxError with a vague description. This just gives you the python error stack with little information of the actual context of the actual problem in the template itself.
By contrast, if you have a problem in the python code, the exception stacktrace will point you to exactly where the problem originates. If you add a `breakpoint()` call in the source before the exception point and run the request again, you'll get dropped into a live debugging repl
Just the one if you're using CRA. None if you're embedding react as is.
The answer depends on how you're using react, and what advantages you want to get from it. "How many tools" is not a real question to ask. If you're concerned about ease of development and learning curves, then that gives you an actual goal to optimize for, and it won't coincide with the amount of tools (react is harder to use embedded than with tooling, hence why the latter is more popular).
For each and every tool that is added to my project, it needs to be installed by every developer, it needs to be understood at least on some level by every developer, and it needs to be maintained by someone.
I love Django a lot too. It has made MVPs really easy to deliver. At the same time, I am interested in understanding about the disadvantages/quirks of using Django. Do you have more examples that you could share?
Obviously nothing is stopping me, that's not the point. I was just highlighting the fact that in my opinion the DX of parts of Django is inferior compared to the JS frontend ecosystem. As the Django community, I think this is something we should have an eye on.
You're absolutely right in the sense that the Django and other communities should not stagnate and should also keep an eye on what the other frameworks are up to. Maybe the default template engine should be replaced in Django?
Template engines are already configurable and pluggable for quite a while.
The "problem" is that most of the third-party apps that want to provide templates end up using the default, so either you have to reimplement those or stick with the default engine.
You can use both the Django Template Engine and other template engines side-by side in the same project. You can then write your custom templates in whatever you want, and have your third-party apps use whatever template engine they want to.
I have been meaning to develop the exact same thing (I was going to call it lastsforever.store), but just never found the time. Thanks for putting this out there. I'd say it's still a little rough on the edges, but should have potential.
What I honestly dislike, however, is to see all the google tracking going on there... is that really necessary?
I'm working on a webapp that enables people to include non-smart (i.e. pdf or paper based) data about their carbon footprint into https://north-app.com/.
The alpha version is available here: outsmart.superservice-international.com/
I studied agronomy and am well familiar with Berrey's work. Nonetheless, I was sucked into technology's vortex and am nowadays working as a software engineer. In my dreams I’ll go back to farming one day, but if I’m dead honest that’s probably never going to happen. We’ll all eat lab food pretty soon, hopefully at least for the better of the environment.
Similar experience. While the django rest framework is a joy to use, I’m almost inclined to call graphene a headache. Poor docs, lots of spread our third party extensions that really should be in the core... I have even found myself wondering if the stark discrepancy between drf and graphene reflects or hints at a decline of django as a framework.
I don't know about decline but in the UK there are currently 65% more Django roles than Rails on Indeed.co.uk if you search by title:Django or Django title:Python.
