Comment by slathrop | Hacker News Reader

Comment by slathrop | Hacker News Reader

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 complexity of the Golang templates was clearly going to be tedious, inflexible, and tough to maintain.

So I settled on using Hugo to generate a read-only REST API instead[4], based on a nice blog post I had read[5][6].

This freed me to use any front-end framework I wished, and I chose Vue, Vuetify, and Axios for their simplicity and productivity on this solo-developer project.

In the end I was quite happy with this combination. Hugo was incredibly fast and productive for ranging over and manipulating all of the JSON/YAML/TOML data files to produce the final read-only REST API JSON... after the initial learning curve with Golang templates.

And the front-end really just boiled down to some key Lodash transformations of the JSON into the various shapes of data that were needed for tabular reports and Chart.js graphs.

[1] https://app.rrpm.run/ [2] https://github.com/railroadpm/site [3] http://www.railroadpm.org/ [4] https://api.rrpm.run/reports/bnsf/all [5] https://discourse.gohugo.io/t/build-a-json-api-with-hugos-cu... [6] https://forestry.io/blog/build-a-json-api-with-hugo/

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/

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.

You shouldn't rely on third-party fonts (some people like me block those) for your graphical design. This is how that page looks in my Chrome: https://i.imgur.com/y03EQBc.png (using uBlock Origin with Fanboy's Anti-thirdparty Fonts blocking list: https://www.fanboy.co.nz/fanboy-antifonts.txt). At least host those fonts yourself.

Meanwhile the old page works perfectly.

I understand that you and some others may block 3rd party fonts, but the percentage of people that do this has to be tiny, no? I’d venture it’s around the amount that block all JavaScript.

Sure you should have your sites work without JavaScript and probably host all your fonts. I personally do that usually, but from a building standpoint, I’m assuming 3rd party fonts or forcing JavaScript for a normal site is going to be fine for more than 95% of your users.

It's not really a question of how many people are savvy enough to protect themselves from 3rd-party data collection.

I don't know how you feel about the GDPR (or the data brokerage industry, in general), but if web developers want to minimize government regulations we should probably architect our sites so as to minimize 3rd-party data collection of PII in the first place (which is enabled by including 3rd-party fonts).

Thanks for that suggestion and screenshot!

Thanks for sharing this. Fascinating!

I'm a big fan of serving content APIs as static assets like you are doing here. Especially good for content which changes infrequently (a few times a day rather than many times a minute).

Static site generators typically make it simple to publish a structured data view like a JSON or XML feed of content alongside content pages as HTML (such a bonus!), but it is interesting to see that you've separated the API generation entirely as a Hugo build. (presumably for compile speed?)

I work at Netlify and am something of a JAMstack enthusiast. I'd love to learn more about the experience of designing and building this. If you'd be interested in doing more of a write up, or just sharing any of the learnings from along the way, I'd love to chat.

(https://twitter.com/philhawksworth)

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")

Reply on news.ycombinator.com