expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2025-12-07 14:24:28 +00:00
Code Issues Packages Projects Releases Wiki Activity

More HTMX - online edit of handbook/troggle/trog2030.html

Browse Source
This commit is contained in:
Philip Sargent
2025-11-01 07:19:47 +00:00
committed by Expo on server
parent 811984a45a
commit bd191a67af
1 changed files with 31 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
handbook/troggle/trog2030.html
View File

@@ -130,7 +130,9 @@ troggle/templates/xxx.html</var>), instead of using the Django-specific database
</div>
<h3>Things that could be a bit sticky 1 - multi-user safety</h3>
<p>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.
<p>Under all conceivable circumstances we would continue to use WGSI or
<a href="https://asgi.readthedocs.io/en/latest/introduction.html">ASGI</a> 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
<ul><li>Flask looks interesting
(but <a href="https://adamj.eu/tech/2019/04/03/django-versus-flask-with-single-file-applications/">maybe is only simpler when
starting a new project and doesn't scale to complexity</a> the way Django does.
<li>Maybe in 2025 we could see a good way to move all the user interface (rewritten to be GIS-centric?) to the client
<li>Maybe in <strike>2025</strike> 2030 we could see a good way to move all the user interface (rewritten to be GIS-centric?) to the client
(re-written in <a href="https://www.educba.com/typescript-vs-dart/">Typescript
or Dart</a>) and just have an API on the server.
<li>We already have a proof of principle JSON export API working, see
<a href="exportjson.html">Troggle JSON</a>.]
<li>Or "HTML6" may simply sweep away the need for these Javascript frameworks for most uses: see the HTMX project below.
</ul>
<h4>front-end code is not just a pretty face</h4>
<p>JavaScript front-end frameworks are <em>still</em> in a state of flux.
<p>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 <a href="https://engineertodeveloper.com/how-to-use-ajax-with-django/">can interoperate
</a> with dynamic systems but support may <a href=
"https://speakerdeck.com/andrewgodwin/just-add-await-retrofitting-async-into-django?slide=76">become increasingly baroque</a> I imagine.
<p>JavaScript front-end frameworks are <em>still</em> 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 <a href=""https://en.wikipedia.org/wiki/Ajax_%28programming%29>AJAX</a> when it first appeared in
1999). These <a href="https://brainbaking.com/post/2025/06/no-time-to-learn-web-framework-x/stackoverflow-popularity.jpg">come and go</a> [2025] on too short a timeframe for expo to cope with.
1999). These <a href="https://brainbaking.com/post/2025/06/no-time-to-learn-web-framework-x/stackoverflow-popularity.jpg">come and go</a> on too short a timeframe for expo to cope with.
<p>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 <a href="https://engineertodeveloper.com/how-to-use-ajax-with-django/">can interoperate
</a> with dynamic systems but support will <a href=
"https://speakerdeck.com/andrewgodwin/just-add-await-retrofitting-async-into-django?slide=76">become increasingly baroque</a> I imagine.
<p>We have been waiting for more than a decade and a half for <a href="trogspeculate.html">the JavaScript Framework mess</a> 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 "<a href="#frontends">Things that could be a bit sticky 2 - front-end code</a>").
<p>In 2024 it now looks as if we may be able to stretch the current architecture into a <a href="trogspeculate.html#frontends">post-Javascript</a> era entirely because Webassembly <a href="https://thenewstack.io/webassembly-4-predictions-for-2024/">continues to develop rapidly</a>. Or maybe future versions of HTML (see HTMX below) will do what we need.
<p>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 <a href="https://testdriven.io/blog/drf-vue-vs-django-htmx/">Django/HTMX</a> article. For Django users particularly, HTMX seems to be <a href="https://blog.jetbrains.com/pycharm/2025/10/the-state-of-django-2025/">a very good fit</a> [2025].
<p>The new kid on the framework block is 'svelte', which is <a href="https://dev.to/hb/react-vs-vue-vs-angular-vs-svelte-1fdm">fast to load and fast to render</a>, 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" <a href="https://www.softermii.com/blog/why-sveltejs-is-the-most-in-demand-framework-for-web-development">in 2022</a>.
<div class="onright">
<figure >
<a href="https://blog.jetbrains.com/pycharm/2025/10/the-state-of-django-2025/">
<img width=350 src="django-htmx.png"></a>
<br><figcaption>HTMX becoming mainstream</figcaption>
</figure>
</div>
<p>Hotwire and <a href="https://turbo.hotwired.dev/">Turbo</a> now also look interesting as ways to gain responsiveness yet not tie us into a heavyweight JavaScript framework (Jan. 2025).
<h3>Things that could be a bit sticky 3 - GIS</h3>
<p>
@@ -193,14 +212,7 @@ A GIS db could make a lot of sense. Expo has GIS expertise and we have a lot of
<h3>API</h3>
<p>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 <a href="https://www.cuyc.org.uk/committee/events_json_short/">what CUYC do</a>. We already have some of this: <a href="exportjson.html">JSON export</a>.
<h4>WebAssembly Front-Ends</h4>
[January 2024]<br />
<p>We have been waiting for more than a decade and a half for <a href="trogspeculate.html">the JavaScript Framework mess</a> 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 "<a href="#frontends">Things that could be a bit sticky 2 - front-end code</a>").
<p>In 2024 it now looks as if we may be able to stretch the current architecture into a <a href="trogspeculate.html#frontends">post-Javascript</a> era entirely because Webassembly <a href="https://thenewstack.io/webassembly-4-predictions-for-2024/">continues to develop rapidly</a>.
<p>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 <a href="https://testdriven.io/blog/drf-vue-vs-django-htmx/">Django/HTMX</a> article (5 Feb.2024).
<p>Hotwire and <a href="https://turbo.hotwired.dev/">Turbo</a> now also look interesting as ways to gain responsiveness yet not tie us into a heavyweight JavaScript framework (Jan. 2025).
<h3>Django and Flask</h3>
<p>The idea that we should replace Django with Flask comes up from time to time: "No! This is a really <em>shit</em> idea":<br>
@@ -214,6 +226,9 @@ A GIS db could make a lot of sense. Expo has GIS expertise and we have a lot of
<p>For an updated (June 24, 2025) comparison, see <a href="https://judoscale.com/blog/which-python-framework-is-best">Choosing the Best Python Web Framework</a>
<h4>Svelte not Flask</h4>
<p>The new kid on the framework block is '<a href="https://en.wikipedia.org/wiki/Svelte">svelte</a>', which is <a href="https://dev.to/hb/react-vs-vue-vs-angular-vs-svelte-1fdm">fast to load and fast to render</a>, 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.
<h3>Postscript</h3>
<p>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: