svelte framework - online edit of handbook/troggle/trog2030.html

handbook/troggle/trog2030.html

@@ -12,7 +12,7 @@
 <h1>Troggle in 2025-2030</h1>
 
 <h2>5-Year Plan</h2>
-<p>[Philip Sargent, 1 June 2020. Async updates 21 April 2021, HTMX updates 28 Feb.2024]
+<p>[Philip Sargent, 1 June 2020. Async updates 21 April 2021, HTMX updates 28 Feb.2024, Svelte update 29 Mar.2024]
 <ul>
 <li>I reckon django has at least another 4-5 years left as a very active project (~2025) and at least a decade or so as a well-maintained project.
 <li>I reckon python has another 10-20 years at least.
@@ -152,23 +152,33 @@ person's intensive use, much like Django's
 <a href="https://docs.djangoproject.com/en/dev/topics/cache/#local-memory-caching">Local-memory caching</a> ]</p>
 
 <h3 id="frontends">Things that could be a bit sticky 2 - front-end code</h3>
-<p>There is not yet a front-end (javascript or <a href="https://en.wikipedia.org/wiki/WebAssembly">WebAssembly</a>) framework on the client, i.e. a phone app or webpage, which is stable enough for us to commit
-effort to (we managed to remove all the jQuery by using recent HTML5 capabilities). Flask looks interesting
+
+<p>There is not yet a front-end (javascript or <a href="https://en.wikipedia.org/wiki/WebAssembly">WebAssembly</a>) framework on the client, i.e. a phone app or webpage, which is stable enough for us to commit effort to (we managed to remove all the jQuery by using recent HTML5 capabilities). 
+<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, but maybe in 2025 we 
-could see a good way to move all the user interface (rewritten to be GIS-centric?) to the client 
+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 
 (re-written in <a href="https://www.educba.com/typescript-vs-dart/">Typescript
-or Dart</a>) and just have an API on the server. [We already have a proof of principle JSON export API working, see
+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>.]
+  </ul>
 
 <h4>front-end code is not just a pretty face</h4>
-<p>Modern JavaScript frameworks support dynamic 'single-page websites' where all the component parts are fetched and replaced 
+
+<p>JavaScript front-end frameworks are <em>still</em> in a state of flux.
+
+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). This is fundamentally different from how Django was originally designed: using public URLs connected to code which produces a 
+1999). 
+
+<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>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.
+
 <h3>Things that could be a bit sticky 3 - GIS</h3>
 <p>
 New functionality: e.g. making the whole thing GIS-centric is a possibility.