9 ms·

State of the Web: Static Site Generators

161 points by AsyncBanana 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
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.
  - 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.
  - 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.
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).
    - 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.
      - taurusnoises 5y ago
        Thanks! I will try this. Sounds like we coming at it with similar skill sets. No js for me, but the others, yes.
    - mattlondon 5y ago
      Command line is the black and white (usually) "hacker view" that you see in movies. All OSs have one easily accessible (even windows). 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!
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]
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...
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
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/
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))
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!
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
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.
- ravishi 5y ago
  A friend of mine used a WordPress plugin that did exactly that. He'd style and develop his WordPress website locally, then generate a static "snapshot" and deploy it. Of course it came with all the usual WP bloat and complications, but for my friend that's a feature, not a bug.
  - noahjk 5y ago
    I believe the most popular implementation of this is Leon Stafford's WP2Static (open source). I've heard good things about it for years, but have never personally tried it.
- 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
- geerlingguy 5y ago
  Drupal has Tome, which some people seem to love: https://www.drupal.org/project/tome https://www.drupal.org/project/tome
  - GongoBalongo 5y ago
    Nobody should ever use Drupal in 2022 - it is horrible. 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.
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.
- pjc50 5y ago
  I would argue that if it doesn't work with Javascript disabled it shouldn't be counted as a static site.
- floodle 5y ago
  I'm confused by what your baseline is here. What are you comparing JavaScript framework SSGs to?
  - 5y ago
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.
- jedimastert 5y ago
  You could probably set up some kind of pipe or shell script with your favorite md renderer/compiler in apache or lighttpd. CGI is a surprisingly simple protocol
- thunderbong 5y ago
  Caddy server does this. https://caddyserver.com/docs/caddyfile/directives/templates#examples https://caddyserver.com/docs/caddyfile/directives/templates#...
  - 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/...
    - indigodaddy 5y ago
      This is awesome I’ll be exploring this for sure! I was going to mess around with Harp but don’t think it gets updated much, and also it seemed overly complicated in general even without considering the templating stuff.. 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..
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.
- im_dario 5y ago
  Allow me to share my own SSG, and let me now if the documentation is clear, please :) https://github.com/imdario/zas https://github.com/imdario/zas There are some issues to iron, but it's functional.
  - mingusrude 5y ago
    On that page, I clicked on your name (http://dario.im/ http://dario.im/) for what I suppose was going to get me to a page generated by zas. You may want to take another look at it :-)
- mattlondon 5y ago
  Agreed...I found Hugo to be an incomprehensible hairball. I spent days and days trying to get it doing what I wanted without success. Jekyll however was a pleasure to use and I got the results I wanted in an afternoon.
- 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.
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.
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.
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.
- 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.
- 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
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/
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

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

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

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).
  - 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.
    - taurusnoises 5y ago
      Thanks! I will try this. Sounds like we coming at it with similar skill sets. No js for me, but the others, yes.
  - mattlondon 5y ago
    Command line is the black and white (usually) "hacker view" that you see in movies. All OSs have one easily accessible (even windows). 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!

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]

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

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

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/

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

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!

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

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.

ravishi 5y ago
A friend of mine used a WordPress plugin that did exactly that. He'd style and develop his WordPress website locally, then generate a static "snapshot" and deploy it. Of course it came with all the usual WP bloat and complications, but for my friend that's a feature, not a bug.
- noahjk 5y ago
  I believe the most popular implementation of this is Leon Stafford's WP2Static (open source). I've heard good things about it for years, but have never personally tried it.
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
geerlingguy 5y ago
Drupal has Tome, which some people seem to love: https://www.drupal.org/project/tome https://www.drupal.org/project/tome
- GongoBalongo 5y ago
  Nobody should ever use Drupal in 2022 - it is horrible. 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.

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.

pjc50 5y ago
I would argue that if it doesn't work with Javascript disabled it shouldn't be counted as a static site.
floodle 5y ago
I'm confused by what your baseline is here. What are you comparing JavaScript framework SSGs to?
- 5y ago

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.
jedimastert 5y ago
You could probably set up some kind of pipe or shell script with your favorite md renderer/compiler in apache or lighttpd. CGI is a surprisingly simple protocol
thunderbong 5y ago
Caddy server does this. https://caddyserver.com/docs/caddyfile/directives/templates#examples https://caddyserver.com/docs/caddyfile/directives/templates#...
- 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/...
  - indigodaddy 5y ago
    This is awesome I’ll be exploring this for sure! I was going to mess around with Harp but don’t think it gets updated much, and also it seemed overly complicated in general even without considering the templating stuff.. 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..

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.

im_dario 5y ago
Allow me to share my own SSG, and let me now if the documentation is clear, please :) https://github.com/imdario/zas https://github.com/imdario/zas There are some issues to iron, but it's functional.
- mingusrude 5y ago
  On that page, I clicked on your name (http://dario.im/ http://dario.im/) for what I suppose was going to get me to a page generated by zas. You may want to take another look at it :-)
mattlondon 5y ago
Agreed...I found Hugo to be an incomprehensible hairball. I spent days and days trying to get it doing what I wanted without success. Jekyll however was a pleasure to use and I got the results I wanted in an afternoon.
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.

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.

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.

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.

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

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/

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.