Building a Hypermedia-Driven Web App with the Beth Stack

The BET stack prioritizes developer experience with a hypermedia-driven architecture using htmx, Typed HTML, and Alicia for web app development.

### Building the Best Hypermedia-Driven Web Stack with HTMX, Typed HTML, Alicia, Terso, and Hyperscript
* 🚀 The "**Best Stack**" for building web apps today is a hypermedia-driven architecture that prioritizes **developer experience and performance**.
* 🛠 HTMX is a popular library that enables hypermedia responses by allowing any element to **make HTTP requests** and **choose where to put the response in the DOM**.
* 🧩 Typed HTML provides a way to write **fully type-safe JSX** with functional components that output directly as **HTML strings**.
* 🖥 Alicia, a fast and type-safe web framework, is used as the **server framework** for the stack.
* 📝 The stack is used to build a simple to-do list app, demonstrating **basic CRUD operations**.
* 🗄 Terso, a serverless SQLite on steroids, is used to **persist the data to an actual database**.
* 📜 Hyperscript, an inline scripting language that fits perfectly with the hypermedia model, is used to **add client-side scripting to the app**.
* ☁ The stack is deployed using Fly.io, with the ability to **colocate the app and the Terso database in the same data center for optimal performance**.

if you're building a web app today but tired of all the chaos of front-end frameworks, I have the tech stack for you. The best stack is a hypermedia-driven architecture that prioritizes developer experience first while still having very strong performance. It begins with htmx. HDMX has been gaining a lot of popularity recently, and for good reason. It provides a sensible alternative to the now most common way of building web apps: a JavaScript-heavy single-page application that gets all of its data by consuming JSON-based APIs and then has to handle all the parsing and rendering logic on the client. htmx says there's another way. htmx is based on the concept of hypermedia responses. To put simply, this means instead of returning JSON, your endpoints return HTML. Most websites technically do this already, but on a full-page level. This is mainly because of a limitation of traditional HTML, which only allows anchor and form tags to submit HTTP requests and forces the whole page to change with the response. HDMX is different in that it allows any

element to make HTTP requests, and then enable you to choose exactly where in the DOM to put the return to HTML, and whether or not to replace what was there before. All of this is done with the declarative HTML embedded syntax instead of traditional scripting. That was a lot, so let's take a look at a quick example. On the top is the HTML that our client will start with. The body contains a single item, a button with two attributes. The first is hxpost equals slash clicked. This tells Htmx that when the element is triggered, which is onClick by default for buttons, to send an HTTP post request to slash clicked. The next attribute, HX swap, tells Htmx what to do with the HTML response that it gets from that request. Here, outer HTML means to replace the entire element. On the bottom represents our server. It simply returns an HTML string when responding to a post request to slash click. Now, with the code running, we can see that when we click the button, it is replaced by the div returned from the server. Pretty cool.

this is just the tip of the iceberg of what's cool about htmx, and all the tools it offers. It can also do loading States, websockets, infinite scroll, CSS transitions, client-side routing, and so much more. I'm going to move on for now, but definitely check out the htmx docs and essays after you finish this video because JSON is so ubiquitous and doesn't contain any additional information other than raw data. Nearly every language has very strong support for serialization and deserialization. However, now that we are working with HTML, things can be a bit trickier. Our code has data, but HTML has UI embedded with data. We need a good way to combine the two that's better than raw string concatenation. An additional challenge when working with HTML is the need for syntax highlighting, formatting, and general editor interrupt. Without these, writing HTML becomes not fun very quickly. Enter templating. Most languages have standard templating libraries. PHP has Blade and Twig, Python has Jinja and Django, Ruby has ERB, and so on. Although personally, as someone coming from a

front-end background. I'm a bit put off by all of these, although I promise it's for fair reasons. All these templating languages involve the template being in a completely separate file from your actual code with the data to be used. This means that you have to constantly go back and forth between these two files, as well as losing any type safety you had. Also, not all of them support components, something that as a front-end Dev I would consider basically a necessity. The ability to split up your UI into reusable pieces is just so important for a good developer experience. Additionally, the ones that do support components are often based around the idea of a single file component, meaning every component, no matter how small or simple, must be in its own file. But wait, who am I kidding, I'm a front-end Dev, isn't JSX basically a templating language? And now that I think about it, it's actually a pretty good one at that. First of all, there's so much supporting tooling for it due to its popularity. TypeScript types for HTML

attributes and tons of supporting syntax highlighting formatting and autocomplete tools. Second, a functional JSX component has a really great mental model. A component is dead simple: a function that takes some properties as an argument, maybe does some logic, and returns a UI. And finally, the actual templating is really clean. Curly braces escape you into JavaScript land where you can do whatever logic you want right in your template as long as it evaluates to a valid result. But remember, our goal here is to write HTML strings, not JavaScript. Technically, we could use React and render to string, but this is pretty stupid for many reasons that I'm not going to go into. What if there was a way to get the developer experience of JSX but with the output as a raw HTML string right from the start? It turns out there is with this amazing library called Typed HTML. Typed HTML allows us to write fully typesafe JSX with functional components but that outputs directly as an HTML string. Perfect. Let's recap. So far, we have HTMX, our client framework that will power all the hypermedia.

requests and DOM manipulation and typed HTML and JSX, providing an easy way to write the HTML to return from our server. But what actually is our server? Well, since we're using JSX, that means we're locked into TypeScript. So, we could use Express or Nest. I'm just kidding. We are way past those. Bun is an all-in-one JavaScript runtime and toolkit designed for speed. Think of it as Node, PNPM, ES build, and Vite in one, but more multiple times faster than all of them. Check out the Bun benchmarks after this video. They will blow your mind. Bun plans to release their 1.0 version in a couple of months. Although what they have now is still really exciting. I was really impressed with how much Bun provides and just how fast everything was. It's currently only available on Linux, but with Windows Subsystem for Linux, I was able to get it installed pretty easily. Alicia is one of Bun's fastest web frameworks, which caught my eye for its commitment to end-to-end type safety while keeping a familiar Express-like syntax. It has all the stuff you would

expect from a web framework, plus input validation, a fully typed safe fetch client, remote procedure calls, dependency injection, automatic Swagger generation, and so much more, as well as being multiple times faster than even the best node offerings. Alicia is awesome and a great pick to be the server framework for our stack. Okay, now we have our tools, let's get building. We're going to make a simple to-do list. I know it's unoriginal, but it's an easy way to demonstrate basic CRUD operations. After installing bun, we'll start by creating a new directory and running bun in it to scaffold our project. Now we can add Alicia with npm add in index.ts. We'll start by creating our Alicia server. We can use bun run to launch our app. Looks like everything seems to be working, so let's move on. Also, from now on, you can use the watch flag to automatically restart your app on changes. We'll need some base HTML to serve as the shell for our app, which I'll define just as a variable for now. This is pretty basic.

just some meta tags in a body. Now let's set up Alicia to serve this on the index route. Alicia has an HTML plugin that adds the necessary headers to the response, allowing the browser to interpret it as a valid HTML document for rendering on the screen. We can add it with bun app. Now we import HTML and apply the plugin to our app with the use method, giving us access to the HTML function in our handlers, which we can use to wrap the base HTML variable. And now we have our base HTML rendering correctly. We won't need this HTML helper from now on. Even though our endpoints will return HTML, it's actually okay that they are just interpreted as plain text. hdmax will handle all the interaction with the DOM. Now it's time to bring in JSX. Let's install typed HTML as a dev dependency and adjust our tsp fig as described in the docs. Now change index.ts to index.tsx and import typed HTML. Our first change will be to make our base HTML variable a component. To do this, we'll turn it into a function that

takes a children prop and places it after the head of our document. Now let's update our route handler to use this component. Whatever we pass as children will appear in the starting HTML when loading the index route. All looks good, so time to bring in htmx. Adding htmx is as easy as dropping a script tag in the head of our base HTML. It's worth mentioning quickly that if you're using VS Code, there's an htmx tags extension which adds types for the htmx attributes, although it seems to only kind of work with JSX. Now let's recreate the basic example from the start of the video. We'll start by adding the initial button to the body in the starting HTML. Then we'll create the slash clicked post endpoint, which will simply return a div with some text back in the browser when we click the button. Htmx is sending the post request and swapping in the response just as we expect. It would be nice if this button was in the middle of the screen, but I would really prefer not.

to use vanilla CSS, we could use Tailwind, but Tailwind requires PostCSS and a build step. Or so I thought. It turns out, Tailwind just works with a single script tag. Pretty convenient. Let's add it to our base HTML. Tailwind is amazing for many reasons, but its inline format actually fits perfectly with the htmx model, so our hypermedia responses can ship with their styles as well. It's also worth noting that if you're using the VS Code Tailwind IntelliSense extension, it requires a tailwind.config.js file present in your project to be enabled, although it's fine to leave empty as our app won't use it. Let's add some Tailwind classes to our HTML, and look at that, our styles work great. Now let's start actually building our to-do list in our app. A to-do will have a unique ID, some text content, and whether or not it's completed. For now, we'll represent it as an in-memory array for simplicity. I've seeded the database with two entries.

give us some data to work with. Now let's create a to-do item component to render it. To do, we'll take the contents of the todoist props and show the content in a p element. Have a checkbox for the completed status and a button to delete. Now, our to-do list component. It will take an array of to-dos as props and map over it, creating a to-do item for each to do. Next, let's set up a new endpoint slash to-dos, which will return the HTML of the rendered to-do list. To do this, we simply return the to-do list component with our DB as the to-dos prop. Checking out the slash to-dos route, and there's our hypermedia in action, our to-do list as HTML. Now let's load this onto our main page. We could put this behind a button click like before, but instead let's have the body element fetch the data immediately on load with HX trigger load and place the contents inside itself with HX swap inner HTML. And if we check the index.

route our to-dos are there as we expect. Now let's focus on adding CRUD functionality. We'll start with being able to toggle whether a to-do is complete. First, we'll create a new post handler for /todos/toggle/:id. On request, we'll get that to-do from the database, toggle its completed status, and return a to-do item component for that to-do for our client to swap in place of the old one. Note the additional argument in the post function. This defines the input validation for the route params using the T object imported from Alicia TDOT numeric automatically attempts to coerce any string to a number. Now we'll modify our to-do item component to start adding the HX post attribute using the ID prop. This will send the post request to the right endpoint for each to-do's ID when the input is toggled. But we want to swap the entire component with a response, not just the input element. To do this, we need to change the htmx Target, and we can do this using the HX Target.

attribute although HX Target supports CSS selectors to Target elements anywhere in the Dom. Here we can just use closest dib to grab the entire component. The final step is to set HX swap to Outer HTML to completely replace the existing element. And look at that, now we can toggle it to do and its state will remain even when we reload the page. Next, deleting a to-do. The process here is very similar to what we just did. We'll create a new delete endpoint and in our Handler remove that to do from the database. Then we can update our delete button, again very similar to before. Notice we're still swapping the parent div outer HTML with the response from the request. HX swap does have a delete value but it deletes regardless of response. We wanted to only delete if the server deleted successfully. The delete endpoint doesn't return anything so swapping the parent div with nothing is basically the same as deleting. But this ensures it only happens if the request completes successfully and success deletion that remains if you reload now.

on to the final part of crud creating new to-dos this time create a post endpoint slash to-dos. Again, note the Alicia input validation. First, we'll make sure the input isn't an empty string and then insert it into the database. Finally, return a new to-do item component to ensure no overlapping IDs. I created a variable to increment on each call. Now let's create our to-do form component. It has one text input with the name content to match what our server expects and a submit button. We can add this right below the list of to-dos in our to-do list component. Back in the form, we can add the HX post attribute to the slash to-dos endpoint. This request returns the new to-do, which we want to place at the end of the set of existing to-dos. To do this, we add the HX swap before begin attribute. This places the new to-do before the form, exactly where we want it to be. And there we go, full crud functionality complete. The only problem now is that our database gets wiped back.

to its default state whenever we run our app. To make it a real application, we'll want to persist our data to an actual database. Bun does provide its own SQLite driver, which although it is technically supported, I couldn't get working with my ORM of choice. These days, Drizzle, but that's okay because the Beth stack uses Terso. Terso is serverless SQLite on steroids and supports creating distributed replica databases at the edge all over the world. It works perfect with Drizzle and also has a very generous free tier to get started. After installing the Terso CLI and signing in, make a database with `tercodb create`. Next, get the database URL with `tarso DB show`, and finally, create a new authentication token for your database with `tercodb tokens create`. Back in our project, create a `.env` file and add your database credentials. We're about to add a separate database folder so to keep things organized. I'm moving our `index.tsx` file to a `source` directory. We'll start by defining our database schema in `schema.ts`. And almost forgot

we'll need to add drizzle drizzle kit and the lib SQL client to our project. Our database schema is very simple: a single to-do's table with the same three fields we had before. ID is our primary key of type integer. I'm enabling Auto increment so we don't have to worry about generating new IDs. Content is a not null text field, pretty simple. For the completed column, sqlite doesn't support booleans, but you can accomplish the same thing with either a 0 or a one in an integer column. Drizzle can emulate this with mode Boolean. Additionally, I've set the default defaults as a to-do always starts uncompleted. Finally, we'll create a new to do type inferred from our table schema. We'll now need to create a drizzle config file to tell drizzle where our schema lives, the database driver we are using, and how to access the database. Enabling verbose and strict just keeps us a bit more informed of what drizzle is doing. Now we're all set to use drizzle kit push to push our

typescript schema to our actual database. If we run drizzle Studio, we should see the to-do's table created but empty. That's perfect for now. For convenience, you might want to add these two commands and scripts in your package.json. Finally, it's time to actually create the database client and replace our old fake one. In a new index file in the DB directory, create the drizzle client. Enabling the logger lets us see a bit more clearly what queries are being run. Now we can start modifying our server code. We'll start by deleting our old database and to do type. Then we'll import our new database to Do's table and to do type. Let's start with our git Handler for slash to Do's. We select all rows from the to-do table and pass the data to the to-do list component. Easy enough. Now the toggle endpoint. First, we get the to-do based off the past ID, then update that to do with the opposite of the old to-do's completion status, and finally return a new to do item with the

updated to do data next the delete Handler. This one is simple. Just delete the row into-do's where the ID is the past ID. Finally, our create new to-do Handler. Like before, we check to make sure the input isn't empty, then create the new row and return the new to-do item. And that's it. If we check the browser, everything works just as before, but now on a remote SQLite database. Awesome. One thing that is kind of annoying is the text input of our form doesn't reset when we submit the form. To solve this, we are going to need to do some client scripting, but don't worry, HTMX actually completely endorses the use of minimal scripting for the places it's required, so not everything has to be done 100% over HTTP, although they make it clear that any scripting should be done inline in your HTML, just like inline styles. With HTMX, inline scripting fits perfectly with our component and hypermedia model. There are multiple inline scripting libraries out there, such as Alpine.js or even vanilla.js, but the creators of HTMX

have also made a companion Library called hyperscript. An easy-to-use yet powerful inline scripting language, which I am deciding to use for our stack. To add hyperscript to our app, we simply drop the script tag in our base HTML. Quick note about types: hyperscript has a VS Code extension, but it only supports HTML, not JSX. So, we'll need to create a .d.ts file in your project and add the underscore attribute that hyperscript uses to the HTML tag interface in the JSX namespace. Now we're all set up to add scripting to our form. This bar is actually really easy. The reset method on the form object resets all of its fields. So, using the target keyword, which by default is set to the element running the script, we can call reset on submit. And look at that, works perfect. Our app is complete. So now it's time to deploy the BET stack. You can deploy anywhere that supports Docker, but by far the most convenient way is with fly.io. One quick note before we deploy: make sure that the module entry point in package.json.

correctly matches the entry point for your app. As we moved and renamed this file a couple times after installing the fly CLI and logging in. Start with fly launch, choose a name and a location, and fly will generate the files needed for your deployment. Now add your environment variables and with that, you can run fly deploy, and in a minute or two, your app will be live. Something cool about turso is that itself runs on fly. This means that when you deploy your app to one or multiple of fly's 34 regions, you can also put a companion database in the exact same data center for some really amazing performance. And there you have the Beth stack. I actually quite enjoyed writing the simple to-do app. I think the stack brings a really strong combination of performance and developer experience to the hypermedia-driven application architecture set forth by htmx. It might not be the best stack, but it is the best stack. Now is a great time to go check out all the cool things I told you to hold out on each part of this stack. Bun.

Alicia Turso and HDMax are amazing and worth your time to give their respective websites a visit and read up on all their cool features. That I didn't mention. If you're interested in seeing the source code to the to-do list app in this video, there will be a link to the GitHub repo for it with a different branch for each step along the way, as well as a link to the live deployed site in the description. If you enjoyed this video, consider subscribing. As always, the transcript and markdown source code are available on my GitHub link in the description, and any corrections will be in the pin comment. Thank you for watching, and I'll see you in the next video.

The BETH Stack: Build Hypermedia-Driven Web Apps with Great DX and Performance

Ethan Niser

The Advantages of htmx and JSX for Web Development

htmx offers a hypermedia-driven architecture with a focus on developer experience and strong performance, using HTML for endpoint responses and providing a declarative syntax for DOM manipulation.

htmx provides a wide range of tools, including loading states, websockets, infinite scroll, CSS transitions, and client-side routing.

JSX, known for its popularity and supporting tooling, serves as a powerful templating language for combining data and UI in web development, with strong support for components, offering a seamless developer experience with its widespread adoption and TypeScript integration.

Using Typed HTML and Alicia to Build a Web Application

Typed HTML allows for typesafe JSX with functional components, outputting directly as an HTML string, providing a great developer experience.

Bun, an all-in-one JavaScript runtime, along with Alicia, a fast and type-safe web framework, are chosen as the server for the stack, offering features like input validation, fully typed safe fetch client, and automatic Swagger generation.

The process involves scaffolding the project with Bun, adding Alicia, setting up base HTML with Alicia's HTML plugin, and integrating Typed HTML and JSX for building a simple to-do list with basic CRUD operations.

Using htmx and Tailwind for Building a To-Do List App

- htmx can be easily added to a web application by including a script tag in the base HTML and allows for dynamic content updates without full page reloads.

- Tailwind, which normally requires PostCSS and a build step, can be used with a single script tag, making it convenient for styling the app.

- The app's to-do list functionality includes rendering to-dos as HTML, fetching data on page load, and implementing CRUD functionality for toggling to-do completion, all of which involves using htmx attributes for dynamic content manipulation.

Using HX Target for CRUD Functionality and Database Persistence

HX Target supports CSS selectors for DOM element targeting, allowing for easy component grabbing.

It can be used to set HX swap to Outer HTML, replacing existing elements and maintaining their state.

The process for deleting a to-do is similar, using a new delete endpoint and swapping the parent div outer HTML.

When creating new to-dos, a post endpoint for to-dos is utilized, with input validation and the use of HX swap before begin attribute to place the new to-do in the desired location.

To persist data to a database, Terso, a serverless SQLite tool, is recommended for its compatibility with Drizzle and generous free tier for distributed replica databases.

The process involves creating a database with Terso CLI, obtaining the database URL, and adding the credentials to the project's .

The database schema is then defined, and the project is reorganized for better structure.

Setting up a Drizzle Database with Drizzle Kit and the SQL Client

The database schema includes a to-do table with ID, Content, and Completed fields, using integer for the primary key and boolean emulation for the completed column.

Drizzle configuration file is set up to specify the schema location, database driver, and access.

The process involves pushing the TypeScript schema to the database using Drizzle Kit, then creating a database client, and modifying the server code to handle to-do endpoints.

Hyperscript is easily added to the app by dropping the script tag in the base HTML, and it allows for simple inline scripting.

Deploying the BET stack is conveniently done using fly.

io, with the option to colocate a companion database in the same data center for enhanced performance.

The BET stack offers a strong combination of performance and developer experience, following the hypermedia-driven application architecture set by htmx.