DEV Community: Mateusz Muszarski

Astro vs Next.js for a portfolio or a landing page

Mateusz Muszarski — Mon, 12 Oct 2026 07:47:58 +0000

This post first appeared on my site, where the clips play and the version tabs work.

For a portfolio or a landing page, Astro is the better default: it pre-renders every page to HTML and ships no JavaScript unless a component asks for it. Next.js is the better call when the site is really an application, with logins, per-user data and server-side writes. This site is Astro; Clockful, the time tracker I built during my internship at Neoteric, is Next.js.

TL;DR

Astro for content: every page pre-rendered to HTML, zero JavaScript by default, interactivity opted into per island.

Next.js for apps: logins, roles and per-user data; its static export gives up cookies, redirects, Server Actions and more.

Public data: in HTTP Archive's August 2026 mobile data, 71.0% of Astro origins pass Core Web Vitals against 35.1% of Next.js origins, partly because people build different things with each.

What does each framework say it is for?

Astro's docs are direct: "Astro is the web framework for building content-driven websites like blogs, marketing, and e-commerce." It calls itself server-first, with zero JavaScript by default. The same page says other frameworks "excel at building more complex, application-like experiences in the browser: logged-in admin dashboards, inboxes, social networks, todo lists".

Next.js calls itself "a React framework for building full-stack web applications". In its App Router, layouts and pages are React Server Components by default, and you opt into client code with the "use client" directive.

Those two lines answer most of the question. A portfolio is a content site with a contact form. A dashboard is an application.

How much JavaScript reaches the browser?

In Astro, every UI component, React included, renders to HTML and CSS, and its client JavaScript is stripped out. Interactivity is opt-in per component, through islands: client:load hydrates at once, client:idle when the browser is idle, client:visible when the component scrolls into view. A page without islands ships no framework runtime.

Next.js renders on the server too, and Server Components keep their code out of the bundle. The client still runs React, though, to hydrate Client Components and handle client-side navigation, and everything a "use client" file imports joins the bundle. That pays off in an app with many screens and shared state; on a five-page portfolio it is overhead to manage.

Here is the Astro path on this site:

Build. Every page becomes HTML, with its CSS inlined in the head.
CDN. Vercel serves the files; the contact form is the one function.
Text first. The H1 is the largest paint and waits for no script.
Small scripts. Component scripts load as small modules, with no framework runtime.
Effects last. Loops and clips wait for the first interaction; shaders draw only in view.

There are no framework islands here at all. Every component is an .astro file, and the interactive parts (the pause button, the credentials tour, the writing rail) are plain scripts that Astro bundles into small modules. On the home page they come to under 10 KB, gzipped.

Can both produce a static site?

Yes, at a different cost. Astro's default is static: "By default, your entire Astro site will be prerendered". If one route needs a server, such as a contact endpoint, you add an adapter and mark that page with export const prerender = false. Everything else stays static.

This site skipped even that: no adapter, and the contact form posts to a plain Vercel Function next to the static files (how the contact form works).

Next.js can produce a static site too: with output: 'export', next build writes one HTML file per route into an out folder. The docs list what you give up, including cookies, redirects, Proxy, Incremental Static Regeneration, Server Actions and dynamic routes without generateStaticParams(). Many of those are the reason to pick Next.js in the first place.

What about content, translations and page transitions?

A portfolio is mostly writing. Astro's content collections load Markdown and MDX from folders, validate frontmatter with a Zod schema and generate TypeScript types from it. This post is one of those files: its title, description and sources are checked before the page builds. The site's three languages run on Lingui, all of it static (how the multilingual setup works).

For page transitions, Astro supports the browser's native cross-document view transitions (the CSS @view-transition rule), and its <ClientRouter /> adds SPA-style ones when you want more control. This site uses only the CSS rule: pages crossfade with no JavaScript, and readers who ask for reduced motion navigate instantly.

What does public data say?

The HTTP Archive Tech Report takes real-user Core Web Vitals from the Chrome UX Report per origin, and detects technologies on each site's home page and one inner page. Astro and Next.js in the August 2026 dataset, mobile, all origins:

Mobile, August 2026	Astro	Next.js
Origins assessed	43,850	374,612
Good Core Web Vitals (LCP, INP, CLS)	71.0%	35.1%
Good LCP	80.6%	53.1%
Median JavaScript per page	405 KB	853 KB

Read it as a picture of two populations, not a verdict on two frameworks. By their own docs, Next.js targets applications and Astro targets content sites, so part of the gap is what people build with each. The report can't separate a framework from the site built on it.

What did this site measure?

This site is Astro 7, Tailwind 4 and one variable font, served as static files from Vercel.

The home page in Lighthouse on mobile, from a local production build on 7 October 2026. The CV, blog and work pages score 96 to 100 on the same setup.

Two honest notes:

I did not build the same site in Next.js, so I can't tell you what it would have scored. That is why the comparison above uses public data.
The framework didn't earn the score alone. On the afternoon of 7 October the home page fell to 67-74 with no framework code involved: animation loops running during load, a class that restyled every element in the offscreen sections, and scripts forcing layouts. Fixing those brought it back. What Astro gave me is the starting point: zero JavaScript, so there was nothing to remove.

The same pattern shows up in Lighthouse runs on 16 developer portfolios: the immersive 3D sites scored far below the minimal ones. The whole build story is in how this site was built.

Since then I have measured one real move: yws.lu, a client site I built in Next.js in 2025. It scored 23-45 on Lighthouse performance, and 94-100 after the rebuild in Astro (Lighthouse 13.5, local, the median of 3 runs). The details are in the yws.lu case study.

When is Next.js the right call?

Pick Next.js when most screens depend on who is looking at them. Clockful, the role-based time tracker from my internship at Neoteric, is that kind of project: logins, roles, per-user data, and Postgres row-level security on every table.

The Next.js docs cover that ground in one guide: authentication, sessions in cookies, authorization in a data access layer, and Server Actions for writes. Astro can render on demand too, but its own docs point to other frameworks for logged-in dashboards. Next.js also wins when the landing page belongs to an existing Next.js product: one codebase beats two stacks for one marketing page.

When is Astro the right call?

When the site is content first: a portfolio, a landing page, docs, a blog, a small business site. You can still write React, Preact, Svelte, Vue or SolidJS where you need interactivity, and only those islands ship code. Hosting is a CDN plus a build, with a server function only where you need one.

Which one fits your kind of site?

Your site	Pick	Why
Portfolio, CV, blog	Astro	Static HTML, zero JS by default, content collections
Marketing landing page	Astro	Same, plus an island for the one interactive widget
Landing page inside a Next.js product	Next.js	One codebase, one deploy
Dashboard with logins and roles	Next.js	Server Components, auth guide, Server Actions
App with per-user data on every screen	Next.js	Built for on-demand rendering
Content site with one or two dynamic routes	Astro	Static by default, `prerender = false` per route

How do you decide for your project?

Write down what the site must do in its first year. If the list says "log in", "dashboard" or "per-user data", start with Next.js. If it says "pages, posts, a contact form", start with Astro, then measure on a mid-range phone.

The rest of what I've built is on my work page; Clockful, the role-based app, is on my CV.

Sources

How this post was made: I wrote it with Claude Code. It drafted the text from my project's wiki, code and notes. Just a quick disclaimer for y'all out there :)

Hello Wor-- I mean, Hello dev.to :)

Mateusz Muszarski — Sun, 11 Oct 2026 21:38:00 +0000

Mateusz Muszarski

Oct 11

Trying to build an Awwwards-winning brutalist portfolio: the process, the mindset and the tools

#showdev #ai #astro #performance

16 min read

Trying to build an Awwwards-winning brutalist portfolio: the process, the mindset and the tools

Mateusz Muszarski — Sun, 11 Oct 2026 21:08:59 +0000

This post first appeared on my site, where the clips play and the version tabs work.

My old portfolio was a WebGL flight from Earth to Neptune. It looked great on my desktop. On a phone it showed an “Oops!” screen. This is the story of swapping it for a poster: the versions, the research, the sites I learned from and the reasons behind each call, mostly in pictures.

How this site got built, in 47 seconds. Made in code with Claude Code: the real site filmed frame by frame, and music written in code.

TL;DR

Before: a 3D site that scored 34 on mobile Lighthouse and didn't work on phones.

After: Astro, three languages, one font, a few shaders that never get in the way, and 95 to 100 on mobile Lighthouse.

How: a project wiki before any code, research on award winners and real products, four live designs to pick from, and checks on every change.

What rules did I work by?

Six rules: most written down before the first line of code, the rest learned on the way. Everything below follows from them.

Plan before code. The project lives in a wiki that every AI session reads first.
Practical first, then wow. Impressive within 3 seconds, usable in one tap on a phone.
Research, then pick. Real sites and real screens first; I choose between live options, not sketches.
Show, don't tell. A picture or a moving demo wherever a paragraph would go.
Keep every version. So I can show how it changed, and go back.
Nothing ships unchecked. Tests, screenshots I look at myself, speed on a slow phone.

How did it go, version by version?

About four days, and every version is kept.

Before: The 3D space portfolio (Replaced)

A WebGL flight to Neptune. Beautiful on my desktop, an “Oops!” screen on phones.

5 Oct 2026: Phase 0: a wiki, no code (Kept)

Plan first, code second.

Research, requirements, brand, legal and the rules of the project, before a single component.

5 Oct 2026: Drafting Table (Rejected)

A clean system is not a good design.

Paper, cyanotype and a title-block header. It passed every check and looked forgettable.

5 Oct 2026: Four live directions (Poster picked)

The type is the picture.

Orbit, Poster, Toybox and Exhibit as working pages. Claude recommended Orbit. I picked Poster.

5 Oct 2026: Round 2: Poster everywhere (Notes)

The whole home page in Poster, three colour themes and two fonts tried side by side.

5 Oct 2026: Round 3: less text (Approved)

Less text, more to see.

Tool logos with their names, a reel per project, a shorter everything. The comps stop here and the real code starts.

6-8 Oct 2026: The site today (Live)

Built in Astro one section at a time, then reshaped by rounds of my notes on the live site.

Why rebuild it?

Here is the old portfolio in motion:

The 3D space portfolio, recorded on a desktop. Planet textures: Solar System Scope, CC BY 4.0. The clips play on the original post.

Beautiful on my desktop. Then I measured it, on 5 October 2026:

13.8 MB before the start button. 7.6 MB of it was an emoji font.
34 on mobile Lighthouse. On a throttled phone the main content took 46.9 seconds to appear.
Phones got an “Oops!” screen. The site didn't run there at all.
Only a mouse wheel moved it. No touch swipe, no keyboard.
Nothing for search engines. The raw HTML had no text to index.

Someone opening a portfolio from a LinkedIn message on a phone gives it maybe ten seconds. My old site spent them on a loading bar. It proved I can write shaders; it also proved I hadn't thought about the person on the other side.

So no preloader, no gate, no scroll-jacking, and the same content on every screen.

What is a portfolio for?

Showing your work. It sounds obvious, yet many portfolios bury the visitor under “about me” paragraphs, or pitch their tech stack as if it were sacred, and the projects end up three scrolls down. Here the projects come right after the name: “See the work” is the first button, the tools are one strip of logos, and the about-me has a page of its own.

How did the planning work?

Before any code, I wrote the project down in a wiki of markdown pages: the audience, the brand, the budgets, the legal texts. The idea comes from Andrej Karpathy's LLM Wiki: the AI keeps the wiki up to date itself, so what it learns builds up. Three Claude Code hooks put the right pages in front of every session:

Session starts. The working rules and the lessons load first.
Each prompt. A hook names the wiki pages the task needs.
The work. Claude Code builds and checks with those pages open.
Turn ends. If the code changed and the wiki didn't, the turn stops once.

↻ A mistake becomes a one-line lesson, and the next session starts with it.

More in An LLM wiki: project memory for Claude Code.

What did the research show?

Agents opened 20 developer portfolios that won Awwwards awards in 2023-2026, on a desktop and on a throttled phone (1.6 Mbps, a 4× slower CPU). Each got two scores from 1 to 5: Wow for how memorable it is, and Practicality for how fast you can reach the projects and the contact. Practicality was measured as the moment the first real link becomes clickable.

20 award-winning portfolios by Wow and Practicality (one run each, 5 October 2026)

Site	Practicality	Wow
Edoardo Lunardi	5	4
Clément Grellier	5	3
Elliott Mangham	5	3
Valentin Mor	5	2
Antoine Wodniack	4	4
Jesper Landberg	4	5
Stefan Vitasović	4	4
Grégory Lallé	4	3
Rafa de las Heras	3	4
Hiroto Sato	3	4
Ravi Klaassens	3	4
Abhishek Jha	3	4
Francesco Michelini	3	3
Lusion (studio)	3	5
Max Milkin	2	4
Corentin Bernadou	2	4
Kris Temmerman	1	4
Bruno Simon	1	5
Samsy	1	5
Jordan Delcros	1	5

Both scores 4 or more: only 4 of 20 sites

What came out of it:

An award doesn't mean usable. On the throttled phone only 8 of the 20 were usable within 3 seconds, and 9 weren't usable within 10. The four least practical (game worlds and gated intros) even had a higher average Site of the Day score than the three most practical ones.
The jury isn't hiring. Awwwards weighs design 40%, usability 30%, creativity 20% and content 10%, and the jurors are designers and developers. A recruiter asks one thing: can I find the projects and the contact?
Stunning and practical is possible, but rare. Only four sites scored 4 or more on both. What they share: real links on the first screen, and the show beside the content, never in front of it.

Here is what that looks like on a phone. First, the immersive end:

Bruno Simon: Click to start

Samsy: No links in the HTML

Jordan Delcros: About 20 s of loading

Three of the most memorable sites in the study, on the throttled phone (5 October 2026). Quoted for review; the sites belong to their authors: bruno-simon.com, samsy.ninja, jordan-delcros.com.

And the four that did both. Each one gave this site an idea:

Edoardo Lunardi: Real links on the first screen

Jesper Landberg: The show beside the content

Antoine Wodniack: Hire me in the header

Stefan Vitasović: One signature effect

Stunning and practical, and what I took from each. Quoted for review; the sites belong to their authors: edoardolunardi.dev, jesperlandberg.com, wodniack.dev, stefanvitasovic.dev.

Section ideas came from Mobbin, a library of real screens from shipped products. The topic chips above my contact form are one of them: you start with a tap, not a blank field.

Why not another 3D world?

Honestly, I love them. My last portfolio was one. But I had measured both kinds of site by then, and the trade looked like this:

	A full 3D world	This site
First screen	a loader or “click to start”	my name, my role and two buttons
Links	often none in the HTML (Samsy, Jordan Delcros)	every link is real HTML
Search engines and screen readers	text drawn in WebGL is invisible to them	real text, painted first
Slow phone	9 of 20 award winners unusable within 10 s	shaders start after the text, only while visible
No WebGL or WebGPU	an error instead of the site (Kris Temmerman)	a CSS picture underneath

So the wow stays, as a layer instead of a gate. Four shaders run on this site, all written for it with no library:

Dither field

Contour lines

Riso prints

Goo

A dither field on All projects, contour lines in every footer, riso prints and goo on My life. Each starts after the text is on screen, runs only while visible, and holds still for reduced motion or the pause button. The clips play on the original post.

How do I run the AI?

Like a small team. I brief the lead agent, subagents research in parallel, MCP servers bring real data, hooks guard the risky commands, checks gate the result, and I review it. The AI does a lot of the typing; I own the decisions.

On the home page: Watch one change, step by step

The same process as a live story: who works on each step and what it looks like. See the seven steps

The building blocks are in Claude Code skills, hooks, MCP servers and subagents.

What happened to the first design?

Drafting Table, the first look. It passed every test and nobody would remember it.

So Claude built four very different directions as live pages. It recommended Orbit. I picked Poster: brutalism with manners. Flat saturated colour, hard offset shadows, square buttons and type fitted edge to edge.

One dark field, a contour map under the title, plates staggered left and right and an X-ray lens over every capture. Calmer, and hard to read.

Now

Easy to scan first, then the show.

A wall of every project to jump from, then a plain grid of cards on a light field. The contour lines moved to the footer.

Blog covers

Before

Colours came from the card's place in the list, so a post changed colour between pages.

After

One palette per cover, and the topic drawn literally.

A scale for a comparison, a crossed-out cookie for cookieless analytics. No words.

The rule behind all six: show the thing, cut the paragraph.

What do the other pages look like?

Every page gets the same care as the home page, on a laptop and on a phone.

All projects

My life

Blog

All projects, My life, the CV and the blog at 1440 px.

The same site on a phone: home, All projects, My life and the CV. Same content, one column.

What are the small details?

The name fills the screen without JavaScript. At build time a script measures the font and works out the exact width for each line, so the name fits edge to edge before any script runs (how it works).

The home page at 390, 1024 and 1920 pixels.

Phones get the same site. Every hover effect has a twin for touch (how), and the contact form has its own write-up, bug included (a contact form on a static site).

Who else is it built for?

Everyone, including people who use the web differently. A site that only works with a mouse and perfect eyesight shuts people out, and I'd rather it didn't. So:

Motion you can stop. One “Pause motion” button stops everything, and with reduced motion turned on, everything shows its final state (how that works).
A keyboard gets everywhere. A skip link jumps past the header, every hover has a focus twin, and focus never hides under the sticky header.
Screen readers hear the full story. Hidden text adds what the eye gets from context, like “opens in a new tab”, and every button's name starts with the words you see on it.
Contrast is tested, not eyeballed. A unit test checks every colour pair, and axe runs on every page.

How do search engines know who I am?

Sitemaps and meta tags are the floor. To find me by name, and one day show a knowledge panel, a search engine has to be sure who the site is about. So every page tells it the same story:

One person, one id. The home page and the CV describe me as one Person in structured data: my name, my role, my real portrait and my profiles. Every post and My life point back to it, and the links to my profiles carry rel="me".
Real photos with real facts. My life shows my own photos, each one marked up with where and when it was taken, and listed in the image sitemap.
A named author. Every post is a BlogPosting by that same person, with an author box under it, and every outside fact has a dated source.
A footer that does the work. Every page links to the projects, the CV, the blog, its RSS feed and my profiles.
One address per page. One canonical URL, the language versions linked to each other, and a share card for every page in every language.

The build fails if a page loses its title, description or canonical, or if the structured data stops parsing.

Author box

Footer

The author box under every post and the footer on every page: the same person, the same links, everywhere.

How is every change checked?

Static. Types, lint and unit tests.
Browsers. Playwright on every page, with axe for accessibility.
Eyes. Screenshots at phone, tablet and desktop widths that I look at myself.
Speed. Lighthouse on a slow phone.

↻ Anything that fails becomes a fix, and a repeated mistake becomes a lesson in the wiki.

Nothing is done until the checks pass and I've looked at the screenshots myself.

What is it built with?

Part	Tool
Framework	Astro 7 (why not Next.js)
Language and styling	TypeScript, Tailwind CSS 4
Translations	Lingui
Repo	Turborepo and bun
Font	Anybody, a variable font (OFL)
Icons	Tabler (MIT) and Simple Icons (CC0)
Hosting	Vercel
Contact form	EmailJS behind a Vercel function, Cloudflare Turnstile
Analytics	Umami Cloud, cookieless
Tests	Playwright, axe-core, Vitest, Lighthouse
AI	Claude Code

Where did it end up?

The home page in Lighthouse on mobile, from a local production build on 7 October 2026. Lab numbers: real-user data comes after launch.

If you'd like to talk about building something like this, or about a role, my contact form is one message long.

How this post was made: I wrote it with Claude Code. It drafted the text from my project's wiki, code and notes; I set the direction, and reviewed and approved it before it went out.