Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Migrating from Jekyll to Hugo

dannyguo.com

Post reply on HN
Print view View original

51–60 of 92 posts

Re: Migrating from Jekyll to Hugo

#51

Post by slathrop »

Avshalom wrote: post #34
slathrop wrote: post #18

I recently completed a pretty fun little website[1] for the U.S. freight rail industry using Hugo, Vue.js, Nuxt, Vuetify, Chart.js and Netlify. It is open source on GitHub[2]. It will soon replace an aging version of the site[3] that was built with Sitecore CMS, .NET, and SQL Server. At first I considered using Hugo to generate the HTML for the site from git-backed JSON/YAML/TOML files. But the quantity and complexit…

Pretty sure you have conflated the abilities of the half dozen frontend frameworks you added (for simplicity) with the the backend you replaced. ".Net" (not actually a specific backend) and an rdbms are not in any significant way a friction against a REST api. Mean while the only noticable difference between the sites is the front end.

My comment above was intended to add some value and perspective on using Hugo in a real world business/industry/paying customer website scenario... something beyond a personal blog.

So RE: the main discussion here about Jekyll and Hugo and static site generators (SSGs), I think that if you take a moment to consider the difference between the SSG/JAMstack approach vs. the traditional "build the response on every request" back-end approach (and I'm not picking on .NET and SQL Server there, I've developed many sites using them myself) you'll see that there are some huge differences[1].

I think the most important difference is that with SSGs and JAMstack, your back-end code only runs at build time, on free build server infrastructure. There is no runtime back-end code, and therefore you can operate these JAMstack sites, at scale, at zero or near-zero operating cost. In the case of my customer, I estimate I saved them $100K over the life of this new site. Of course, your use-case must align with this sort of architecture. Not every site can or should be totally re-generated when content is changed.

And importantly for my customer, they did not have to sacrifice a nice, user-friendly content-management experience. I happen to be using Netlify CMS, but others like Contentful and Forestry are nice options too[2].

[1] https://youtu.be/uWTMEDEPw8c [2] https://headlesscms.org/

Re: Migrating from Jekyll to Hugo

#52

Post by dguo »

rammy1234 wrote: post #39

I agree to most of your points. I too recently moved from jekyll to Hugo and I know I did not make a bad choice. It is awesome and making me to write more. Hosted on github pages. https://www.rammy.in

Hey, just giving you a heads up that the www version of your site gives me an SSL error. https://rammy.in works though.

Re: Migrating from Jekyll to Hugo

#53

Post by slathrop »

Waterluvian wrote: post #50
slathrop wrote: post #18

I recently completed a pretty fun little website[1] for the U.S. freight rail industry using Hugo, Vue.js, Nuxt, Vuetify, Chart.js and Netlify. It is open source on GitHub[2]. It will soon replace an aging version of the site[3] that was built with Sitecore CMS, .NET, and SQL Server. At first I considered using Hugo to generate the HTML for the site from git-backed JSON/YAML/TOML files. But the quantity and complexit…

What are lodash transformations?

Good question! Sorry to be kind of cryptic there in the interest of brevity.

Lodash is sort of a query language for data in JavaScript. The name is a play on Underscore, the name of a rival implementation. So Lodash is literally a "lowered dash character"... i.e., an underscore.

Anyway, here's an example in the code for the website I mentioned above[1].

In this example, Lodash is wrapping a JavaScript array of objects named "rows", filtering out just the "keys" in the objects, further filtering down to only the ones that are numeric, and then mapping those to an array of strings that are properly-formatted dates.

The original array came from Hugo-generated JSON exposed as a read-only REST API[2]

[1] https://github.com/railroadpm/site/blob/master/app/component... [2] https://api.rrpm.run/reports/bnsf/current (see "rows")

Re: Migrating from Jekyll to Hugo

#54

Post by gschier »

sandGorgon wrote: post #41

The momentum around static site builders is around the react based builders like Gatsby. Since you are going to spend a huge amount of time writing js code for the front-end anyways, it makes sense for the whole stack to be js. We moved from Hugo to Gatsby for primarily this reason. I can now handover the site to js folk ...instead of having them learn golang based templates.

I went this way too. If your site has a dynamic/interactive frontend, Gatsby makes it super easy to build a static-but-interactive site. Another huge plus with Gatsby is that it uses React's server-side-rendering to ensure that the site is still seo-friendly.

If you have more than a few snippets of JS on your site, Hugo comes up way short. It's great for simple things though.

Re: Migrating from Jekyll to Hugo

#55

Post by haskellandchill »

Avshalom wrote: post #34
slathrop wrote: post #18

I recently completed a pretty fun little website[1] for the U.S. freight rail industry using Hugo, Vue.js, Nuxt, Vuetify, Chart.js and Netlify. It is open source on GitHub[2]. It will soon replace an aging version of the site[3] that was built with Sitecore CMS, .NET, and SQL Server. At first I considered using Hugo to generate the HTML for the site from git-backed JSON/YAML/TOML files. But the quantity and complexit…

Pretty sure you have conflated the abilities of the half dozen frontend frameworks you added (for simplicity) with the the backend you replaced. ".Net" (not actually a specific backend) and an rdbms are not in any significant way a friction against a REST api. Mean while the only noticable difference between the sites is the front end.

We’ve mostly lost track of our ability to talk about things of technical interest on the front end. It’s common to see framework soup (though OP explained themselves well in their response). I have to put headphones on when junior engineers talk JavaScript tech, it makes me too angry/amused and they probably should be talking about it anyway since it will help their careers if they pick the right ones.

Sadly a similar thing has happened to programming languages, we use languages just for their libraries. The language itself must be treated as an empty vessel for the ML/Numeric/Web/Physics whatever it is you need. Or programmers you need to hire. This bothers me but is the purpose of our industry, to minimize construction time through reuse.

Re: Migrating from Jekyll to Hugo

#56

Post by RobertRoberts »

Aaaaaand this is why I don't jump on the latest frameworks anymore... I can almost hold my breath long enough for a framework to go out of style.

The first time I read about Jekyll was here, and now already something better has come along, my brain just gave me that tiny little mental high-five on my decision to no longer live on the bleeding edge

Re: Migrating from Jekyll to Hugo

#58

Post by sidmani »

kchoudhu wrote: post #13

I feel like people spend more time migrating blogging engines than actually blogging.

I found the existing static site generators confusing and wrote my own, which ended up being equally confusing for everyone except me. Whatever works, I guess. https://github.com/sidmani/anodize

Re: Migrating from Jekyll to Hugo

#59

Post by veidr »

kaushalmodi wrote: post #48
nickjj wrote: post #6

Earlier quoted context omitted.

md5 tagging at the Hugo level has been talked about since 2014 and it's still no where on the horizon. If SASS support still isn't out yet, who knows how long "later" is. > Once that’s added the reasons to use Jekyll, which is essentially abandonware, will shrink to zero. They are working hard on Jekyll 4.x and huge sites like Docker's documentation[0] use Jekyll. I'd still feel comfortable using it today. It really…

> md5 tagging at the Hugo level has been talked about since 2014 and it's still no where on the horizon. If SASS support still isn't out yet, who knows how long "later" is. As someone who follows Hugo development closely, I wouldn't be surprised if both md5 tagging (fingerprinting) and sass support is out in the next week :) See the Hugo Discourse for more details.

Specifically: https://discourse.gohugo.io/t/coming-soon-sass-support-and-m...

Re: Migrating from Jekyll to Hugo

#60

Post by slathrop »

sandGorgon wrote: post #41

The momentum around static site builders is around the react based builders like Gatsby. Since you are going to spend a huge amount of time writing js code for the front-end anyways, it makes sense for the whole stack to be js. We moved from Hugo to Gatsby for primarily this reason. I can now handover the site to js folk ...instead of having them learn golang based templates.

I ended up with a hybrid approach where Hugo and Golang templates are only for building the data (TOML files) into the required JSON for a read-only REST API. The remainder of the solution is all JavaScript (in my case Vue and Nuxt instead of React and Next).

I came very close to switching to Gatsby early on, and I am very curious to know how my project[1] would have gone with Gatsby instead of Hugo.

I get the impression that for the data manipulation (avoiding complex Golang templates that generate HTML) and for build speed, Hugo takes it. Certainly if you are working in React the simplicity of a single framework is the way to go, as you did.

I also kind of felt a little more weird about mixing Gatsby and React with my preferred front-end framework, Vue, than I did about having to combine Golang template logic in one layer (API) with JavaScript in another layer (App).

[1] https://github.com/railroadpm/site

Post reply on HN