Static vs React: Two Ways to Build a Portfolio

Two portfolios, two philosophies

I recently built two personal portfolios back to back, and they landed on opposite ends of the web-development spectrum. jacqmagawa.com is a hand-built static site — semantic HTML, CSS, and a little vanilla JavaScript. magawa.website (this site) is a React single-page app backed by a FastAPI + MongoDB server.

Same designer, same dark aesthetic, two completely different engines. That contrast is the best possible teaching tool, so this post puts them side by side: what each approach is great at, where each one hurts, and how to choose.

The two builds at a glance

	jacqmagawa.com	magawa.website
Type	Static site	React SPA + API
Front end	HTML5 · CSS3 · vanilla JS	React + Tailwind CSS
Back end	None	FastAPI (Python)
Database	None	MongoDB
Content updates	Edit files & redeploy	Log in to an admin dashboard
Dynamic features	Minimal (galleries, lightboxes)	Blog CMS, likes, newsletter, admin
Attack surface	Tiny	Larger (auth, API, DB)
Hosting	Static files + CDN	App server + database

When static wins

For Jacqueline's portfolio, static was unquestionably the right call. Here's why:

• Speed out of the box. There's no framework runtime to download, parse, and boot before the page is usable. The HTML is the page.
• Almost nothing to attack. No login, no API, no database means the classic web vulnerabilities simply don't exist. For a public brochure site, that's a feature.
• It basically can't go down. Static files sit on a CDN edge. No server process to crash, no database connection to drop.
• Cheap and durable. Hosting is trivial and often free, and the site will still work untouched years from now.

The trade-off: every content change means editing files and redeploying. For a portfolio that updates a few times a year, that's a non-issue. For a blog that publishes weekly, it would be friction.

When a framework and backend win

magawa.website earns its extra complexity because it does things a static site can't:

• A real blog CMS. Posts, categories, tags, series, likes, and a newsletter are all managed from an admin dashboard — no code edits, no redeploys.
• Interactivity at scale. Filtering, search, pagination, live like/love counts, and reading-progress all benefit from React's component model and state.
• Server-side logic. Contact and newsletter emails, spam throttling, secure admin authentication, and scheduled digests all need a backend.
• Data that changes constantly. When content lives in a database, the site reflects edits instantly for every visitor.

The trade-off: more moving parts to secure, host, and maintain. Authentication, an API, and a database are power and responsibility.

Performance: it's not as one-sided as you'd think

Static has a natural head start — but a well-built React app closes most of the gap. On magawa.website that means code-splitting, lazy-loaded routes and images, responsive srcset images, and edge caching. The lesson: architecture doesn't excuse you from performance work, and it doesn't guarantee it either. A bloated static site can be slower than a lean React app. Discipline matters more than the label.

SEO: both can rank, with effort

A static site is SEO-friendly by default because the content is right there in the HTML. A React SPA has to work a little harder — magawa.website uses per-route metadata, canonical URLs, JSON-LD structured data, Open Graph tags, an auto-generated sitemap, and clean semantic markup so crawlers get everything they need. Both sites verify ownership in Google Search Console and ship a sitemap. Neither approach is a shortcut; both reward the fundamentals.

Maintenance and cost

• Static: near-zero ongoing cost, near-zero maintenance, but content changes require a developer's workflow (edit → commit → deploy).
• Framework + backend: a running server and database to pay for and keep patched, but the owner can publish and edit content themselves, forever, without touching code.

That last point is the real deciding factor more often than performance ever is: who needs to update the site, and how often?

A simple way to choose

Ask three questions:

1. How often does the content change? Rarely → static. Constantly → framework + backend.
2. Who updates it? A developer → static is fine. A non-technical owner → you want a CMS/admin.
3. Does it need server-side logic (accounts, payments, email, live data)? No → static. Yes → backend.

Jacqueline's portfolio answered "rarely / developer / no," so it's static. This blog answered "weekly / owner / yes," so it's a React app with a real backend. Neither is more advanced than the other — they're answers to different questions.

The takeaway

The most senior instinct in engineering isn't reaching for the most powerful tool — it's matching the tool to the problem. Two portfolios, one designer, two right answers. If your site is a living, frequently-updated product, invest in a framework and a backend. If it's a fast, secure, rarely-changing showcase, a hand-built static site is not a compromise — it's craftsmanship.

---

This is Part 3 of the Design to Build series. See how each site was made: magawa.website in React (Part 1) and Jacqueline's static portfolio (Part 2).