I’ve been playing around more with HTMX and one of the really cool features that I think we need to talk more about is the ability to trigger client side events from the server. This is accomplished by using the hx-trigger header and elements on the page can listen for events using hx-trigger: myEvent from body.

This means that it’s easy to inform the client that something has happened and then let the client take appropriate actions. For example, imagine that we put an item in the shopping cart. The server responds with the event SHOPPING_CART_UPDATED. A lot of elements on the page can now update based on this event; counter in the shopping cart, list of “other people also bought”, a banner with discounts etc.

Event driven client side architecture. Just imagine what this could do for micro frontend, where each component might...

HTMX is great! And I really like .NET Minimal APIs. Let’s put it together and see how it works.

When I first thought about creating a backend for HTMX using .NET I went down the rabbit hole of Razor Pages. Which was not great I have to say. That programming model is weird and I don’t like it. But in my spelunking I found Razor Slices which will work great as a template engine.

That means that we have a lightweight and easy to grasp backend with Minimal API and then use Razor Slices to render the HTML.

When I describe what HTMx does to people that has never heard about it I often end up telling them about the good old days when we wrote server-side rendered apps, but sadly that replaced the whole page. And then came SPA frameworks and all you got downloaded in the first page access was a <div id="app></div>, then the app got rendered by JavaScript from JSON and the whole concept of the web, HTTP and REST got lost.

HTMx marries these two together. But showing the main.ejs as it stands right now reminds me too much about the old days. Let’s clean it up, and we will soon see that it will look much like a modern SPA, with the huge difference that it is using server rendered HTML that and is easy to grasp.

This is the sixth post in a series that I’m making...

This is the fifth post in a series that I’m making about HTMx that I think is utterly amazing and will change how I (we?) write web apps in the future.

You are more than welcome to read from here, but then I would recommend getting the code from this point, if you intend to type along.

The application is working fine, but there’s zero validation in place. I wanted to do some simple validation on the client (and here I have a bug) and then also show how to do validation on the server-side and return an error message from there.

Validation can be tricky and often lead to a lot of code. But it’s an obvious addition to the code.

This is the fourth post in a series that I’m making about HTMx that I think is utterly amazing and will change how I (we?) write web apps in the future. You are more than welcome to read from here, but it will be hard following along code-wise if you haven’t stepped through part I, part II and part III first.

In the last part we built out most the actual application, which means that we are left with the fun part here. There’s one section of the application that is not working yet - the footer. In the footer I wanted to show a tally of the number of items, the number of completed items, and also the number of late items.

Keeping track of numbers like that can be a bit messy since we need to update them when we are doing other actions, like...

This is the third post in a series that I’m making about HTMx that I think is utterly amazing and will change how I (we?) write web apps in the future. You are more than welcome to read from here, but it will be hard following along code-wise if you haven’t stepped through part I and part II first

In this part we will build the core logic of the application and start to create todo-items and store them in Firestore.

This is the second post in a series that I’m making about HTMx that I think is utterly amazing and will change how I (we?) write web apps in the future. You are more than welcome to read from here, but it will be hard following along code-wise if you haven’t stepped through part I

In this part we will allow our users to sign in with Google.

I felt the urge to write a tutorial. Maybe I’m the last human that will write one now that AIs are baked in everywhere. But that urge comes when I stumble on a new things, ways of working or ideas - and now I’ve reading, playing around with and used HTMx for awhile and I’m hooked.

HTMx totally rubs me the right way now that building a plain old web site, with some login-capabilities and personal data requires a SPA framework of hundreds of megabytes (2.802.804 lines of code…).

That’s a lot. And a lot to learn. Finally, the whole “API returns JSON” - “SPA framework turns JSON to HTML” dance feels pretty redundant, when you think about it.

I’m going to try to avoid to make this and Old Man Rant (tm), but first let’s go back in time to life before SPAs, and I’ll show how we...

I read this LinkedIn Post with great interest (even though it’s the first time I heard about ASPICE).

In particular a sentence at the end at the end caught my attention

it’s about removing friction so engineers can move fast.

I’ve just attended a discussion about process improvements in general and retrospectives specifically, together with a few ScrumMasters. I wanted to take the time to jot down some of the good ideas that popped up as we talked.