Designing a dynamic web application with Astro

Astro.js is among the most popular meta-frameworks for JavaScript developers, and for good reason. Astro makes it relatively easy to structure web applications for maximum effect with minimal effort. It can be hard to get your head around how Astro works, however, due to the ways it breaks from more traditional front-end JavaScript frameworks.

In this article, we’ll take a hands-on approach to Astro. My goal is to leave you with a good overall understanding of how the framework handles web development essentials like pages, endpoints, routes, and deployment. See my recent introduction to plug-and-play web development with Astro for an overview of the framework.

The demo application

The to-do application is a classic way to explore a new tech stack and see how it handles standard development requirements. The online to-do list requires a small feature set but lets you explore all the basic elements of listing data and performing CRUD operations. Once you have these basics down, the sky is the limit for adding new features. How about adding drag-and-drop columns and infinite scrolling, or delivering your to-do list as an RSS feed? It’s no problem once you understand how the tech stack works.

Web application components are notoriously diverse, and sometimes getting them to work together nicely is like herding kittens. I might start off wanting to deploy a snappy, attractive page with simple functionality, but I’m soon elbow-deep in arcane configuration files. Astro alleviates some of that complexity by providing a universal layer that handles many of the common back-end infrastructure and engine concerns. And it lets you use or even combine a variety of familiar front-end frameworks.

SPA, MPA, or something in the middle?

There are a few considerations to designing the to-do application using Astro. One immediate decision point is whether you want a single-page application (SPA) or muti-page application (MPA). The type of application you choose determines how the app will load its data into the client.

The defining characteristic of SPAs is that most (if not all) interactions are driven by the client issuing API requests in the background and updating the UI accordingly. The idea of a single-page app is that you load everything you need, including the JavaScript, and then do the work from there. The result is essentially a thick or fat client in the browser.

MPAs are more in the tradition of Web 1.0: a collection of static pages connected with hyperlinks. Whereas SPAs are more modern and dynamic, MPAs can be more reliable. While the two styles are often pitted against each other, the truth is many modern applications blend these styles. Ideally, we want to maximize the strengths and minimize the weaknesses of each one. It is common to load as much content as possible statically, and then apply the dynamic elements where they make an impact. In both cases, you want to apply the best practices for the style you are using.

That’s the idea, anyway. But anyone who has set out to code a blended application can tell you it gets tricky fast! Astro employs an islands architecture to make the hybrid format more manageable. Islands essentially divvy up the application layout into discrete parts, which can then be loaded using best practices for the given type of content.

Taking the to-do app as our example, it makes sense to render any framing content (like headings) in a way that supports maximum speed and SEO-friendliness. Then, for the dynamic to-do list, we have a few options. We could use a reactive framework like React in full SPA mode, in which case we’d send the client assets over and then load the data from a server API. Another option is to use the same component and pre-render it on the server, a kind of middle-ground between SPA and MPA. Another option altogether is using plain JavaScript or HTMX to create and render the list.

Regardless of the style you choose, Astro does much of the upfront thinking for you. It walks you through deciding how parts of the UI should be rendered, then lets you use the same process to construct your server-side APIs.

Static or server-side rendering?

Astro offers both static and server-side rendering of web application pages and components. In static mode, the content is rendered ahead of time on the server and packaged for utmost efficiency in delivery and display on the client. In server-side rendering (SSR) the content is rendered live upon every request. (Static rendering is sometimes called SSG or server-side generation, to contrast it with SSR.)

Astro is best known for its ability to generate front-end views using reactive frameworks like React, but it can also handle back-end needs like API endpoints. In both cases, the static vs. SSR question comes into play. A statically generated endpoint or page is essentially a hard-coded file that is created at runtime and serves the same content for every request.

In Astro, pages and endpoints are generated on the server by default. This pre-rendering is intended to give you maximum efficiency in terms of bits going over the wire and minimizing processing power being used at the client.

You tell a page or endpoint to use dynamic rendering with the following syntax:

export const prerender = false;

Setting the deployment target

Keep in mind that when you are running in dev mode, you don’t necessarily see the effect of static loading because the dev-mode serving is constantly reloading your changes. That’s why it’s important to mention Astro’s adapter concept, which is used to prepare your application for deployment.

Adapters might seem complex at first, forcing you to deal with another concern in the midst of trying to just build your application. But adapters can greatly simplify the question of deployment. (SvelteKit is another framework that employs adapters.)

Astro includes several deployment targets in its adapter providers, including Netlify, Vercel, and Node. If you think about it, only SSR components require an adapter. If a component is SSG, then it ultimately is turned into a static asset—either a bundled-up HTML page or a JavaScript file in the case of endpoints.

Adapters provide a clear-cut path to deployment and flexibility in targets, similar to the flexibility Astro gives you when choosing a front-end framework.

Routing

Like Next.js, Astro provides file-based routing. This is nice because your URL mapping is defined simply by where you put your files and what you name them. Of course, Astro also supports other needful things like route parameters.

In Astro, the /src/pages directory holds your routes. So your main index landing page would be defined as:

/src/pages/index.astro

While the URL /test would live at:

/src/pages/text.astro

Similarly, your endpoint routes follow a similar convention. You could define a /data.json endpoint like so:

/src/pages/data.json.ts

Note that the.ts extension will be stripped off in the URL. Astro uses the.astro versus.ts distinction to tell if you want a web page or an endpoint. Astro is also happy to use the following if you like your JavaScript untyped:

/src/pages/data.json.js

Sometimes, I do like my JavaScript untyped. So sue me.

HTMX on the front end

Regular readers will know that I’m a fan of HTMX. I’ll even go so far as to predict it’ll be added to the HTML spec at some point. I’ve previously explored using Astro with front-end frameworks like Svelte and React. This time, I’m interested to see how it works when combined with HTMX.

This should be a neat way to get a look at both HTMX and several of Astro’s powers, like SSG pages and SSR endpoints. Of course, React, Svelte, or Vue could also work very well. The snazzy part of HTMX is that it provides much of the interactivity we need, like AJAX requests and partial view updates, without stepping outside of HTML.

Combined with Astro’s server-side and deployment capabilities, HTMX should give us a good foundation for doing everything we need. Hopefully, we can try adding something more sophisticated as well, like infinite scrolling. Check back next week for the next article in this series.