Posts in Jamstack (5 found)
neilzone Today

Speeding up static site generation with BSSG

Three months ago, I moved from hugo to BSSG for this blog (and my work blog). You can get BSSG here . I’ve been really happy with BSSG, and a couple of recent changes by Stefano have made it even better. I have a minimalist blog. A list of posts on the front page, and generally text-only posts. I like it to load fast even though it is running on a Raspberry Pi 4, along with a couple of other bits. This means that there are some features of BSSG that I do not use, including descriptions of blogposts. I use the title for that, on the basis that this should be informative in itself. It suits me, anyway. There are also some other UI elements that I do not need, such as reading time. I bodged my way around these, using CSS rules to hide the unwanted content from display. I could have changed the code to neither generate nor display them, but I didn’t really want to run, and need to maintain, my own branch. With the recent changes, Stefano added some new config options: These are set to “true” by default - to preserve the experience for people who already use BSSG and expect these things, which makes sense to me - but now I can set them to “false”, and have an even slicker, faster experience. The second brilliant change is about the way the scripts handle incremental updates. The idea being that, rather than building every post, every time, it will just build the new posts. I struggled to get this to work initially, as it was building all posts, every time. This turned out to be entirely down to me: my build script, which I use to control building and deploying both the cleartext and .onion versions of the blogs, cleared the output directory each time. I removed that, and bingo, incremental updates! This combination of things meant that building each site went from ~10 minutes (which was a bit painful) to ~1 minute (which is fine!). Happy days.

css CSS Jamstack web-development Web Development performance Performance
0 views
Alex White's Blog 5 days ago

Having fun with static generation

I recently moved my blog to Astro . Since then I’ve been having an absolute blast with the static site generation process! I love being able to hydrate the site with dynamic data while keeping things fast on the server. It reminds me of HotSyncing data onto a Palm Pilot (how could I not reference Palm Pilots after my last post ). Here’s a few cool things that happen when my site is built: I started using GoatCounter (awesome service) and have been leveraging their API to show stats on my site via a custom build plugin. My analytics page now shows statically generated graphs of the analytics data as of the last site build. Additionally, posts now feature a “readers” count in the header. The previous iteration of my blog featured dithered images. While this was partly an aesthetic choice, it also greatly reduces the size of images. The downside was the amount of work involved in manually dithering images via ImageMagick for each post. Thanks to my new build process I was able to build a custom plugin that creates dithered copies of every image across all posts. It replaces images with a dithered copy, and then wraps the image with a link that points to the original full color version. I also have an escape hatch where I can specify a front matter flag in a post to skip dithering. This functionality came out of the box with my theme ( Astro Sienna ). Webmentions are fetched during build and displayed on the relevant post. I haven't seen this in action yet since I don't have any webmentions, but it's still super cool! Another plugin that came with my theme is the dynamic generation of meta images for sharing on social media. The plugin gathers info from the post and dynamically generates a png image at build time. Very cool! It’s been a lot of fun messing around with my new toy, maybe this means I’ll go longer than 2 months without changing my entire site! ...maybe... Thanks for reading on RSS, you're awesome! If you want to be notified of new posts even faster, I have a newsletter as well, you can signup here!

Jamstack frontend Frontend web-development Web Development
0 views
Kev Quirk 6 months ago

Static Site Generators

Jan talks about how static site generators are far more complicated than WordPress, despite (ironically) their output being far simpler. Read Post → I enjoyed this post from Jan once I’d translated it from Dutch and could actually read it. He talks about the irony of how the output of a static site generator is so simple, yet they’re somehow difficult to set up and maintain. Since I’ve been around the block when it comes to blogging platforms, I have some thoughts on this. While talking about his time testing Jekyll , Jan says: Ruby dependency mess, this is not what anyone wants, drama. I get where he’s coming from. Dependency issues with Ruby can be annoying. But honestly, I can’t say I’ve had any real problems with Jekyll while using Ubuntu. For me it’s been as simple as following the install instructions , running a quick , and I was off to the races. Yes, setting up a static site is definitely more involved than installing WordPress. I completely agree there. But once it’s up and running, I’ve found there’s very little ongoing maintenance. The worst it gets for me is when a gem updates and I need to run before getting back to work. WordPress, on the other hand, has always been more frustrating for me to manage. There’s just so much noise in the admin UI. So many panels, so many settings, so much stuff most people will never touch. And then you have plugins, their updates, their banners, their upsells. It becomes… messy. That said, if you’re willing to ignore those frustrations, WordPress can be simple. Especially if you stick to an off-the-shelf theme and don’t tinker. The truth is, it’s great that we have all these options. Different people have different expectations, preferences, and levels of comfort. Some folks want a managed dashboard full of knobs and switches. Others want a quiet folder of Markdown files and a build command. I don’t agree that static site generators are inherently more difficult than WordPress. It really comes down to the use case and the person using the tool. Anyway, go read Jan’s post — it’s interesting. And if you have opinions, drop me an email or leave a comment below. Thanks for reading this post via RSS. RSS is great, and you're great for using it. ❤️ Reply to this post by email

ruby Ruby Jamstack web-development Web Development
0 views
Kev Quirk 6 months ago

RE: Why Do You Need Big Tech for Your SSG?

Loren posts a response arguing that while self-hosting and local builds have their charm, the simplicity and zero-maintenance nature of services like Netlify often make them the more practical choice for small personal sites. Read Post → I enjoyed this post as it approaches the problem I wrote about yesterday from a completely different perspective. While I spoke about rolling my own infrastructure and building locally to maintain control, Loren talks about the simplicity and cost (free!) of hosting with services like Netlify. Loren closes his post by saying: If you’re running a complex site or you’re philosophically opposed to big platforms, a VPS + rsync pipeline might be worth it. […] For my tiny, low-traffic static site, the convenience, zero cost, and redirect handling of GitHub + Netlify are hard to beat. I think this is the crux of the whole discussion. For me, it’s more about control than being opposed to big platform. I think they have their place, but for my use case, my personal blog isn’t it. For Loren, it’s all about simplicity and just getting shit done. It’s fantastic that we have different options that allow for more control, or for ease of use. As a result, we have a diverse pool of people and opinions on the Indie Web, and I don’t think anyone can argue against that being a good thing. Thanks for reading this post via RSS. RSS is great, and you're great for using it. ❤️ Reply to this post by email

Jamstack web-development Web Development devops DevOps
0 views
Kev Quirk 6 months ago

Why Do You Need Big Tech for Your SSG?

A look at why small, personal websites don’t need big-tech static hosting, and how a simple local build and rsync workflow gives you faster deploys, more control, and far fewer dependencies. OK, so Cloudflare shit the bed yesterday and the Internet went into meltdown. A config file grew too big and half the bloody web fell over. How fragile . It got me thinking about my fellow small-web compatriots, their SSG workflows, and why on earth so many rely on services like Cloudflare Pages and Netlify. For personal sites it feels incredibly wasteful: you’re spinning up a VM, building your site, pushing the result to their platform, then tearing the VM down again. Why not just build the site on your local machine? You’re not beholden to anyone, and you can host your site anywhere you like. All you need is a hosting package that supports SSH (or FTP if you must) and a small script to build your site and rsync any changes. Here’s the core of my deployment script: Here’s what it does: That’s it. And that’s all it needs to do. With these few lines of Bash, I can deploy anywhere, without waiting for someone else’s infrastructure to spin up a build container. My full script also checks the git status, commits changes, and clears the Bunny CDN cache, but none of that’s required. The snippet above does everything Cloudflare Pages and similar services do — and does it much quicker. My entire deploy, including the extras, takes about eight seconds. If you’re hosting with one of the big static hosting platforms, why not consider moving away and actually owning your little corner of the web? They’re great for complex projects, but unnecessary for most personal sites. Then, the next time big tech has a brain fart, your patch of the web will probably sail right through it. Thanks for reading this post via RSS. RSS is great, and you're great for using it. ❤️ Reply to this post by email ✅ No CI/CD pipeline. ✅ No big tech — just you and your server. ✅ No VMs spinning up and down at the speed of a thousand gazelles. Jumps into the directory where my source website files live. Builds the Jekyll site locally. Syncs the built files to my server over SSH, deleting anything I’ve removed locally.

Jamstack devops DevOps Bash web-development Web Development
0 views