Just ran across îles, a new static site generator mostly centered around Vue. The world has no particular shortage of static site generators, but it’s interesting to see what this “next generation” of SSGs seem to focus on or try to solve.
îles looks to take a heaping spoonful of inspiration from Astro. If we consider them together, along with other emerging and quickly-evolving SSGs, there is some similarities:
- Ship zero JavaScript by default. Interactive bits are opt-in — that’s what the islands metaphor is all about. Astro and îles do it at the per-component level and SvelteKit prefers it at the page level.
- Additional fanciness around controls for when hydration happens, like “when the browser is idle,” or “when the component is visible.”
- Use a fast build tool, like Vite which is Go-based esbuild under the hood. Or Rust-based swc in the case of Next 12.
- Support multiple JavaScript frameworks for componentry. Astro and îles do this out of the box, and another example is how Slinkity brings that to Eleventy.
- File-system based routing.
- Assumption that Markdown is used for content.
When you compare these to first-cohort SSGs, like Jekyll, I get a few feelings:
- These really aren’t that much different. The feature set is largely the same.
- The biggest change is probably that far more of them are JavaScript library based. Turns out JavaScript libraries are what really what people wanted out of HTML preprocessors, perhaps because of the strong focus on components.
- They are incrementally better. They are faster, the live reloading is better, the common needs have been ironed out.
Your website now depends on a gazillion of npm packages that might break/conflict someday.
Ahh php devs. Gotta love em
The biggest improvements that matter to me seem to be related to the fanciness around hydration. Simplifying those JavaScript aspects into a one-liner has had a huge development impact. It makes building the site itself much more fun as I’m focused on the site and not the tools to build the site.
How does Hugo compare to these? Does it even compare?
We’ve been working on a new site for our landing pages and developed prototypes with both Hugo and Astro. I’d say the biggest difference is that Astro (haven’t looked at íles but I’d imagine it’s similar to Astro) is JSX-based and largely unopinionated, while Hugo is more of a strict templating system.
It looks like Astro is winning for us for the following reasons.
1) In Astro, styles can be scoped to components, which means if the component isn’t included, neither are its styles. We weren’t able to accomplish this with Hugo. While it does have an asset management system, it doesn’t have a concept of component-scoped styles. Not that I’m the end of the line here but I tried for a couple of hours to make it happen and couldn’t. You’d probably need to fork Hugo and build your own binary with that feature.
2) with Astro, you can leverage the full power of a modern frontend framework with no client-side cost (unless you opt-in to it at the component level). The ecosystem around these frameworks has exploded in the past few years and I find them enjoyable to work with. The development tooling is fantastic. The concepts of components mounting, unmounting, and running side effects on state changes I find easier to accomplish in the newer frameworks than with vanilla JavaScript (because that’s exactly what they were made for). With Hugo, you write your JavaScript separate from the HTML. That’s fine, but I enjoy writing JavaScript in {react, svelte, etc} because they make complex things pretty easy. Also, I love having the HTML, CSS, and JS all in the same file. Coupled with the component/ JSX ideology, I find all of this a way more sane way to develop a website. All dependencies can be accounted for and you know exactly what your CSS and JS is for.
3) my last point also ties into the fact that you get a lot of asset management magic with Astro that you won’t find in Hugo because Astro is a product of the modern tool chain. It’ll make smart decisions about what to do with CSS and JavaScript.
Sure there are more reasons but this is already a pretty long comment!
I completely agree that they are very much alike, in fact, Jekyll is a major inspiration for îles.
Started with îles after releasing Jekyll Vite, and feeling componentization was still awkward (include tags).
Still missing some of the niceties of Jekyll around collections, but planning to cover that soon.
I’d also argue that the asset management is a lot simpler in these modern tools, thanks to Vite. You can use any tool without waiting for a kind soul to wrap it in a Ruby gem
Another benefit of these new tools is that they can prerender the components that will be hydrated, preventing FOUC and layout shifts.
This results in a tangible improvement in the UX of a site
I second Joeee’s question, how do these new JS based SSGs compare with the Go based Hugo?
Are they just playing catch up? Hugo already had the speed and the filesystem based routing.
I’d love to see a write up of what the latest SSGs add that Hugo doesn’t
Hugo seems highly relevant to me, particularly because of the speed.
Check out the real data on all that we’ve reported on:
But, it’s not JavaScript-library based, which, as I noted, feels significant. The way you nest them and pass props around and such is becoming kind of a defacto way of HTML processing, essentially.