When I started building Jottings, I had to make a fundamental architectural choice: Should user sites be dynamic or static?
Dynamic seemed obvious at first. It's what WordPress does. It's what Substack does. Build a database, build a server, serve pages on request. Simple, right?
But the more I thought about it, the more static sites made sense. Here's why—and what actually happens when you click the "Publish" button.
The Architecture Decision
Jottings generates pure HTML files. Your entire site—home page, tag pages, feeds, sitemaps—is compiled into static HTML and CSS. That HTML is then uploaded to a CDN.
This is the opposite of WordPress, where every single request hits a server, which hits a database, which generates HTML on-the-fly.
Why did I choose this?
Three reasons: security, speed, and simplicity.
Security: No Database to Hack
A static site has no database server running behind it. There's nothing to SQL inject. There's no admin panel to brute-force. There's no server-side code that could have a vulnerability.
Your site is just files on a CDN. You can't hack a file.
Compare this to WordPress. A WordPress site gets attacked roughly once per day (I've dealt with the cleanup). There's PHP code executing on request. There's a MySQL database connected to the public internet. There's a /wp-admin/ login page. Every single one is a potential attack surface.
With Jottings, the attack surface is gone. The only way to modify your site is with your password, which authenticates to our API (not your public site). Once it's published, it's immutable.
That's a fundamentally different security model. And it's much harder to break.
Speed: The Physical Advantage
It's physically impossible for a dynamic site to be as fast as a static site.
A dynamic site has to:
- Receive the request
- Wake up (or start) a server
- Query a database
- Render the HTML
- Send it to you
A static site has one step: send the file from the CDN closest to you.
CDNs like Cloudflare cache content at hundreds of locations worldwide. Your site loads from a server that's geographically close to your reader. The first byte arrives milliseconds after the request—there's nothing left to optimize.
And that global caching is free with static sites. A WordPress site would melt under the load of a Hacker News post. A Jottings site? It handles it like it's nothing.
Simplicity: One Less Thing to Break
Running a database requires maintenance. You need backups. You need monitoring. You need to worry about capacity. You need to patch security vulnerabilities.
With a static site, there is no database. There are just files on a CDN. Cloudflare handles the complexity. We don't have to maintain anything for your public site.
That means lower costs. That means fewer things breaking. That means we can keep Jottings cheap or free.
What Happens When You Click "Publish"
This is where the architecture gets interesting. You get a dynamic writing experience with a static reading experience.
Here's the flow:
1. You Click "Publish"
You've written a jot in the Jottings dashboard. You click the "Publish" button. The API receives the request and stores your jot in our DynamoDB database (serverless, managed by AWS).
That takes milliseconds. The button lights up green. Your jot is saved.
2. A Message Goes Into a Queue
But we don't build your site immediately. Instead, we send a message to an AWS SQS queue: "Hey, rebuild the site for user X, site Y."
This is asynchronous. The API doesn't wait. It just queues the work and returns.
Why? Because building a site can take time (especially if you have hundreds of jots). We don't want to make you wait.
3. A Lambda Function Wakes Up
A few seconds later, a Lambda worker (serverless compute on AWS) picks up the message from the queue. It's been idle, so there's a cold start. But cold starts are fast these days.
The Lambda worker runs a build process. Here's what it does:
Fetch your jots from DynamoDB
Fetch your site settings (theme, author info, site title, custom domain, etc.)
Render HTML for every page:
- Home page (with pagination if you have many jots)
- Each tag page (with pagination)
- Tag cloud page
- Archive pages
- RSS feed
- JSON feed
- Sitemap
- SEO files (robots.txt, humans.txt, ai.txt)
Upload to Cloudflare R2 (our object storage with a built-in CDN)
Mark the build as complete
4. Your Site is Live
Within 10-30 seconds of clicking "Publish," your site is rebuilt and live on the CDN.
If you visit your site immediately, you get the new content. Readers around the world get cached copies from CDNs near them.
It's the best of both worlds: You get the dynamic power of a CMS for writing, and readers get the speed and security of a static site.
The Trade-offs (And Why They're Worth It)
I'm not going to pretend static sites are perfect for everything.
Trade-off 1: Slight Publish Delay
There's a 10-30 second delay between clicking "Publish" and your site going live. For most use cases, this is fine. But if you're building a real-time commenting system or live updating your jots, this won't work.
Jottings doesn't support real-time features by design. We think that's okay. Your blog doesn't need to update in real-time. Real-time makes sense for instant messaging or collaboration tools. For publishing, eventual consistency is fine.
Trade-off 2: No Real-Time Features
Related to the above: no real-time comments, no live counters, no instant notifications.
You can work around this with third-party services (Disqus for comments, etc.), but Jottings doesn't build this in.
Again, this is by design. We're optimizing for simplicity and reliability, not feature richness.
Why This Matters
Static site generation isn't new. It's been around since the dawn of the web. But it fell out of favor during the "everything is dynamic" era.
Now it's coming back. Not as a niche thing, but as the default for a huge category of content: blogs, portfolios, documentation, and personal sites.
There's a movement called the Jamstack (JavaScript, APIs, Markup) that's specifically built on this idea. But the core concept is older: build your content once, serve it everywhere.
For personal content, this is the right choice. Your blog post doesn't change after you publish it (well, it shouldn't). Why regenerate it on every request?
Some people call this the "100-year website" philosophy—content that's meant to last. Bit Rot and Link Rot are real problems. A static HTML file generated today will still be readable in 50 years. A WordPress site? Good luck keeping PHP compatible that long.
The Bigger Picture
We could have built Jottings as a traditional web app with a database server behind every reader's request. We chose not to.
That choice ripples through the entire architecture:
- Lower cost: No database servers to run. No caching layers to maintain. We pass those savings to you.
- Higher reliability: CDNs are battle-tested infrastructure. Cloudflare operates globally. Your site works even if we have infrastructure issues.
- Better security: No attack surface. No database to compromise.
- Future-proof: Your content is portable. It's just HTML files. You can download your entire site. You could host it anywhere.
These aren't accidents. They flow from a single architectural decision: static sites are the right tool for the job.
If You Want to Try It
If this philosophy resonates with you—if you want a blog that's fast, secure, and built to last—try Jottings. It's free to start.
Write your first jot. See how fast it loads. No database queries. No server waiting to respond. Just your thoughts, served from a CDN near your reader.
That's the experience we're building toward.
Thanks for reading. If you have thoughts on static vs. dynamic architecture, I'd love to hear them. You can find me on Twitter or GitHub.