3 ms·

If you already write your posts in Markdown, it makes sense for sure. About a year ago I converted my 500+ post Jekyll blog to Hugo, overall it's been a net wi

by nickjj 10mo ago

If you already write your posts in Markdown, it makes sense for sure. About a year ago I converted my 500+ post Jekyll blog to Hugo, overall it's been a net win but boy do I find myself looking up syntax in the docs a lot. Thankfully not so much nowadays but figuring out the templating syntax was rough at the time. Jeff, you don't have to set draft to false. You can separate your drafts into a different directory and use Hugo's cascade feature to handle it. Also you don't have to update the date in your frontmatter if you prefix the file with YYYY-MM-DD and configure Hugo to use that. Just a heads up, you didn't mention this in your post but Hugo adds a trailing slash for pretty URLs. I don't know if you had them before but it's potentially new behavior and canonical URL differences unless you adjust for that. When I did the switch from Jekyll to Hugo, I wrote a 10,000 word post with the gory details and how I used Python and shell scripts to automate converting the posts, plus covered all of the gotchas I encountered. There are sections focused on the above things I mentioned too: https://nickjanetakis.com/blog/converting-my-500-page-blog-from-jekyll-to-hugo https://nickjanetakis.com/blog/converting-my-500-page-blog-f...

tasuki 10mo ago
> About a year ago I converted my 500+ post Jekyll blog to Hugo Why? I'm using Jekyll and been happy with it. What am I missing?
- nickjj 10mo ago
  The blog post linked in my previous comment covers the why and everything else.
  - tasuki 10mo ago
    Right, I missed that! > That gives near instant live reload when writing posts which makes a huge difference from waiting 4 seconds. Mhm. Why? I can write all of my post and look at it only afterwards? Perhaps if there's a table or something tricky I want to check before. But normally, I couldn't care less about the reload speed. > I use that plugin because it digests your assets by adding a SHA-256 hash to their file names. This lets me cache them with nginx. I can’t not have that feature. Why?
    - nickjj 10mo ago
      > Mhm. Why? I can write all of my post and look at it only afterwards? My site has a fixed max width which is what most tablets or desktops will view it as. Sentence display width is something I pay attention to. For example sometimes I don't want 1 hanging word to have its own full line (a "hanger") because it looks messy. Other times I do want it because it helps break up a few paragraphs of similar length to make it easier to skim. Seeing exactly what my site looks like while writing lets me see these things as I'm writing and having a fast preview enables that. Waiting 4 seconds stinks. > Why? [asset digesting and cache busting with nginx] It helps reduce page load speeds for visitors and saves bandwidth for both the visitor and your server. If their browser already has the exact CSS or JS file cached locally, this allows you to skip a server side call to even determine if the asset can be served locally or needs an update from the server. The concept of digesting assets with infinitely long cache header times isn't new or something I came up with. It's been around for like 10+ years as a general purpose optimization.
      - tasuki 10mo ago
        > Sentence display width is something I pay attention to. For example sometimes I don't want 1 hanging word to have its own full line (a "hanger") because it looks messy. Other times I do want it because it helps break up a few paragraphs of similar length to make it easier to skim. Isn't your website responsive? If it is, for how many different resolutions do you check this? I think I obsess about details, but thankfully not about this! You should be able to use `text-wrap: pretty;` to eventually remove orphans. If you sometimes want them on purpose and sometimes avoid them, that's just weird. I'm sure this is a lost fight: it'll look different with different setups anyway. Different browser, different OS, different fonts, ... it's a lost battle. > It helps reduce page load speeds for visitors and saves bandwidth for both the visitor and your server. Mhm I just use apache's cache_dist[0]. It works fine out of the box, for all my myriads of websites. Yes sometimes there's a new file and a browser is stuck on the old version. Requires a hard refresh. Someone who doesn't know will see the old version. I don't particularly mind that. I guess you're more of a perfectionist than I am. [0]: https://httpd.apache.org/docs/2.4/mod/mod_cache_disk.html https://httpd.apache.org/docs/2.4/mod/mod_cache_disk.html

by nickjj 10mo ago

tasuki 10mo ago

> About a year ago I converted my 500+ post Jekyll blog to Hugo Why? I'm using Jekyll and been happy with it. What am I missing?

nickjj 10mo ago
The blog post linked in my previous comment covers the why and everything else.
- tasuki 10mo ago
  Right, I missed that! > That gives near instant live reload when writing posts which makes a huge difference from waiting 4 seconds. Mhm. Why? I can write all of my post and look at it only afterwards? Perhaps if there's a table or something tricky I want to check before. But normally, I couldn't care less about the reload speed. > I use that plugin because it digests your assets by adding a SHA-256 hash to their file names. This lets me cache them with nginx. I can’t not have that feature. Why?
  - nickjj 10mo ago
    > Mhm. Why? I can write all of my post and look at it only afterwards? My site has a fixed max width which is what most tablets or desktops will view it as. Sentence display width is something I pay attention to. For example sometimes I don't want 1 hanging word to have its own full line (a "hanger") because it looks messy. Other times I do want it because it helps break up a few paragraphs of similar length to make it easier to skim. Seeing exactly what my site looks like while writing lets me see these things as I'm writing and having a fast preview enables that. Waiting 4 seconds stinks. > Why? [asset digesting and cache busting with nginx] It helps reduce page load speeds for visitors and saves bandwidth for both the visitor and your server. If their browser already has the exact CSS or JS file cached locally, this allows you to skip a server side call to even determine if the asset can be served locally or needs an update from the server. The concept of digesting assets with infinitely long cache header times isn't new or something I came up with. It's been around for like 10+ years as a general purpose optimization.
    - tasuki 10mo ago
      > Sentence display width is something I pay attention to. For example sometimes I don't want 1 hanging word to have its own full line (a "hanger") because it looks messy. Other times I do want it because it helps break up a few paragraphs of similar length to make it easier to skim. Isn't your website responsive? If it is, for how many different resolutions do you check this? I think I obsess about details, but thankfully not about this! You should be able to use `text-wrap: pretty;` to eventually remove orphans. If you sometimes want them on purpose and sometimes avoid them, that's just weird. I'm sure this is a lost fight: it'll look different with different setups anyway. Different browser, different OS, different fonts, ... it's a lost battle. > It helps reduce page load speeds for visitors and saves bandwidth for both the visitor and your server. Mhm I just use apache's cache_dist[0]. It works fine out of the box, for all my myriads of websites. Yes sometimes there's a new file and a browser is stuck on the old version. Requires a hard refresh. Someone who doesn't know will see the old version. I don't particularly mind that. I guess you're more of a perfectionist than I am. [0]: https://httpd.apache.org/docs/2.4/mod/mod_cache_disk.html https://httpd.apache.org/docs/2.4/mod/mod_cache_disk.html