Static-Site Generator


#1

Hello, Folks,

Not sure where to post this, as I can’t in the Git forum for some reason (and why is that? Anyone know??), but while trying to get into Git through GitHub I came upon this static-site generator stuff due to GitHub Pages…and I really don’t understand the point so could someone kindly explain it to me?

Specifically, why not just code in HTML instead?? All I see on Google is stuff about how Jekyll generates lean lightweight sites for folks who don’t need databases, but it seems like people could just go put up a good old-fashioned HTML site if they want Web 1.0 all over again! What is the point of a Jekyll over HTML??? I haven’t seen that addressed; all I see is static-site generators being compared to full-fledged CMSes like WordPress and Drupal but never compared to simple HTML…

Thanks for any insight!


#2

To be honest, I never made it through this course. Somewhere I hit a wall and gave it a pass.

Let’s think of what concerns even a static site will have. Say it goes viral and millions of hits come pouring in on the same day. Given that there is no compression on static HTML uploaded to a domain (unless we actually go to the trouble) our site’s server would be under a very heavy load that day. Perhaps to excess. And we might get a whopping bandwidth bill. Might.

Something of value would be a system that can retrieve requested pages, then bundle and compress all the components of the page before sending them down. At the other end (the client) everything would be unpacked and handed to the DOM to parse into its tree. If Jekyll facilitates all this, then I should be jumping on board immediately, assuming I have a going concern site that might go viral or have millions of visitors.

From a conscientious standpoint of view, it behooves all websites to lower their bandwidth consumption on the web. This is needed to offset the rapid growth of the consumer base. CDN’s help to localize responses to requests in terms of resources but the domain is taking a hit if none of its downloads are compressed.

As small, static HTML sites go, none of the above seems relevant. How much are they going to be in demand? From my experience the robots far outweigh the user base in terms of hits. We can control them, if needs be, to a certain degree if they seem to be taking a toll on bandwidth, but I rather doubt this is an issue nowadays. It was in the past.

Forward thinking is what the web has been built upon. Always thinking, always considering, always devising new ways. It’s the living web that we are all embarking upon. If Jekyll is a useful tool that can make a static site more responsive to the web, and use less bandwidth, and give faster page load times, then it should be considered viable, even to a small concern. It’s still a going concern, static or not. Keeping up with web standards is never a bad idea.


#3

Hmm, that’s interesting! I wonder why you lost interest?

I’m just about to possibly begin – I really don’t wanna learn Git and GitHub but it seems de rigueur and I was hoping it’d at least be easy (and not just easier than programming)…

Maybe I overestimate the power of current technology but I don’t think a simple static site, even with hundreds of plain ol’ uncompressed (not Minified) HTML pages, could crash a typical web host’s server these days simply on account of “virality”…

Anyway, I remain puzzled by the existence, never mind mild proliferation, of static-site generators…especially when they all seem to require a bit of under-the-hood tinkering (installing Ruby first, and then Ruby Gems, and maybe learning Markdown, in the case of Jekyll)…it’s like going to LMGTFY.com instead of directly to Google.com!!


#4

Sorry, to repeat, I’m not well informed around this stuff and without having implemented any of it have no experience to draw upon. I’m old school… Static and PHP driven sites. Hopefully someone will pipe in who can gvie a more qualified answer.


#5

LOL: seems like you’re one of the only three other people around these forums!! :wink:


#6

There’s very little activity on the free side. The Pro side has advisors, coaches and a private Slack channel so we don’t see much of that traffic.


#7

The primary benefit of static site generators over raw HTML is that you can use templates, rather than copy/pasting a header or footer or other module onto each page. For example, on my personal site, which uses Jekyll, I could write this:

---
layout: page
permalink: /lorem-ipsum.html
title: Lorem Ipsum
---

Quibusdam itaque est incidunt...

And get this output, with all of the <head>...</head> content and the footer automatically added by the generator:

(for a more impressive example, Smashing Magazine uses Hugo, another SSG that competes with Jekyll).

Another nice feature most of the popular SSGs have is code syntax highlighting. For example, on my personal website I have this code snippet on a page:

<img src="https://fake" onerror="alert('XSS');">

In order to highlight it, Jekyll produced this code:

<code><span class="nt">&lt;img</span> <span class="na">src=</span><span class="s">"https://fake"</span> <span class="na">onerror=</span><span class="s">"alert('XSS');"</span><span class="nt">&gt;</span>
</code>

Obviously, you wouldn’t want to do that by hand, especially for a long code block.

Anyway, I remain puzzled by the existence, never mind mild proliferation, of static-site generators…especially when they all seem to require a bit of under-the-hood tinkering (installing Ruby first, and then Ruby Gems, and maybe learning Markdown, in the case of Jekyll)…it’s like going to LMGTFY.com instead of directly to Google.com!!

It will take longer to learn how to use an SSG on top of HTML rather than just writing plain HTML, but it’s worth it in some scenarios:

  • You publish a lot of content
  • You have a lot of “pieces” of your page that repeat themselves throughout the site
  • You just dislike (or don’t know) HTML and prefer writing plain text instead

The time savings may not be worth it for many situations in which they’re used, but the easiness of using an SSG once it’s set up also draws a lot of people in.

Jekyll is sort of like a bridge between WordPress and straight HTML. An author doesn’t have to know code to add a new article to a website, but the result is still cleanly generated HTML files and no need for a database or PHP, and the security problems that come with them.


#8

Wow!! That’s really surprising! 'Cause, you know, “information wants to be free” and all that…

I’m really shocked…I’d looked over the Pro offerings and while fairly affordable (and I’m a low-wage earner in NYC so really, Pro is affordable), I couldn’t discern any value except maybe for the portfolio projects and personal feedback on them – which is why once I’m up to speed on the basic to intermediate stuff, I’ll sign up for Pro for portfolio-building purposes.


#9

Oh h e l l no!

I just came from 2.75 man-hours puzzling over Netlify’s Hugo integration…Good God but talk about a wild-goose chase!! 'Cause it turns out that the one-click installation Netlify provides isn’t a standard Hugo installation but customized so I’m googling left and right only to eventually find out on their Gitter channel – after wading through a bunch of posts hastily written in broken English, mind you – that basically it’s a special case, that one-click install, and the usual rules don’t always apply!

Sigh…the more things change (quick fast easy clean) the more they stay the same (poor documentation that’s behind the current feature-set, users-as-guinea-pigs for MVP testing, time savings eaten up by clunky interfaces and workflows)…

I’ve been putting up WordPress sites for years (until about three years ago), way back when it had just gone to Version 3, and I’ve seen security patches frequently – a robust “Justice League” of superhero coders watches over the digital gotham that is a WordPress installation and I’ve never read of anyone’s WordPress site being hacked to death who had taken all the typically simple proper precautions.

Good description, though – but I think these static-site adopters are basically geeks who just like new toys…I’ve yet to come across any Jekyll, Hugo, or Gatsby site that seems “serious” (the most such prominent example was Obama’s fundraiser site or some-such that used Jekyll)…it’s like Linux – most people don’t wanna be wading waist-high in the weeds getting bit by mosquitoes and snakes; they just wanna get to the Promised Land (“everyone wants to go to Heaven but nobody wants to die first”)…


#10

Careful. Lots of newbies might think this is an easy way out, without realizing what a content creator really is.


#11

@stillyetanotherstude

I just came from 2.75 man-hours puzzling over Netlify’s Hugo integration

I haven’t used Hugo at all, and Netlify only a little with my Jekyll site (it worked fine). Netlify isn’t the only place to host a site, though. Theoretically, with a static site, you just have to build it, then transport the HTML files to your server, wherever that is.

I host my website in a VM with SSH access, and do exactly that using rsync for deploys:

$ bundle exec jekyll build
$ rsync -a _site/ user@server:/site/directory/

I’ve never had any issues doing it this way, and I could switch to any other hosting provider that allows rsync/SSH access without needing to change my deploy process.

If Netlify wants to use a custom version of Hugo, it seems to me that issues arising from that should be blamed on Netlify, not Hugo.

I’ve seen security patches frequently – a robust “Justice League” of superhero coders watches over the digital gotham that is a WordPress installation and I’ve never read of anyone’s WordPress site being hacked to death who had taken all the typically simple proper precautions.

Yes, WordPress has lots of contributions to keep it secure, but that’s the point with static sites: they don’t need any patches applied. And applying patches to a CMS gets old after a while :slight_smile: (I had to patch 20-ish sites once, keeping 3 different environments for each site in sync - not fun, or efficient)

WordPress sites get hacked more often than static HTML sites, but you’re correct about it being rare as long as reasonable security precautions are taken.

I think these static-site adopters are basically geeks who just like new toys

Yeah, that’s fair. I think the advantages of SSGs ought to make them more popular, but I also think that about Linux…

Still, it’s not any harder to set up an SSG than it is to install WordPress or any other CMS - it’s mostly a matter of what you’re used to and how much relevant experience you have. For example, a PHP developer probably won’t have any trouble setting up a new WP site, but messing with Ruby versions would confuse him, and vice-versa for, say, a Ruby on Rails developer trying to set up Postgres.

I wasn’t able to get either WordPress or Jekyll working the first time I tried each, but I got more experience and eventually came back to each of them, with no trouble installing/configuring either.


I guess we may differ on whether SSGs are practical to use, but I hope I was able to answer your questions satisfactorily?


#12

That’s what I’m talkin’ about!!

I thought these things are supposed to make life easier!!!

Geez it’s like I stumbled into “gearhead-world,” like ultimate-super-über-geek-land!!

Oh my Goodness…I have to say that I’m trying my damnedest not to tackle that challenge again as it’s lost me some several hours of JavaScript learnin’ time but I’m so ticked off that it’s like I feel like I gotta win that war now!!!


#13

Indeed, GitHub offers GitHub Pages! But now I’m really piqued by the challenge – of tinkering with that custom installation they’ve got set up…I just wanna change my theme but there’s no way to do that with their one-click install 'cause the normal theme-changing instructions don’t apply since it’s a Hugo customization that’s being used called Victor Hugo and not plain vanilla Hugo itself!

So frustrating…but I’m so damned tempted to throw myself at it again despite all the lost hours last week!!

LOL…their support dudes are friendly enough but they (I’ve been in touch with more than one now – more than three, even, as they each hand me off to someone else!) all insist that it’s most definitely not a Netlify matter!!

Erm…whaaaa?? Plain ol’ HTML sites can’t be hacked??? Sorry, I’m not following here…how are static sites any less vulnerable – unless you mean simply because they present less of a target (namely, a smaller target) simply due to consisting of less bytes because of not having databases and so forth…

Good Grief, I tried elementary OS, the most Windows-like Linux distro I could find, and guess what – needed to do good ol’ '70s/'80s CLI acrobatics simply to install stuff!! I mean, there’s a “service” or whatever that’s called built in that scans the 'net for updates but sometimes I’d still have to CLI for some reason or other…and then there are the constant password requests to do anything!!! In fact, I need to reinstall the old laptop with elementary OS on it 'cause I forgot my pasword and now can’t update or nothing on it!!! Sheesh…

Well, WordPress now has one-click installs on like every web host out there so it’s literally brainless, especially if you have a web host like Bluehost with the unlimited tech support (I can’t wait to go back to Bluehost one day, I love 'em so much – but right now I have no reason to have a site and that would totally distract me from trying to learn JavaScript [which, like, I’m very slow at learning as it is!])…that’s what I’d thought Netlify’s one-click install would be like, too…but they install a specific customization of Hugo for some reason, one that doesn’t always follow the rules for regular Hugo…

Yes, thanks so much for, uh, “commiserating,” kinda…I’d appreciate it if you could expound on how static sites are less of a security risk, though – thanks!!


#14

Plain ol’ HTML sites can’t be hacked??? Sorry, I’m not following here…how are static sites any less vulnerable – unless you mean simply because they present less of a target (namely, a smaller target) […]

Yes, pretty much. With a static HTML site, there are fewer potential entry points than with a dynamic site. Any software that accepts data from the user is a potential security issue, so you want as few as are necessary. A typical server running a static site pretty much has only two potential points of entry:

  • SSH
  • Webserver (Apache, nginx, etc.)

But a dynamic site has both of those, and accepts data from other places as well:

  • SSH
  • Webserver
  • Admin login
  • Comment section
  • Email subscription form

If you’re interested, you can look through the WP security release announcements at https://wordpress.org/news/category/security/. There aren’t a huge number of security releases, maybe 5-10 a year, but that’s still 5-10 updates more per year that need to be applied than when running a static site.


#15

Thanks for the outline there…I really appreciate it. I could’ve googled it all, of course, but then I’d probably wind up with different bits and pieces which as a beginner is hard to put together and see how they directly relate to my question – any question I as a beginner would have, really – so thanks very much for taking the time to describe things to me in terms of my question!

So let me ask another, then (!)…why would programmers, developers, coders – why would such people then rely on a Jekyll or Hugo or Gatsby or whatever instead of just doing their own HTML or writing up their own simple short static CMS?? Like, I don’t get it that all these developers and their websites which are just like Web 1.0 brochure-type sites with a few pages showcasing their portfolio, projects, et cetera…why not just leave it all in HTML, with a bit of Node or PHP or whatever for the occasional site-wide change…

Sorry, here’s the “logic” behind my continued puzzlement:

  1. CMSes let people focus on content creation, not code
  2. Dynamic CMSes are overkill for most use-cases
  3. But what do static CMSes actually manage in the case of a static site that has only a few pages and barely gets updated – why not just do this in plain HTML or code a short simple custom CMS of one’s own (since one is a web developer)?

Thanks again!!