When people talk about islands architecture, the conversation often stops at implementation. It gets reduced to “hydrate less JavaScript” and left there.
That is true, but incomplete.
Hydration is part of product design
Every hydrated component creates a long tail of cost:
- JavaScript bytes
- parse and execute time
- state complexity
- more failure modes on low-end devices
If a page is mostly for reading, then hydration should have to earn its place. A blog post usually does not need a client-side state tree to feel modern.
The right default for a technical blog
For this project, the right default is:
- server-render content
- keep navigation simple
- load interactive components only where they create distinct value
The homepage globe clears that bar because it changes the mood of the site and creates a clear technical signature. A table of contents, on the other hand, can stay fully static.
Performance is identity
Readers do not care whether a page is technically elegant if it still feels heavy.
That is why performance here is not just a metric target. It is part of the editorial voice. Fast pages imply restraint. Restraint implies deliberate engineering. That tone matters.
What this means in practice
The site should keep chasing a zero-JS reading experience wherever possible, and spend interactivity on features that feel irreplaceable rather than fashionable.