Read on Twitter
@eleven_ty absolutely needs layers on top that minify things, provide an asset pipeline etc... I don't recommend it for all types of projects/project for this reason.
There's loads of tools and combinations of tools that meet different needs. Amazing right? It depends on what you need. Who would have thought!?
I don't want to write a blog post (yet) so how about a twitter thread...
I don't want to write a blog post (yet) so how about a twitter thread...
Why are you going static? Is it 100% about a better TTFB? Are you otherwise happy with WordPress (or similar)? Don't want to invest in a rebuild?
Start here: https://sitesauce.app/
This crawls a website and extracts the assets and pushes to @vercel.
Start here: https://sitesauce.app/
This crawls a website and extracts the assets and pushes to @vercel.
I gave it a couple of test drives and the tooling + results were impressive. It can watch for change and trigger rebuilds in a lot of different ways.
All built by 18yo @m1guelpf - what a champion :)
All built by 18yo @m1guelpf - what a champion :)
This obviously has limitations. It might give you better performance, but this is only going to be as good as your WordPress theme. If that generates garbage HTML and a boat load of JavaScript, minifying won't help.
If like me poor website performance makes you sad, or if you want to uncomplicate your infrastructure, you probably want a static site generator.
The first step away from WordPress or Craft is probably something like: https://statamic.com/
The first step away from WordPress or Craft is probably something like: https://statamic.com/
It's a PHP based static site generator so it's not a hard shift for a WordPress dev, but it's also a CMS. In some ways it's similar to http://foresty.io or http://netlifycms.org but with built-in SSG.
This is a good option for someone looking to simplify their stack, and improve the quality of the output without loosing the editorial experience, completely re-skilling their team or drastically changing hosting/deployment infrastructure.
Statamic doesn't have a database so it's probably not going to scale for those really big sites with many thousands of pages and assets.
(but honestly I haven't tested it with anything huge)
If you don't want to run a database this is where https://gohugo.io/ shines.
(but honestly I haven't tested it with anything huge)
If you don't want to run a database this is where https://gohugo.io/ shines.
Hugo is incredibly fast. I've not seen any SSG that can generate huge numbers of pages as fast as Hugo. Sometimes it seems to be faster than copying content in the terminal. Frankly it's creepy magic.
If build times are killing you Hugo is a consideration.
If build times are killing you Hugo is a consideration.
However Hugo's templating language is ... a bit challenging, it can be opinionated and it can't really be extended.
I've hit had issues with Hugo without any good solutions. If you use it, stay on the rails or it will bite you!
I've hit had issues with Hugo without any good solutions. If you use it, stay on the rails or it will bite you!
If you need more customisation and complete control over the output try http://11ty.dev . It's my favourite SSG because it's pretty easy to connect it with anything.
@eleven_ty is going to suit indie developers, as well as small to medium sized projects.
@eleven_ty is going to suit indie developers, as well as small to medium sized projects.
It's a good choice for teams that don't have specialisation in any particular JavaScript framework. So if a team has a board skills, I recommend 11ty.
I'd also recommend it where you have a bunch of data you want to fetch from different APIs. Its data cascade is just simple.
I'd also recommend it where you have a bunch of data you want to fetch from different APIs. Its data cascade is just simple.
This is unlike @GatsbyJS where the data cascade is a bit more complicated. GatsbyJS leans in really heavily on a graphQL and React stack.
So you write resolvers and queries to generate data for pages.
So you write resolvers and queries to generate data for pages.
If familiar, it might make sense, but for me it's always seemed a bit much for static pages and I don't like that I can't generate a truely static build rather than a server rendered SPA.
For this (and other reasons) http://nextjs.org is my preferred SSG for a React stack.
For this (and other reasons) http://nextjs.org is my preferred SSG for a React stack.
Next.js can be a hybrid between a static site generator and a server rendered application. Which can be handy when complexity rises.
For this reason it's my preferred recommendation for medium and large scale applications and teams with a specialist React focus.
For this reason it's my preferred recommendation for medium and large scale applications and teams with a specialist React focus.
I hope this thread is useful anyone considering building a JAMStack application or static site.
Final word - if you're building for yourself use @eleven_ty. If you need help assessing requirements, I've many built sites and applications with all these platforms - my DMs are open
Final word - if you're building for yourself use @eleven_ty. If you need help assessing requirements, I've many built sites and applications with all these platforms - my DMs are open
