Source for www.franksmovielog.com. Built with Astro.
-
Install nvm.
-
Initialize your Node env.
An .nvmrc is included in the project.
# use the .nvmrc version of Node. nvm use
-
Install dependencies.
NPM has come a long way and we don't need workspaces (yet)
npm i
-
Start a Dev server.
# start Astro dev. npm run dev
-
Open the source code and start editing!
The site is now running at
http://localhost:4321
.
A quick look at the non-standard directories included in the project.
.
├── content
├── src/images
├── src/styles
└── src/utils
-
/content
: The movie log content. Reviews and data copied from the backend system, as well as front-end specific assets like backdrops and posters. It also contains the content for the how I grade page. We don't leverage Astro's content directory because I prefer keeping content and code separate. -
/src/api
: Functions to access the data in the/content
folder. This replaces Gatsby's GraphQL layer./src/api/data
contains Zod schemas to validate all the JSON and Markdown. -
/src/utils
: Shared utility functions.
Push to Github and Actions builds the project and POST's to Netlify.
Gatsby's deathbed status prompted me to migrate to a new framework. I tried Next.js first (see why not next? below) and decided on Astro. Losing Gatsby's GraphQL layer hurt (I still miss it) but the move means I can finally use ES modules and bump multiple dependencies (looking at you, unified).
I also opted to prune as many dependencies as possible in the name of simplicity. Notably:
-
Tailwind instead of Vanilla Extract and Sprinkles. The big draw for Vanilla Extract was the ability to leverage Typescript to type the styles, but Tailwind now has an eslint plugin that covers this use case.
-
Vitest instead of Jest. Astro's built on Vite (which handles Typescript transpilation), so Vitest is a minimal add. Adding Jest would bring Babel into the mix.
-
Npm instead of Yarn. I still prefer Yarn's DX (having to type 'run' for every NPM script is annoying) but Yarn's recent change to how it resolved peer deps made me wary of its long-term stability. I don't need workspaces (yet) so NPM will do.
Total distinct packages (i.e. name + version):
v1 | v2 |
---|---|
1826 | 971 |
Source lines of code:
Language | v1 | v2 |
---|---|---|
Typescript | 274,815 | 10,202 |
Javascript | 185 | 252 |
I considered Next. Even ported the entire site over and had it all working. React Server Components are sweet. But Vercel (and Next) are focused on apps not static sites. They don't have an asset pipeline and Vercel doesn't even cache anything in the /public
folder. This makes sense as most apps will offload this to a CDN. But for a static site, it's the priority.
Astro, while not perfect, has static sites as it's top priority, and it's asset pipeline is easy to use. The biggest downside is that now the static pages in my site (the home pages, the review pages, and the stats pages) are now really static with no javascript loading, so each page is a full-reload. But given most visits to my site are for single reviews, this seems like a better option.
Still, I hope Astro soon supports RSCs so those pages that are interactive (like the review and viewing lists) can benefit from the faster client-rendering.