41–50 of 92 posts
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.
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.
Earlier quoted context omitted.
The main advantage of a hash is that browsers will download the new version of your CSS/JS on the next page view, while still caching it «forever» If the url stays the same, you never know what version your visitors will get. You might publish a new version, but the user would not see it due to browser caches or proxies.
Caching something forever just doesn't impress me at all, it did when I first heard about the rails pipeline, but what matters to me more is that it's cached through a proxy or CDN, and that eTags prevent large files containing the exact same bytes from being sent repeatedly to the same client.
You are likely complacent because you're always on a good connection, since you keep arguing in these comments (even farther down) as if conditional GET requests obsolete other forms of caching.
The real benefit of ETags is that they generalize over all content dynamically, but they come at the cost of incurring more requests than expiration caching. I don't see how you could keep arguing here unless you didn't understand that trade-off.
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.
Why would I spend a huge amount of time writing JS for the front-end?
If you use reactjs based frameworks, you get the same amount of upfront effort as Hugo. It's not harder. However build times are slower.
But as your website complexity increases, you can leverage the reactjs ecosystem (both people and libraries). In Hugo, you get locked to their templating system. Which is nice...but very non standard and relatively non-Googleable.
Earlier quoted context omitted.
Funny, I wrote a blog about that: http://pokstad.com/2018/05/20/power-of-simplicity.html
I really liked your blog theme. Very neat!
Earlier quoted context omitted.
At least then you can blog about the blogging engine migration.
I personally enjoy the grand tradition of nerds writing blogs only about how they set up a blog.
Writing in Org mode has really reduced the writing block for me. I'm so glad I switched from Octopress to Hugo about maybe 2 years back.
Earlier quoted context omitted.
An asset pipeline (and templatized at that) is being added to Hugo as we speak. Just Sass support to begin with but more later. Once that’s added the reasons to use Jekyll, which is essentially abandonware, will shrink to zero.
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…
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.
I don't see myself moving from Jekyll for a long time. And it's mainly because of Jekyll-Assets. It's just too useful for not only bundling assets but effortlessly md5 tagging everything for caching on the nginx side of things. Hugo and others have nothing like this, and rolling your own set up isn't feasible for that because for it to be done right, it needs to be supported at the generator / plugin level so your te…
I do cache-busting > hugo > minification using a simple bash wrapper script. Though, in the coming week, Hugo might natively start supporting the cache busting and minification.
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…