Removing Next.js Got My Blog to 100 on Every Lighthouse Category
j / k
|
Down or up a comment |
h / l
|
Previous or next link |
?
|
This help |
This is like writing a post about how I didn't need a Ferrari to commute to work and I saved money by taking the bus.
I run a dynamic website on nextjs static export - landingpages and docs are fully static, login and user dashboard use REST calls to a non-nextjs backend. Blazing fast, no nodejs or SSR in production.
Keeping an unnecessary dependency for legacy reasons is never a good move. Be bold and delete things. Your software will be better for it.
But yes, another static site blog generator would also work.
As someone who's ran a blog for 25 years it's surprising I never knew these things were necessary until now.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
[2] https://caniuse.com/picture
Not just as the dev delivering the solution, but also library and package authors.
Ran into lots of issues around Next 12, Next 13 was very buggy, moved to Astro and never looked back.
Because "heavyweight SPA for a static blog" isn't exactly a rare problem.
The problem isn’t the size of the code. It’s the unnecessary framework complexity. Suggesting this to a corporate JavaScript developer, though, is like throwing acid on your own face as they whine about how impossible it is to do their jobs.
Which is great if people only use it from localhost.
The point being made further up the thread was that people are using SPAs for static text.
TBF, they could have explained that better in the post.
https://eric-frost.github.io/solarite/
You get the best of both worlds, better language than XML/HTML and yah, you can deliver only HTML since the consumer typically doesn't need all that JavaScript, spa stuff. The Island Architecture.
Feels like a good in-between. Good DX for me, great UX and mostly HTML with some JavaScript sprinkled and fallback for users.
Note, I say that while literally knowing people who run k8s clusters on pis for heir home lab with like 3 users. Good people. I love them to death, but they also may or may not have recently tested positive for autism.
The question is how to get a good and efficient dev experience while also preserving that level of speed.
AI has now made that question mostly irrelevant, since it can generate and rapidly edit vanilla webpages without a framework to make the DX better.
There is no secret ingredient, writing a website, or anything really, without a framework is not wildly more difficult than using a framework.
Save for a few cases where all you really want to do is covered by the default configuration, you generally don't end up writing a lot less code with a framework. Worst case, you end up spending most of your time working around the framework.
What? This is absolutely untrue for anything that isn't a trivial v1 prototype. Complex applications have a lot of boilerplate, which is unavoidable with the baggage of HTML and CSS.
There's a reason people are obsessed with web frameworks. Writing vanilla HTML/CSS/JS for large or complex apps is an enormous pain.
React et al. won’t just be 10x slower, it will also use 5x the amount of code with 5x the complexity.
People are obsessed with web frameworks because it’s more fun to engineer frameworks than make products or ship applications. Applications are boooooring. But, most of the time, you’re just wasting your time with the framework.
Not consistently over time it can't — at least not the usual LLM-as-a-service suspects, which don't even guarantee the model you use today will function identically tomorrow — unless you use it to create your own static site generator, which may or may not make sense depending on whether existing, battle-tested tools don't already fit the bill.
Claude seems better at frontend dev work than at any other category of task. It’s far better than the last senior frontend dev I worked with.
A srcset lists those versions, and the browser picks the one that fits the current viewport and screen density. https://responsiveimages.org/ has details.
For an example, view the source of https://photostructure.com/tags/. All the header art looks like this:
<picture><source type="image/webp" srcset="/img/2026/05/desk-2000w_hu_f9b8e901c6d3512c.webp 400w, /img/2026/05/desk-2000w_hu_4e2d65cccd03c969.webp 800w, /img/2026/05/desk-2000w_hu_11f3bf6c90dbf78d.webp 1200w, /img/2026/05/desk-2000w_hu_8c1a7d0a013e4ee2.webp 1600w, /img/2026/05/desk-2000w_hu_4cebe999e55b5486.webp 2000w" sizes="100vw"><source type="image/jpeg" srcset="/img/2026/05/desk-2000w_hu_cf5671a2e3bdd0cc.jpg 400w, /img/2026/05/desk-2000w_hu_2906e4ba7cda040.jpg 800w, /img/2026/05/desk-2000w_hu_f59ef0388799d4d2.jpg 1200w, /img/2026/05/desk-2000w_hu_e183d28df837e14a.jpg 1600w, /img/2026/05/desk-2000w_hu_ea9c422963c8e0e1.jpg 2000w" sizes="100vw"><img src="/img/2026/05/desk-2000w_hu_f59ef0388799d4d2.jpg" width="1200" height="600" alt="About" class="w-100 header-image" loading="eager"></picture>
That’s generated by https://gist.github.com/mceachen/d5915e46d1294489698e155eb11..., which uses Hugo’s resources.Get and .Resize.
Then chooses an approach that looks like a lot more work than setting up Hugo.
Now I use a git repository with a simple git hook, which runs a tiny bash script on commit, allowing for basic HTML templating. The static site is then served with Caddy.
I know not everyone like the design of my website, but I personally do which is why I still have it :^)
[0] https://stigsen.dev
[1] https://git.stigsen.dev/stigsen/stigsen.dev
I would say that in the era of agentic coding you don't need any framework. Just a backend + router + markdown generator. I use Hono + Tanstack router for the first two. Tell any decent LLM to wire those up for you and you'll have a simple static site ready to go in an hour or two.
I’ve used Astro for more complex applications, and it’s perfectly suitable for that too.
Of course, if you’re building an SPA, then it’s probably not the best choice.
Astro is also great (as others have noted) esp if you want to leverage the JS ecosystem at large.
[1] https://frominsidethebox.com
[2] https://yakshed.com
https://astro.build/
It is more like a dialect of JavaScript optimised for developing static sites than a static site generator in and of itself. It has lots of 'builtins' for things like RSS and converting Markdown to HTML. It is so wonderfully flexible and doesn't lock you into a specific site structure like others SSGs do.
https://weborigami.org/
Whatever you use, I feel it is tradition to have 3 odd blog posts about journey of building a SSG of your own since nothing else matched exactly what you needed and that’s it. Then you should forget that blog ever existed.
https://qip.dev/docs/router
[1] https://zine-ssg.io
edit: i mean have the ai write the generator, don't use it to actually generate pages...
I started with an empty repo, wrote the first half of a README describing my decision-making process in choosing a static site generator, and conversed with an AI to finish the decision and set everything up.
https://writing.brlewis.com/posts/2026/blog-based-on-git/
Both my css and js are dynamically minified and included in the html depending on which component is loaded on the page.
[0]: https://idiallo.com/blog/handling-1-million-web-request
* I am bragging
The big selling point of them was a fast, convenient dev experience with many features (most often unused) being built-in.
Now, those built-in features are becoming a security risk as more vulnerabilities are being found in their 1000s of lines of code, and the developer experience benefit is being nullified by agents whittling away the human involvement anyway.
I'm open to the idea that we're doing it wrong and that there's a correct and pleasant way to write nextjs, but I think with the tools available today, everyone should just profile and optimize their app so they don't need to render it serverside.
1. https://tanstack.com/blog/tanstack-start-1-0
TanStack Start absolutely merits a closer look. It's not a flash in the pan or "the new shiny". It's the robust, coherent, independent and logical evolution of battle-hardened wisdom and brilliant design and implementation from first principles. See TanStack Router and TanStack Query for more evidence and background context. I've been around the block (25+ years in webdev) and gained a deep appreciation for Tanner's way of thinking. No affiliation, just a grateful user trying to help others notice by amplifying the signal in the noise.
P.S. Yes I wrote ~"it's not X, it's Y". No I didn't use genAI to write here (nor anywhere, ever).
Having said that, sure perhaps Astro would be lighter than Nextjs.