I realised today when writing a post into the Django Forum that I had a half formed idea in the new post form that I had totally forgot about out. I spent some chatting with Carlton about it, so it seemed worth dropping the ideas here before they’re lost to the ether.
Background – Carlton’s DjangoCon Europe 2024 talk
This post won’t make much sense without knowing about the talk I’m referring to, Carlton Gibson’s DjangoCon Europe talk – API Maybe: Bootstrapping a Web Application circa 2024.
The link I’ve used points to the talk abstract and I’ve below on to the youtube recording of the talk too:
The gist is that while we’ve had a few years of separate front and back end teams building projects of late, and that in 2024, it’s not really that necessary any more.
For me there were a few takeaways relevant to this post, namely:
- the tools for server side development are getting a lot better
- a new paradigm has been emerging where we stop sending json back and forth over the wire with relatively ‘thick’ React/Ember/Vue clients that replicate logic client-side that we already implemented in the server
- this paradigm instead relies on much less javascript in the browser, and sending html fragments that have been rendered server side instead
- in the django ecosystem, we’re well served with htmx alphine.js and various django packages like django-htmx
Naming this pattern
Anyway, one thing we discussed is that while the pattern he described in his talk had been helpful to him, we didn’t know if there was a useful shortform name for it like we had in the mid 2000’s with the ‘AJAX’ term coined by Jesse James Garrett , for the new kind of interactivity that didn’t rely on entire page reloads all the time.
In 2024, different frameworks now implement this process, but I’m unaware of the shared name for what is effectively the same kind of behaviour.
In the Elixir community, there is one feature, LiveView that is similar. In the Rails community, I believe there is a related feature called TurboLinks.
Anyway, names for stuff are useful, so we joked about wishing there was a pronouncable catchy acronym, for this pattern we could use in 2024. So over a drink, we started trying a few out.
In the end, I think WNDR was one I remembered, standing for Web Native Dynamic Rendering, and pronounced wonder.
Let’s unpack this:
Web Native
Web Native was a reference to where possible using the existing elements that the HTML language offers us, and all the functionality you get by default when you implement links and forms as the spec suggests.
A common criticism of extremely heavy javascript front-ends is not only that they are slow, and resource hungry, but they also end up being a disaster accessibility wise. You lose many of the accessibility benefits from using proper hyperlinks and buttons for example, and in many cases, you lose the ability to hyperlink to views of the app too
So Web Native is a response – to emphasis that we have loads of nice tools now, and where possible, we should invest the time to see what browsers now offer if you “go with the grain” as part of the approach to development, instead of immediately looking for a npm-installable library.
Dynamic Rendering
Was the reference to not needing a full page load to see updates, while avoiding the need explicitly name a technology.
While back in the day AJAX explicitly referenced XMLHTTPRequest, HTMX isn’t the only game in town, so if you avoid naming specific technology, you can include not just Django-HTMX and Unicorn in the Django Ecosystem, but you could use this term to describe the patterns I linked to in other communities too.
Big tents and all that.
Anyway, it’s out of my head. I can move on with my life, and if I say WNDR in future, I now have a link I can refer to.
Onwards!
Leave a Reply