Hi all – I see tons of JavaScript in a lot of the Hugo themes. I expected this because pretty much all web themes or templates I’ve seen have tons of JS, usually an old version of jQuery, maybe Bootstrap or React and others.
What I’ve never been able to understand is why static sites need a ton of JS, especially blogs or academic sites (presenting a CV, publications, etc.). I don’t know enough about JavaScript to trace exactly what it’s all doing, though I’m pretty sure a lot of it is unused (especially when it comes to big libraries like jQuery).
I’m trying to build two awesome, beautiful, lean, and fast static sites (with comments). I’m going the AMP way by default, where the CSS is all in the head. (Major AMP sites still have tons of unused CSS even though it’s in the head – I use unCSS and PureCSS to treeshake all the unused CSS.) I also want minimal JS, unlike AMP, but it’s harder to figure out. Has anyone successfully treeshaked the JS in their Hugo theme? How much were you able to delete?
If it helps any, I’ve built a very lean Hugo starter kit called Indiego, hardly any JavaScript at all. It’s designed for frontend developers who want to use modular CSS (using gulp js build process) and microformats to build simple blogs. GitHub repo: https://github.com/growdigital/indiego/ (it is a bit 0.1.3 so be careful!)
I always strip a theme I use from all JavaScript. Then when I’ve adjusted the theme to my taste/needs, I write my own plain JavaScript for the few features I need. In my case that’s only JavaScript for ga-lite, defer loading images, and a ‘back to top’ button.
My unofficial policy is to never use libraries like jQuery for any website I work on.
So I’m fully on board with what you’re saying, I also see a lot of JavaScript that serves no purpose (for me, that is, of course). But this does make me a bit curious why you want to use AMP? That’s in my view also adding JavaScript that doesn’t add much value – I doubt a static website served with AMP is much quicker than the regular page (assuming you did other basic speed optimisations already).
This is a great article on AMP in my view: AMP, the missing controversy (also looks at the website speed performance of AMP).
Edit: Just to clarify, I don’t want to say that people should not use AMP. That’s the decision for each of us. I just mean to say that AMP does not necessarily bring that much performance benefits. So I’d suggest to do some tests before and after to see if it helps your website.
Not much JS in my theme at all! Will have less when I get round to removing a dependency on FontAwesome.
I only use it for things that help user interactions and I’ve been trying to find alternatives where possible. For example, my social media buttons are all static, no JS required.
Thanks @growdigital. That looks like a great project. By microformats, do you mean Schema.org? I’d love to find an easier way to use Schema.org.
Thanks @Jura. That’s awesome that you strip out all the JS to start with. What usually breaks, if anything, when you strip all the JS? What themes did you do this on?
As for your “why AMP?” question, I want to use it for the search/SEO benefits. I want my articles to make it into the carousel of AMP pages at the top of Google search results. (I’m not sure if Bing or Yandex have similar top-of-search-results features.)
@TotallyInformation, nice! I like static social media buttons. Font Awesome can be surprisingly heavy. One of the things that annoys me is that sites will sometimes force my browser to download the font files even though I have Font Awesome installed on all my PCs. I have a lot of web fonts installed on my machine, always the latest releases from GitHub repos: Open Sans, Roboto, Merriweather, Noto, Font Awesome, etc. but if the CSS don’t have that source: local syntax I have to download the fonts I already have over and over all over the web.
I think browsers should have all major JS and CSS libraries permanently installed in the browser itself, and highly optimized. It would only take a few MB, even with having every release of jQuery, Angular, React, etc. because of the compaction opportunities from the fact that releases will be very similar to each other and will have large amounts of identical code. And web fonts too. No one should ever have to download Open Sans or Font Awesome. The JS libraries could be highly optimized by grabbing the typed versions of them (Definitely Typed project) or by creating fresh type-annotated versions and putting them through something like Google’s Closure Compiler, which can use type annotations to optimize the JS. Then this optimized JS could either be pre-parsed or even pre-compiled (most of it) and stored in an efficient binary format kind of like WebAssembly. It would be so much faster and waste a lot less bandwidth.
Thanks. Yes, I’ve already replaced most of what I was using FA for with SVG images which should cache properly. Just need to find some time to do the remaining few. The only sticking point was about.me but I don’t need that any more.
Well, it is an interesting approach and certainly would have benefits. But it also introduces a LOT of complexity and some potentially large security issues.
I think what might be better would be a more standardised caching mechanism. Perhaps with whitelisted caches that would agree on URL structures for libraries and versions. That would make the caching more robust, would still allow for multiple versions and updates and would let users control security.
IMHO AMP is about as parasitic as just about everything Google does to destroy the Web. But nothing is more pleasing than watching tech giants cough twitter cough make multi-million dollar mistakes leaning into another Google web failure.
I almost built my theme with HTML2 until I realized I couldn’t use block level containing elements. As for themes, if they use too much JS they won’t work with Telegram Instant View so we’re lucky at least one company with with over 200 million MAU is helping improve the Open Web.
Most often the mobile menus break, but that’s totally fine for me because I typically redo the whole theme (CSS, Hugo templates, and throw away the JavaScript) when I use a Hugo theme.
It’s a bit of an odd (and time consuming process), but I find it easier to start with a Hugo theme and then strip away everything I don’t want or like. Then when the theme is clean, I re-add Hugo template code and JavaScript when needed. Then I go through the CSS file by hand and remove unneeded selectors and simplify the others so that the CSS file is as lightweight as possible.
It’s probably a lot more efficient to start with hugo new theme and then add only the stuff I need and want. But for some reason it’s easier for me to think about what needs to be removed from a theme than what I need to add.
I’ve used Mainroad, Icarus, Ghostwriter, Hyde in the past. (Those were already quite lightweight themes to begin with.)
Totally agree. Web fonts are not worth the speed and privacy sacrifice, I think.
CSS font stack is a great website to see which fonts are installed on which percentage of computers, for those interested. That way people can still use great looking fonts with wide support.
Thanks for sharing. I’m not sure how to split this into a new topic so I’m going to cross-link this with another thread where JSON-LD was being discussed recently in case someone is looking for a complete example.
I’m not entirely finished with it, but I migrated my javascript-free Jekyll theme to Hugo earlier this year. It may have some useful examples, but a fair warning that it’s my first Hugo theme and it’s a port so there may be some strange choices in there.
It’s built with a minimal CSS grid + flexbox layout with no javascript (except optionally NetlifyCMS).
. Rather than use microdata inline attributes, you can use JSON-LD. Apparently a lot easier but I haven’t used it yet: 
. TBH, I just include the microformats in