Building a Game Guide Site Without a Framework: The Quiet Power of Static HTML

天知道997 997 — Thu, 16 Jul 2026 07:51:37 +0000

I love a good framework as much as the next developer. Give me routing, components, hot reload, a tidy build pipeline, and I am happy.

But for this project, I deliberately went the other way.

Sootseer is a small, focused Palworld guide site. It answers a very specific player intent: where to find Sootseer, what it drops, how breeding works, and what changed in newer game data. It is not a dashboard. It is not a SaaS product. It is not a social app.

It is a content-first reference page.

So the architecture is almost aggressively simple:

Static HTML
One CSS file
One small JavaScript file
Local image assets
A privacy page
robots.txt
sitemap.xml
Structured data in the page head

No bundler. No hydration. No client-side router. No dependency graph that needs a weather report before deployment.

And honestly? It works really well.

The Main Technical Decision: Let HTML Do the Heavy Lifting

The page is built around plain semantic sections:

<section id="route">
  ...
</section>

<section id="breeding">
  ...
</section>

<section id="faq">
  ...
</section>

That sounds basic, but for a guide site, basic is a feature.

Search engines, browsers, screen readers, and impatient users all benefit when the document is readable before JavaScript does anything. The page has a real title, real headings, real links, real FAQ content, and real tables. If the JavaScript never runs, the core content still exists.

That was the rule I kept coming back to:

JavaScript can improve the experience, but it should not be required to understand the page.

For a game guide, this matters. A lot of visitors arrive from search with one narrow question. They do not want an app shell. They want the answer.

Structured Data Is Part of the Architecture

One thing I think developers often treat as “SEO garnish” is structured data. For this kind of site, I consider it part of the core architecture.

The page includes JSON-LD for:

Organization
WebSite
WebPage
Article
BreadcrumbList
FAQPage

That gives the content a machine-readable shape.

The visual page says, “Here is a Sootseer guide.”

The structured data says, more precisely, “This is an article, published by this entity, about this topic, with these FAQ answers, at this canonical URL.”

That distinction matters when the site is designed to compete in search results where many pages are saying roughly the same thing.

Just Enough JavaScript

The JavaScript layer is intentionally tiny. It handles three things:

Tab switching for encounter routes
Filtering the skill table
Remembering checklist progress in localStorage

The checklist is a nice example of progressive enhancement:

const storageKey = "sootseer-guide-checklist";

function readChecklist() {
  try {
    return JSON.parse(localStorage.getItem(storageKey)) || {};
  } catch {
    return {};
  }
}

Nothing here needs a framework. There is no shared global state problem. No server state. No complex synchronization. Just a few DOM nodes and a small piece of browser storage.

The page feels interactive, but the interaction is not allowed to take over the architecture.

CSS Carries the Product Feel

The CSS does more than make things pretty. It defines the whole reading experience.

The layout uses responsive grids, compact panels, sticky navigation, visual tags, loot cards, tables, and mobile-specific adjustments. The design goal was not “landing page.” It was “useful guide that feels polished.”

That distinction changed the UI choices.

Instead of a giant marketing hero and vague feature blocks, the first screen gives users the practical identity of the page: Sootseer, Palworld version context, type tags, stats, and direct navigation to location, Predator Core, breeding, and ranch information.

A content site can still have personality. It just has to respect the reader’s intent.

The Boring Files Matter

The project also includes robots.txt, sitemap.xml, Open Graph tags, Twitter card tags, canonical links, image preloading, and a privacy page.

None of that is glamorous.

All of it matters.

A small static site does not get to hide behind application complexity. Every file has a job. The page needs to load quickly, preview cleanly when shared, index correctly, and explain its data and privacy posture.

That is especially true for niche content sites. Trust is built through small signals: clear source policy, current review dates, stable URLs, and no unnecessary friction.

What I’d Use This Architecture For Again

I would happily reuse this approach for:

Game guide pages
Small documentation hubs
Local business microsites
Tool directories
Comparison pages
Static editorial projects
SEO-focused niche sites

I would not use it for everything. Once the site needs user accounts, server-side personalization, large content operations, or shared UI across hundreds of dynamic pages, I would reach for a framework.

But for a single-purpose guide, static architecture is not a compromise. It is a strategy.

The Lesson

Modern web development often nudges us toward more machinery than the problem actually needs.

This project was a useful reminder that a fast, useful website can still be made from the old ingredients: HTML that explains itself, CSS that respects the content, and JavaScript that knows when to stop.

Sometimes the best stack is the one that leaves the user alone and lets the page answer the question.

I Built a Daily Browser Game Without a Framework, and I Kind of Loved It

天知道997 997 — Thu, 16 Jul 2026 07:49:50 +0000

Modern web development can make you feel like every small idea needs a full production stack before it deserves to exist.

A framework. A router. A bundler. A component system. A styling strategy. A content layer. A deployment adapter. Maybe a database, because apparently we all enjoy having responsibilities.

For Vexle, a small daily flag-drawing game, I went in the opposite direction.

The site is built with plain JavaScript, a tiny Node.js static generator, JSON content files, one HTML game fragment, and a browser canvas. The final output is just a dist folder that can be dropped onto Vercel or any static host.

And honestly? For this kind of project, it felt great.

The Product Shape

Vexle is a daily geography game. The player sees a country name, draws the flag from memory, then reveals the real flag and gets a rough match score.

That meant the site needed a few things:

A playable first screen
Fast loading
Mobile-friendly drawing controls
Local daily progress
SEO pages like About, Privacy, and Terms
Metadata, Open Graph tags, structured data, sitemap, and robots.txt
A simple deployment story

What it did not need was a client-side app framework.

There is no complex state shared across routes. There is no authenticated dashboard. There are no deeply nested UI flows. The game is the app, and most of the surrounding site is content.

So the architecture became very boring in the best possible way.

The Architecture

The project is split into a few plain folders:


text
content/
  home.json
  game.html
  pages/
    about.json
    privacy.json
    terms.json

public/
  app.js
  styles.css
  data/
    game-data.json

scripts/
  build-static.mjs

server.mjs
site.config.json

DEV Community: 天知道997 997