At work we build our web apps using Django + DRF or graphql for our API’s and use Angular, React and Mithril for our frontends. I’m sick of SPA’s, sick of overly complex frontend architecture for what could be easily accomplished by pulling JQuery in from a CDN, sick of arguing over Angular vs React vs etc etc.
Lately I’ve been thinking… why am I jumping through these hoops at all? Why am I not just building full sites with Django + static js rather than just using it for API’s? I’ve done it before for personal projects and honestly I kinda really liked it compared to having a separate frontend.
I guess what my questions are:
- In what cases is it actually even worth it to use Django as just a backend and have a framework like Angular driving the frontend?
- What would the cons be to using Django templates + static js as opposed to having a separate frontend?
- What is the difference of level of effort between using Django templates + static js as opposed to having a separate frontend?
I can’t speak for the “SPA” / “JS Framework” crowd, but I see some value for browser-based applications that need to more “look” and “feel” like a traditional desktop application.
KenWhitesell I love django for it’s simplicity and development speed. I have few questions: 1) is it worth to build django fontend using react?
2) if we need to be show dynamic content in our websites so should we use ajax for that ? Does ajx load our content fast ? What’s the best alternative of ajax ?
3) what technology should we use for display dynamic content without refreshing page and will load our site faster?
I think the excitement about htmx is probably justified, though I’m only beginning to use it myself. It encourages a HATEOS (Hypertext as the Engine of State) instead of a lot of shadow DOM programming. If you have a pretty normal website with pretty standard media, you can get a smooth SPA-like feel with Django and templates that have a few extra htmx attributes. The components (if they’re reasonably independent) can be reused anywhere by calling their view within your new page view and inserting the output in the template for this view.
The developer (architect?) of htmx (Carson Gross) has a related project called HyperScript which is for in-page updates; it is absurdly readable (like natural language), but still developing fast, so might not be stable?
That being said, there are also things where the ‘media’ is not something that django templates is naturally set up to satisfy and a custom frontend tailoring a framework makes sense. 3d graphics, editable SVG - anything where the update has to be computed locally. So to sum up, I reckon:
- possibly not if you are not using large parts of django (forms, ORM, templates). Depends on the alternative I guess?
- can’t think of any that you couldn’t avoid with htmx, if you don’t have special media needs for your users, and even then, I think I’d use a framework that covered that medium (e.g. a dedicated game engine).
I guess as soon as you have to support an Android app, an iOS app and a responsive browser interface, a common backend that just sends data is simpler than sending HTML back and forth(?)
To address your questions:
- Personally? I don’t think so. There are a lot of people who disagree however, and they’re not wrong. I think it really depends upon the type of application you’re building and your target market. My opinion is that many web sites are tremendously “over-engineered” to provide “glitz” rather than functionality. However, that’s not to say that there aren’t a significant number of web apps that do benefit tremendously from that type of architecture.
2a) AJAX is used to retrieve data to update a page without doing a full page refresh. If your application needs that, then that’s your option.
2b) The only alternative to that that may under most circumstances be “faster” would be moving data through a websocket connection. Once the websocket connection is established, you’re no longer incurring the overhead involved in an http exchange.
- Your technology choices are up to you. Such architectural decisions should rarely be made in the absence of accounting for the context of the environment, infrastructure, and personnel.
Thanks for that bit of info! I’ll have to check into htmx and HyperScript.
On your last point, even if I did need to support an Android and iOS app I could always just add a REST API for those and still do the browser interface using django templates right?
For a small to medium project I’m convinced that going the “hybrid” route - either by statically serving some framework embedded in a Django app or by using something like htmx - will be totally sufficient from a usability perspective and substantially better from a developer productivity / speed perspective.
The main benefits of a separate front end are:
- If you have other clients, e.g. an IOS app
- If your team is large enough that you want a firewall between the front end and back end developers.
In your case the only thing that gives me pause is that you identify as a front end developer. The transition to a django-hosted front end can trip up people coming from a “create react app” type of background, and you can get mired in tooling issues getting things like hot reloading working. But for the average Django developer I’d say hybrid or htmx all the way!
You say for small to medium projects it’s good, but what tends to break down for a large scale project to the point where a separate frontend is preferred in your opinion?
I’ve been looking into htmx since yesterday and I’m really excited about it, I think it might actually be the solution I’m looking for. I briefly checked out the site you linked and seems like there’s some good knowledge there, I’ll check it out further.
Ah - given that extra context I feel very confident recommending a Django + HTMX type of stack (the last article in the series I linked above may be helpful).
I already mentioned the two cases where I find a separate front end to be valuable: if you have multiple clients or a team structure that works better with a fully isolated front-end team. If it’s a pure web app and the same people are working on the front and back end then I think it’s almost always overkill and likely to slow you down.
Hi all! I just want to add my opinion
I had already read @czue posts months ago, I came to them because I had been very interested in how to properly mix Django with React without having to create more repos + domain + CI?CD pipelines and so on, and your guide helped me a lot.
I just discovered HTMX, and I just love it! It seems obvious to me that it is the future of development, I think it is the path we should have taken and we had lost it, during the last years we have added unnecessary complexity for 95%, and HTMX comes to help us.
I think SPAs are only ideal for dashboard-type sites or apps, but not for content-based sites that need traffic from search engines. (Search engines can index client-rendered JS, but those sites don’t tend to rank well.)