..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.
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.
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.
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 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.
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 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!
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.
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/
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.
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.
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.
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.
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.
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.
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.
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'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 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.
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.
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
166 comments
[ 4.0 ms ] story [ 202 ms ] threadI do mine on https://viggy28.dev hosted on Firebase. Source https://gitlab.com/viggy28-websites/viggy28.dev
Let's see how long we go.
DNS provided by Cloudflare. Comments with Disqus.
Self-hosted, works with IPFS, open-source Commento for comments.
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.
gatsby is a fun option as well if you dont mind working with react, docs are great, they point you to lots of example sites you can reference for help
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.
[1]: https://github.com/jgm/pandoc
http://doc.cat-v.org/plan_9/4th_edition/papers/mk
[1]: https://jaspervdj.be/hakyll/
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/
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.
[1] https://react-static.js.org/
Find it incredibly strange when people say ”static site generator written in X” as though it means anything to the end user.
And truly if compilation speed is actually of any importance to you as a blogger perhaps you are too big to be a "blogger".
There's no major static site generator out there that doesn't have enough customisation for well over 99% of users.
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).
Here's the source for my site: https://github.com/brndnmtthws/brndn-io
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)
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.
[0]: https://pandoc.org/
[1]: https://9fans.github.io/plan9port/man/man1/mk.html
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.
For example
is evaluated to Or becomes XQuery is a W3C standard, so there are several implementation of it. I wrote an XQuery interpreter (http://www.videlibri.de/xidel.html) myselfI 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...
The markdown authoring experience is also one that I really love, personally, which is an added bonus.
Btw, checkout https://www.stackbit.com/. really good.
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.
Bootstrap team is moving their docs to Hugo: https://blog.getbootstrap.com/2019/02/11/bootstrap-4-3-0/#br...
I'd link the damn thing but I don't want to dox myself.
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.
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'm not using any Jekyll specific theme.
I started with a Bootstrap 3.x base and custom made it. I would have used Bootstrap 4.x but it wasn't out at the time.
When coming up with the design the main focus I had in mind was "minimal and readable".
What's the pricing for this? There's no mention on the website
https://putyourlightson.com/plugins/blitz + https://craftcms.com/ (free if you're building the site for yourself)
[0] https://github.com/john-bokma/tumblelog