I recommend Lektor [0], because it ships with a administration UI. This means you can give/sell it to people that would otherwise want a wordpress site. Unfortunately that feature doesn't pop out on the staticgen list.
Sure, having good existing themes is important, but it's much harder to quantify.
Also, themes are not 'one size fits all', so consider meeting your local designer/frontend developer (or contact me :) to create a theme or at least adjust an existing one. It makes quite a difference when the theme fits to your needs.
And I'm quite the opposite. If your SSG comes with prebuilt themes and a ton of deep integration overhead (like Hugo) I'm going to pass. Just give me RSS, blogging, ability to use any templating language, and I'm good to go.
Being able to easily create and pack themes is meta-important. That is, a good set of themes cannot appear by a community effort unless creation of a theme is reasonably easy and well-documented, and themes are self-contained and easy to share.
If anyone is considering using Hugo, please account the tens of hours you will spend debugging its weirdness and magic. Yes, it's fast but it seems that ease-of-use was its lowest of the low priority. How variables work is impossible to understand. So is creating new layouts. Every change, however minor, involves fighting hard until I give up and settle for a hack.
The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway. It's hard to know why would anyone make such weird design choices to solve a problem that has an easy, known solution. Am I trivializing? Maybe, but I know how much time I spend on rendering when I am working with Flask + Jinja and how it's 10x worse with Hugo.
Sadly, moving my blog way from Hugo would be too much work and I have to bear with it.
Because in my opinion, it starts to make sense if you understand what's going on behind the scenes with Go.
Hugo always struck me as an SSG for developers who want something in between the super-easy to use, with zero experience and, well, starting from scratch with every site.
Admittedly, even with a Golang background, I find there is quite a learning curve, so I wouldn't recommend it for anyone who is just trying to get their blog online.
You don't. I use Hugo, and haven't touched a line of go code. For me, setting it up, using one of the available templates, with a few tweaks, seemed very easy. But I haven't used other static generators so I'm not sure how Hugo compares.
This is not directed to me but I'd like to chime in and say that one doesn't need to know Go language to write Hugo templates. I appreciate Go Templates even without knowing Go.
It's quite simple:
- If you don't want to learn the templating for a static site generator, use one of the readymade themes.
- If you want to tinker with the themes or create your own themes, learn the templating language. There's no magic potion.
Hugo has gotten very confusing as it has become more powerful. They are moving so fast and people are doing crazy stuff with it now! As the maintainer of a simple Hugo theme and a few simple blogs I can hardly keep up.
I have been following Hugo development, and I see that a lot of new features are getting added. But if it's something that I don't care about (i18n, SASS support, archetypes update, etc) I just ignore and don't use the new features.
I'm interested in knowing the overhead you are facing in keeping up. I just read the Release notes, and often find something I really wanted in the next update (if not everything in that update).
Overall Hugo development is quite conservative about introducing backward incompatible changes. They do happen, but very rarely (sign of progress). I remember the last time that happened about a year back when Page Bundles got introduced.
Seconded. Cannot speak of other static site generators, as Hugo is the only I know, but it IS a pain to make anything that deviates from the golden path that's shown in the documentation.
Stick with Jekyll, its robust, has support with github pages, most number of themes for a static site generator, and the benefits you get from Hugo for performance are very small
What prevent Hugo from being supported by GitHub pages? I have never understood the "Jekyll integration" thing, you're just pushing static assets created by your static site generator to GitHub, so why would it be different from a generator to an other?
Github runs Jekyll for you, that's all integration there is. Meaning you do not have to push the generated files to update a Jekyll page hosted on there, only the source files.
Github is based on ruby, so is jekyll, so its a frictionless setup that's free.
You can use netlify but there's more setup to that than github imo.
with github you can also have as many sites as you want, little unknown fact just make 100 organizations and you have 100 sites. Content is open to anyone though. But the option is still nice to have
IMO, GZ compression is really something that should be handled by your webserver and most do it easily. There is a jekyll-gzip plugin if for some reason you need it.
The content is static, and webservers like nginx support service gzip compressed equivalents if it finds it alongside the uncompressed ones. Might as well do that compression once rather than multiple times.
If you're doing it just once, you can also realistically take the extra effort and use zopfli for further (albeit slower) compression.
Most of the major web server software caches the gzipped content. It only happens once.
Plus you can actually look at the files on the server without modification or piping them to gzip to check the files.
You can also elect not to gzip files smaller than MTU (1500 bytes) and stop wasting your and your client's time. Realistically it's often wasteful to gzip small files (below 5KB).
If you're worried about squeezing maximum compression out of your text files, then you're serving up too much stuff to clients anyway. You probably don't care about your users... just about your bloated page loading fast. Get rid of some ad garbage.
That is what GitLab Pages expects, and because I can control my own pipeline with GitLab I am able to support multiple file formats that GitHub would not be able to support. It doesn't get any simpler than the example I provided.
I'll try and contain my derision towards serious conversations about hosting performance-sensitive content on GitHub/GitLab Pages. As explained in a separate comment, gziping _everything_ is wasting CPU.
If you just gzip from nginx, have content caching enabled (why don't you with static content?), and set a minimum size for gzipping, you have the best possible scenario and take a small hit on first requests of files until server-restart/cache-expiration.
I know what you mean. I’ve been recently struggling with OpenGraph tags in Hugo. But there’s barely any documentation on how they work, so I had to hack something together that doesn’t work very well.
I’m looking into Jekyll, but can’t find any themes as minimalistic as my current Hugo theme[1]. Any recommendations for a simple theme that doesn’t look like the default?
Hugo is way too complex for me as well. Not to mention the awful awful Go template engine.
I ended up writing my own static site generator which has a good chunk of the features of Hugo but focusing on ease of use rather than increasing the feature count.
> The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway.
I have to disagree on that. My Pelican blog a few years back was taking several seconds to render vs milliseconds now and live reload is instant.
Not sure what you mean, but my blog is currently generated by Pelican, and on dev server mode, live reload is unnoticeably fast! (To be fair, my blog is also relatively tiny, so it may be a consequence of this).
On the other hand, would love to take a peek at your static site generator, if there is such a difference :)
The slow part was mostly syntax highlighting and that was at least 3 years ago. Looking at https://github.com/getpelican/pelican/issues/1326 it seems live reload as I mean it (without hard-refresh of the page) is only available through a plugin.
> On the other hand, would love to take a peek at your static site generator, if there is such a difference :)
It probably depends on how complex you are trying to make things. I'm using Hugo for my blog, and everything I've wanted to do (beyond creating the initial theme) has been a 5 minute task. Now that it includes SASS compilation it's perfect...
Its gets worse if like me you only blog once a year. It takes a while to figure out how to write a post let alone publish it. I can't imagine how long it would take to tweak the template. I too am sticking with Hugo, simple setup. I am not going to maintain a Drupal installation to host my blog. Makes one realise there are pros and cons with each technology.
What do you mean by "It takes a while to figure out how to write a post"? With Hugo it is just adding a .md file inside your content folder, write the blog post and generate the blog with `hugo`. Or am I missing something here? The templating issue aside.
It probably is just me. I find myself having to look up things like configuration for the menu, syntax highlighting. Hugo is a fantastic tool. I should just blog more often.
Absolutely agree. I tried Hugo after Jekyll and I run back to Jekyll screaming after touching Hugo. It is an implicit horrific mess with fucked up (il)logic.
I recently looking into different static site generators and I chose Hugo in the end because I found their documentation to be very clear.
The Hugo framework can do a lot of things out of the box, without the need of plugins like most other frameworks. I saw this as an advantage, but I can understand you might want to go for something more simple if you don't need any of those features.
Biggest problem for me is the template engine and its incoherence, followed by poor documentation.
Also the lack of flexibility in content organization, although this seems like a common feature of static site generators, so I won't hold it (too much) against it.
I started using Hugo thinking I would not need to know Golang, but could use it as a way of learning the language. I'm starting to realize it's probably better to do it the other way around, as without knowing Golang much of Hugo seems unaccessible or very challenging at the least.
This doesn't fit my needs, we are several that interact with the static sites and getting the whole team productive with it is too expensive.
I'm looking into Gutenberg now, at least the template engine looks familiar enough.
> Biggest problem for me is the template engine and its incoherence, followed by poor documentation.
What's wrong with the template engine? Also, before you switch to a different SSG, bring up the pain points in the documentation on the Hugo Discourse forum or as an issue in the HugoDocs GitHub repo. Please.
> Also the lack of flexibility in content organization
An example would help. What part of the content organization is inflexible. Of course there are some rules, else how will the SSG find the content consistently? But an example would help. (Atleast all the files don't have to be prefixed with date stamps.)
> I started using Hugo thinking I would not need to know Golang, but could use it as a way of learning the language. I'm starting to realize it's probably better to do it the other way around, as without knowing Golang much of Hugo seems unaccessible or very challenging at the least.
Examples please. What part is inaccessible? I have been using Hugo for 1+ year, and I am still going string on not learning Go (learning Nim instead, it's awesome!)
> This doesn't fit my needs, we are several that interact with the static sites and getting the whole team productive with it is too expensive.
Typically when deploying SSG for a team, most of the team just contributes to the content (Markdown, for example), and few few folks handle the design of the site layout. So everyone doesnt even need to learn Go templates.
I ported my Wordpress blog to Hugo, yes it did take a bit of time for me to learn it. I created my own template, and now its super easy to write a new post.
If your trying to do some form of email list, or e-commerce I would stick with Wordpress
> tens of hours you will spend debugging its weirdness and magic.
That's a very surprising comment, without any detail. Can you elaborate on what you found surprising and magical?
> How variables work is impossible to understand. So is creating new layouts.
Again, some details would help understand the real problem.
[ It's agreed that you need to learn any new thing you'd like to use. ]
I have used Hugo for more than a year now, and I don't see any reason to move away from it, as it is awesome! Once you understand Go Templates (this is awesome too. Coming from Emacs-Lisp, I can associate the Go Template syntax with it in some ways :D).
> The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway.
I publish/update my site about a dozen times on days when I am updating my notes (which I publish to my site). It's a real boon to be able to save the content file, glance to the browser, and see it updated within that time. There is no exaggeration; it's that fast!
It's difficult to take your complaints seriously if you update your site "only once"!
> It's hard to know why would anyone make such weird design choices to solve a problem that has an easy, known solution. Am I trivializing?
Can someone suggest a good static site generator that uses Org files?
I'm looking for something I can have a blog & wiki with that integrates with how I already take notes. Gollum & derivatives seem alright but very bare bones.
I have developed an Emacs/Org Mode package that can export subtrees or whole files to Markdown files. The front-matter stuff like title, author, tags, categories, dates gets auto-derived. These Markdown files are Hugo compatible.
Shameless plug: If you want to organize your content with files and directories without any configuration files and all that fuzz, I created PLY[1] this summer.
All it does is convert .md files to .html and optionally uses nested Golang templates. There are some tricks behind the scenes, like support for tags and meta data (just like regular static site generators). Flexibility is concentrated into the templates, so no other files are needed.
I think the content (files) should reflect the structure of the webpage as close as possible when using a static site generator. When reducing complexity, we can go all the way down to the filesystem, where files and directories are the main building blocks. Content and design must be separated as much as possible.
I have not tested all static site generators out there, but the few that I tried did not satisfy my demands. So I just made my own (for fun and learning).
Why not try http://ngDocumentor.github.io ? It needs no generator. Works as a SPA. Works as a Offline app (PWA). Custom routing feature, simpler search. More just one json config file to set up the whole site. Serves markdown files on the fly. Try it you will love it. Works on Github/Gitlab pages as well. No root access required.
I did a crazy thing and used sapper[0] for a recent static site. It has a beta feature that allows for exporting a static page, and it worked really well for me. Fast, modular, es6 and little setup. Would definitely use it again.
I found Hugo to be a convoluted mess. Pelican on another hand was very easy to get started with. Plus it's written in Python so debugging it is easier.
The reason why there are so many static site generators is that they are trivial to write (which is why making your own is a good beginner coding project):
for {post}.md in in blogdir:
if timestamp({post}.html) < timestamp({post}.md):
convert_md_2_html({post}.md)
That's a good explanation for why there are so many SSGs on Github but it doesn't explain why there are so many in use. Surely someone talented would put all the pieces together and outshine all the hobbyist projects but it hasn't happened yet. So either something is in the way or the problem domain is harder than you describe.
Those who are unaware of history is doomed to repeat it, eh.
I use makefiles for a lot of things, they're very straight-forward. If you just follow the UNIX design philosophy, your programs are going to be makefile-useable anyways.
In fact, I’m doing that right now! Mostly because I want a blog with a graph structure for linking, and most assume you just want a tree of categories, with tags as a seperate set of trees, usually with a depth of one.
And it mostly just boils down to those 3 lines, with some additional support for the graph structure (and to force the urls to reflect the path taken, symlinks for all possible paths)
Does pmWiki count? Files are stored as plain text, though it does go through the php on rendering?
A few months ago I saw a recommendation n LinkedIn to use it for a personal-wiki, just storing notes and remembering things. I have found it to be really fast (1G DO node) and super easy to get going and keep doing including from multiple devices - as long as they've got a web browser they're good to go.
You want to write a simple static website. Now you have to choose between 100 generators. Your life has become a little bit worse.
Personally I rolled my own, but I can't say I would necessarily recommend it. But in less than 300 lines of JS it can generate by site from Markdown, with index pages and RSS, as well as watch in the background for changed files and update them live. It was a fun and useful learning experience though.
I have really, really enjoyed building my personal site (https://hotair.tech) in Gatsbyjs. I am not sure of how steep the learning curve is as I started using it w/ the intent to learn React and GraphQL. It strikes a good balance of being both a productive framework and letting you use the full features of GraphQL and React.
I much prefer it over my previous experience w/ Jekyll.
Jekyll has been working well for me. I have around 190 public posts, dozens of pages and 50+ drafts on my site.
With Jekyll-Assets I work with SCSS and everything becomes minified, along with getting md5 tagged file names for cache busting with no effort to set up.
When writing a blog post it takes around 2 seconds for live reload to kick in and refresh the post (which works nicely as a near real-time preview when writing). A full site build takes around 10 seconds but I only do this when deploying so it doesn't matter that it takes so long.
The only thing that sucks is for whatever reason I cannot get Jekyll to work at all with Docker for Windows which ultimately may end up convincing me to move to a different generator in the next iteration of my site. The devs don't seem to want to address the issue.
I don't see it on this list but I think the Hacker News crowd may be the R blogdown package. (Different than the JavaScript blogdown on the top list; ) The main features for me are good LaTeX support (for formatting mathematical expressions) and R and Python code blocks for creating charts, etc. It's great for a moderately technical blog that has equations, data visualizations, formatted code blocks sprinkled throughout the text.
I like the mindshare of the Jigsaw generator with Laravel, it uses the Mix bundler and Blade templating, basically Laravel without the backend stuff. It might be a good choice for people who want to start with a landing page before going full saas. Strange that it's not more popular..
I love Pelican. It was relatively easy for me to migrate from Octopress (which seems pretty much dead at this point). With pelican it was pretty easy for me to write by own extremely lightweight theme: https://brashear.me/blog/2017/07/30/migration-from-octopress...
My Python is only marginally better than my Ruby (not great). Even so, developing my own theme was easy following their docs.
Looking at their blog[1] they seem to do releases very infrequently. 3.5 was released 2014-11-20. 3.6 was released 2015-06-15. 3.7 was released 2016-12-12. It seems like each release is about a year and a half apart. By that cycle we're about due for one.
Possibly because stability is a good thing in software. Not saying that's the case with Pelican, but I like things that don't change much. It often means developers know what they're doing.
Well, I'm still using an ancient version (2.8?) cause the last stable broke the Markdown footnotes' linking (maybe it's a bug in my theme).
I'll probably look this week if the bug was fixed, but I'm not in a hurry, last time I updated I didn't realized they eliminated some Jinja2 corner cases that I abused for scoping variables outside code blocs and I think I'm still using the global context in a "creative" way... ^__^;
My understanding of the AGPL in this case is that if you publish a blog with Pelican, you have to also publish any trivial fork of Pelican that you create, even if only by a single trivial patch.
Seems rather onerous given how likely us devs are to tweak something here or there.
I'd gravitate towards any of the many MIT-licensed generators instead.
Pelican is great, especially if you spend a little time configuring the URL structure to remove the `.html` from the end of the URLs. I think something like this will work for most pages (might be incomplete):
Dead simple. I set it up six years ago, with maybe a full day of work. Never really had to do anything since then, except write my entries in markdown file, and run a script that generates the website and uploads to my nearlyfreespeech hosting server.
I tried Hugo, Jekyll and Gatsby. Assuming that a static site is 95% likely a marketing (self, company or otherwise) site and a marketing site needs to impress, a static site generator should be first and foremost built from the requirements of frontend and not leave the user to "theme" some default HTML.
Gatsby is ridiculously fast (React based) and its plugin universe is full of all the common features you could ever need. It has built in 1-click service workers plugin for offline access, 1-click plugins for prefetching links you put on your page, auto-inlined-css (in v2), all kinds of markdown + fringe requirements like LaTex, video embedding, things like Call to Action plugins, MailChimp sign-up-here plugins etc. To get a feeling of the snappiness, check out their landing at https://www.gatsbyjs.org/ and their plugins here: https://www.gatsbyjs.org/plugins/ .
The community pushes and PRs at break neck speed every day and is super friendly - can definitely get the support you need. Lastly, it is a great way to "inverse learn React" if the objection is "Wow, I don't know enough React". React by itself is not that opinionated and Gatsby has enough good practices of putting together a React framework for you to use productively.
Just wanted to point out that there are at least two kinds of fast: fast to build and fast to load. And while Gatsby-based sites are indeed very fast to load (although I haven't compared a Gatsby site with an optimized Hugo site), they are painfully slow to build.
But it is truly a pleasure to work with; that's for sure!
In develop mode, hot module reload (HMR) changes the text immediately on the screen as you edit. But yes, HMR and caching has some glitching once in a while.
How do you people regard the kilobytes of JS (50—100KB in the very least) that a Gatsby-built website will inevitably require? Big deal? Not a big deal?
I kind of cheated at making a 'static site' though as I'm using PHP for some dynamic stuff like my contact form and latest Instagram posts (but that's via AJAX)
I used Jekyll until the combination of various Ruby versions, FreeBSD pkg, gems, and unaccountable bloat drove me mad with rage.
Have you ever looked at the dependencies for Jekyll? Why does it need a JS compiler? I mean, how many lines of code and how many Ruby packages with very specific version numbers does it take to convert markdown to html?
I'm now using Pelican and it hasn't driven me into a rage yet. Happy that development on it is slower and seemingly more deliberate. Then again I haven't had to upgrade it yet.
I'd love to see a graph of the stars over time. Or perhaps a graph of a new-stars-per-month statistic. That would show which ones are getting more popular and which are in decline.
Jekyll has a ton of stars, but that's probably because it's been around so long.
We used to have those charts per site generator on the detail page before the Middleman -> React Static rewrite of the site.
Would love to see them back myself. Pull Request at https://github.com/netlify/staticgen would be super appreciated, since it might take a while before any of the main contributors will have time to add it back in.
I look at static site generators every now and again, and I'm totally overwhelmed at the range. Beyond starting with trying out the popular ones, is there a way to get into this whole thing without losing my way in the rabbit hole?
I say this coming from a traditional PHP + MySQL CMS background of 15 years, the irony of the vast array of PHP + MySQL CMSes is not lost on me.
Ultimately, they all do roughly the same thing in the same way. They're just Markdown-to-HTML converters, with some nice quality-of-life features tacked on.
Just pick one (even just one at random will do), and start there. It's easy enough to change your mind later.
The only thing I don't like about SSGs is the need to be on a computer that have the right software installed: I use different computers and sometimes I just want to add some link into my website. This leads to too much work for just a link.
I've been interested in [1], that is written in Rust and is available in a single binary. This eases the installation process.
Something interesting to consider are client-side site generators. I don't think there's a lot of them, but if you want to write your articles on markdown files on github/vim and update your website with a git push, it's a nice thing to consider. I wrote my own tiny one because it's fun (and it works just right for me), but see [2] and [3] if you're interested in these type of solutions. They work well with Github Pages.
Well, you can add Netlify CMS to your statically generated web site. That adds a configurable admin web interface through which you can add or edit your pages without installing the generator on the computer you are currently using.
160 comments
[ 3.5 ms ] story [ 244 ms ] thread[0]https://www.getlektor.com/
The super simple deployment and administrative process, along with Hugo's crazy speed and flexibility make this stack shine.
If you know a bit of Golang, then there's almost nothing you can't do with this.
https://forestry.io
A static site generator needs good themes. A static site generator ranking based just on GitHub stars isn't telling much.
Also, themes are not 'one size fits all', so consider meeting your local designer/frontend developer (or contact me :) to create a theme or at least adjust an existing one. It makes quite a difference when the theme fits to your needs.
The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway. It's hard to know why would anyone make such weird design choices to solve a problem that has an easy, known solution. Am I trivializing? Maybe, but I know how much time I spend on rendering when I am working with Flask + Jinja and how it's 10x worse with Hugo.
Sadly, moving my blog way from Hugo would be too much work and I have to bear with it.
I agree that doing new layouts is quite hit and miss. An extensive example using all possible variables would be quite welcome.
Because in my opinion, it starts to make sense if you understand what's going on behind the scenes with Go.
Hugo always struck me as an SSG for developers who want something in between the super-easy to use, with zero experience and, well, starting from scratch with every site.
Admittedly, even with a Golang background, I find there is quite a learning curve, so I wouldn't recommend it for anyone who is just trying to get their blog online.
This is not directed to me but I'd like to chime in and say that one doesn't need to know Go language to write Hugo templates. I appreciate Go Templates even without knowing Go.
It's quite simple:
- If you don't want to learn the templating for a static site generator, use one of the readymade themes.
- If you want to tinker with the themes or create your own themes, learn the templating language. There's no magic potion.
I have been following Hugo development, and I see that a lot of new features are getting added. But if it's something that I don't care about (i18n, SASS support, archetypes update, etc) I just ignore and don't use the new features.
I'm interested in knowing the overhead you are facing in keeping up. I just read the Release notes, and often find something I really wanted in the next update (if not everything in that update).
Overall Hugo development is quite conservative about introducing backward incompatible changes. They do happen, but very rarely (sign of progress). I remember the last time that happened about a year back when Page Bundles got introduced.
Maybe we have different criteria for how a theme should be constructed.
You can use netlify but there's more setup to that than github imo.
with github you can also have as many sites as you want, little unknown fact just make 100 organizations and you have 100 sites. Content is open to anyone though. But the option is still nice to have
https://gitlab.com/equalos/equalos.gitlab.io/blob/master/.gi...
https://about.gitlab.com/installation
Plus you can actually look at the files on the server without modification or piping them to gzip to check the files.
You can also elect not to gzip files smaller than MTU (1500 bytes) and stop wasting your and your client's time. Realistically it's often wasteful to gzip small files (below 5KB).
If you're worried about squeezing maximum compression out of your text files, then you're serving up too much stuff to clients anyway. You probably don't care about your users... just about your bloated page loading fast. Get rid of some ad garbage.
https://theartofmachinery.com/2016/06/06/nginx_gzip_static.h...
That is what GitLab Pages expects, and because I can control my own pipeline with GitLab I am able to support multiple file formats that GitHub would not be able to support. It doesn't get any simpler than the example I provided.
If you just gzip from nginx, have content caching enabled (why don't you with static content?), and set a minimum size for gzipping, you have the best possible scenario and take a small hit on first requests of files until server-restart/cache-expiration.
Could you help me understand the value of this? It doesn't seem too hard for an SSG to provide documentation on what to put in a `.travis.yml` file.
In my experience, Netlify.com is 1000x better.
HTTPS, smooth integration with any SSG (including Hugo), any of the big git repos (GitHub, Gitlab, Bitbucket), great customer service, all for free.
I’m looking into Jekyll, but can’t find any themes as minimalistic as my current Hugo theme[1]. Any recommendations for a simple theme that doesn’t look like the default?
[1]: https://applecrazy.github.io/blog
Edit: I found one (https://chesterhow.github.io/tale/). Beginning the switch soon.
I ended up writing my own static site generator which has a good chunk of the features of Hugo but focusing on ease of use rather than increasing the feature count.
> The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway.
I have to disagree on that. My Pelican blog a few years back was taking several seconds to render vs milliseconds now and live reload is instant.
On the other hand, would love to take a peek at your static site generator, if there is such a difference :)
> On the other hand, would love to take a peek at your static site generator, if there is such a difference :)
Sure: https://github.com/Keats/gutenberg It is going to change name this week or next week though, gutenberg was not original enough :(
And I liked that name.
I find it hard to understand what's so awful about Go Templates. Can you paste few examples of Go templating that you didn't like?
I actually wrote an article about why I choose Hugo, on the site I made using Hugo: https://verummeum.com/blog/2018/09/02/how-verummeum-is-build...
I'm wanting to learn from our predecessors and avoid their mistakes.
Also the lack of flexibility in content organization, although this seems like a common feature of static site generators, so I won't hold it (too much) against it.
I started using Hugo thinking I would not need to know Golang, but could use it as a way of learning the language. I'm starting to realize it's probably better to do it the other way around, as without knowing Golang much of Hugo seems unaccessible or very challenging at the least.
This doesn't fit my needs, we are several that interact with the static sites and getting the whole team productive with it is too expensive.
I'm looking into Gutenberg now, at least the template engine looks familiar enough.
What's wrong with the template engine? Also, before you switch to a different SSG, bring up the pain points in the documentation on the Hugo Discourse forum or as an issue in the HugoDocs GitHub repo. Please.
> Also the lack of flexibility in content organization
An example would help. What part of the content organization is inflexible. Of course there are some rules, else how will the SSG find the content consistently? But an example would help. (Atleast all the files don't have to be prefixed with date stamps.)
> I started using Hugo thinking I would not need to know Golang, but could use it as a way of learning the language. I'm starting to realize it's probably better to do it the other way around, as without knowing Golang much of Hugo seems unaccessible or very challenging at the least.
Examples please. What part is inaccessible? I have been using Hugo for 1+ year, and I am still going string on not learning Go (learning Nim instead, it's awesome!)
> This doesn't fit my needs, we are several that interact with the static sites and getting the whole team productive with it is too expensive.
Typically when deploying SSG for a team, most of the team just contributes to the content (Markdown, for example), and few few folks handle the design of the site layout. So everyone doesnt even need to learn Go templates.
If your trying to do some form of email list, or e-commerce I would stick with Wordpress
That's a very surprising comment, without any detail. Can you elaborate on what you found surprising and magical?
> How variables work is impossible to understand. So is creating new layouts.
Again, some details would help understand the real problem.
[ It's agreed that you need to learn any new thing you'd like to use. ]
I have used Hugo for more than a year now, and I don't see any reason to move away from it, as it is awesome! Once you understand Go Templates (this is awesome too. Coming from Emacs-Lisp, I can associate the Go Template syntax with it in some ways :D).
> The speed of generation doesn't seem much of an added advantage since you're gonna do it only once anyway.
I publish/update my site about a dozen times on days when I am updating my notes (which I publish to my site). It's a real boon to be able to save the content file, glance to the browser, and see it updated within that time. There is no exaggeration; it's that fast!
It's difficult to take your complaints seriously if you update your site "only once"!
> It's hard to know why would anyone make such weird design choices to solve a problem that has an easy, known solution. Am I trivializing?
Which weird design choice? Which easy solution?
I'm looking for something I can have a blog & wiki with that integrates with how I already take notes. Gollum & derivatives seem alright but very bare bones.
[1]: https://vicarie.in/posts/blogging-with-org.html
[2]: https://orgmode.org/worg/org-tutorials/org-publish-html-tuto...
[3]: https://news.ycombinator.com/item?id=17940393
See https://ox-hugo.scripter.co.
Dozens of ox-hugo + Hugo users have shared their sites and site source in Org mode here: https://ox-hugo.scripter.co/doc/examples/
All it does is convert .md files to .html and optionally uses nested Golang templates. There are some tricks behind the scenes, like support for tags and meta data (just like regular static site generators). Flexibility is concentrated into the templates, so no other files are needed.
I think the content (files) should reflect the structure of the webpage as close as possible when using a static site generator. When reducing complexity, we can go all the way down to the filesystem, where files and directories are the main building blocks. Content and design must be separated as much as possible.
I have not tested all static site generators out there, but the few that I tried did not satisfy my demands. So I just made my own (for fun and learning).
[1]: https://github.com/atmoz/ply
[1]: https://github.com/imdario/zas
[2]: https://github.com/zserge/zs
[3]: https://github.com/cjp/z
[1] http://www.dabeaz.com/ply/
https://smalldata.tech/blog/2018/08/16/building-a-simple-sta...
[0] https://sapper.svelte.technology
Turned out a hell of a lot faster than any static site generator I've used.
I use makefiles for a lot of things, they're very straight-forward. If you just follow the UNIX design philosophy, your programs are going to be makefile-useable anyways.
And it mostly just boils down to those 3 lines, with some additional support for the graph structure (and to force the urls to reflect the path taken, symlinks for all possible paths)
Does pmWiki count? Files are stored as plain text, though it does go through the php on rendering?
A few months ago I saw a recommendation n LinkedIn to use it for a personal-wiki, just storing notes and remembering things. I have found it to be really fast (1G DO node) and super easy to get going and keep doing including from multiple devices - as long as they've got a web browser they're good to go.
Personally I rolled my own, but I can't say I would necessarily recommend it. But in less than 300 lines of JS it can generate by site from Markdown, with index pages and RSS, as well as watch in the background for changed files and update them live. It was a fun and useful learning experience though.
No, you don't _have_ to. It's perfectly fine to write a markdown file and render it into html with Pandoc.
On the other hand, now you have to choose between 100 destinations, and your life has become a little bit worse.
I much prefer it over my previous experience w/ Jekyll.
With Jekyll-Assets I work with SCSS and everything becomes minified, along with getting md5 tagged file names for cache busting with no effort to set up.
When writing a blog post it takes around 2 seconds for live reload to kick in and refresh the post (which works nicely as a near real-time preview when writing). A full site build takes around 10 seconds but I only do this when deploying so it doesn't matter that it takes so long.
The only thing that sucks is for whatever reason I cannot get Jekyll to work at all with Docker for Windows which ultimately may end up convincing me to move to a different generator in the next iteration of my site. The devs don't seem to want to address the issue.
https://github.com/rstudio/blogdown
I am still wondering, why the last release was made over 18 month ago.
Looking at their blog[1] they seem to do releases very infrequently. 3.5 was released 2014-11-20. 3.6 was released 2015-06-15. 3.7 was released 2016-12-12. It seems like each release is about a year and a half apart. By that cycle we're about due for one.
1. https://blog.getpelican.com/category/news.html
I'll probably look this week if the bug was fixed, but I'm not in a hurry, last time I updated I didn't realized they eliminated some Jinja2 corner cases that I abused for scoping variables outside code blocs and I think I'm still using the global context in a "creative" way... ^__^;
My understanding of the AGPL in this case is that if you publish a blog with Pelican, you have to also publish any trivial fork of Pelican that you create, even if only by a single trivial patch.
Seems rather onerous given how likely us devs are to tweak something here or there.
I'd gravitate towards any of the many MIT-licensed generators instead.
https://github.com/j127/pelican_blog_project_template/blob/m...
Gatsby is ridiculously fast (React based) and its plugin universe is full of all the common features you could ever need. It has built in 1-click service workers plugin for offline access, 1-click plugins for prefetching links you put on your page, auto-inlined-css (in v2), all kinds of markdown + fringe requirements like LaTex, video embedding, things like Call to Action plugins, MailChimp sign-up-here plugins etc. To get a feeling of the snappiness, check out their landing at https://www.gatsbyjs.org/ and their plugins here: https://www.gatsbyjs.org/plugins/ .
The community pushes and PRs at break neck speed every day and is super friendly - can definitely get the support you need. Lastly, it is a great way to "inverse learn React" if the objection is "Wow, I don't know enough React". React by itself is not that opinionated and Gatsby has enough good practices of putting together a React framework for you to use productively.
ps: the other frontend alternative would be vuepress, it should feel blazing fast too. Here's another article on why speed is so important: https://www.gatsbyjs.org/blog/2017-09-13-why-is-gatsby-so-fa...
Just wanted to point out that there are at least two kinds of fast: fast to build and fast to load. And while Gatsby-based sites are indeed very fast to load (although I haven't compared a Gatsby site with an optimized Hugo site), they are painfully slow to build.
But it is truly a pleasure to work with; that's for sure!
However.
How do you people regard the kilobytes of JS (50—100KB in the very least) that a Gatsby-built website will inevitably require? Big deal? Not a big deal?
(I think Alex Russell would have a fit (https://twitter.com/slightlylate/status/1029898039903670272).)
https://www.benbristow.co.uk/
https://github.com/benbristow/benbristow-website
I kind of cheated at making a 'static site' though as I'm using PHP for some dynamic stuff like my contact form and latest Instagram posts (but that's via AJAX)
Have you ever looked at the dependencies for Jekyll? Why does it need a JS compiler? I mean, how many lines of code and how many Ruby packages with very specific version numbers does it take to convert markdown to html?
I'm now using Pelican and it hasn't driven me into a rage yet. Happy that development on it is slower and seemingly more deliberate. Then again I haven't had to upgrade it yet.
Why would I want to restrict myself to a third party's servers?
Jekyll has a ton of stars, but that's probably because it's been around so long.
Would love to see them back myself. Pull Request at https://github.com/netlify/staticgen would be super appreciated, since it might take a while before any of the main contributors will have time to add it back in.
Hugo vs Jekyll: Interpolation is in the favor of Hugo :)
I say this coming from a traditional PHP + MySQL CMS background of 15 years, the irony of the vast array of PHP + MySQL CMSes is not lost on me.
Just pick one (even just one at random will do), and start there. It's easy enough to change your mind later.
I've been interested in [1], that is written in Rust and is available in a single binary. This eases the installation process.
Something interesting to consider are client-side site generators. I don't think there's a lot of them, but if you want to write your articles on markdown files on github/vim and update your website with a git push, it's a nice thing to consider. I wrote my own tiny one because it's fun (and it works just right for me), but see [2] and [3] if you're interested in these type of solutions. They work well with Github Pages.
[1]: https://www.getgutenberg.io/
[2]: http://chrisdiana.github.io/cms.js/
[3]: https://huytd.github.io/azeroth-js/
Small up-front time cost, then you can just make your change wherever and let the system do the rest.