A lot of these seem to be JS-based. Static site generators are supposed to be simple, static, and generate small pages that load fast. I don't see why I'd need React or Vue support for a *static* site.
Static just means your site is loading actual CDN- and cache-friendly files and not stuff dynamically generated on the fly by a server side process, or loaded through such a process.
Javascript can still be statically loaded in this situation and could be used to provide UI elements (such as collapsible sections) or even an interactive local search.
That is a very new domain specific overloading of what the term 'static website' means. Unlike the old usage which is from the point of view of the website user where static means they don't have to execute code, the new usages tend to be developer experience focused and of little general utility.
Yeah, the "new" usage of the term, where it describes the location of page generation, doesn't seem all that helpful. If you generate a file that's mostly html (with maybe a bit of JS mixed in), you have something that serves and renders fast even on lesser machines. That has always been the important distinction to me.
Edit: Just to be clear, I'm not saying web pages should be mostly statically generated html with a bit of JS. The point is that someone developing a web app shouldn't normally be concerned about whether or not it's static.
No one wants a bespoke template language for every different project. You want to be able to share and use the same template for rendering a dynamic contact list populated by an AJAX call on your site's dynamic pages, with the simple static marketing page that lists all the project creators for example. React/Vue/Svelte/etc. are just templating systems that started as dynamic frontend-only solutions but now see use in generating static pages too. The idea is that the same templates can be reused, shared, mixed and matched, etc. in all uses. You don't need to spend weeks building and maintaining two separate types of templates--those used for dynamic vs. static pages.
If you love building stuff in Rails, keep an eye on my project Sitepress at https://github.com/sitepress/sitepress (there's a project site too at https://sitepress.cc). I'm a few betas away from dropping a 2.x release. I'm still working through a few refactors that makes the whole thing more modular.
I built this because it was extremely difficult to embed Middleman or Jekyll into a Rails site. While I was building it, I discovered that Rails actually has a LOT of stuff in it already that make it work well for a static site compiler.
I run it in a few places, with the largest deployment at https://www.polleverywhere.com. At Poll Everywhere it's happily been serving up content pages for a few years. I've switched all of my personal static websites over to it as well.
Here's what's kind of crazy about Sitepress: you can use it to compile static websites -- OR -- you can embed it in rails and do things dynamically like display a "Login" vs "Logout" button state. The choice of "static" vs "dynamic" just isn't a big deal with Sitepress, you can have it both ways.
Last thing: I'm currently working on making Sitepress serve up Notion and Webflow content. This can be really helpful for teams that need to deal with multiple CMS formats from large teams.
Check out Bridgetown, "a Webpack-aware, Ruby-powered static site generator for the modern Jamstack era". It's come a long way since it forked from Jekyll a year ago [1].
A while ago I was picking a new SSG and I would have preferred something written in Python so I can hack on it more easily. I ended up moving on because of the license.
Thanks for educating me - I did not know about this.
Not sure I see it as a problem, though. I'm producing static files, and uploading them to a web server. At no point is a user communicating with the program - which I think is the key clause that triggers the AGPL. The whole discussion about templates being treated as code is enlightening - but again: No user is communicating with the templates either.
Furthermore, even if I'm wrong on this, I don't see the leap that the content of the blog has to be AGPL. At worst, I'd merely have to release my templates and any other modifications I've made to the code (custom plugins, etc).
Things like "not sure" and "I think" and "even if I'm wrong" suggests that it is not very clear what is covered and what isn't. A lawyer would probably have to sort that out.
The practical problem is that some organizations simply discourage or don't allow the use of GPLv3 or AGPL software. I don't want to learn one tool for personal projects and another for potential work projects, in case the opportunity comes up.
The easiest way to deal with that is to just switch to a tool that has a license that is more widely accepted.
> Things like "not sure" and "I think" and "even if I'm wrong" suggests that it is not very clear what is covered and what isn't.
No - it suggests that I'm not a lawyer. I would use those phrases for any license.
Let me put it concretely. Had I read the AGPL, I would have concluded that there is no problem in this use case - just as I would with the GPL or any permissive license. It's only because others disagree, for reasons that seem faulty to me, that I hesitate. Frankly, for me, this is a good example of (unintentional) FUD.
> The practical problem is that some organizations simply discourage or don't allow the use of GPLv3 or AGPL software.
I thought the issue was GPL vs AGPL. If you're avoiding GPL, then it makes it more understandable. In any case, I use it for personal reasons. Were I considering it for our work, we would consult with our lawyers (have done so in the past) - regardless of the license. My work does not involve the web, so I don't have the concern of having to learn two different tools.
I use pelican, mainly because it was the top Python SSG at the time and thought maybe I’d hack on it. I never hacked on it, just used it. I’d probably pick something new if choosing today, like Hugo which has a larger ecosystem
I picked Pelican for similar reasons. All my prior experiences eventually led me to wanting to change some aspect of the blog software, but they were always in languages I didn't know. So I picked Pelican.
In the years since, I write code to get my desired output via Pelican probably once every few years, but it's totally been worth it to have that option. I really got sick of "Let's search to see if someone's written a plugin that does exactly what I need." And then to have the plugin broken with an upgrade.
“Written in GO and readily installable as a binary, Hugo is tremendously portable…”
I am but a humble designer, who only knows enough to write some simple prototypes, and wants some organizational helps. Partials. Concatenating stylesheets. Little things that I used to use CodeKit for.
And I like Hugo because of that “it’s just a binary” bit. There’s no dependency hell. No leaning tower of JS or Ruby. You install it, it sits there, nothing can really break. That’s what I want.
Is that a niche criteria? Obviously. But I do appreciate it. (And if someone has a better suggestion for a very simple static site generator, bring it on.)
Hugo can be that simple if you don't have a complex frontend template. As soon as you want to make a SPA (or SPA-like experience), use a framework like React/Vue/Svelte/etc., or even try out stuff like TailwindCSS you're going to get sucked into the deep rabbit hole of bundling frontend assets, webpack/esbuild/etc.
So you kind of have to decide, are just static templates and static assets all you need? Stick with Hugo and enjoy the speed, simplicity, etc. There are some even simpler alternatives you might enjoy too, like mdbook or mkdocs. Both are more oriented towards technical docs but are similar to hugo at their core--send in some markdown (in the case of these tools you don't even need frontmatter or other schema) and get out some HTML.
If you're building something fancier or using more complex frontend setups then... there's no perfect answer right now. It's all about balancing complexity of the build system with what it gives you in the output. IMHO webpack and gnarly dependencies can be tamed pretty well with a simple docker container. Spend some time getting your perfect workflow setup, chuck it in a container that a CI system can run all day, every day without fail, and you'll be pretty well setup.
Can you share more about this? I like Hugo for its speed and simplicity, but I find it hard to create elements within components the way I can in Vue. I haven't found any good resources for combining Hugo with frontend frameworks, so I'm curious what you do.
src/entrypoints/donate.js defined a custom element, which was included on layouts/donate-page/single.html and layouts/partials/get-src.html conditionally included the Vue component either with Parcel's dev server in testing or precompiled files in production.
It's not very different from what you'd do in any not-JS web framework.
Everything is kind of converging. In the SPA world they realized the SEO sucks and they need static server rendered content, so there's a whole realm of SSR (server side rendering) built around it with Next.js, Vuepress, Sveltekit, etc. And on the static site side folks realized static sites can kinda suck and feel clunky, so loading some JS to add smoothness is nice. Check out Docusaurus for an example of a static site generator that actually uses React internally to build a SSR friendly SPA with fluid page loads. You don't have to choose one or the other anymore, you can get both a smooth SPA experience with full server rendered and SEO friendly content.
Leaning tower of JS just hit me in the soul after two full days of composer and npm dependency hell. I'll have to give Hugo a try for my next fitting use case.
I love Gridsome, and it had tons of potential, but it's effectively a dead project. The maintainers haven't cut a new release since November 2020.[0] There's barely been any feature work since 2019.[1] Their Github repos have tons of PRs that have not been reviewed. There are serious site-killing bugs that have not been fixed for over a year.[2]
I really wanted this project to succeed. I asked to sponsor the project and volunteered working on their documentation for a few months, but it didn't seem to yield any new dev work.
The maintainers are extremely talented, and this is not a knock against them, but I just caution anyone against marrying themselves to a framework that's unlikely to have any ongoing maintenance.
Maybe I'm missing something, but how are these alternatives to Gridsome? These all appear to be headless CMSes, where Gridsome would be the front end accessing the CMS.
No you're absolutely right -- these are all headless CMSes, I did not actually complete the JAMstack, only the wrong piece -- I don't know what I was thinking, don't know what made me zoom in on CMSes so much, guess I think of them as more important than the front-end in a JAMstack.
As recompense, some lesser known options for the frontend part of the JAMstack that weren't mentioned in the original post:
I had the same thought when reading the list. I was very excited about gridsome when I discovered it last year. It had so much potential but disappointing to see it untouched since.
Thanks for sharing, interesting that you liked the sections/pages structure because it was something I was fumbling with initially (but did eventually settle into a groove).
I will say there is currently a lot of momentum behind other projects when it comes to the "out of box" themes that are available. I'd like to see more community maintained themes.
I made my templates and CSS (SASS) from scratch. I would have released them if they weren't so bespoke. I'd like to see some that make use of well-known CSS frameworks (eg. Bulma or Tailwind).
I'm surprised there isn't more love for pandoc in the SSG world. It is an unbelievably flexible and fast tool in my experience, with very little opinions or concepts to learn. Yet despite the simplicity it opens up a huge amount of customization with its AST filtering (either in lua or bring your own executable plugin). Pandoc + a shell script or even makefile could likely replicate many folks needs for a simple SSG.
I love pandoc, but it explodes the size of my Arch Linux updates because of the way Haskell is packaged. I'll have to check out whether there's some kind of single AppImage binary or something.
30 seconds after posting the comment, I found this:
I don't know why I never tried to look for it. But I can attest to that fact pandoc + miniserve is a very interesting static site stack for those who want ultra simple.
Yep they have single static binaries now that are way more convenient. Better yet too, there's a nice docker image that's easy to use as-is or build on with your own plugins/filters/etc: https://hub.docker.com/r/pandoc/core
Btw there is a static page generator utilizing pandoc directly: hakyll[1]. Since it's configuration is done via haskell source code file, you need to be willing to learn a bit of haskell though.
I have been working with Hugo about three years ago. I found Hugo quite nice and easy to learn compared to the other options. But later I discovered Publii (which isn't listed on this article).
Publii finally made editing and publishing a real pleasure by offering a real backend to manage your articles, media, organize your site etc.
Because for a lot of use cases, there's simply no need to have a full LAMP (or one of the many various alternatives) stack to serve what should be a simple website.
I'm not sure quite what you think static site generators do if you're comparing them to a CDN, but they take a set of scripts, markup, images, and whatever else you care to mix in, and then emit a static site - just a bunch of HTML/CSS/JS/etc. You can host it on anything that supports serving static files - Google Cloud Storage works (especially when fronted by Cloudflare, data bandwidth between those two companies is cheaper), a random old server, etc.
You typically render it locally, then simply upload the changes to whatever you're using to host.
Not all websites (and not even all websites dealing with somewhat dynamic content such as blogs) need a full server stack, and the security of the server is far better if it's just serving files.
I transitioned my blog from Blogger (when they updated it last summer and absolutely ruined the core functionality of their editor, which is editing text) to a Jekyll-rendered site. It works out well, and I simply integrate a Discourse instance I run for a variety of things into the templates to have a functional comment section for posts.
Many sites don't need to be dynamically generated - they just need to provide some text and pics or whatever.
Some bonuses with non-dynamic - no worries if a php update fails - no worries if some other server side thing is broken - just serve files - no thinking.
Less worries about cpu overload - like having a dozen wordpres sites on a box - you can run into problems if one of those sites is getting hammered by login requests or similar - even if you 100% prevent them from logging in - you are still eating up php and what not which may affect your other dynamically generated sites on the server more than some static files that need to be pushed.
Of course you are right in that modern CDNs and cacheing make much of what used to be bigger problems more trivial in general..
A single site on a VPS less likely to be of concern compared to shared hosting or a dedicated box with several sites - in my experience - situations vary.
If you're using a CDN just to a cache a dynamic site you still need a server running, with the asociated costs, maintenance and security issues. With a SSG you really can have just a CDN: build and deploy direct to the CDN and you don't need to keep anything running. The costs and attack surface are much lower.
I guess these things are not what ( a majority of the actively posting) HN crowd is thinking about when static site generators come up - but I want to mention that there is no need for all these hugo / jeckyl type setups for everyone when you can download a program write some text and publish - generating a static site with tools like:
I loved making pages and sites with NetObjects fusion the most - it seems that PineGrow is the closest thing to that but modern.
There are also a couple of 'Wordpress goes Static' plugins ( https://wordpress.org/plugins/simply-static/ is one of them ) that can pipe out static html pages from a WP install - and they are handy for positives of having a static site - with the bonus of all the WP themes - of course doing that destroys the dynamic things you may want - site search, contact forms, comments - but handy for the right use case.
In a pinch it is sometimes faster to pop open notepad and paste in an html5 boilerplate add some text and save it - done.
It's quite trivial to pull in bootstrap, bulma or similar with an include line or two and start making a page / generating a static site.
I wanted to write posts in Markdown with Latex support and the option of raw HTML but honestly every static site generator I looked at was super complicated and opinionated.
I ended up using Pandoc and a Makefile. It works really well.
I've worked with Scully. It's nice in that it let us share stylesheets with another Angular repo, but apart from that there were a lot of things that felt unpolished and difficult to work with.
I'm cheering for it and I don't want to come off as discouraging for a product that I didn't pay for, but it has a long way to go. A lot of my work with it (but not all) was pre-1.0 though, so maybe it's improved.
The user entered <script> you should save that verbatim, but there are many output formats, HTML, SQL, PS (Post Script), XLS etc etc where you need to escape user provided values
Mine's duct taped on Svelte/Sapper and Airtable as a CMS... it's completely free, is static, and super fast... don't knock Airtable as a CMS until you've tried it...!
Is there any kind of static site generator that lets me write documents in Markdown, store them in a directory, and automatically loads them into the static site and translates them to CSS?
I say this out of a genuine desire to be helpful, I promise: you wouldn't be translating your Markdown "into CSS", you'd be translating it into HTML, and then optionally applying CSS
To your original point, if you want something really simple this might work (haven't tried it, just found it on Google):
https://github.com/gomarkdown/mdtohtml
>I say this out of a genuine desire to be helpful, I promise: you wouldn't be translating your Markdown "into CSS", you'd be translating it into HTML, and then optionally applying CSS
Thanks, that’s what I meant, just didn’t think I needed to spell it out for this crowd :)
9 of these run on Node.js - quite interesting departure from what was the state a few years ago.
I wish we had a common specification around static-site generators though, something akin to CommonMark - so it was easier to switch between generators without having to spend time porting things around. The Jekyll directory structure for eg, is mostly respected various implementations - but it isn't a accepted everywhere for eg.
If you're considering using a static site generator for creating something like a personal blog, I suggest trying to create one yourself. The more hacky you do it, the better. It's a lot of fun.
86 comments
[ 2.8 ms ] story [ 140 ms ] threadJavascript can still be statically loaded in this situation and could be used to provide UI elements (such as collapsible sections) or even an interactive local search.
Edit: Just to be clear, I'm not saying web pages should be mostly statically generated html with a bit of JS. The point is that someone developing a web app shouldn't normally be concerned about whether or not it's static.
Sometimes the reason is the dev workflow rather than the output.
I built this because it was extremely difficult to embed Middleman or Jekyll into a Rails site. While I was building it, I discovered that Rails actually has a LOT of stuff in it already that make it work well for a static site compiler.
I run it in a few places, with the largest deployment at https://www.polleverywhere.com. At Poll Everywhere it's happily been serving up content pages for a few years. I've switched all of my personal static websites over to it as well.
Here's what's kind of crazy about Sitepress: you can use it to compile static websites -- OR -- you can embed it in rails and do things dynamically like display a "Login" vs "Logout" button state. The choice of "static" vs "dynamic" just isn't a big deal with Sitepress, you can have it both ways.
Last thing: I'm currently working on making Sitepress serve up Notion and Webflow content. This can be really helpful for teams that need to deal with multiple CMS formats from large teams.
Check out Bridgetown, "a Webpack-aware, Ruby-powered static site generator for the modern Jamstack era". It's come a long way since it forked from Jekyll a year ago [1].
[1]: https://www.bridgetownrb.com
It's been around for a long time. Has lots of plugins. Easy to extend. Fairly active development.
https://blog.getpelican.com/
A while ago I was picking a new SSG and I would have preferred something written in Python so I can hack on it more easily. I ended up moving on because of the license.
I am now very happily using Hugo.
Not sure I see it as a problem, though. I'm producing static files, and uploading them to a web server. At no point is a user communicating with the program - which I think is the key clause that triggers the AGPL. The whole discussion about templates being treated as code is enlightening - but again: No user is communicating with the templates either.
Furthermore, even if I'm wrong on this, I don't see the leap that the content of the blog has to be AGPL. At worst, I'd merely have to release my templates and any other modifications I've made to the code (custom plugins, etc).
The practical problem is that some organizations simply discourage or don't allow the use of GPLv3 or AGPL software. I don't want to learn one tool for personal projects and another for potential work projects, in case the opportunity comes up.
The easiest way to deal with that is to just switch to a tool that has a license that is more widely accepted.
No - it suggests that I'm not a lawyer. I would use those phrases for any license.
Let me put it concretely. Had I read the AGPL, I would have concluded that there is no problem in this use case - just as I would with the GPL or any permissive license. It's only because others disagree, for reasons that seem faulty to me, that I hesitate. Frankly, for me, this is a good example of (unintentional) FUD.
> The practical problem is that some organizations simply discourage or don't allow the use of GPLv3 or AGPL software.
I thought the issue was GPL vs AGPL. If you're avoiding GPL, then it makes it more understandable. In any case, I use it for personal reasons. Were I considering it for our work, we would consult with our lawyers (have done so in the past) - regardless of the license. My work does not involve the web, so I don't have the concern of having to learn two different tools.
In the years since, I write code to get my desired output via Pelican probably once every few years, but it's totally been worth it to have that option. I really got sick of "Let's search to see if someone's written a plugin that does exactly what I need." And then to have the plugin broken with an upgrade.
One aspect of static site development nobody seems to want to do is to keep themes up to date.
I am but a humble designer, who only knows enough to write some simple prototypes, and wants some organizational helps. Partials. Concatenating stylesheets. Little things that I used to use CodeKit for.
And I like Hugo because of that “it’s just a binary” bit. There’s no dependency hell. No leaning tower of JS or Ruby. You install it, it sits there, nothing can really break. That’s what I want.
Is that a niche criteria? Obviously. But I do appreciate it. (And if someone has a better suggestion for a very simple static site generator, bring it on.)
So you kind of have to decide, are just static templates and static assets all you need? Stick with Hugo and enjoy the speed, simplicity, etc. There are some even simpler alternatives you might enjoy too, like mdbook or mkdocs. Both are more oriented towards technical docs but are similar to hugo at their core--send in some markdown (in the case of these tools you don't even need frontmatter or other schema) and get out some HTML.
If you're building something fancier or using more complex frontend setups then... there's no perfect answer right now. It's all about balancing complexity of the build system with what it gives you in the output. IMHO webpack and gnarly dependencies can be tamed pretty well with a simple docker container. Spend some time getting your perfect workflow setup, chuck it in a container that a CI system can run all day, every day without fail, and you'll be pretty well setup.
src/entrypoints/donate.js defined a custom element, which was included on layouts/donate-page/single.html and layouts/partials/get-src.html conditionally included the Vue component either with Parcel's dev server in testing or precompiled files in production.
It's not very different from what you'd do in any not-JS web framework.
In my particular instance: yup. I’m at the “loop through an array of things in a folder” level, not “deploy at scale” level.
I had that issue with Jekyll, I just couldn't get the set up to work on my system (to be fair, I gave up easily instead of asking for help).
When I came across Zola (https://github.com/getzola/zola), I was immediately drawn by the single binary aspect.
I love Gridsome, and it had tons of potential, but it's effectively a dead project. The maintainers haven't cut a new release since November 2020.[0] There's barely been any feature work since 2019.[1] Their Github repos have tons of PRs that have not been reviewed. There are serious site-killing bugs that have not been fixed for over a year.[2]
I really wanted this project to succeed. I asked to sponsor the project and volunteered working on their documentation for a few months, but it didn't seem to yield any new dev work.
The maintainers are extremely talented, and this is not a knock against them, but I just caution anyone against marrying themselves to a framework that's unlikely to have any ongoing maintenance.
[0] https://github.com/gridsome/gridsome/releases
[1] https://github.com/gridsome/gridsome/graphs/code-frequency
[2] https://github.com/gridsome/gridsome/issues/1032
- https://github.com/netlify/netlify-cms
- https://github.com/strapi/strapi
- https://github.com/directus/directus
- https://github.com/tinacms/tinacms
- https://github.com/sanity-io/sanity
- https://github.com/wintercms/winter
- https://textpattern.com/
- https://github.com/Camberi/firecms (tied to firestore)
As recompense, some lesser known options for the frontend part of the JAMstack that weren't mentioned in the original post:
- https://github.com/getzola/zola
- https://hexo.io/
- https://www.getblades.org/getting_started.html
https://github.com/getzola/zola
https://mrkaran.dev/posts/migrating-to-zola/
I will say there is currently a lot of momentum behind other projects when it comes to the "out of box" themes that are available. I'd like to see more community maintained themes.
I made my templates and CSS (SASS) from scratch. I would have released them if they weren't so bespoke. I'd like to see some that make use of well-known CSS frameworks (eg. Bulma or Tailwind).
https://vishalsodani.com/programming/moved-to-zola/
30 seconds after posting the comment, I found this:
https://aur.archlinux.org/packages/pandoc-bin/
I don't know why I never tried to look for it. But I can attest to that fact pandoc + miniserve is a very interesting static site stack for those who want ultra simple.
https://aur.archlinux.org/packages/pandoc-bin/
[1] https://jaspervdj.be/hakyll/
I'm not sure quite what you think static site generators do if you're comparing them to a CDN, but they take a set of scripts, markup, images, and whatever else you care to mix in, and then emit a static site - just a bunch of HTML/CSS/JS/etc. You can host it on anything that supports serving static files - Google Cloud Storage works (especially when fronted by Cloudflare, data bandwidth between those two companies is cheaper), a random old server, etc.
You typically render it locally, then simply upload the changes to whatever you're using to host.
Not all websites (and not even all websites dealing with somewhat dynamic content such as blogs) need a full server stack, and the security of the server is far better if it's just serving files.
I transitioned my blog from Blogger (when they updated it last summer and absolutely ruined the core functionality of their editor, which is editing text) to a Jekyll-rendered site. It works out well, and I simply integrate a Discourse instance I run for a variety of things into the templates to have a functional comment section for posts.
Many sites don't need to be dynamically generated - they just need to provide some text and pics or whatever.
Some bonuses with non-dynamic - no worries if a php update fails - no worries if some other server side thing is broken - just serve files - no thinking.
Less worries about cpu overload - like having a dozen wordpres sites on a box - you can run into problems if one of those sites is getting hammered by login requests or similar - even if you 100% prevent them from logging in - you are still eating up php and what not which may affect your other dynamically generated sites on the server more than some static files that need to be pushed.
Of course you are right in that modern CDNs and cacheing make much of what used to be bigger problems more trivial in general..
A single site on a VPS less likely to be of concern compared to shared hosting or a dedicated box with several sites - in my experience - situations vary.
Haven't used it myself yet, just heard about it in John's Static Site Generation Corner on the Stacktrace podcast.
NotePad++
sublimeText
PineGrow - https://pinegrow.com
CoffeeCup (site designer, html editor, form makers) -https://www.coffeecup.com/
BlueGriffon is a static site maker even has wysiwyg - https://en.wikipedia.org/wiki/BlueGriffon / http://www.bluegriffon.org/
I loved making pages and sites with NetObjects fusion the most - it seems that PineGrow is the closest thing to that but modern.
There are also a couple of 'Wordpress goes Static' plugins ( https://wordpress.org/plugins/simply-static/ is one of them ) that can pipe out static html pages from a WP install - and they are handy for positives of having a static site - with the bonus of all the WP themes - of course doing that destroys the dynamic things you may want - site search, contact forms, comments - but handy for the right use case.
In a pinch it is sometimes faster to pop open notepad and paste in an html5 boilerplate add some text and save it - done.
It's quite trivial to pull in bootstrap, bulma or similar with an include line or two and start making a page / generating a static site.
I ended up using Pandoc and a Makefile. It works really well.
I'm cheering for it and I don't want to come off as discouraging for a product that I didn't pay for, but it has a long way to go. A lot of my work with it (but not all) was pre-1.0 though, so maybe it's improved.
https://github.com/react-static/react-static
The user entered <script> you should save that verbatim, but there are many output formats, HTML, SQL, PS (Post Script), XLS etc etc where you need to escape user provided values
To your original point, if you want something really simple this might work (haven't tried it, just found it on Google): https://github.com/gomarkdown/mdtohtml
And then for CSS, you could drop in something like this: https://github.com/andybrewer/mvp
Thanks, that’s what I meant, just didn’t think I needed to spell it out for this crowd :)
And this smaller one: https://github.com/collections/static-site-generators
https://jamstack.org/generators/
I wish we had a common specification around static-site generators though, something akin to CommonMark - so it was easier to switch between generators without having to spend time porting things around. The Jekyll directory structure for eg, is mostly respected various implementations - but it isn't a accepted everywhere for eg.