5 ms·
For blog sites I tend to use a hand written site generator that converts markdown to html, typescript to js and scss to css at compile time. This allows me to
by apatheticonion 4y ago
For blog sites I tend to use a hand written site generator that converts markdown to html, typescript to js and scss to css at compile time.
This allows me to ship a static html site (S3 website) where the javascript functionality is limited to basic things, like toggling dark mode.
To build an "API", I crawl the files at compile time and generate json files in an /api folder, allowing me to fetch blog post metadata for searches that are processed on the client.
As icing on the cake, once the user has settled in, I use a service worker to pre-download/cache the all the posts in the blog site and allow for offline viewing. I have some tricks to avoid the annoyances of stuck sw caches.
Leads to a great user experience and maintainers don't need to have a backend portal - just write markdown and commit it straight to GitHub. Easy enough to teach people to use Typora and SourceTree
- jppope 4y agonice setup. I'm going to have to look into the service worker approach. typora and github are my version of what you're talking about - which I love
- kim0 4y agoSounds very nice. Is this available for others to use?
- apatheticonion 4y agoI have only just started building it out, I built the first prototype for my personal blog site. (Not a plug, it's a WIP and I have only put a few toy articles up) You can see it in action here: https://davidalsh.com/posts/the-case-for-a-sandboxed-script-tag https://davidalsh.com/posts/the-case-for-a-sandboxed-script-... I'm making a few too many requests in the first iteration, no cache control headers, asset minification, etc Since then, I have been refining it for a contract that I am working on (introducing the SW) and I am keen to release it as an open source project - including a terraform script to deploy it to S3, setup Cloudfront and all that good stuff.