expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2024-11-25 16:52:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

Webassembly update - online edit of handbook/troggle/trog2030.html

Browse Source
This commit is contained in:
Expo on server 2024-01-06 16:27:25 +00:00
parent b293cb91cf
commit 0c553e6036
1 changed files with 11 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
handbook/troggle/trog2030.html
View File

@ -5,7 +5,8 @@
<title>Handbook Troggle Design</title> <title>Handbook Troggle Design</title>
<link rel="stylesheet" type="text/css" href="../../css/main2.css" /> <link rel="stylesheet" type="text/css" href="../../css/main2.css" />
</head> </head>
<body><style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style> <body>
<style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style>
<h2 id="tophead">CUCC Expedition Handbook</h2> <h2 id="tophead">CUCC Expedition Handbook</h2>
<h1>Troggle in 2025-2030</h1> <h1>Troggle in 2025-2030</h1>
@ -134,7 +135,7 @@ NB We do cache one page per expedition, but explictly in our own python code. So
person's intensive use, much like Django's 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> <a href="https://docs.djangoproject.com/en/dev/topics/cache/#local-memory-caching">Local-memory caching</a> ]</p>
<h3>Things that could be a bit sticky 2 - front-end code</h3> <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 <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 effort to (we managed to remove all the jQuery by using recent HTML5 capabilities). 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 (but <a href="https://adamj.eu/tech/2019/04/03/django-versus-flask-with-single-file-applications/">maybe is only simpler when
@ -156,9 +157,16 @@ complete webpage based on a single template. Django <a href="https://engineertod
<p> <p>
New functionality: e.g. making the whole thing GIS-centric is a possibility. New functionality: e.g. making the whole thing GIS-centric is a possibility.
A GIS db could make a lot of sense. Expo has GIS expertise and we have a lot of badly-integrated GPS data, so this needs a lot of thinking to be done and we should get on with that. A GIS db could make a lot of sense. Expo has GIS expertise and we have a lot of badly-integrated GPS data, so this needs a lot of thinking to be done and we should get on with that.
<h3>API</h3> <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>. <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>.
<h3>Postscript</h3> <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: <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:
@ -174,6 +182,5 @@ Return to: <a href="trogdesign.html">Troggle design and future implementations</
Return to: <a href="trogintro.html">Troggle intro</a><br /> Return to: <a href="trogintro.html">Troggle intro</a><br />
Troggle index: Troggle index:
<a href="trogindex.html">Index of all troggle documents</a><br /> <a href="trogindex.html">Index of all troggle documents</a><br />
<hr /> <hr /></body>
</body>
</html> </html>