Top Open-Source Static Site Generators
staticgen.com
staticgen.com
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...
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?
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.
for {post}.md in in blogdir:
if timestamp({post}.html) < timestamp({post}.md):
convert_md_2_html({post}.md) %.html: %.md
generatehtml $^ >$@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)
Recently I tried Nuxt because I really like Vue, but although these new types of generators are great for handling layout, and the live reloading rocks, they're not really designed for a truly static site, the pre-rendering includes a lot of unnecessary bloat. There's basically a copy of every post both in the html and the javascript, it's also super hard to control it so it's only the posts for that one page. You can remove the scripts manually but then you lose all js functionality. I gave up trying to find a sane workaround. They're not really meant for content that's truly static that you don't need to update.
I've given up on this point and have just started to write my own, focusing on fast live reloading and easy config (like Vue's cli) because that's one of the other huge problems with all generators.
- You have little data that needs to be pre-loaded (e.g. item name, price, description, thumbnail, etc). - If you do have a lot of data, then your website is of the type that users revisit a lot (e.g. a documentation site). - The data is modular (it's not one chunk of data) and can benefit from using a framework to organize it. - Very little content changes from page to page (in a store front, the majority of the layout is re-used). - There's a lot of DOM manipulation you want to do (e.g. checkout, cart, etc)
This is not true of content heavy blogs:
- It's a lot of data which must at a minimum be duplicated twice. - The data is not modular. In one markdown file you have to process the text, images, videos, embeds, etc., all at once. So, for example, you can't take advantage of your framework to generate image tags. - There's almost zero DOM manipulation needed (at most I might have a portfolio page which needs some js, a lazy-load script, and some share buttons). - A lot of content changes from page to page (it overshadows any content they might have in common). - The content is not exactly of the type users would revisit often.
With Nuxt (again don't know with Gatsby, and I think they're working in Nuxt to fix this), you also have to jump through hoops to pre-convert your markdown to html because otherwise you're converting on the client side. Found this out when I looked at the bundles and there were a bunch of emojis in it, turns out it was my markdown converter getting imported into the bundle.
Now, let's suppose this wasn't that difficult, there was some function were you could pre-convert this data and it wasn't including the libraries to do it in the bundle.
Except this is THE pain point of SSGs for blogs. The majority of the problems are here and you would essentially end up writing a static generator inside this function (when I realized this I gave up on Nuxt and similar framework renderers). I would have gained very little for that headache, and how big I would be willing to have the bundle size is a LOT smaller.
And while, yes, bundle sizes are usually small and don't matter for the cases I outlined in the beginning, this is not true, like I said, of a content heavy blog. I don't have a nice a proper benchmark, but I do have some notes from when I tried nuxt. These are the sizes of a single test index page (plain text + a couple lines of css for basic styling) and the full loading times with unthrottled and fully throttled (though this is a bit deceiving* ):
Nuxt w/o Content ~170kb - 250ms - 7.8s
Nuxt w/ 10 Blog Posts ~500kb - 70ms - 14s
Nuxt w/ 10 Blog Posts w/ All Scripts Removed ~110kb - 8ms - 4.3s
You can see how my text is about ~100kb, framework is ~170kb, but the script it produces is 500kb because, I actually forgot, it's reproducing my content 3 times (did not bother to investigate why, just twice is bad enough imo)!
* Now, yes technically the throttled load times don't matter because the static html is loaded (they all paint, even throttled at around the same time), so there's no waiting for the page to load, but who knows what the rest of the background loading does to interactivity (on a proper site, with images, buttons, etc, this was just text) on slow phones with slow internet. Why would I do this to my users? It's not like it's even pre-loading anything useful (this test was with a single page, no other existing pages), imagine if it were.
> Using JS to render a new page is going to be faster than loading the entire static page.
Yes, the lack of a refresh is nice, I'll give you that and it's true that subsequent navigations are faster, but in my case I don't think it's worth the overhead. Plus, so much content changes per page, I could always just fetch the next page and replace the body manually without the overhead of a framework.
Don't get me wrong though, I would probably use a framework based SSG for say, a code blog, where it has more pros than cons. So I can see where most developers are coming from when they use them / design them.
You mentioned TTI (time to interactive) as a concern but that is a metric the Gatsby team seems to really be aware of from the beginning and I think they've done a pretty good job of dealing with it so far, see: https://www.gatsbyjs.org/blog/2017-09-13-why-is-gatsby-so-fa... In general though I've found client-side hydration to work pretty seamlessly in both React and Vue. I'll be shipping my first (non-trivial) Vue Server-Side Rendered app to production soon.
I think Gatsby would do a pretty good job even for content-heavy sites. It's built to try to only render the critical-path items. If you have a content-heavy site, you most likely have implemented some sort of summary list and pagination and only the first set of links on each static page are going to be prefetched by the browser. So it's not like you have to load all the data up front (and you probably shouldn't for UX reasons), you just have to organize the data appropriately like you would for any other kind of site. I've found that Gatsby's graphql interface makes doing these things a breeze compared to my previous React experience where I've had to mess around with state management libraries like Redux.
I'm confused by what you meant by "you can't take advantage of your framework to generate image tags". Is this in the context of Nuxt processing markdown on the client? Like I mentioned previously, this shouldn't be an issue with Gatsby and there are some cool plugins that, for example, allow you to process images in markdown during the build so that they are lazy loaded and initially show a low-res geometric representation of the image.
I can understand your hesitation to want to work with React though. I was hesitant at first. I would get annoyed at writing JSX, but once I got used to it, I found it tolerable and on rare cases I actually prefer it now.
> I'm confused by what you meant by "you can't take advantage of your framework to generate image tags".
I mean that the framework needs to be handed the final html. It has no knowledge about the formatting inside a post. You have to rely on plugins, often third-party, which don't play well with each other.
I know I've gone on about bundle size (that was just the straw that broke the camel's back) but my main problem is that these frameworks don't help in going from the markdown to the final html which is 90% of the work. I'm not saying they should or can, just they don't, so they don't add enough value imo to be worth the overhead. This is true of all SSGs I've tried though. Yeah they always have a markdown plugin and, for example, that image loading plugin does sound really cool, but can I trust them to work nicely with other plugins? Do the plugins I need even exist? Will they be maintained? I can just feel I will end up fighting them and I've wrestled with too many SSGs already. I'd rather just try to roll my own at this point.
Are creating RSS templates [1] considered as "handling the complexity", or is that too much hassle?
[1]: https://github.com/atmoz/atmoz-net/blob/master/.ply/feed.tem...
For me, lack of nice (ie. controllable, but 'automagic') image handling is a huge bug bear in nearly every cms out there, static or otherwise. Perhaps I didn't find the right platform/plugin...
In my case, I wanted to have 1 source image that was resized at various (author controllable) sizes and then saved them, while also generating supporting HTML (eg. 'srcset' to automatically swap between them). I ended up with a couple of ways to template it in [0]:
For a thumbnail:
<img src="{{image #thumb{w:50} }}">
For srcset:
<img src="{{image}}" srcset="{{image #srcset{w:'256,512,800',orig:'1152'} }}" sizes=...>
[0] https://github.com/ergo-cms/plugin-thumbnail. (Note the entire project itself stalled some time ago, and wouldn't recommend it here -- even though I do dogfood it)
EDIT: reorder wording
There are CMS solutions for static sites which will probably handle images, and all kinds of content, easily. Check out Dato[1], Siteleaf[2] or Netlify CMS[3].
Alternatively you can use external tools to prepare your images and simply rely on the standard HTML srcset within your static site generator of choice. I use RetroBatch[4] to prepare my images.
That should be doable. I may consider implementing something like that in my own SSG some day.
Exactly what cmroanirgo describes, also see my reply to epage (https://news.ycombinator.com/item?id=17961353) for that and my problems with rss, and some other things I didn't mention. For images, I ended up writing my own metalsmith plugin to resize images to different sizes and add all the attributes to the tags properly.
That's why I've started a web framework with the goal of being entirely flexible. I've made all code ejectable, minimized/simplified the glue code (so that you eject beautiful code) and made the stack flexible (you can remove/add a frontend/backend/ORM/database to your app easily and at any time). That should give you the flexibility you are looking for.
It's called Reframe (https://github.com/reframejs/reframe).
(The default starter "react-frontend" creates a static site.)
Doesn't look like it would work for me though for the same reasons Nuxt doesn't. It's not really lock-in pain that's my problem btw, but more config fatigue and missing features, and if the SSG has a plugin system to counteract this, then there's the problem that most don't work well or age quickly (imo this is usually because the plugin system is not strict enough), and regardless of whether they work, you end up with this patchwork of plugins, with a bunch of hacks and glue code to make them interact nicely, it's awful.
Could you give examples of these pain points? As a maintainer of one of the SSGs on the list, I'm wanting to better understand users pain points, even if they aren't my users.
- Layout & Routing - Having "special" pages is usually impossible with "structured" SSGs (like Hugo). For example, say you want a page that's your portfolio and only contains posts with x and y tags and you want it to look different than normal pages. Also see rss below. Or for example archives, where "/year" = "/year/index.html" but also "/year/month/" = "/year/month/index.html" and "/year/month/postname" = "year/month/postname.index.html".
- Sitemaps - I have videos on my blog and usually you want to add those to your sitemap properly. To do this I had to patch together a plugin to fetch the video info from the youtube api.
- Smart tags/embeds - Similarly I had to do something similar to fetch embeds from just the link like "[instagram]link[/instagram]". You have to do this with every provider you want, ugh, awful. Also means fighting the markdown converter you chose sometimes.
- Images - I run a blog with lots of images and different views of those images, so I need to have them all in at least thumbnail size and the regular size, sometimes the original as well, but not always. I used to batch convert new ones by hand but that was a pain. I eventually patched together a metalsmith plugin for this to automate the conversion of originals to "regular" (max post width) and thumbnails but it needs improvement. Edit: And I forgot, actually adding the correct attributes needed for lazy-loading, etc, to the image tags was also a pain.
- RSS, Most do not come equipped to handle rss, and available plugins are too simple (for routing that is, like having an rss feed per tag, per archive page, etc).
- Layout Language - Depends on the SSG, most allow choosing or these days are super flexible (e.g. Nuxt) but those that don't and just use one template language, argh! Template languages like handlebars are just not flexible enough. This was the easiest to fix though. I just use ejs now, basically allows any valid javascript, love it.
> - Layout & Routing - Having "special" pages is usually impossible with "structured" SSGs (like Hugo). For example, say you want a page that's your portfolio and only contains posts with x and y tags and you want it to look different than normal pages.
Have you looked at the "layout" and "type" front-matter?
> Or for example archives, where "/year" = "/year/index.html" but also "/year/month/" = "/year/month/index.html" and "/year/month/postname" = "year/month/postname.index.html".
The "/foo/ = /foo/index.html" or pretty URLs is the default behavior in Hugo, which you can also disable.
Regarding archíves, there are quite a few examples in the Discourse forum. I believe I have seen people implement the yearly/monthly archives using taxonomies.
>- Sitemaps - I have videos on my blog and usually you want to add those to your sitemap properly. To do this I had to patch together a plugin to fetch the video info from the youtube api.
You can have a custom layout for your sitemap. Also, you can fetch data from an API during Hugo builds. Look at the Data feature.
> - Smart tags/embeds - Similarly I had to do something similar to fetch embeds from just the link like "[instagram]link[/instagram]". You have to do this with every provider you want, ugh, awful. Also means fighting the markdown converter you chose sometimes.
Using API like embed.ly and such, and can get such data in real time during the site builds. Alternatively, you can create JSON/TOML/YAML/CSV of all such data, save it to the data/ dirnl before the Hugo builds and use that instead if you want to save on thousands of API calls during each build. This is the same Data feature.
> - Images - I run a blog with lots of images and different views of those images, so I need to have them all in at least thumbnail size and the regular size, sometimes the original as well, but not always. I used to batch convert new ones by hand but that was a pain. I eventually patched together a metalsmith plugin for this to automate the conversion of originals to "regular" (max post width) and thumbnails but it needs improvement. Edit: And I forgot, actually adding the correct attributes needed for lazy-loading, etc, to the image tags was also a pain.
Hugo has inbuilt image processing for a while now. Look at Image Processing in docs. It can do automatic centering, cropping, resolution adjustment, etc during site builds. You can choose to do that afresh during each build, or reuse the altered images from the resources cache.
> - RSS, Most do not come equipped to handle rss, and available plugins are too simple (for routing that is, like having an rss feed per tag, per archive page, etc).
Hugo has this inbuilt. You can choose to have RSS for each "list" page like home page, tag page, category page, etc., and even for each individual post if you like. All of that is configurable.
> - Layout Language - Depends on the SSG, most allow choosing or these days are super flexible (e.g. Nuxt) but those that don't and just use one template language, argh! Template languages like handlebars are just not flexible enough. This was the easiest to fix though. I just use ejs now, basically allows any valid javascript, love it.
Yes, Hugo mainly supports Go Templating. (And I don't have any complaints against that :))
Regarding archives, the problem if I remember correctly was getting them to nest properly, not just a "/archive" with all your posts, but lists at "/year/", "/year/month/", etc. until you reached the post. So no path was empty. I don't think I ever got that working.
Regarding embeds, didn't know about embed.ly. Seems great, but it's not free. If there's some free alternative I will definitely use it next time around. One of the main reasons I use an SSG is to keep my costs close to 0.
> Yes, Hugo mainly supports Go Templating. (And I don't have any complaints against that :))
Maybe I'm weird, but I can't stand 99% of template languages. They're too watered down. I want the full power of a programming language, or alternatively, some easy way to manipulate the data the template gets. Correct me if I'm wrong, but I don't remember Hugo having the latter either.
I still don't understand this point. You are free to put all your files in a flat structure like:
content/
post1.md
post2.md
content/
posts/
post1.md
post2.md
about.md
You will find many themes, at least right now, that implement "bread crumbs". Even searching bread crumbs in the Discourse forum will yield a lot of results.
> Regarding embeds, didn't know about embed.ly. Seems great, but it's not free. If there's some free alternative I will definitely use it next time around. One of the main reasons I use an SSG is to keep my costs close to 0.
I just arbitrarily threw that name out there. While I am not aware of 100% free API services, there are a few I know of that provide that service for free with rate limits.
See:
- https://docs.microlink.io/api/#introduction (this works with OpenGraph, Microformats2, JSON-LD, and a lot more) - https://www.opengraph.io/ (this works with only OpenGraph metadata)
> Maybe I'm weird, but I can't stand 99% of template languages. They're too watered down. I want the full power of a programming language, or alternatively, some easy way to manipulate the data the template gets. Correct me if I'm wrong, but I don't remember Hugo having the latter either.
What kind or degree of manipulation are you looking for. The replaceRE template is pretty powerful for my purposes.. I use it to insert anchor links next to headings as I don't like using JS solutions to do that.
For comparison I now use my own metalsmith plugin which is the opposite of these types of SSGs. It only relies on the post metadata. I can basically say, pick all posts that match x criteria, use x route (it can dynamically generate them based on metadata variables), use x template for this route, and set basic settings (posts per page, etc). All from one place. Files can be organized however I think makes sense. There aren't different types of pages or anything. The only "special" thing I had to do was for /year/month/date/ archives, but I plan to remove that exception with the SSG I'm writing now.
Regarding the archives, bread crumbs are not what I mean exactly. I want the pages to also be paginated. So /year/ is not just a list of links to all posts or links to all months, it should paginate the posts list for that year as well if they pass the posts per page limit. Seems like this has never been implemented, see this four year old issue I found: https://github.com/gohugoio/hugo/issues/448
> What kind or degree of manipulation are you looking for.
I often want array manipulations. For example, to create tag clouds. I'm sure it's possible, but I doubt it's pretty. With something like EJS, I can just have the logic in plain javascript, right above the div that iterates through it. I will grant you, I'm not sure this is the best solution. With the SSG I'm writing, I've been playing around with the idea of having a header or footer section in javascript for the templates, where you can run this type of logic and the variables will be available in the template. Kind of how when you use a JS frameworks (e.g. Vue which I love) if you have something complicated to iterate over, you remove the logic from the template. This would make simple templating languages attractive again.
Thanks for the links btw.
Be careful what you wish for! I had used Nikola, but every release kept handling more complexity. Which meant an ever increasing number of options, but most annoyingly a large number of warnings due to config options that had changed, been obsoleted, interacted differently etc. Nikola is one of those tools that generates an initial config file for you, which exacerbates the problem since you probably don't use all the config items, and then have this option warning mess due to those items.
Yes you can install a version pinned version of the tool, but then have to do the same with all the dependencies. Before you know it, Wordpress seems easy and trivial.
The main problem IS the config imo. That and plugins (and their configs). Don't know if you've tried Vue's new CLI, but my idea is if I don't want to or can't abstract away the complexity without imposing limits on flexibility, the next best thing is to "visually" abstract it by making the configuration happen in a UI like Vue's CLI. This will get rid of errors because you would be able to stop the user choosing conflicting actions, and things that cannot be abstracted in a config, usually CAN be in a UI. Main one, for example, and the one I'm focusing on is routing. There's tons there that can be abstracted in a UI there. You can also add hints, links, etc in a UI. There would be no need to be looking at the docs all the time. In the future hopefully I can expand the idea further to include an editor, but I have to keep my goals reasonable or I will never finish.
As for how many features and how complex, after migrating my site so many times I feel the following should be included (because if they're third party plugins they end up un-maintained): RSS, Sitemaps, Image Resizing, and maybe Embeds
PS: I tried wordpress with a static generator plugin once, it was horrifying, never going back. Even ignoring the static generator plugin, it still did barely better than the previous SSG I'd been using. The plugins were all of wildly varying quality. In particular I was constantly fighting the one that resized my images.
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.
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.
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...
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/
Small up-front time cost, then you can just make your change wherever and let the system do the rest.
https://smalldata.tech/blog/2018/08/16/building-a-simple-sta...
Here's my personal hacky take[0]
You can get pretty far by simply supporting Mustache templates[1], Markdown parsing (even that isn't necessary, though I did it since my old posts were already in Markdown), and a metadata format (ie frontmatter, or something similar. I went with toml files sitting next to my content).
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 :)
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).)
Static sites generators and the JAMstack are inherently crippled.
With a JAMstack, by design, everything needs to be rendered on the client. This means poor performance on mobile, loss of control over SEO, and virtually no SMO for dynamic content.
Kinda funny to promote a crippled stack that hard...
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/imdario/zas
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.
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.
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...
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/
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.
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.e. something that performs well on all devices, and is optimized to just providing static data via CSS-styled HTML.
Does anyone know of a recognized term for this thing?
That's generated using Jekyll, and executes exactly zero lines of JavaScript. I think most static site generators, except maybe Gatsby, can do that. Just don't put any script tags in your template.
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?
Also, static generators and bundlers (webpack, parcel, etc.) strike me as needing to solve many related problems. Do we believe there's a meaningful integration to be reached down the road?
I'm currently playing around with Frog (Racket based SSG).
For example, I don't want to see options that are written in JavaScript or use the AGPL license.
TT is stable, available virtually everywhere and (like perl itself) is well documented and works without fuss.
Thanks!