I am a crusty old (I mean punch card old) 'programmer', with multitude of languages under my belt. [theoretical proof that I should be able to do a static site with my one good eye closed.]<p>I love the concept.<p>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.<p>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.<p>I really believe that static site generators are lagging in adoption, because unclear documentation.
My ideal static site generator would have a locally run web app for editing files, styling content, etc. and then would just generate the static assets when you're ready to deploy. Not sure if anything like this exists currently or not.<p>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.
I love static site generators and I really wish more sites were built with them. There are likely millions of websites that have no login functionality or other functionality that specifically requires a back-end, but use a CMS anyway. Usually a CMS is slower for the users on the site, more expensive for the company running it, less secure, less stable, and more maintenance than a statically generated site.<p>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.)<p>[1] <a href="https://github.com/coderifous/jquery-localize" rel="nofollow">https://github.com/coderifous/jquery-localize</a>
<i>> Static site generators are significantly faster than dynamic websites because they run expensive computations beforehand and compile static files. First, let’s dig deeper into the first point. If you run a website with dynamic software like WordPress, there are multiple steps to send your content to the user.<p>…<p>> These steps take valuable time, and if they take too long, the user could leave before the content loads.<p>…<p>> 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.<p>> The solution is partial hydration, which allows you to define what you want to hydrate.</i><p>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.<p>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).<p>Just like how it’s easy to spot Electron based apps, it seems easy to spot JavaScript framework based sites too.
Static Site Generators (SSG) are not new. The SSG blog software <i>Moveable Type</i> launched in 2001 (written in Perl) and preceded WordPress. It featured a friendly browser-based editing, and a publishing experience suitable for all users.<p>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.<p>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.)<p>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.<p>Outside of developer circles, SSGs have had neglible impact on non-technical users.
SSG's feel like the first step towards something. Unless the website has really simple structure it likely that you will get stuck i) with sub-optimal content management (e.g using an IDE) and ii) a complex mess of mixing code and content, poorly documented and incompatible themes (my experience is with hugo)<p>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
> Not everyone who writes knows how to program too.<p>Aren't static generators much harder to grok for nonprogrammers than wordpress?<p>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
I use XQuery as static site generator. It is a w3c standard.<p>You just write the HTML and then it replaces $variables with data, e.g.:<p><pre><code> <html><head>
<title>{$title}</title>
</head><body>
<h1>{$title}</h1>
<div class="main">{$content}</div>
...
</code></pre>
It has for loops and functions, too
I'm currently in the process of moving my simple blog away from Ghost (formally WordPress) into a static HTML site. I can write HTML with my eyes closed and it's barely more inconvenient than Markdown, only I don't need some parser in the middle to complicate things. The most painful part of this is rewriting my content and moving the images etc across but it's more mundane than anything. Only dynamic part of the site is some simple includes for the header and footer. This is the way I used to run my site back in 1998 and it's far less troublesome. No security updates to worry about, no plugins, just straight up content.
Static site generation definitely predates Jekyl. If anything I think Jekyl would be better flagged in the timeline as the beginning of a renaissance for static site generation. I can think of two eras when it was in vogue before that<p>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.<p>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.<p>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.
Love SSGs too! Came here to share praise for Hakyll[1], for people with an FP leaning.<p>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.<p>[1] <a href="https://jaspervdj.be/hakyll/" rel="nofollow">https://jaspervdj.be/hakyll/</a>
My experience with SSGs was a mixed bag. I like the concept, but integrating with a headless CMS requires too much coding and simple things like page preview is a pain to setup and use. The existing headless CMSs leave a lot to desire in terms of usability (although, Strapi is not bad).<p>Static site generation should be simpler. Currently it's over-engineered.
I've made a simple php solution with markdown and blade templating. Newest post with two images fully loads in 1.88 seconds in Germany without a CDN running on 5$ linode in Tokyo.
No build steps and I just write .md files in the git repo. Static Site Generators are nice, but using fewer parts is also an option.
What would you recommend for a GUI interface to authoring a site based on Hugo<p>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.<p>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.<p>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.<p>Suggestions to check out?
I now use Zola with esbuild + postcss + tailwind, and with the new JIT tailwind, I got cold (not counting npm install) build under 500ms for large sites.<p>I run multitail with one watcher running zola server and the other one running esbuild.<p>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.
Found this - SSG - <a href="https://staticfire.site" rel="nofollow">https://staticfire.site</a>. More specifically this - <a href="https://staticfire.site/content/static_site/" rel="nofollow">https://staticfire.site/content/static_site/</a>
Nice article. WordPress and most of CLI solutions are covered well.<p>I missed though a bit on apps and alternative site generators like Lektor, Pinegrow and our app, Kit55 (<a href="https://stack55.com" rel="nofollow">https://stack55.com</a>).
Hey guys, anyone know if there is any server/webserver that can actually serve raw markdown files as html? I think Harp can do it but I was just wondering if there is anything else. Thanks.
If you know how to code, writing your own basic Static Site Generator can be a fun side project that shouldn't take too much time.<p>Bonus points if you auto-generate an RSS feed!
My ideal is a static site generator that has markdown as the input, a couple of data connectors (to things like Google sheets), and that can be "hosted" in GitHub. On commit, a Github Action would generate the static content.<p>We're close to that I think. Something like Hugo may already be there.<p>For the vast majority of WordPress or small business portfolio websites (beauty, building, etc) this would be perfect.
Funny, I wrote about this recently as well.<p>I'm a huge fan of SSG but concerned about the impact that it has on SEO and search engine quality.<p><a href="https://zestyrx.com/blog/nextjs-ssg" rel="nofollow">https://zestyrx.com/blog/nextjs-ssg</a>
I‘m going to make a case for one of the more complicated SSG setups.<p>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.<p>By using the Netlify free tier, my site gains free SSL and builds automatically when I push to master.<p>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.<p>Do you <i>need</i> this setup? No. But I had fun doing it.
> Hugo is usually around 6 times faster than Jekyll and is even faster compared to Next.js or other framework-based SSGs.<p>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?
For those who might want to explore SSG themselves here's a great directory: <a href="https://jamstack.org/generators/" rel="nofollow">https://jamstack.org/generators/</a>
I just skimmed the article. Was 11ty ever mentioned?
That looks to me like one of the easiest to start with and it has some pretty advanced features also.
Huge fan of statically generated pages. We statically generate all our pages at Levels.fyi. Another benefit is that static websites are also great for SEO. Cool to see a lot more adoption and progress around the tech here. For example, once you reach tens of thousands of generated pages it can get a bit hard to maintain, but tools such as Next's incremental static regeneration make things a bit easier: <a href="https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration" rel="nofollow">https://nextjs.org/docs/basic-features/data-fetching/increme...</a>