feat: add Astro to the benchmark suite - #29
Conversation
Adds Astro 7 as the 14th framework, a like-for-like port of the shared weather app wired into the existing build, test, lint and benchmark tooling. The app follows Astro's model rather than mimicking a component framework: every .astro file renders to static HTML at build time and the only client JavaScript is a single island script that owns state, fetching and DOM updates. astro.config.mjs sets build.assetsPrefix to "." so the emitted asset URLs stay relative and the same build works at the site root and under /astro/app/ on the benchmark server. Because the Astro CLI is neither vite nor ng, three places that special case those two needed an astro branch as well: config.json's requiresNpx, build_time.py, and build.py, whose raw fallback failed with "astro: not found". Registration otherwise mirrors the other frameworks: a frameworks.json entry, a playwright config plus an entry in the shared config map, generated npm scripts, a dev server port, a chart colour, and the app README. Brand colour and logo come from Astro's current press assets, whose gradient runs #D83333 to #F041FF; the pink end is used because the red end is nearly indistinguishable from Angular's. Also documents Lume.js in .github/docs/apps.md, which was missing from the list, and corrects the framework count. Verified on CI: 22/22 Playwright tests pass, lint clean, and all six benchmark types complete.
There was a problem hiding this comment.
If all of the logic is vanilla JS, then what is the difference between this and the vanilla js version?
|
I did think about building an Astro version initially. I love Astro and use it for a lot of my sites. But, it's not really a frontend framework in the same sense as the others. It's a build-time meta framework (and you then use a frontend framework like Svelte/React/Angular/whatever inside Astro for your client-side reactivity). So I'd worry that the comparison would be like apples and oranges. Because most of the benchmarks ar client-side stuff, so it would just be comparing the vanilla js island. |
Fair point, and I don't really disagree. The client-side numbers here are a vanilla island, not Astro reactivity. Astro does call itself a web framework and benchmarks itself, but its own comparison set is Next, Nuxt, Gatsby and WordPress, not React or Svelte. Which is your point again really. So maybe the fix is grouping rather than dropping it: tag it as a meta framework in frameworks.json so the charts can separate it, with vanilla as the shared floor. Leaves room for Next or Eleventy later too. Happy to rework it that way, or close it if you'd rather. Either way the apps.md fix (Lume.js was missing from the list, count was off) and the vite/ng hardcoding in build.py and build_time.py are worth splitting out, since those bite any non-vite framework you add next. |
|
I'll go ahead and merge :) |
2 participants
Adds Astro as a 14th implementation of the weather app, ported like for like from the existing apps and wired into the build, test, lint and benchmark tooling.
I built it the way Astro is meant to be used rather than making it look like the component framework apps. Every
.astrofile renders to static HTML at build time, and the only JavaScript that ships is a single island script holding state, fetching and DOM updates. That is the interesting thing to measure about Astro, so it felt wrong to hide it behind a UI framework integration.One config choice worth explaining:
build.assetsPrefixis set to"."so the emitted asset URLs stay relative. Without it the built app 404s when the benchmark server hosts it under/astro/app/.The Astro CLI is neither
vitenorng, and three places special case those two by name, so each needed an astro branch too:requiresNpxinconfig.json,build_time.py, andbuild.py, whose raw fallback failed withastro: not found.For the brand colour I used
#F041FF, the pink end of Astro's current logo gradient. The red end (#D83333) is close enough to Angular's that the two are hard to tell apart in the charts.While I was in
.github/docs/apps.mdI noticed Lume.js was missing from the list, so I've added it and fixed the framework count.Ran the Lint, Test and Benchmark workflows on my fork against this branch, all passing. 22/22 Playwright tests, and all six benchmark types complete. Lighthouse came out at 96 performance, 100 accessibility, 100 best practices, 90 SEO, with a 3.8 KB gzipped bundle.
Two notes:
NaN hPaunder?mock=true. I've kept parity with react, svelte and vanjs, which all readcurrent.pressure_mslwhile the shared mock fixture only hassurface_pressure. Looks like a cross framework fix rather than something to patch in one app.Closes #27