-
The goals of this project:
- Make the non-API code more stable and require less maintenance (over a period of many years)
- Make the non-API code more secure
- Make the non-API code more performant
- Achieve those things with least effort
- Make it easier to add new features
And on #2 and #3... when new features emerge in browsers and infrastructure, add support as soon as possible.
I do not believe that going the JS route with a rich client would deliver on #1, #2, #3, #4. I do believe it would do #5, but that over time maintenance of that code would slow down adding further features.
Instead I'm aiming for:
- Render pages in less than 2ms on the server
- Reduce API calls and cache where possible (so total serve time is < 10ms on a cached page, and is the shortest possible time for non-cached)
- During the render of templates, fully hydrate the HTML (i.e. the "6 hours ago" is currently JavaScript... everything will be done server-side) so that JS is not required to draw and all JS can be deferred and the draw time reduced
- Use local storage as a cache and add service workers to populate the cache. Things like the web fonts are not going to be loaded on page load, I'm going to draw the page without them and then populate the cache in the background and then they will be there for the next and all subsequent requests
- Isolate features in the templates to speed up addition of new features
I'm building this quite an old school way, because ultimately it will be very maintainable for a seriously long period of time.
I'm aiming for long-term neglect as a design feature... we have a bus factor of 1, and if I die I would like the hundreds of sites that exist on Microcosm to be able to exist for a very long period of time with the only maintenance of the system required is my wife making sure that every few years the payment details are kept up to date and that the PayPal keeps working and donations keep covering costs.
The JS approach may be snazzy but it doesn't deliver on most of my goals. I could've stayed on Django and started layering in the JS there.
- Make the non-API code more stable and require less maintenance (over a period of many years)
You are reading a single comment by @Velocio and its replies.
Click here to read the full conversation.
Velocio
Just curious, have you considered ditching the django server-side templating completely and have the browser talk directly to the API? ie move the django logic into browser javascript instead of Go.