+Multi-user synchronous use could be a bit tricky without a solid multi-user database sitting behind the python code. So removing all the SQL database use may not be what we want to do after all. +
Under all conceivable circumstances we would continue to use WGSI or ASGI to connect our python code to a user-facing webserver (apache, nginx, gunicorn). Every time a webpage is served, it is done by a separate thread in the webserver and essentially a @@ -163,27 +165,44 @@ person's intensive use, much like Django's
JavaScript front-end frameworks are still in a state of flux. +
Refreshing content within a page is fundamentally different from how Django was originally designed: using public URLs connected to code which produces a +complete webpage based on a single template. Django can interoperate + with dynamic systems but support may become increasingly baroque I imagine. + +
JavaScript front-end frameworks are still in a state of flux [2025]. JavaScript frameworks such as JQuery, Vue, Angular, React etc. support dynamic 'single-page websites' where all the component parts are fetched and replaced asynchronously (this used to be called AJAX when it first appeared in -1999). These come and go [2025] on too short a timeframe for expo to cope with. +1999). These come and go on too short a timeframe for expo to cope with. -
Refreshing content within a page is fundamentally different from how Django was originally designed: using public URLs connected to code which produces a -complete webpage based on a single template. Django can interoperate - with dynamic systems but support will become increasingly baroque I imagine. + +
We have been waiting for more than a decade and a half for the JavaScript Framework mess to sort itself out. We want to see where we could sensibly move to a front-end+back-end architecture, instead of redrawing every screen of data on the server (see above "Things that could be a bit sticky 2 - front-end code"). + +
In 2024 it now looks as if we may be able to stretch the current architecture into a post-Javascript era entirely because Webassembly continues to develop rapidly. Or maybe future versions of HTML (see HTMX below) will do what we need. + +
HTMX now looks like it may evolve into replacing large chunks of what is now done with JavaScript packages (Angular, React, Vue.. and jQuery before them). See Django/HTMX article. For Django users particularly, HTMX seems to be a very good fit [2025]. -
The new kid on the framework block is 'svelte', which is fast to load and fast to render, but until we see some hint of stability it makes no sense to spend a lot of effort re-writing things that fundamentally work already. "Svelte leads the top favorite frameworks among developers, with over 71% dev satisfaction rate" in 2022. + +
+Hotwire and Turbo now also look interesting as ways to gain responsiveness yet not tie us into a heavyweight JavaScript framework (Jan. 2025).
@@ -193,14 +212,7 @@ A GIS db could make a lot of sense. Expo has GIS expertise and we have a lot of
We will also need an API now-ish, whatever we do, so that keen kids can write their own special-purpose front-ends using new cool toys. Which will keep them out of our hair. We can do this easily with Django templates that generate JSON, which is what CUYC do. We already have some of this: JSON export. -
We have been waiting for more than a decade and a half for the JavaScript Framework mess to sort itself out. We want to see where we could sensibly move to a front-end+back-end architecture, instead of redrawing every screen of data on the server (see above "Things that could be a bit sticky 2 - front-end code"). - -
In 2024 it now looks as if we may be able to stretch the current architecture into a post-Javascript era entirely because Webassembly continues to develop rapidly. - -
HTMX now looks like it may evolve into replacing large chunks of what is now done with JavaScript packages (Angular, React, Vue.. and jQuery before them). See Django/HTMX article (5 Feb.2024). -
Hotwire and Turbo now also look interesting as ways to gain responsiveness yet not tie us into a heavyweight JavaScript framework (Jan. 2025). +
The idea that we should replace Django with Flask comes up from time to time: "No! This is a really shit idea":
@@ -214,6 +226,9 @@ A GIS db could make a lot of sense. Expo has GIS expertise and we have a lot of
For an updated (June 24, 2025) comparison, see Choosing the Best Python Web Framework +
The new kid on the framework block is 'svelte', which is fast to load and fast to render, but until we see some hint of stability (still major changes happening in 2025) it makes no sense to spend a lot of effort re-writing things that fundamentally work already. +
Andy Waddington, who wrote the first expo website in 1996, mentioned that he could never get the hang of Django at all, and working with SQL databases would require some serious book-revision: