4 ms·
> But once you get into adding images, rss, or any sort of complex layout and routing, none of them are really designed to handle that much complexity. Could y
by epage 8y ago
> But once you get into adding images, rss, or any sort of complex layout and routing, none of them are really designed to handle that much complexity.
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.
- alan_n 8y agoWell just off the top of my head, here's what I remember from most to least painful. Some of these are not 100% fixable though or I'm not sure the best way to fix them yet without adding more complexity or some sort of editor to my SSG. - 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.
- kaushalmodi 8y agoI can answer to your comment with respect to Hugo. > - 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 :))