베스 스택으로 하이퍼미디어 중심 웹 앱 구축하기

BET 스택은 웹 앱 개발을 위해 htmx, Typed HTML, Alicia를 사용하는 하이퍼미디어 중심 아키텍처를 통해 개발자 경험을 우선시합니다.

### HTMX, Typed HTML, Alicia, Terso 및 Hyperscript로 최고의 하이퍼미디어 중심 웹 스택 구축하기
* 🚀 오늘날 웹 앱 구축을 위한 **'최고의 스택'은 개발자 경험과 성능을 우선시하는 하이퍼미디어 중심 아키텍처**입니다.
* 🛠 HTMX는 모든 요소가 HTTP 요청을 하고 DOM에서 응답을 저장할 위치를 선택할 수 있도록 하여 **하이퍼미디어 응답을 가능**하게 하는 인기 있는 라이브러리입니다.
* 유형화된 HTML은 HTML 문자열로 직접 출력하는 함수형 컴포넌트를 사용하여 **완전히 형식이 안전한 JSX**를 작성할 수 있는 방법을 제공합니다.
* 🖥 빠르고 형식이 안전한 웹 프레임워크인 **Alicia**가 스택의 서버 프레임워크로 사용됩니다.
* 📝 스택은 간단한 할 일 목록 앱을 빌드하는 데 사용되어 **기본적인 CRUD 작업**을 보여줍니다.
* 🗄 서버리스 SQLite인 Terso는 **실제 데이터베이스에 데이터를 지속시키는 데 사용**됩니다.
* 📜 하이퍼미디어 모델에 완벽하게 맞는 인라인 스크립팅 언어인 **하이퍼스크립트**는 앱에 클라이언트 측 스크립팅을 추가하는 데 사용됩니다.
* ☁ 스택은 Fly.io를 사용하여 배포되며, 최적의 성능을 위해 **앱과 Terso 데이터베이스를 동일한 데이터 센터에 코로케이션**할 수 있습니다.

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

웹 개발을 위한 htmx 및 JSX의 장점

htmx는 개발자 경험과 강력한 성능에 중점을 둔 하이퍼미디어 중심 아키텍처로, 엔드포인트 응답에 HTML을 사용하고 DOM 조작을 위한 선언적 구문을 제공하며 로딩 상태, 웹 소켓, 무한 스크롤, CSS 전환, 클라이언트 측 라우팅 등 다양한 도구를 제공합니다.

인기와 지원 도구로 잘 알려진 JSX는 웹 개발에서 데이터와 UI를 결합하는 강력한 템플릿 언어로, 컴포넌트에 대한 강력한 지원과 함께 광범위한 채택 및 TypeScript 통합을 통해 원활한 개발자 경험을 제공합니다.

입력된 HTML과 Alicia를 사용하여 웹 애플리케이션 구축하기

타입이 지정된 HTML은 기능적 컴포넌트가 포함된 타입 안전 JSX를 허용하고 HTML 문자열로 직접 출력하여 뛰어난 개발자 경험을 제공합니다.

올인원 JavaScript 런타임인 Bun과 빠르고 타입 안전성이 뛰어난 웹 프레임워크인 Alicia가 스택의 서버로 선택되어 입력 유효성 검사, 완전 타입 안전 가져오기 클라이언트, 자동 Swagger 생성 등의 기능을 제공합니다.

이 프로세스에는 Bun으로 프로젝트를 스캐폴딩하고, Alicia를 추가하고, Alicia의 HTML 플러그인으로 기본 HTML을 설정하고, 기본 CRUD 작업으로 간단한 할 일 목록을 작성하기 위해 Typed HTML과 JSX를 통합하는 작업이 포함됩니다.

할 일 목록 앱 구축을 위한 htmx 및 Tailwind 사용

- htmx는 기본 HTML에 스크립트 태그를 포함하여 웹 애플리케이션에 쉽게 추가할 수 있으며 전체 페이지를 다시 로드하지 않고도 동적으로 콘텐츠를 업데이트할 수 있습니다.

- 일반적으로 PostCSS와 빌드 단계가 필요한 테일윈드는 단일 스크립트 태그로 사용할 수 있어 앱 스타일링에 편리합니다.

- 앱의 할 일 목록 기능에는 할 일을 HTML로 렌더링하고, 페이지 로드 시 데이터를 가져오고, 할 일 완료 토글을 위한 CRUD 기능을 구현하는 등 동적 콘텐츠 조작을 위해 htmx 속성을 사용하는 모든 기능이 포함되어 있습니다.

CRUD 기능 및 데이터베이스 지속성을 위한 HX Target 사용

HX Target은 DOM 요소 타깃팅을 위한 CSS 선택기를 지원하므로 컴포넌트를 쉽게 가져올 수 있습니다.

이를 사용하여 HX 스왑을 외부 HTML로 설정하여 기존 요소를 대체하고 해당 상태를 유지할 수 있습니다.

새 삭제 엔드포인트를 사용하고 부모 div 외부 HTML을 스왑하면 할 일을 삭제하는 과정도 비슷합니다.

새 할 일을 만들 때는 할 일의 포스트 엔드포인트가 사용되며, 입력 유효성 검사와 시작 전 HX 스왑 속성을 사용하여 새 할 일을 원하는 위치에 배치합니다.

데이터베이스에 데이터를 지속하려면 서버리스 SQLite 도구인 Terso가 권장되는데, Drizzle과의 호환성과 분산 복제 데이터베이스를 위한 넉넉한 무료 티어를 제공합니다.

이 프로세스에는 Terso CLI로 데이터베이스를 만들고, 데이터베이스 URL을 가져오고, 인증을 위해 프로젝트의 .

env 파일에 자격 증명을 추가하는 작업이 포함됩니다.

그런 다음 데이터베이스 스키마가 정의되고 프로젝트가 더 나은 구조를 위해 재구성됩니다.

Drizzle Kit 및 SQL 클라이언트로 Drizzle 데이터베이스 설정하기

데이터베이스 스키마에는 기본 키에 정수를 사용하고 완료 열에 부울 에뮬레이션을 사용하는 ID, 콘텐츠 및 완료 필드가 있는 할 일 테이블이 포함되어 있습니다.

스키마 위치, 데이터베이스 드라이버 및 액세스를 지정하도록 Drizzle 구성 파일이 설정됩니다.

이 프로세스에는 Drizzle Kit를 사용하여 TypeScript 스키마를 데이터베이스에 푸시한 다음 데이터베이스 클라이언트를 만들고 할 일 엔드포인트를 처리하도록 서버 코드를 수정하는 작업이 포함됩니다.

하이퍼스크립트로 BET 스택 배포하기

하이퍼스크립트는 기본 HTML에 스크립트 태그를 드롭하여 앱에 쉽게 추가할 수 있으며, 간단한 인라인 스크립팅이 가능합니다.

io를 사용하여 편리하게 배포할 수 있으며, 성능 향상을 위해 동일한 데이터 센터에 동반 데이터베이스를 코로케이션할 수 있는 옵션이 있습니다.

BET 스택은 htmx에서 설정한 하이퍼미디어 중심 애플리케이션 아키텍처에 따라 성능과 개발자 경험의 강력한 조합을 제공합니다.