30 ms·

State of the Web: Static Site Generators

161 points by AsyncBanana 5y ago

miki_tyler 5y ago
Nice article. WordPress and most of CLI solutions are covered well. I missed though a bit on apps and alternative site generators like Lektor, Pinegrow and our app, Kit55 (https://stack55.com https://stack55.com).
- cyberge99 5y ago
  I would add Hexo to that list if generation speed is important. My site generates in 2-3 seconds and there are about 75 pages.
  - chrismorgan 5y ago
    2–3 seconds for 75 pages is not at all fast. My own Zola-powered site with unusually complex templates and emitting a bunch of large feeds takes under 200ms for that many pages; and Zola is not really architected to be fast (it’s more just incidentally comparatively fast because of Rust)—a static site generator actually designed for performance could certainly handle a site like that in well under fifty milliseconds with no loss of ergonomics, and I think five milliseconds with potential slight loss of ergonomics is feasible. (Amusing note: Hexo and Zola both have a heading on their home pages “blazing fast”. I think they’re both wrong.)
    - shakna 5y ago
      Once you get below a couple seconds, you're unlikely to be measuring the speed of the SSG, you're measuring I/O latency. Suggesting it could be faster or slower is pointless unless you have identical hardware. The same disks, CPU, and RAM, the same OS, down to the kernel version. The same running processes.
      - dmitriid 5y ago
        Even a 5400 rpm hard disk delivers reads in the hundreds of megabytes per second. 75 pages should never take several seconds. Or even "under a couple of seconds". It should bot even register in the radar.
        chrismorgan 5y ago
        Hundreds of megabytes per second is decidedly on the high side for such a device to begin with, but it only holds for big sequential writes. For random I/O, which is what this is, you’re more likely to average 0.5–5MB/s plus latency. 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.
  - miki_tyler 5y ago
    In my opinion there are other things that are probably more important besides speed for medium size sites, like SEO optimization, ADA compliance or multilingual support.
taurusnoises 5y ago
I so wish I was code savvy enough to build a simple blog site on Hugo or one of the other SSGs. (sigh)
- loloquwowndueo 5y ago
  You don’t need to code to get started with Hugo. You just copy some template files around, write your pages using any text editor in the very simple markdown format, run Hugo in the command line, and get html files ready to upload. None of this is actually “code”.
  - taurusnoises 5y ago
    I'm ridiculously noob with all this. Trying to teach myself. I don't even know what a "command line"is. It's a wonder that I keep up with anything at all on here!(though I'm trying).
    - lhuser123 5y ago
      > what a “command line” is. 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.
      - taurusnoises 5y ago
        I was teaching myself about Git today, and it's hilarious the Google threads I develop. "Git is a Distributed Concurrent Versions System." OK what's a "Distributed Concurrent Versions System"? Hmmm OK what's a "Concurrent Versions System?" hmm OK what's a "Version system?" googling is helpful af, but at some point I need a human interaction for real time questions. Slowly but surely.
    - davchana 5y ago
      https://gitlab.com/pages https://gitlab.com/pages 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.
jeffreyrogers 5y ago
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. 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.
- XorNot 5y ago
  I've been using Nikola which can publish Jupyter notebooks - which turns out to provide most of the functionality I actually want (previews, graphs, drag and drop image inclusion).
- miki_tyler 5y ago
  As I mentioned in another comment somewhere else in the thread, there are a few apps (Lektor, Kit55, Pinegrow) that do exactly that.
  - veb 5y ago
    There's also Cloudcannon! https://cloudcannon.com/jekyll-cms/ https://cloudcannon.com/jekyll-cms/
- deleted 5y ago
  [deleted]
- soheilpro 5y ago
  You can use tools like staticgen [1] with any CMS that you want. [1] https://github.com/tj/staticgen https://github.com/tj/staticgen
- promiseofbeans 5y ago
  Astro is working on something that lets you edit and preview markdown files locally via a web based WYSIWYG editor.
- porphyra 5y ago
  Many static site generators are so fast that you could use, say, the unix `watch` command to rebuild your website every two seconds while running an `http-server` locally to preview the results. And then just rsync the artifacts when ready to deploy.
aidog 5y ago
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.
- ivanmontillam 5y ago
  So, is it just flat-file CMS like Grav?
selfmodruntime 5y ago
I‘m going to make a case for one of the more complicated SSG setups. 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.
- deleted 5y ago
  [deleted]
AnonHP 5y ago
> 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. … > 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.
- floodle 5y ago
  I'm confused by what your baseline is here. What are you comparing JavaScript framework SSGs to?
  - AnonHP 5y ago
    The ones that build the site server side completely (including the ones that are JavaScript based, but not the ones that are JavaScript framework based that tend to move certain parts to the client).
johnfernow 5y ago
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. 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.) [1] https://github.com/coderifous/jquery-localize https://github.com/coderifous/jquery-localize
- tomrod 5y ago
  Naive question from a beginner in this space. 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?
  - miki_tyler 5y ago
    What do you mean with low code? HTML + CSS only?
  - Mikeb85 5y ago
    Static site generators generally only require tiny amounts of scripts to get going and you just write markdown. You can use pre-made themes so no knowledge of HTML or CSS needed. Business website providers use CMSes with databases in part because they support full on WYSIWYG editors in the browser, among other things.
zuhayeer 5y ago
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: https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration https://nextjs.org/docs/basic-features/data-fetching/increme...
indigodaddy 5y ago
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.
- yanmaani 5y ago
  What is a "md5 file"?
  - indigodaddy 5y ago
    Sorry meant to say md (markdown). Edited my comment.
- thunderbong 5y ago
  Caddy server does this. https://caddyserver.com/docs/caddyfile/directives/templates#examples https://caddyserver.com/docs/caddyfile/directives/templates#...
  - indigodaddy 5y ago
    Holy crap I had no idea, wow!
    - unfocussed_mike 5y ago
      Possibly the reason why you had no idea is that Caddy -- while legitimately amazing -- has documentation that feels something like you're playing a 1980s text adventure, stuck in a maze of twisty tunnels.
  - mholt 5y ago
    Yep, just enable templates with the 1 line of config and then put {{markdown "here"}} in your web pages and there you have it. Caddy's entire docs are powered by this kind of templating, it's quite useful: https://github.com/caddyserver/website/blob/master/src/docs/index.html https://github.com/caddyserver/website/blob/master/src/docs/...
rammy1234 5y ago
Found this - SSG - https://staticfire.site https://staticfire.site. More specifically this - https://staticfire.site/content/static_site/ https://staticfire.site/content/static_site/
WaitWaitWha 5y ago
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.] 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.
- goostavos 5y ago
  The documentation problem is because they're trying to be everything for everyone imo. You end up with this bizarre labyrinth of conventions (and extension points) for which the only way to navigate is the documentation (and the documentation is unclear, so...) 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.
  - deleted 5y ago
    [deleted]
  - luismedel 5y ago
    This. 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? :-) [0] https://github.com/luismedel/clarin https://github.com/luismedel/clarin
  - throwaway984393 5y ago
    One of the most annoying things about computers to me is that they require constant maintenance. I don't want to do maintenance anymore; I want a mechanic to do it for me. I have built my own bed, desk, shelves, serving trays, fixed my own cars, plumbing, electric, screens, hinges, walls, drawers, tended my own garden, and wrote my own software. The garden is the only thing I still enjoy maintaining. So I use a SSG. They fix bugs and add features and patch security holes and do releases, and I just download and run it. 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 :(
kuon 5y ago
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. 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.
jay_kyburz 5y ago
Anybody remember CityDesk.
- jay_kyburz 5y ago
  https://www.joelonsoftware.com/2001/10/12/what-does-citydesk-do/ https://www.joelonsoftware.com/2001/10/12/what-does-citydesk...
buro9 5y ago
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. 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.
- tonyedgecombe 5y ago
  >For the vast majority of WordPress 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.
  - marc_io 5y ago
    I could be wrong, but I think Publii is the only SSG that doesn't work from the command line and is specifically targeted at end users.
- mattlondon 5y ago
  GitHub already does this for Jekyll automatically. 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))
open-source-ux 5y ago
Static Site Generators (SSG) are not new. The SSG blog software Moveable Type launched in 2001 (written in Perl) and preceded WordPress. It featured a friendly browser-based editing, and a publishing experience suitable for all users. 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.
- camillomiller 5y ago
  I would also point out that by means of heavy caching Wordpress can solve all the performance issues indicated by the author as the main advantage of SSGs. In my opinion opposing Wordpress and dynamic CMSs to SSGs is the wrong way to frame the topic. They have different applications, especially if you’re doing client work.
- mrctte 5y ago
  > 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 https://zestyrx.com/blog/nextjs-ssg
cblconfederate 5y ago
> Not everyone who writes knows how to program too. 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
hellweaver666 5y ago
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.
declnz 5y ago
Love SSGs too! Came here to share praise for Hakyll[1], for people with an FP leaning. 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. [1] https://jaspervdj.be/hakyll/ https://jaspervdj.be/hakyll/
nathias 5y ago
missing eleventy
simonjgreen 5y ago
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 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.
- physicsguy 5y ago
  Yeah definitely. I did some work with a really ancient Python SSG called rest2web that was around since ~2004ish, so several years before Jekyll even started
- eloisant 5y ago
  Yes, I feel like Jekyll was the first to make static sites "cool". Maybe because of github that made it super easy to create a site based on Jekyll, without having to compile it locally then upload to FTP or whatever. 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.
harryvederci 5y ago
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. Bonus points if you auto-generate an RSS feed!
- anyfactor 5y ago
  This is exactly what I wanted to do. This idea has been sitting on my sideproject to do list for a while. 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!
Zababa 5y ago
> Hugo is usually around 6 times faster than Jekyll and is even faster compared to Next.js or other framework-based SSGs. 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?
pointlessone 5y ago
For those who might want to explore SSG themselves here's a great directory: https://jamstack.org/generators/ https://jamstack.org/generators/
dgudkov 5y ago
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). Static site generation should be simpler. Currently it's over-engineered.
calltrak 5y ago
mrctte 5y ago
Funny, I wrote about this recently as well. I'm a huge fan of SSG but concerned about the impact that it has on SEO and search engine quality. https://zestyrx.com/blog/nextjs-ssg https://zestyrx.com/blog/nextjs-ssg
streamofdigits 5y ago
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) 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
- marcos100 5y ago
  You forgot iii) and you'll want write your own ssg, just because.
- pclmulqdq 5y ago
  I have been using Hugo for a new blog I am starting, and I have to say that it would be a lot better if the CMS was something like notion. Using an IDE will definitely have some growing pains past 100 posts.
benibela 5y ago
I use XQuery as static site generator. It is a w3c standard. 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> ... It has for loops and functions, too
- messo 5y ago
  Wow, did not know about XQuery. Can you point to some resources explaning how one would use it as a SSG?
  - benibela 5y ago
    I only read the specification. It covers every there is in XQuery I searched around and found this article: https://www.gnu.org/software/qexo/XQ-Gen-XML.html 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 https://github.com/benibela/site
    - messo 5y ago
      Thanks, this is fascinating!
msh 5y ago
Sometimes i miss the simple elegance of tools like city desk.
dv35z 5y ago
What would you recommend for a GUI interface to authoring a site based on Hugo 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?
jbergens 5y ago
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.

161 points by AsyncBanana 5y ago

Nice article. WordPress and most of CLI solutions are covered well. I missed though a bit on apps and alternative site generators like Lektor, Pinegrow and our app, Kit55 (https://stack55.com https://stack55.com).

cyberge99 5y ago
I would add Hexo to that list if generation speed is important. My site generates in 2-3 seconds and there are about 75 pages.
- chrismorgan 5y ago
  2–3 seconds for 75 pages is not at all fast. My own Zola-powered site with unusually complex templates and emitting a bunch of large feeds takes under 200ms for that many pages; and Zola is not really architected to be fast (it’s more just incidentally comparatively fast because of Rust)—a static site generator actually designed for performance could certainly handle a site like that in well under fifty milliseconds with no loss of ergonomics, and I think five milliseconds with potential slight loss of ergonomics is feasible. (Amusing note: Hexo and Zola both have a heading on their home pages “blazing fast”. I think they’re both wrong.)
  - shakna 5y ago
    Once you get below a couple seconds, you're unlikely to be measuring the speed of the SSG, you're measuring I/O latency. Suggesting it could be faster or slower is pointless unless you have identical hardware. The same disks, CPU, and RAM, the same OS, down to the kernel version. The same running processes.
    - dmitriid 5y ago
      Even a 5400 rpm hard disk delivers reads in the hundreds of megabytes per second. 75 pages should never take several seconds. Or even "under a couple of seconds". It should bot even register in the radar.
      - chrismorgan 5y ago
        Hundreds of megabytes per second is decidedly on the high side for such a device to begin with, but it only holds for big sequential writes. For random I/O, which is what this is, you’re more likely to average 0.5–5MB/s plus latency. 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.
- miki_tyler 5y ago
  In my opinion there are other things that are probably more important besides speed for medium size sites, like SEO optimization, ADA compliance or multilingual support.

taurusnoises 5y ago

I so wish I was code savvy enough to build a simple blog site on Hugo or one of the other SSGs. (sigh)

loloquwowndueo 5y ago
You don’t need to code to get started with Hugo. You just copy some template files around, write your pages using any text editor in the very simple markdown format, run Hugo in the command line, and get html files ready to upload. None of this is actually “code”.
- taurusnoises 5y ago
  I'm ridiculously noob with all this. Trying to teach myself. I don't even know what a "command line"is. It's a wonder that I keep up with anything at all on here!(though I'm trying).
  - lhuser123 5y ago
    > what a “command line” is. 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.
    - taurusnoises 5y ago
      I was teaching myself about Git today, and it's hilarious the Google threads I develop. "Git is a Distributed Concurrent Versions System." OK what's a "Distributed Concurrent Versions System"? Hmmm OK what's a "Concurrent Versions System?" hmm OK what's a "Version system?" googling is helpful af, but at some point I need a human interaction for real time questions. Slowly but surely.
  - davchana 5y ago
    https://gitlab.com/pages https://gitlab.com/pages 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.

jeffreyrogers 5y ago

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. 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.

XorNot 5y ago
I've been using Nikola which can publish Jupyter notebooks - which turns out to provide most of the functionality I actually want (previews, graphs, drag and drop image inclusion).
miki_tyler 5y ago
As I mentioned in another comment somewhere else in the thread, there are a few apps (Lektor, Kit55, Pinegrow) that do exactly that.
- veb 5y ago
  There's also Cloudcannon! https://cloudcannon.com/jekyll-cms/ https://cloudcannon.com/jekyll-cms/
deleted 5y ago
[deleted]
soheilpro 5y ago
You can use tools like staticgen [1] with any CMS that you want. [1] https://github.com/tj/staticgen https://github.com/tj/staticgen
promiseofbeans 5y ago
Astro is working on something that lets you edit and preview markdown files locally via a web based WYSIWYG editor.
porphyra 5y ago
Many static site generators are so fast that you could use, say, the unix `watch` command to rebuild your website every two seconds while running an `http-server` locally to preview the results. And then just rsync the artifacts when ready to deploy.

aidog 5y ago

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.

ivanmontillam 5y ago
So, is it just flat-file CMS like Grav?

selfmodruntime 5y ago

I‘m going to make a case for one of the more complicated SSG setups. 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.

deleted 5y ago
[deleted]

AnonHP 5y ago

> 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. … > 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.

floodle 5y ago
I'm confused by what your baseline is here. What are you comparing JavaScript framework SSGs to?
- AnonHP 5y ago
  The ones that build the site server side completely (including the ones that are JavaScript based, but not the ones that are JavaScript framework based that tend to move certain parts to the client).

johnfernow 5y ago

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. 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.) [1] https://github.com/coderifous/jquery-localize https://github.com/coderifous/jquery-localize

tomrod 5y ago
Naive question from a beginner in this space. 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?
- miki_tyler 5y ago
  What do you mean with low code? HTML + CSS only?
- Mikeb85 5y ago
  Static site generators generally only require tiny amounts of scripts to get going and you just write markdown. You can use pre-made themes so no knowledge of HTML or CSS needed. Business website providers use CMSes with databases in part because they support full on WYSIWYG editors in the browser, among other things.

zuhayeer 5y ago

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: https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration https://nextjs.org/docs/basic-features/data-fetching/increme...

indigodaddy 5y ago

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.

yanmaani 5y ago
What is a "md5 file"?
- indigodaddy 5y ago
  Sorry meant to say md (markdown). Edited my comment.
thunderbong 5y ago
Caddy server does this. https://caddyserver.com/docs/caddyfile/directives/templates#examples https://caddyserver.com/docs/caddyfile/directives/templates#...
- indigodaddy 5y ago
  Holy crap I had no idea, wow!
  - unfocussed_mike 5y ago
    Possibly the reason why you had no idea is that Caddy -- while legitimately amazing -- has documentation that feels something like you're playing a 1980s text adventure, stuck in a maze of twisty tunnels.
- mholt 5y ago
  Yep, just enable templates with the 1 line of config and then put {{markdown "here"}} in your web pages and there you have it. Caddy's entire docs are powered by this kind of templating, it's quite useful: https://github.com/caddyserver/website/blob/master/src/docs/index.html https://github.com/caddyserver/website/blob/master/src/docs/...

rammy1234 5y ago

Found this - SSG - https://staticfire.site https://staticfire.site. More specifically this - https://staticfire.site/content/static_site/ https://staticfire.site/content/static_site/

WaitWaitWha 5y ago

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.] 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.

goostavos 5y ago
The documentation problem is because they're trying to be everything for everyone imo. You end up with this bizarre labyrinth of conventions (and extension points) for which the only way to navigate is the documentation (and the documentation is unclear, so...) 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.
- deleted 5y ago
  [deleted]
- luismedel 5y ago
  This. 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? :-) [0] https://github.com/luismedel/clarin https://github.com/luismedel/clarin
- throwaway984393 5y ago
  One of the most annoying things about computers to me is that they require constant maintenance. I don't want to do maintenance anymore; I want a mechanic to do it for me. I have built my own bed, desk, shelves, serving trays, fixed my own cars, plumbing, electric, screens, hinges, walls, drawers, tended my own garden, and wrote my own software. The garden is the only thing I still enjoy maintaining. So I use a SSG. They fix bugs and add features and patch security holes and do releases, and I just download and run it. 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 :(

kuon 5y ago

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. 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.

jay_kyburz 5y ago

Anybody remember CityDesk.

jay_kyburz 5y ago
https://www.joelonsoftware.com/2001/10/12/what-does-citydesk-do/ https://www.joelonsoftware.com/2001/10/12/what-does-citydesk...

buro9 5y ago

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. 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.

tonyedgecombe 5y ago
>For the vast majority of WordPress 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.
- marc_io 5y ago
  I could be wrong, but I think Publii is the only SSG that doesn't work from the command line and is specifically targeted at end users.
mattlondon 5y ago
GitHub already does this for Jekyll automatically. 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))

open-source-ux 5y ago

Static Site Generators (SSG) are not new. The SSG blog software Moveable Type launched in 2001 (written in Perl) and preceded WordPress. It featured a friendly browser-based editing, and a publishing experience suitable for all users. 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.

camillomiller 5y ago
I would also point out that by means of heavy caching Wordpress can solve all the performance issues indicated by the author as the main advantage of SSGs. In my opinion opposing Wordpress and dynamic CMSs to SSGs is the wrong way to frame the topic. They have different applications, especially if you’re doing client work.
mrctte 5y ago
> 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 https://zestyrx.com/blog/nextjs-ssg

cblconfederate 5y ago

> Not everyone who writes knows how to program too. 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

hellweaver666 5y ago

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.

declnz 5y ago

Love SSGs too! Came here to share praise for Hakyll[1], for people with an FP leaning. 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. [1] https://jaspervdj.be/hakyll/ https://jaspervdj.be/hakyll/

nathias 5y ago

missing eleventy

simonjgreen 5y ago

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 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.

physicsguy 5y ago
Yeah definitely. I did some work with a really ancient Python SSG called rest2web that was around since ~2004ish, so several years before Jekyll even started
eloisant 5y ago
Yes, I feel like Jekyll was the first to make static sites "cool". Maybe because of github that made it super easy to create a site based on Jekyll, without having to compile it locally then upload to FTP or whatever. 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.

harryvederci 5y ago

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. Bonus points if you auto-generate an RSS feed!

anyfactor 5y ago
This is exactly what I wanted to do. This idea has been sitting on my sideproject to do list for a while. 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!

Zababa 5y ago

> Hugo is usually around 6 times faster than Jekyll and is even faster compared to Next.js or other framework-based SSGs. 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?

pointlessone 5y ago

For those who might want to explore SSG themselves here's a great directory: https://jamstack.org/generators/ https://jamstack.org/generators/

dgudkov 5y ago

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). Static site generation should be simpler. Currently it's over-engineered.

calltrak 5y ago

mrctte 5y ago

Funny, I wrote about this recently as well. I'm a huge fan of SSG but concerned about the impact that it has on SEO and search engine quality. https://zestyrx.com/blog/nextjs-ssg https://zestyrx.com/blog/nextjs-ssg

streamofdigits 5y ago

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) 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

marcos100 5y ago
You forgot iii) and you'll want write your own ssg, just because.
pclmulqdq 5y ago
I have been using Hugo for a new blog I am starting, and I have to say that it would be a lot better if the CMS was something like notion. Using an IDE will definitely have some growing pains past 100 posts.

benibela 5y ago

I use XQuery as static site generator. It is a w3c standard. 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> ... It has for loops and functions, too

messo 5y ago
Wow, did not know about XQuery. Can you point to some resources explaning how one would use it as a SSG?
- benibela 5y ago
  I only read the specification. It covers every there is in XQuery I searched around and found this article: https://www.gnu.org/software/qexo/XQ-Gen-XML.html 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 https://github.com/benibela/site
  - messo 5y ago
    Thanks, this is fascinating!

msh 5y ago

Sometimes i miss the simple elegance of tools like city desk.

dv35z 5y ago

What would you recommend for a GUI interface to authoring a site based on Hugo 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?

jbergens 5y ago

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.