I'm a big fan of Jekyll. I've been using it for ~5 years and just made a new site with it recently so I would still use it today.
I currently use it for:
- My personal blog with 250+ posts and tons of pages[0]
- A podcast platform[1] which is open source[2]
- The landing pages for all of my web development courses (not going to bother linking them since I don't want to seem like I'm fishing HN for sales)
I also recently wrote about my whole site's tech stack here[3]. That post might not fully apply to you since you want to host it on S3. I personally self host everything on DigitalOcean but using S3 wouldn't be a problem.
You mentioned "static assets" and this is where Jekyll shines IMO. The jekyll-assets plugin (optional) will md5 tag your assets for cache busting and bundle your scss / JS too. It's really handy and avoids having to set up more complicated tools. It pretty much works out of the box with close to zero configuration.
The plugin system is nice too. You can do some really useful things like automatically add certain rel attributes to external links with a few dozen lines of Ruby. It's very handy for a blog.
I’d second Jekyll because it’s easy to get hosted on GitHub pages with a custom domain, or just a .io default. A no-brainer for low maintenance pages with easy Markdown updates in my opinion. Also nice to know it will be supported by that group since it powers so many pages.
The markdown authoring experience is also one that I really love, personally, which is an added bonus.
Isn't Jekyll slow for a lot of blog posts? Also,adding all those plugins for everything must slow it down. Asking you since you have 250+ posts. I had read this in a Hugo vs Jekyll comparison and picked Hugo.
I haven't noticed it, otherwise I would have for sure switched by now. I have zero patience for slow downs like that.
I think it's only really slow if you make questionable decisions at the template level around tagging, categories and pagination where you could end up with deeply nested loops but you can avoid all of those problems without making compromises.
For every day writing, I run Jekyll with --incremental. Basically what this translates to is I can have my editor open and write a blog post with a browser next to it and every time I save the file it takes around 3-4 full seconds to auto-reload and see a live preview. Using --incremental only incrementally rebuilds what changed instead of everything.
This is in an absolute total worst case scenario environment too where I'm running Ruby directly inside of WSL1 and the code is mounted in from a non-SSD using an i5 3.2ghz quad core from 5 years ago. When WSL2 hits I wouldn't be surprised if it finishes in 1-2 seconds (or if you had MacOS / Linux now it would be faster too).
For builds (at deploy time) it takes around 20-30 seconds for Jekyll to create what it needs to create and push everything to my server using Ansible. This delay doesn't bother me because I run 1 command and let it do its thing while I do something else. I only run this a few times a week at most too.
Realistically 250+ posts isn't a ton but for a solo blogger it's sort of a decent amount. That was ~5 years worth of posting consistently.
But I think --incremental will save you no matter how big it gets for writing where you want a fast feedback loop.
I converted an extremely large marketing/news site of 5000+ articles (and growing) to Jekyll from Wordpress. Lots of custom-built plugins. Total build & deploy time start to finish is around 20 minutes, but about half of that is webpack doing its thing. I think the team responsible after I left has been able to speed things up to about 5 minutes, but can't confirm.
I've built a ton using both Jekyll and Hugo, and while that later is speedy, its templating is extremely inflexible. The more complicated your content and the things you try to do with it, the more grim things look for it.
I do want to stress though that in that case, Hugo's speed wasn't a positive enough tradeoff vs worse templating to switch.
We used both on a case by case basis there. A few dozen online properties. Hugo got used on the simplest stuff, often 4-5 page lead generation sites which is about 30% of what that company did. Speed of builds/deployment is basically the same there, but with Hugo the tooling/pipeline was much simpler.
Hey, Stackbit founder here. Creating websites with Stackbit is and will continue being free. It has a low cost of operation for us and we find its an attractive way for people to experiment with static sites / the JAMstack.
A request. All those new upcoming Themes. Could you at least make a video demo of them(in case they're somewhat ready) if not the date of their release, so that I keep them in mind and wait for them? Hoping for a Christmas release
The thing about static site builders is that it's really easy to get started building one, and very difficult to make one that meets everyone's needs. The result of this is a sort of Life-Cycle of the Static Site Generator:
1. Look at the huge list of open-source static site generators (literally hundreds![1])
2. Try some out, and fail to find one that works exactly right.
3. Start writing a new one that fits better.
4. Gradually extend it and make it more general.
5. Get excited about how useful it is, and publish it as an open-source project so others can use it, adding it to the already enormous list.
I've taken to just building a new one one to meet whatever my immediate need is, and developing a sort of mental toolkit of techniques rather than trying to smush an existing program into the particular requirements of a specific project. You can get surprisingly far with just a handful of lines of code.
I like knocking up JS to pump out some HTML and often it’s quicker than using a framework when you consider how much of a dead end they leave you in when there is something they can’t do with their DSL or whatever.
Not nearly as fast as Hugo or Jekyll (~5 minutes to generate a 1300 post blog), but a nice alternative if you want to keep using a CMS and don't want to expose it to everyone.
thank you for this link - i want to use jekyll or hugo, i do, but i am real bad at organization and i always fall back to using a local WP install to take content and do all the heavy lifting - organizing it, styling it, etc. i get insanely frustrated sometimes trying to work with hugo, just little things that fly in the face of what is mostly a pretty straightforward program, but its those little things that really ruin the entire thing for me.
I use Pelican. If you know Python, it's decently easy enough to extend it for your own needs. It was the first one I used way back in 2011, and I've not needed to use a different one.
I'm certainly not alone in going down that route! Sometimes it can be rewarding though, as you do get something you understand and which suits you completely.
I wrote a (perl-based) blog-compiler for my own site https://blog.steve.fi/ and recently rewrote it in golang to get the advantage of easier installation and faster generation.
Generating a thousand blog posts, over five+ years, shouldn't take more than a second. My Perl code used to take 30 seconds to rebuild and upload my site (via rsync) complete with comments, tags, etc. But the new rewrite takes 3 seconds to do the same job. So it was a good rewrite even if I'm not even going to pretend it is a general purpose utility any more.
Nice site. A suggestion: cleanup the duplicate languages. I saw there were two “TypeScript” options which were different only due to variation of capital letters.
- Single binary distribution. No dependencies or time wasted setting up things. Just extract and use.
- Dozens of themes to pick from [0]
- Straight forward customization of theme's styling
- Tinkering Go templates are fairly easy
- Accepts markdown and Org-mode as input formats
- Tags, categories, multilingual, search, etc.
- Support for comments [1]
I've been using it for my site [2] for more two years now. It has embedded JavaScript/CSS WebGL demos, code blocks with syntax highlighting (again no dependency on Pygments, etc. and has preset themes), images, footnotes, math equations using MathJax, etc. Tools enough to write a well-formatted book.
I've used Hugo for a while and was drawn to its single binary, quick builds, and nice template features. However, after a few years I've decided that it's not for me.
While the Hugo developers are very responsive and do a good job maintaining the project, they don't generally respect their users (be they theme or site developers) time. Every few versions I find that my sites are broken because the developers changed something on me, sometimes in ways that just silently change the behavior of the site (as opposed to a build error, which would be annoying but which is more discoverable).
The documentation is also very difficult for me to learn from. Despite being extensive, it's extremely hard to learn how to do anything and I find that it frequently makes assumptions that you already are an expert theme or site developer. I wish I had a better grasp on what makes their documentation so hard to use despite the fact that there's so much of it, but I find that what I'm reading is almost never what I need to actually understand what's going on. This might just be me though.
I find exactly the same thing. Hugo is perfect for me, it does exactly what I want it to do and has all the features I’ve wanted in a static site builder, but despite having used it for a couple of years, I still cannot find what I’m looking for in the documentation.
I am also a Hugo user - and I love it - but also find the documentation pretty bad. Not only hard to find stuff I need but also pretty basic sometimes.
I've read their documentation many times, and never found any of it clear. Quite the contrary, I've found the docs very hard to navigate and learn from. Maybe this is just me though? They always seem to have a lot of documentation, but all of which just assumes you understand what other terms mean, or how complicated things behave without actually pointing you to where you could learn such things.
To further this, to get a "good looking" Hugo site going I find myself going through shared hugo projects and pulling various features together in my project - a process that requires a fair amount of trial and error and plenty of frustrations. I haven't tried Jekyll, and I still think Hugo is a great project, but it didn't leave me with a fully satisfied experience such that my next static site will try out something else. I'm also a full-time go developer fwiw.
I made two fairly advanced SaaS / product sites using Hugo (https://vamp.io and https://checklyhq.com) and would actually advice to not use Hugo for any new initiatives.
- the templating syntax is just very confusing.
- the documentation was terrible, is still terrible and probably will remain terrible.
- the split between index and list pages is still a big pain. Many things work on one but not the other.
- upgrades break your site almost always.
- error messages are arcane
This might sound bitter, but I was a fan in the beginning. Development seems to have gone off track somewhere, probably when the original maintainer left.
Probably Vuepress for simple docs and blog site is the simplest one I’ve found, but I’m pretty comfortable with Vue.
I understand that you feel so, but I found Hugo to be logical and straight forward.
Jekyll, OTOH, needed me to install umpteen things. Note: C++ developer here, never had to use Ruby directly for anything. I write my articles on-the-fly on different laptops, during flight, etc. So having `git` and `hugo` alone in the terminal and Emacs is good enough for me. Hugo also runs a local server which updates Firefox on every save.
I'm also a C++ dev an I'm envious of how clean your site design is. Do you have any insight you can share on how you approached the frontend design? I find myself constantly fiddling with the CSS and I feel like I could fiddle around with it forever and still not be happy.
> I find myself constantly fiddling with the CSS and I feel like I could fiddle around with it forever and still not be happy.
I'm afraid I'm guilty of this too; countless hours of yak shaving [0] the stylesheet :( However, one thing I consciously avoid: not being happy. Every session, at close, I make peace with the existing styles and tell the perfectionist in me that it'll never be perfect but will eventually get close. For that session I'll make possible changes and write the rest on my mind in TODO. My original site was just a copy of Ghostwriter theme[1] and small incremental updates eventually led to what you saw.
I agree on not recommending Hugo, I spent way too much time on it without being able to figure it out. I now use Lektor, it's simple and very flexible.
Another +1 for Lektor. I use both Lektor and Hugo to run a few static sites and have come to dread updating the Hugo ones, while the Lektor model just seems to fit better with the way I think.
Personally, I'd go with hugo as it is fast at generating but I've used nikola for years as it is python based (my prefered language). I'd recommend checking out https://www.staticgen.com/ as it tracks SSG's popularity and gives nice info. A SSG built on a language/platform you are comfortable with is always a plus as sometimes you just need to get under the hood and ti.ker with things.
And for people who want "Hugo but written in Rust" or "Hugo but written in Javascript" — then, there's Zola (Rust): https://github.com/getzola/zola, and 11ty (Javascript): https://github.com/11ty/eleventy. (Or at least that's how I think about these two.)
Why would you want that? I generally prefer Rust or JavaScript over Go. But with a static site generator, you're not actually using the language at all, and Hugo has a much bigger ecosystem.
Thank you for pointing out StaticGen. Now I can find the product built with technologies I know so that I can get stuff done quickly instead of learning the tools of the most popular product on that list.
A slightly different take on this. I've recently seen people combine Pandoc[1] with their own (generally quite small) shell script. It's pretty amazing how little time it can take just using Pandoc / shell to come up with something that's just right for your needs, without all the bells and whistles.
I'd probably recommend Gatsby, it's super flexible, has great documentation, tons of plugins and includes good defaults.
I've previously used hugo to build some customer sites. It's super quick to build, but we ended up replicating a bunch of work that Gatsby has support for like image optimisation, minification, etc.
Netlify is a good hosting option if you're not married to S3.
Take a look at forestry.io - it's a CMS that can use various different static site generators, but edits in the CMS are committed directly to your git repo.
So all your content stays in git, and yet you can still collaborate with non-technical partners.
Also check out https://dlvrit.com/ - this posts new articles to social networks automatically. I've configured it so that:
* There's a tick-box in the forestry config for posting to social networks.
* When this is ticked, Hugo includes the article in a special custom RSS feed.
* dlvr.it uses that custom RSS feed as its input.
So as far as my non-technical collaborator is concerned, when they're happy with the article, they tick the Socials box in the forestry admin and it magically posts to all the social networks. It's awesome.
I'm using Hugo with Netlify. I've used just about every tool over the years, and I'm pretty happy with Hugo. Netlify makes deployment a breeze, and there's a free tier with 100GB of bandwidth which is fine for a basic blog.
If you want to do anything fancy, or you have a love for React, I'd suggest Gatsby as an alternative. It also makes it easier to pull in the JS ecosystem. Currently, pulling in JS libraries with Hugo is a bit clunky because it doesn't integrate directly with the standard JS tools (npm, webpack, etc).
I love this stack. Although the one where you are most comfortable with is the way to go, hugo + netlify (and eventually add forestry if you need a real CMS) is astonishingly easy and straightforward to set up. Just amazing.
edit: About adding js libraries, just import them via html instead of using package managers
It is a Python based, "make a blog from theme template and markdown content" engine. There's hundreds of themes and plugins for all sorts of functionality. I spent some time twisting it and its theme engine to make http://snafuhall.com/ (read as, don't blame them for my site, the horrors are all my responsibility)
Not just rst support, but with plugins you can get support for pretty much any format. I wrote a plugin for org format. All it does behind the scenes is create an rst using pandoc for each org file and Pelican handles the rest.
It’s like asking what is the best web framework, or what is the best scripting language. There are several prominent static-site generators, each with their strengths and weaknesses.
1. What is your preferred language? For Ruby, it’s probably Jekyll, Middleman, and maybe nanoc. For Javascript, it’s Gatsby and Eleventy. If you don’t mind Go’s templating language, it’s Hugo.
2. What are your priorities for a static-site generator?
- available themes? then it’s probably Jekyll or Gatsby
- easy generation of documentation? Docusaurus might be worth a look
- flexibility? for a front-end developer, Gatsby is insanely flexible
- fast build time? Hugo is probably unbeatable
- small initial payload? not Gatsby then (eleventy looks nice, and was used by Google webrel folks to build the Chrome Dev Summit site). Keep in mind that server-side-rendered React, used in Gatsby, will leave your site non-interactive during the time javascript is loading
My personal preference, as a frontend developer who likes javascript/typescript and React, is Gatsby, but Eleventy is looking increasingly appealing.
The best CMS is the filesystem. Don't be afraid to just write HTML and use it.
For my personal site I write html posts as discrete files with filenames that allow me to use bash to cat them easily into pages. Then every time I write a new post for the blog I just run something like, ls -v 2019-*.html | tac | xargs cat > blog-2019.html
To style the raw posts themselves I use HTTP header linked CSS (https://www.w3.org/TR/html4/present/styles.html#h-14.6). It doesn't work in every browser but I don't care about every browser. That's the joy of personal sites. You can just do what you want.
For generating the RSS feed I wrote a small perl script. Everything is hosted from home with nginx running on my main desktop over a cable ISP connection.
I have a server-side CMS written entirely in bash. It was originally kind of a joke, but it's been working well on a relatively high-traffic site for over 5 years now so I guess the joke is now on me. I named it SCMS, which was originally "stupid CMS", but maybe now I can retcon it to "shell CMS".
We now have come the full circle, and I expect that people now - after rediscovering plain html - will next start to rediscover all the issues with maintaining purely static html sites, all those reasons why we ditched the idea back in 90s
If you are interested in learning about software, making your own SSG is a fun and simple project. If you don’t know HTML, handwriting a couple of pages is a great way to learn. If you want to make a website, writing by hand is a total waste of time.
Oh? So my niche technical website that gets a couple thousand uniques per day has all been a waste of time? Who knew that just concentrating on content instead of wasting all my time on tools and appearance was in fact the opposite of what it seemed...
Writing a bash script and sending CSS as headers(!) is a huge and unnecessary waste of time compared to learning how to use Hugo, yes. Learning Hugo takes less than one business day. If your system works for you great, but you are not being time efficient.
If you really want the low-tech version I'd still recommend writing in Markdown and using Pandoc to convert to HTML. You can then use one HTML template to style all of your blog and a Makefile for the conversion and you got your static site generator.
I mostly do Tor onion sites. So I absolutely don't want any scripting. Because that would piss off the most valuable part of my potential audience. And given Tor's latency, you want to avoid unnecessary traffic.
I write mostly in ReText. It generates decent HTML. But I usually end up tweaking.
For my personal site I just I built my own with Ruby and I love it. It's perfectly molded to my use and I don't have to fuss around with keeping up with updates or handling edge cases that static site builder may not have thought of. For example, some of my work has been translated into other languages and having a template that was easy to streamline into French is really nice.
And really static site builders are EASY to build. It's just building strings! It feels like so much of development has turned into libraries and glue code these days. It's nice to have something small and simple.
Tried using Hugo but it was full of magic and silly naming and conventions that I really didn't like.
I even created my own little language which I used the Go parser to parse (but the syntax was closer to Lisp - the Go parser is just for the expressions after the commands - e.g. `(cmd expr)`).
After I made it, I discovered that this is one of the most popular projects for programmers to embark on and actually pull off something usable (it's both useful and interesting, while not being too overwhelming)...
Here's a full list with 100s of static site generators (mine included haha) : https://www.staticgen.com/
Honestly I haven't found any I really like. Gatsby for example I found overly bloated (eg. requiring GraphQL - with which you can't even dynamically generate queries) without offering everything I need out of the box (eg. Disqus integration), build times felt long, and there are very little templates (at least last time I used it) and like other SSGs switching a template basically requires re-architecting your whole app.
I think the biggest weakness with these SSGs is the difficulty of switching themes. With a CMS like Wordpress, changing themes takes no work, you just specify a new theme. In any popular SSG, changing themes generally means re-architecting your codebase, requiring a developer to dive into the codebase and spend an insignificant amount of time (leading one to question the value of their SSG framework), or otherwise abandon their current project and start over on the new template from scratch.
Because changing themes is such a hassle and time sink, if you just want to use a pre-made template and be done with it, then I actually recommend you look for the template you want first on ANY popular SSG, and then just use that (Jekyll seems to have the largest section of templates).
If you're planning to make your own custom template and you're a developer, then honestly I recommend you to just create your own project without these SSG frameworks, unless you just really happen to like the (often super overly opinionated) stack that they tie you into (that won't be cool anymore a year later as developers flock to the next shiny thing). Even then I think you'll find yourself working against the framework more often then you'd like, pretty much defeating the purpose. For my needs I found it easier to just parse my own Markdown files and use an npm library like showdown to convert them to HTML, and then just develop in my preferred stack.
If anyone wants to recommend something for beginners. Then checkout https://www.stackbit.com/. It can even convert your existing themes b/w various SSGs (like Hugo,Jekyll). And they have some pre-made themes too, although, small selection, but good ones.
For me, I'd rather brush up on my HTML and CSS than learn a new framework. So I coded a mockup webpage, google'd for responsive CSS layouts and tested on a few devices. Then a little python glue (which I enjoy hacking with) to turn that template and markdown into a simple website. Et viola! http://fadedbluesky.com/projects/sitegen.html
I have to plug mine, even though I haven’t touched it in years:
Frankenstein’s ___.sh , a bash script that mash some html placeholders together with your multimarkdown content into a bunch of static files. Supports blog, hierarchical and plain pages.
I use pandoc[0], along with an mkfile – which is like a makefile, but slightly cleaner[1].
The mkfile handles deployment (just scp a fixed list, keeps me in control over what is put online) as well as construction of the pages. It also runs checks like spelling and liveliness of links. Local links are checked by first cloning the repo, so that I do not forget to add files.
There is also some custom code in there to add prefetch links for local files.
11ty solves static site generation to me. What makes it unique is it's simplicity. Unlike others it doesn't work on a lot of conventions. It supports a bunch of template formats that can be nested. And that's pretty much all there is to it.
I ditched wordpress and the likes around 2012 and I've solely been building static sites since. I've tried most of the bigger generators out there and there's a lot of good new ones, each filling a different need.
What I've personally used the most is Jekyll, and while it's great, I wouldn't necessarily recommend it anymore in 2019, mainly due to the diminishing ecosystem.
Personally I've moved on to 11ty which is just insanely cool, easy and flexible if you don't hate javascript.
I tried React-Static (the founder has many inspiring videos) but I wasn't a good enough programmer to build all the nodes/pages from scratch. You are really having to code out some very basic parts of things to get it working. Support was limited.
I switched to Gatsby and have generally enjoyed it. Gatsby also has had bugs that take me 10+ hours to fix but there are enough people working on Gatsby that you can often find some blog, SO, or github issue that gets you out of the jam.
Gatsby is awesome. It's all React, you can pull from so many different data sources. The plugins mean you're not needing to re-invent the wheel.
The downside of Gatsby is still the initial learning curve and API. There's a lot of fairly arbitrary feeling parts in gatsby-node.js, gatsby-browser.js, and the plugins/config that you can get stuck on or confused by. But once you generally get where it all lives, I can't imagine switching to something else.
Recent project I built with Gatsby, Material-ui, and google sheets: berlinmusicmap.com
I don't like writing manual HTML/CSS/JS, so I write Pug/Stylus/Coffeescript and generate the site with a Makefile that calls all the compilers. For example,
..and also super flexible/powerful. If you just want to turn markdown into static pages, it's probably overkill. But if you want interactivity or complex layouts, it's great. Here's my Gatsby site: https://robinl.github.io/robinlinacre/
I’m sure there are occasions where it makes a ton of sense, and React, especially for large or complex web applications, is amazing.
But for a static site generator, it’s like someone sat down to develop the most convoluted way of getting a bit of html on the screen. Bonus points for the resulting site not working at all without JavaScript.
I recently evaluated a bunch of static website builders to find the best one to create and manage a website for my app[0] which is hosted on Amazon S3. This was to replace a hand-coded HTML site.
I tried Harp, Wintersmith, Jekyll, Hugo and Gatsby.
After doing a few tests, I found that Jekyll was the best match for my uses. It seemed the most straightforward and flexible without being unnecessarily complex.
Creation of templates with custom content types was straightforward and templating didn't force the site into an overly specific HTML or directory structure.
Would recommend for similar product based or article sites. Personally haven't had any issues since migrating to Jekyll.
It doesn't solve the same problem as a static site builder. e.g. A static site builder lets you build templates using whatever plain html/css you want, and then you can write individual pages in markdown and have them generated using your template.
I think this is the way to go if you're not one to change the HTML very frequently. It can be a repetitive process to update HTML for each page if you've wound up with lots of them. If that's not so much a concern, go for it!
If you want the pages to share a header, footer, and menu, it can be a pain because if you ever want to change something in a shared component, you'd have to do it for every single page.
I used to have a 5 page portfolio site and it was a pain even with that few copy/pastes to do in order to update my header. Static site generators ftw.
Being familiar with React and Javascript, React Static [1] was really quite great: easy to use, works without Javascript, but for people with Javascript enabled, page loads while navigating the site are way faster and don't require a full page refresh. Plus, it's far easier to use than Gatsby in that it doesn't require you to use a whole local GraphQL database, which is great for use cases in which the pages of your website fit in memory easily.
How did you get Create-React-App to transform markdown files and build separate HTML files for every page? Because it doesn't do any of that out of the box.
Of course it's possible to set this all up, but I don't think it's fair to refer to Create-React-App a static site generator.
They will generally all meet your criteria, but there is one important gotcha to watch out for. If you intend to maintain the site for a long period of time (years) then look very carefully at features and functionality, and rate of development.
The more that exist and rapid development, the worse your experience will be! Those features end up using third-party libraries and other tools. The static builder as well as those libraries/tools keeps getting updated, until each time you try to use the builder you get a long list of warnings (or worse errors). You spend more time updating configuration files, deciphering why you should care about a default changing, wondering what Ubuntu has renamed a package to this week, and somehow end up stubbing your toe on NPM even though you picked the builder because it was in another language. (Minor exaggeration for effect.)
TLDR: pick the builder with the least amount of functionality and development pace to keep things simpler over time.
I like Javascript so I use Metalsmith[0]. It’s a very simple core with functionality added by plugins, of which there are many, covering everything I ever needed to do with my site.
Here’s a simple example of a blog + standalone pages, similar to what you get with Wordpress install[1].
I still wish netobjects fusion could of adapted to the html5 future. It handled templates and generating a wide variety of content very well. Easy to use.
I've seen this newer pinegrow editor which looks like the closest replacement for it I've seen: https://pinegrow.com/
I still use notepad ++, sometimes sublime text for easier multi-line template updates sitewide, and various templates like bootstrap, bulma, etc
If I was going to get into these others I've seen people mention on HN like hugo / jeckly and such, I would probably lean towards using wordpress with one of the two static html generator plugins I've found, that way there are many more template and layout options.
(you can use WP to design and crank out pages, shoot out static html and then delete all the wp files... though on sites I zip up the wordpress php files and leave the DB in case I decide to go back and add more posts / pages )
heck bluegriffon or similar can crank out html.. unless I was trying to do some kind of programmatic api connect thing, I just don't see the appeal of these other static generators - but it may just be I've used to more visual things and others are more used to command line kind of things - so long as text hits the web I guess it doesn't matter that much.
now if someone was able to make a connector where these static generators could use the themes from the wordpress.org directory - that would have me looking more closely at them.
I'm currently working on Sitesauce[0], a service that generates a static site from any CMS and uploads it to Netlify or Zeit. It used to require you to host a CMS instance somewhere public, but I've just released a CLI tool that allows you to deploy a local CMS as a static site to the internet. Hopefully it'll help someone :D
I've gone down this road and think for most users prerendering is a better approach.
Switching to a static site framework or SSR usually means throwing away your existing processes only to be tied into a limited framework that most likely doesn't work with all the tools you already use or want to start using.
Just search for SSR on the issue trackers of some your dependencies to see what I mean - just recently a React Beta/RC broken NextJS sites...
The right approach( as we see it is to stick a prerendering and maybe a CDN in front of your site and call it a day.
Shameless self-promotion:*
I/we run oyato cloud (beta), a proxy service (à la Cloudflare) that does prerending, etc. It's per page so you can e.g. code your site in React, but have only the landing page statically rendered e.g. https://oya.to/
Demo of a Google Lighthouse simulation of the Product Hunt homepage:
I'm using Middleman [1] for the homepage of my product Trolley [2] - love it.
As an ex-Rails guy, ERB is so familiar, and the rest of the structure just makes sense.
What's the best programming language? Best text editor? Best car? Best book?
There is no absolute best, otherwise everyone would use that and we'd only have one left to choose from. There may be a best for your specific use case, but to find that you'll need to do your own tailored research to decide.
I quite like Publii. It’s more of a CMS that builds a static site, and is nice from a “don’t want to fiddle with template languages” perspective. Will push to different services (I use GitHub Pages) as well as just generate a folder to sync yourself.
Check out Svelte/Sapper which is server side JS framework but can generate static site. Svelte is SPA framework like Angular, React, VueJS. Sapper is like NextJs/NuxtJS, with server side rendering features for Svelte.
I use Jekyll and Webpack (plus Stimulus) together and write a number of plugins to help me build component-ish website layouts with various interactive bits, and that's worked out quite nicely. At this point anything I build that's not a Ruby on Rails app proper starts its life out as a Jekyll project.
I'm not going to call it the best SSG out there, but not the worst. I wrote one and released it. It started as something to just spit out some Twig templates wtih content mixed in, and a few features later, I had a Static Site Generator. And anybody who wants to take a look, maybe make some pull requests, it's in my github, https://github.com/SeleneSoftware
I am the sole developer on a news site that is generated by Hugo. I find Hugo to be extremely flexible. But I am considering switching to Nuxt so I can ingest pages from an API instead of just md files in the repo. Still, you can’t go wrong starting with Hugo. It’s extremely versatile.
Hands down Gatsby. It's just incredible. Can pull data in from almost any source (Wordpress, CMS, Markdown).
It's the fastest you can ever get, because it utilizes service worker and preload and caches pages on mouse hover. It works offline after you visited the page once.
It fully pre-renders every page on build time so works without javascript a bots can crawl the original pages without javascript!
If you want a site rather than a blog, I'd recommend Nanoc. It's a bit more hands off than the likes of Jekyll and Hugo but is incredibly flexible and powerful.
I use it for generating the guide for one of my projects. It loads a Rails form builder and generates syntax highlighted code samples and output with barely any effort.
I'm moving my blog to GatsbyJs coming from Wordpress and it's been great so far. Significant performance improvements, great plugin ecosystem and utilizes common front-end patterns with less context switching if you have front-end experience using JS/React as opposed to Python, or Go based alternatives.
After using all the popular static and non static site builders, I ended up creating a single utility js with nodejs. Some markdown and handlebar support... a little scrappy but proud of it. Opensource too... https://docodethatmatters.com
That is exactly what I've been thinking about using for a personal blog lately, and now that you mentioned I got my thoughts validated and might just start building it now.
I recently picked up Zodiac for a small project as it's just the right amount of simplicity for my needs (uses awk and sh): https://github.com/nuex/zodiac
httrack - an open source utility that downloads a site and makes it static - so build it with wordpress for example then download it to deploy using httrack
We've been working on https://www.unstack.com to provide one comprehensive toolset for building and scaling up a static site. Would love to hear feedback from HN.
If it’s just me or other even moderately technically inclined people I’d just write straight HTML in git, no need for some fancy production.
I was recently asked to propose an alternate website for the church I go to (they ended up rejecting it, which I think is good because I’m not interested in maintaining it) and what I came up with was an mkdocs repo with a hook to auto rerun mkdocs (so like a janky homebrew version of readthedocs.io) with a custom theme (also in the repo).
I’m surprised no one has mentioned it, it’s very complete and I didn’t think it had many dependancies (as far as python projects go.) It just converts a folder full of .md to a folder full of .html and will even add edit buttons to point to a web UI for your repo host (which is really great because that means authentication isn’t your problem, I’ve heard of churches running Wordpress getting their pages replaced with porn because of that which is IMO the worst case for all of this.)
I can’t remember why I didn’t use the one written in go, I tend to gravitate towards go projects since the dependancies usually aren’t so bad and you get a (mostly) statically linked binary at the end.
I currently use it for:
- My personal blog with 250+ posts and tons of pages[0]
- A podcast platform[1] which is open source[2]
- The landing pages for all of my web development courses (not going to bother linking them since I don't want to seem like I'm fishing HN for sales)
I also recently wrote about my whole site's tech stack here[3]. That post might not fully apply to you since you want to host it on S3. I personally self host everything on DigitalOcean but using S3 wouldn't be a problem.
You mentioned "static assets" and this is where Jekyll shines IMO. The jekyll-assets plugin (optional) will md5 tag your assets for cache busting and bundle your scss / JS too. It's really handy and avoids having to set up more complicated tools. It pretty much works out of the box with close to zero configuration.
The plugin system is nice too. You can do some really useful things like automatically add certain rel attributes to external links with a few dozen lines of Ruby. It's very handy for a blog.
[0]: https://nickjanetakis.com/
[1]: https://runninginproduction.com/
[2]: https://github.com/nickjj/runninginproduction.com
[3]: https://runninginproduction.com/interviews/1-100k-page-views...