slathrop's comments

There have been attempts at decentralization of git storage and collaboration. See for example:

https://cointelegraph.com/news/interview_yurii_rashkovskii_t...

I would love to see something like this succeed for all manner of infrastructure... from domains and DNS, to email, to version control.

Thanks for that suggestion and screenshot!

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

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

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/

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/

Nicely done. This is a must read for anyone stuck in "manual DOM querying and manipulation land" with jQuery looking to level-up using Vue.js as an excellent alternative.

By the time I got to the 2nd code example in this article, I was already rolling my eyes at the old jQuery approach I used for years: "Wait, is it .val() or .text() to pull the "value" out of that element?"(1)

Web devs who give Vue.js a try have to come away with a smile on their face. Sure, they may prefer React or Angular for a variety of reasons, such as team size. But Vue.js just makes it so darn easy to get started. It definitely helps to "progressively" adopt modern, model-driven approaches to web apps.

(1) https://stackoverflow.com/questions/807867/difference-betwee...

This is a terrific idea! The code I reviewed so far looks very well written. Thanks for this... folks looking to interview for a software developer position (especially at Google or with any group that emphasizes fundamentals) would do well to get acquainted with this repo!

Interesting that two "heavy" CMSs, SharePoint and Drupal, top the list of most "Dreaded" Platforms (Section II., 4th item after Languages, Libraries, and DBs).

I can see a number of reasons for this: (1) The new trend is toward the simplicity, security, speed, and flexibility of the JAMstack and new CMSs like Netlify CMS, (2) The learning curve for big CMSs is steep, and (3) It's extremely challenging to deliver modern, mobile responsive sites with these heavy CMSs in the timeframe that stakeholders expect. Stakeholders chose a CMS because they thought it would deliver their site faster and cheaper than custom development. So the deck can be stacked heavily against developers using SharePoint, for example, unless stakeholders are happy with using mostly the out-of-the-box (OOTB) UX.

Steve and a few others have done a little work recently on DotNetAnywhere (DNA) under this branch: https://github.com/ncave/DotNetAnywhere/commits/latest

But aside from these recent tweaks, the code hadn't been touched for about 5 years.

It's just a toy and POC for now, but interesting nonetheless.

JavaScript won't be unseated as the go-to language for web development and web frameworks by WASM, C#, Java, Python, Go, or anything else... at least not in the next decade.

But certainly high-performance pieces will be dropped-in via WASM to interop with JS for things like image manipulation, etc.

The "War Room" idea promoted by Scrum Masters and Project Managers has a similar downside. War Rooms take your best people and force them to answer questions all day long posed by your least-knowledgeable people. War Rooms are one of the surest ways to reduce the morale and productivity of your best people.

However, if you require real-time visibility of project status, you want all of your people to be easily interchangeable and replaceable, and you think that knowledge concentrated in a few good people is risky, then the War Room is for you.