State of the Web: Static Site Generators
byteofdev.com
byteofdev.com
I love the concept.
That said, I do have a bone to pick with the listed generators. They over complicate or fail to explain the site development and the documentation is often a twisted nightmare.
It is absolutely true, that if I could get the site generated as I want it, it would be less cost for the server, faster, and so on as described.
I really believe that static site generators are lagging in adoption, because unclear documentation.
I'm of the mind that if you want a static site generator, then... you should just build one yourself! Something completely tailored to you can be built in about the same time that it'd take to figure out how tf to get the features you want working with whatever static generator that's popular right now.
I was tired of having to learn how each SSG worked so I ended up writing my very-specific-for-my-needs one in an afternoon (and polishing in a few days more)[0]
Surprisingly, my SSG is starting to look like those SSG I didn't want to use. Is it the natural evolution or am I being biased after years of reading lots of SSG docs? :-)
Incidentally, I really would like some kind of free offline WYSIWYG html editor for the body of pages, if anyone has a suggestion? I've looked but all the simple ones seem to require JavaScript knowledge? I just want to make content :(
The tooltips and dialogs are all empty on macOS (the latest Big Sur).
Pick your favourite programming language, load some files, do string.replace(), job done.
If you have any specific needs that you'd rather not compromise on then I agree completely, and do in fact have a plan to make my own. I expect it'll be quicker than trying to panel beat somebody else's into submission.
There is no middle ground - all the existing ones are either simple and/or strongly opinionated (great if you are happy with the fixed style and features) or so flexible and complex that it'll take to many plugins and hours poking it and it's documentation that you are practically programming the whole site anyway.
> Something completely tailored to you can be built in about the same time
And if you have any complex ideas you can develop it piecemeal instead of needing to think about everything in detail from the start to make sure the framework truly supports what you want (without you having to write a custom plugin) and you aren't starting in a way that'll make features difficult to add in later.
I don't really think that what I'm doing is making a static site generator, certainly not a generic one. I'm creating a dynamic but slowly changing site with a very strong caching layer.
> with whatever static generator that's popular right now
A key advantage of using an existing SSG is that you essentially get free upgrades from time-to-time, useful if the new features/options are actually useful or otherwise desirable to you. But that only works if the one you pick is one that survives the churn long term.
"Right now" is also key though. I might use one of the simple opinionated SSGs first with a view to getting some stuff out quickly and convert over later. Or I may just make a fully dynamic setup and convert to static if there is any chance the content is popular enough that the resource saving & response time benefits matter at all.
Jekyll however was a pleasure to use and I got the results I wanted in an afternoon.
So in a sense you're correct, it does generate a React app, but it is also true that a Gatsby site works like any other SSG'ed website when you don't have JS enabled. Arguably it's the best of both worlds. It's classic progressive enhancement.
The downside is that it makes the code more complex.
Gatsby does have other rendering options as well - https://www.gatsbyjs.com/docs/conceptual/rendering-options/
And progressive enhancement is kind of a solution looking for a problem, there are a lot of low hanging perf fruits you can pick before considering PE.
Progressive enhancement is a solution to the problem of giving users the best experience possible without serving unnecessary code, or breaking the site, for users who don't have the capability to run particular features. It's not a perf thing. It's a features thing. And it's a very real problem (see every site that only works in Chrome for details.)
There are some issues to iron, but it's functional.
I mean, we live in an age, where, if Medium says that something is >7min read, no one reads stuff, and everyone uses videos to give, and consume, information.
I wrote a fairly ambitious infrastructure system, and spent months writing detailed, accurate, relevant, documentation.
That no one ever read.
It wasn't until I transferred the system over to a new team, who started posting videos on Facebook, that it started to take off. It's now the de facto world standard. Documentation is important, but so is the medium.
Sheesh. Kids, these days (Get off mah lawn!).
I write about how I do documentation, here (I need to update for DocC): https://littlegreenviper.com/miscellany/leaving-a-legacy/
It's definitely a >7min read.
I do see many static site generators as something that requires that you are a developer. At least you must understand html and templates (and folders and markdown) but often you end up doing things that are basically just programming.
Static sites are nice from a deployment perspective, but CMS's make a lot of things easier than static site generators do. Seems like there's room to have the best of both worlds.
thank you, that was my experience too.
as a web developer, my primary concern is the users who provide content for a site (including myself).
i have only actively worked with hugo myself and i was disappointed by its complexity.
there are only a few situations where a static site generator is helpful.
one is a distributed team of teach-savy volunteers. here it means that i can submit occasional changes to a site as a patch.
however, the group of people that will benefit from this is limited. and the benefit does not come from the fact that the site is made with an SSG but that the content is stored in a text based revision control system. the friction in such a situation is access control and not deployment. one could easily imagine a dynamic site that pulls its contents from a text based source and still get the same benefits.
They tried to convert the base to the mainstream PHP framework called Symphony - but there is still too much "PHP Think" in the code, lessons of modern web development never learned, abyss of bad practices.
Also Symphony is more of a joke copy of frameworks from other languages, e.g. often security problems in auth code after many years of development, like the coders simply do not understand what they are doing - you should not rely on that as a base. People speaking of Symphony as a "quality framework" have not worked in different IT areas or with different languages most often - it is mainly a small group of french developers that depend on the popularity of Symphony and keep up a cult, but it is still a joke.
If you are a customer and somebody is offering you a product based on Drupal, save yourself some horror.
Good people simply have left the PHP world a long time ago and moved on to different languages and frameworks. What you get today as "PHP Developers" is the underdogs, the people, that can not get good jobs with better quality work experience missing, mostly people from the global south or eastern europe that have been misused for many years by companies that wanted to save a lot of money on "cheap coders" to sell bad products.
Wordpress is still no shining example of good PHP, but somehow the company Wordpress managed to establish a not too bad ecosystem, still miles ahead of what Drupal is - so if you are forced into PHP, Wordpress with near to zero plugins plus the great static export plugin will give you best results.
It doesn’t have a front end for authoring pages, styles, etc, but that could be built on top of this library.
After creating a site you start a local server by executing "lektor run" in the local folder, then preview the site in your webbrowser. There you get a edit-button whivh opens a backend with which you can edit the website. From that backend you can hit an upload button which allows you to push the static site directly to a remote (e.g. via scp).
Multilanguage support works quite good as well.
On the surface it seems like a pretty roundabout way to work, but the static generation side of things works well. Not quickly (well, not Hugo-quickly).
I quite liked it but development tailed off after a couple of years so I imagine it failed in the marketplace.
[1] https://www.joelonsoftware.com/2001/10/12/what-does-citydesk...
[1] http://runtimeterror.com/devlog/
[2] http://runtimeterror.com/pages/badsector/nyan/gimme/cdsite/
The whole template problem, along with customization (or is it configuration?) is the biggest blocker for me. I'm going back to a straightforward Markdown-like to HTML generator for my next blog revision.
How you generate the content is a separate question. It's quite common to use WordPress as a CMS (because the content people already know it), and then pull the content in to something like 11ty or Gatsby to bake to files and put on a server.
A few years ago I wrote a static generator for Ghost. The workflow was the following:
- A Ghost instance runs on my raspberry pi
- I log into it to write content, and save
- A hook is triggered by the content update (this is a native Ghost feature), that sends an HTTP request to a local ExpressJS instance
- A script downloads the whole dynamic Ghost site as static files, fixes the links, and then publish them somewhere
It was _very_ brittle but it worked for my use case.
You have one Wordpress instance completely internal, safely hidden behind a VPN, get all the convenience of Wordpress, and each time you publish a change in an article it will publish the static site.
Everything was generated on the server but only static pages was served to visitors.
I currently use pelican since i'm ok drafting my stuff in markdown...but I used to use lektor alot...and every person - techie or non - that i've shown Lektor (back when i used it myself) loved lektor! Since that time i'm sure there are other SSGs that operate like lektor.
I do think there's still plenty of room for improvement for static site generators though. Does anyone have any recommendations for an SSG with easy support for multi-lingual websites? Ideally, I'd be able to translate the text and provide alternative images, videos, and links without having to change the HTML structure of a given page for each language. Technically, this can be done easily with JavaScript by using a plugin like jQuery Localize [1], but that has two major downsides: (1) all other languages except the default breaks if JavaScript is disabled and (2) users won't know that the site supports their language from search engine results (the snippet will be in the default language.) So it'd be great if I could write the pseudo HTML of a page once, but generate multiple HTML files for each different language (placed into their respective directory, e.g. en/, es/, fr/ etc.)
Most of the business website providers out there, like Wix, seem to be all-in on CMS systems.
Is there a low-code way to get started?
Business website providers use CMSes with databases in part because they support full on WYSIWYG editors in the browser, among other things.
For content, you basically put blogarticle.en.md and blogarticle.fr.md next to each other it will treat it as the same article in different languages. Per default it puts different language websites into different subdirectories (with a default language at root level) but it also supports multi hosts setups where you can define different domains for each language (e.g. blog.de and blog.fr). There's support for generating "this article in other languages" type menus, which allows you to crosslink the website across languages. There's also i18n support for translating stuff in templates etc., where you provide a dictionary file with translated versions of each string, and it'll replace them based on the language of the current article (useful for stuff like navigational menus etc.).
…
> These steps take valuable time, and if they take too long, the user could leave before the content loads.
…
> If you use one of the SSGs that use a JavaScript framework, you are likely sending unnecessary JavaScript to the client. However, partial hydration can solve this. To understand why, let’s first look at what hydration is. Most JavaScript frameworks run code on both the build step and the client. The build step creates the HTML. However, interactivity is still needed. To solve this, they use hydration. Hydration uses client-side JavaScript to make static HTML interactive. Sounds good, right? The problem is that frameworks often send code for parts of the HTML that are not interactive. Doing that slows down page loading without actually changing anything.
> The solution is partial hydration, which allows you to define what you want to hydrate.
So if you started out with performance as a key measure and moved to SSGs (despite the usage being more complex compared to a GUI based CMS), with the JavaScript framework based SSGs (not to be mixed up with simple JavaScript/Node based ones) that use/prefer client side rendering and hydration you now have poorer performance for a lot more complexity in designing the site and building it.
Somehow it feels like the JavaScript framework based SSGs are poorer on many fronts, and seem to give me the impression that they could appear slower to the end user browsing the content (I hate seeing empty placeholders with animations while they wait for the content to be rendered).
Just like how it’s easy to spot Electron based apps, it seems easy to spot JavaScript framework based sites too.
Build or use a headless CMS for pure content management, have a preview build (client side rendered) of your site to see the changes instantly. Then trigger releases for optimized, static builds.
For me this is a quality improvement in terms of performance and security and a DX improvement in terms of extensibility and separation of concerns. But again, requires one to make a bunch of decisions and plumbing so everything plays nice and coherent.
Moreover, Nextjs's devs are increasingly ignoring that use case to the point where it is unclear if you'll hit a roadblock where you can't update anymore because the required amount of hacking is just too much to continue using it like that.
https://github.com/city41/neo-geo-dev-book/blob/main/src/pag...
Here is that page: https://neogeobook.mattgreer.dev/
It is, even on good connections and using new hardware, they'll load slightly slower than bare HTML pages. The latter will finish rendering before you're even aware that it loaded. I've run into many simple blogs that won't load at all without JavaScript.
It isn't just blogs either. I inherited a static site from a client that ran a real estate development business, and it wouldn't load without JavaScript. If you opened it on a phone or tablet you'd see a loading screen for 5+ seconds. The site just had some images and text.
This article omits an important aspect of popular SSGs and the 'Jamstack': they are not easy-to-install or easy to use by non-technical users.
Some of the most popular SSGs are surprisingly complex despite claims to the contrary. (A simple contact form is impossible in many SSGs without embedding third-party services.)
Also, the love of Markdown is not shared by anyone who isn't a developer. Step outside of basic Markdown and it becomes unpleasant to use and cumbersome. It's even harder for non-technical users - try adding a table using Markdown.
Outside of developer circles, SSGs have had neglible impact on non-technical users.
I don't think so. Publishers are leaning heavily into SSG to improve SEO: https://zestyrx.com/blog/nextjs-ssg
But those are not arguments to go back to using a database when it is clearly not needed, but rather to evolve tools, documentation, theme design principles etc to eliminate pain points
Aren't static generators much harder to grok for nonprogrammers than wordpress?
This is a non-problem. The problem is not wordpress. The problem is that modern browser programming, and modern javascript in particular are way more complicated than they need to be for lay people to build their own websites as they did in the good old days. That's why everyone moves their communities in discord instead of building a self-hosted forum. We need to be talking about how to make the browser an accessible platform for everyone again (including moms and pops, remember Frontpage?). NOT to keep over-complicating even the smallest tasks and build frameworks that only benefit the BigCorps
You just write the HTML and then it replaces $variables with data, e.g.:
<html><head>
<title>{$title}</title>
</head><body>
<h1>{$title}</h1>
<div class="main">{$content}</div>
...
I searched around and found this article: https://www.gnu.org/software/qexo/XQ-Gen-XML.html
And here is the source of my website using it: https://github.com/benibela/site
To give an example, my team was doing this in the early 00's on some major brand websites to eek performance out of stacks originally built on either PHP or Perl with MySQL Cluster (as in NDB) as the backend.
We fired crawlers both on article creation and periodically overnight that browsed the dynamic site dumping out to a static "cache". Initially this was html chunks which was bolted together by Apache SSI includes. (eg header, footer, menu, content, and a wrapper). Later that evolved in to storing in Memcached with a simple Memcached implementation frontend wrapper to cache on demand.
If I wind my memory back even further to late 90s early 00s I remember pre-Web2 tools that would give you a local desktop based CMS and site generator that pumped out flat files and pushed over FTP. These were especially commonly used by graphic designers making the transition from print design to web for things like brochure sites.
In the early days, it seemed like static sites were for programmers who didn't really understand the web, or only had hosting for static content.
Predictably, it's not easy to get started, but once you're into it the power of building your own arbitrary content "compilers" (and template extensions etc etc) is pretty impressive.
Static site generation should be simpler. Currently it's over-engineered.
I put together a Hugo site, where the site is automatically deployed to Render (similar to Heroku) whenever a commit is made to the GitLab repo.
While I am "ok" using Obsidian + WorkingCopy (iOS git client) on my phone to update the site - its clunky but works- is not acceptable to less-technical people.
I want the benefits of a site based on plaintext Markdown, but want something that approaches the ease of jamming out a doc on Google Docs, Notion etc, dropping images into the content, etc.
Suggestions to check out?
I run multitail with one watcher running zola server and the other one running esbuild.
It is the first time since a long long time that I have a js/css build system that is not impossibly complicated to grasp. I do use a few postcss plugins, but all with default configuration (except tailwind). I did them all, grunt, gulp, bower, webpack... always a nightmare.
That’s exactly the question I would search in google to get started. Then when another question pop up in my mind, I would also google it. Keep doing that until you start building a better mental model & before you know it, You are reading tutorials & getting started.
At least that how I do it.
Follow this extremely simple guide & project for a basic free ssg site. I use plain html & Jekyll, two different ones. I have no experience except simple html, css, js & markdown.
It has been discussed previously on HN ( https://news.ycombinator.com/item?id=22226380 )
Think of it as a text-only way of moving around and looking at directories/folders inside your computer - you start off in some directory and can move to other ones. In side each directory you can do really basic things like just list the files there, or rename them or move them etc. Just like you can in the GUI.
Where the command line gets powerful is that as well as manipulating files you can run arbitrary "commands" - i.e. you can run programs like you can by double-clicking an icon - AND you can start to do smart stuff like sending the output of one command as the input to another.
So you can do things like sort all of the lines in a text file in alphabetical order, remove duplicates, then count the number of lines with the command line in a couple of seconds, where as in the GUI you'd probably end up pasting the text file into a spreadsheet or something I guess.
Look for "terminal" or "CMD" in Linux/osx or Windows and have a poke around by moving through directories and listing files etc, checking against the GUI as you go. Eventually you'll get an intuition for using it.
Good luck!
That will get you started getting comfortable moving around and doing things, but it doesn't go further than the absolute minimum. It will at least get you started and hopefully slightly comfortable if you need to use the terminal for anything else in the future as that is where the real learning comes from. E.g. following a tutorial and they say "type this in the command line" you are now at least a little familiar with it and can google the rest.
Have fun.
But if instead you want to play around with SSGs, just go ahead and play with SSGs.
If you just want a simple site with a handful of posts a year then manually making .html files with an WYSIWYG editor or just copying old HTML/CSS templates from site likes "alistapart" is a legitimate, simple option. Installing nginx from your system repos is safe and easy too but if you don't want to self host then https://neocities.org/ is decent.
Currently dealing with a snobbish painter/graphic designer who has used Microsoft Frontpage and Adobe Muse for over 20 years and just wants their GUI WYSIWYG back.
My thinking: if I understood basic concepts and philosophy of coding and how the "the web works," I'd be able to build build myself a simple blog, simple website, but also be less beholden to Zuck and Google platforms. Obvs I'd still be using some of it, but I'd just have more choices.
Or if they are using a Mac, just give them RapidWeaver.
Just give them visual tools like Webflow, Blocs.app, Bootstrap Studio or even WordPress (now a complete visual page builder, from version 5.9 onwards).
I don't want to use a theme at all because I don't really use it for making posts, but just a website with different pages. I have a page template that pulls in my head, nav, page content, and footer.
You can see an example here: https://github.com/etheralpha/clientdiversity-org/blob/main/...
Pretty basic stuff but when I checked out Hugo I was having the hardest time trying to figure out how to do it.
[edit] I just want to add - pay attention to the content “type” in relation to creating a template and specifying the type in the frontmatter. https://gohugo.io/content-management/organization/#type may point you in the right direction. You can manifest your own type by creating a template in the correct layouts dir and then specifying that type in your frontmatter.
The Go templating of Hugo is extremely confusing for most non-Go people. After using it for years I still constantly look up how to do simple conditionals.
11ty is a very competent, "good enough" generator. We used it to build this site[1] for CERN back in 2019 from scratch over the course of a few days.
The only tool I'm aware of that can (mostly) correctly reformat Django templates is the PyCharm/IntelliJ family of IDEs, but their reformatting often introduces subtle breakage (such as adding new lines inside tag attributes) and requires careful review.
I missed though a bit on apps and alternative site generators like Lektor, Pinegrow and our app, Kit55 (https://stack55.com).
(Amusing note: Hexo and Zola both have a heading on their home pages “blazing fast”. I think they’re both wrong.)
75 pages should never take several seconds. Or even "under a couple of seconds". It should bot even register in the radar.
I was assuming it would be more CPU- than I/O-bound, because hopefully we’re all using SSDs these days, and because Hexo’s website uses similar time figures in its preposterous “blazing fast” description.
shakna’s gone too far the other way (a couple of seconds for a load like this (~80 file reads, processing, ~80 writes, all of the files under 64KB) is easily enough that if it’s measuring I/O latency there’s either something wrong with your machine or you have a slow HDD and wrote your I/O code the wrong way), but my 200ms certainly already reaches the point where CPU, disk and OS/antivirus solution all matter significantly.
https://caddyserver.com/docs/caddyfile/directives/templates#...
Caddy's entire docs are powered by this kind of templating, it's quite useful: https://github.com/caddyserver/website/blob/master/src/docs/...
So how does Caddy accomplish this sort of processing? Just somehow on-the-fly converts to html? Anyway I’ll check it out— would have to also figure out theming/templating if there is also basic functionality for that..
Also this gives me another idea that is going to sound weird. But given this new info, I’m thinking of hosting Caddy+some_md_content on Replit hosting (as Replit can host any Go application (or virtually any language I believe)). This way I can use the Replit web UI if I want, to create md/posts, and then Caddy-on-top-of-replit will serve the page.
Is this weird? I think it’s feasible right? I could/should also put Cloudflare in front perhaps in case of unexpected traffic as Replit’s free tier doesn’t provide a ton of transfer o don’t believe..
Bonus points if you auto-generate an RSS feed!
I know the cliché is that there are too many web frameworks. But give it a shot. Don't ask others people to use it, make it opinionated and use it yourself.
I want to build this blog generator using python, markdown, jinja and 'chose a classless css yourself'. Jinja is the templating engine, it is super fast and fun to use. If I weren't procrastinating I could ship it under a week. But I think it would be a fun project to do in Typescript if I ever decided to learn it first!
We're close to that I think. Something like Hugo may already be there.
For the vast majority of WordPress or small business portfolio websites (beauty, building, etc) this would be perfect.
The current crop of SSG's will have no impact on WordPress because they are only available through the command line. Normal people have no interest in learning how to use the terminal nor how markdown works.
I run a couple of charity's websites on their own custom domains from GitHub. The charity workers use github's web UI to edit the markdown and submit, and it automatically rebuilds the site quickly (O(minutes))
I'm a huge fan of SSG but concerned about the impact that it has on SEO and search engine quality.
My current domain is a full blown Next.js setup hosted at Netlify. I use Next.js because I use React in my day job and frankly, I enjoy it. Out of Next I get: partial hydration, automatic image optimization, a no-bullshit build setup, static pages where I need them and the ability to add complex things like Markdown and LaTeX support or interactive graphs for more involved blog post. The real winner is MDX. Where I had to resolve to cheap tricks like shortcodes before, I can just import and place my graph components.
By using the Netlify free tier, my site gains free SSL and builds automatically when I push to master.
You would think this is insanely heavyweight for a basic homepage, but it’s not. Once setup, I can just write my blog in markdown. My entire site ships at just a bit over 50KB gzipped.
Do you need this setup? No. But I had fun doing it.
Just 6 times? That sounds not much for a rewrite from Ruby to Go. Is this one of those things that's mostly IO-bound?