From code being written to code working in an app, there are a wide variety of places where code is run. This distinction needs to be kept in mind, especially for something like web metaframeworks, where you have code running on different contexts using the same language (so it's no longer as obvious). So I think it's a good idea to write it down.
My mental model
When making the thing:
While editing I can use my editing commands, as well as on save, on commit…
- ie. edit time
During some sort of build process: automatically turning the current code/data into stuff that is more ready for deployment
- ie. compile time, build time
How is the code deployed?
For local apps: then there's only one place left where the code can run.
For server-client architectures:
The server listens for requests. When one comes, the server runs some code to make a response.
- I call this "response time"
- "server-side rendering" happens here, generally. For instance, in the "SSG/SSR/SPA" distinction "SSR" refers to rendering in response to a request. (However, sometimes "SSR" includes any rendering not done on the client: "SSR support" in, say, something like Svelte means it's able to render the HTML outside the browser.)
The response reaches the client and might include more code for the client.
- ie. client-side
Example
So, for instance, when writing a SvelteKit or server-side rendered Astro project, I would frequently refer to these contexts:
- (edit time: I sometimes prefer to just automate something in Emacs)
- build time
- response time
- client side
JS metaframeworks allow us to share code across different contexts, but they are still different contexts, and sometimes it is necessary to distinguish between them. Having this mental model has been pretty useful.