# TLDR

Datastar is a new hypermedia framework that makes building real-time web applications simpler and more efficient. It prioritizes server-side logic, uses “signals” for automatic UI updates, and leverages Server-Sent Events for lightning-fast performance. If you’re looking for a streamlined alternative to traditional JavaScript frameworks or HTMX, Datastar is worth exploring.

However, it requires that you approach web development with a fresh perspective, embracing server-driven architecture and reactive programming.

# Introduction

I’ve been diving into hypermedia lately looking at frameworks and libraries to build a new product and to help quickly create proof of concepts and web tools for clients.

HTMX at the time of writing was getting basically all the attention in the Hypermedia world. It demos really well and the examples are great. However, this article is NOT about HTMX.

I believe hypermedia and HTMX offer a promising direction, but when I tried to develop a new product using HTMX, I felt stuck due to challenges in figuring out the project structure, the HTML structure combined with excessive HTMX tags and realizing HTMX cannot handle the front-end interactively for which you have to bring in something like AlpineJS. (Did I mention I hate javascript?). HTMX is cool but I think before you start a new project with it you might want to look at Datastar as well.

I had looked at Datastar in the past while evaluating HTMX but I did not grasp its potential over HTMX until I took a second look at started to feel some HTMX pain. Your results may vary.

## My Background

First let’s understand my biased perspective. Everyone’s background is different and I think it is important to understand where I am coming from.

• I am an expert in the PeopleSoft ERP platform creating “enterprise” applications
  • PeopleSoft is a large ERP system that is used by many large organizations. It is a very powerful but a bit dated. Since it is the hub of most corporate data it is not going away anytime soon but SAAS apps are slowly chipping away at it.
  • I spent most of my time creating business CRUD applications that are used by business users and students.
  • These are always “config” driven because PeopleSoft makes it easy to create setup/config tables and GUIs to manage the data. Think of PeopleSoft has one big ball of “feature flags” in the form of setup tables.
  • PeopleSoft completely abstracts the front-end away. You never worry about the front-end. The back-end controls the front-end. PeopleSoft was built 30 years ago and it’s meta-data architecture allowed the porting from a client-server architecture to a web architecture. Developers can deploy applications and never worry about JavaScript or even HTML and CSS at all. This is amazing.
    • This has kept me away from the front-end for most of my career. I have always been a back-end developer but with PeopleSoft a back-end developer can easily deploy front-end user-facing applications. So I am used to handling and delivering solutions to clients that are 100% server-side but also user facing. You don’t need a front-end developer to deploy a PeopleSoft application.
  • These applications contain some of the most sensitive corporate data from payroll, biographic data, student data, financial data, etc. You cannot “move fast and break things” in these applications. You have to be very careful with the data and the business logic.
  • In these applications, you cannot trust code running in the browser and your backend code must protect access to the data.
• I use Go for most of my side projects. I like the simplicity, speed and type safety of Go.

# What Am I looking for?

I have been looking for a framework or a set of libraries to build a new product that is modern and efficient. I had been looking at Hypermedia to do this.

My rough requirements are:

• A modern web framework that is efficient and can handle real-time updates.
• A framework that can handle the front-end and the back-end but rely 100% on the back-end where possible.
• A framework that can handle the front-end state and interactions.
• Simplicity, Simplicity, Simplicity
• A framework where I can use Go on the back-end.
• Rapid development and prototyping
• Avoid Javascript and NPM as much as possible or totally from a development perspective.
  • Javascript makes me queezy 🤢 and every time I see NPM I get a headache 😵‍💫 and my instincts tell me to run away. I am not a fan of the JavaScript ecosystem.
• A “stable” platform that I can deploy something and just have it work for years without me worrying about it.
• Rapid deployment to the cloud like Fly.io.
• Freedom to use any CSS framework I want because those seem to change with the wind.
• Avoid the split-team, JSON API approach of modern web apps where frontend and backend are disjointed.

Previously I was looking at Phoenix but did not want to shift to another language. If you google “hypermedia” you will see a lot of articles about HTMX and it seems GitHub is full of projects using it. I think it is the most popular hypermedia library at the moment. I had looked hard at the Live Golang Library .

## My First Impressions of HTMX

Of course, I looked at HTMX and started to get excited about its potential. So I started to develop a real application after deploying some fairly simple “web tools” that my clients use for some one-off tasks.

I created some simple tools for myself and clients. I did not need any front-end state or interactions. I was just updating the UI with new HTML fragments from the server mostly as a result of field change or clicks. In these simple cases, HTMX handles those well.

In my HTMX prototyping of a more complex application, the HTML code became a mess with HTMX tags for some parts that were non-trivial. I found myself struggling to understand the project structure and myriad of HTMX tags and how to manage the front-end and the back-end. I also needed some front-end functionality and state and HTMX is NOT designed to handle that. With HTMX you have to import AlpineJS and I broke out in hives because I hate JavaScript 😢.

It was when I got to the more complex parts of the application that I felt HTMX was sort of getting in the way. I was starting to a get a huge lint ball building up. My intuition told me I was headed in the wrong direction. I hit the pause button and started to look for alternatives because I felt I was working too hard and the code was getting too complex.

# Revisiting Datastar and a Turning Point

I was busy working at client sites and I had put a pause on my research for HTMX alterntives or some non-trival TODO application examples. Then on my YouTube feed one day, I saw an interview with creator of Datastar , and it had me look again. If I had not had some experience with HTMX I would not have “been ready” for that interview and understood some of the points he was making.

Here are some AI Generated main points of the interview. The ones I put in bold are the ones that got me to look again at Datastar:

1. Delaney explores hypermedia beyond HTMX, focusing on real-time applications.
2. HTMX is seen as solving 1999’s hypermedia issues, but not pushing current boundaries.
3. Server-sent events (SSE) offer efficient real-time updates, surpassing traditional AJAX.
4. Datastar, a modular alternative to HTMX, aims to simplify code and enhance performance.
5. Game development’s efficiency can inspire web development’s speed and capability.
6. SSE enables microsecond updates, challenging the limitations of polling in HTMX.
7. The event-driven architecture is vital for scalable, efficient, real-time applications.
8. Datastar’s declarative approach reduces complexity compared to HTMX.
9. Emphasizing server control, SSE can optimize and simplify web interactions.
10. Delaney argues for a paradigm shift towards smarter use of hypermedia technology.

I had looked at the Datastar documention previously when I was evaluating HTMX. I probably found it from some discussions on Reddit. However, I previously struggled to grasp its purpose and found its documentation confusing and dense. Honestly, I think it was just over my head when I first read the Datastar docs. I was not ready to understand it. It claims to be a better alternative to HTMX and AlpineJS. Another thing that turned me off was the project did not have a huge amount of contributors. However, after watching the interview from the Datastar author, I realized he might have some serious insights and I should give it another look. He is also a contributor to HTMX.

The two things that I originally found confusing about Datastar were:

• Use of SSE (Server-Sent Events) for real-time updates.
  • I had no experience with SSE and didn’t understand how it could be used in a real-time application. I had some vague memories from reading about how they did not scale or they suffered from issues with the connection being dropped. I had not looked at them in years. I have zero experience with them.
• The concept of “signals” for reactive programming.
  • I did not realize how this can drastically simplify your code.
  • The term signal was confusing and I just did NOT get it on the first read. I had no experience with reactive programming. It turns out signals can help me avoid a lot of front-end code and state management but I did not realize that at first.

That interview had me look at the documentation again which had undergone some updates. After I spent some time reading and re-reading the documentation and looking at the examples then trying some “hello world” examples on my own then the light bulb went off.

Datastar might be the library I had been looking for. It looked promising after I started to peel off some onion layers.

# What is Datastar?

It seems the author delaneyj is taking some base primitives of HTMX and Hypermedia and making it easier to use and Datastar is his answer. Those are the claims at least. At the time of writing, I am still creating my first application with it. I am not ready to give a full review. But I am excited about the potential.

It seems that the Author is also a big fan of Go which helps me because any examples and libraries will have Go examples.

First let me clarify. I am not an expert in Datastar. I am just starting to learn it. I am also NOT a contributor or author to Datastar in any way. I am NOT taking any credit. I just want to spread the word about it as I don’t think it is getting the attention it deserves.

From my current understanding of Datastar, there are some key concepts that form the foundation of Datastar:

• Signals: Reactive programming primitives that automatically update the UI when data changes.
  • We will explore what the heck these are shortly.
  • You as the developer will decide what signals you want and put some special tags on the HTML elements that will trigger the server to send back updates to the signals. This will be associated with some sort of server state.
• Server-Sent Events (SSE): Efficient data streaming for real-time updates and page changes.
  • These are just the repsonses sent back from the server to the client. They are just text over HTTP and are generally HTML fragments that update the UI. You can do many other things but let’s not get ahead of ourselves.
• Actions: HTTP verbs (GET, POST, PUT, DELETE) that trigger server-side logic and UI updates.
  • These are the HTML tags that you put on HTML elements that trigger the server to send back updates to the signals or new HTML fragments that update the UI.
• Fragments: HTML snippets that update the UI based on server-side logic and user interactions.
  • Your server side has to be structured to send back these HTML fragments that will update the UI.

You include the Datastar JavaScript library in your HTML and then you can start to use these concepts to build your application. You will also need to structure your server to handle the SSE requests and the GET/POST/PUT/DELETE requests.

Your backend choice does not matter.

## Comparing to HTMX

I will mostly compare it to HTMX because that is the current perspective I have and HTMX is getting a ton of ink and attention.

• With HTMX to build a real application you need:

  • Front End
    • HTML
    • HTMX JavaScript and Tags to handle the triggers to backend updates
    • AlpineJS (or other JavaScript framework) to handle front end logic and interactions and state.
  • Backend
    • HTML fragments that are that is dependent on your UX
    • Routes and Code to handle the GET/POST/PUT/DELETE

• With Datastar to build a real application you need:

  • Front End
    • HTML
    • Datastar JavaScript to handle the triggers to backend updates and all the UI state and interactions.
  • Backend
    • HTML fragments that are dependent on your UX
    • Routes and Code to handle the GET/POST/PUT/DELETE
    • SSE routes to handle the updates to the signals

So just from looking at the dependencies, Datastar gives you a single JavaScript library that can handle state on the front-end (signals) and making HTML attributes perform actions (GET/POST/PUT/DELETE) and handle the updates from the server. The server is 100% responsible for generating the HTML fragments and the updates to the signals.

• Datastar provides the benefits of HTMX and AlpineJS under a single library. You get the best of both worlds.
• You can ditch much of what a front-end framework like React or Vue.js would provide and use Datastar. (Bold claim)
• Your server is 100% responsible for generating HTML snippets and templates very similar to what you would do with HTMX.
• It is back-end agnostic and can be used with Go, Node.js, PHP, etc. I prefer Go but it does NOT matter.
• It relies heavily on Server-Sent Events (SSE) for real-time updates but after you pull the cover off of SSE it is just text HTTP responses with a some different headers.

## What is a “Signal” and what is “Reactive Programming”?

I think one of the biggest things that I missed in my initial read of the docs was the concept of a signal. This was not invented by Datastar and I believe is implemented in Datastar using a library from another developer.

I’m sure I’m just behind the curve and you may already know what a signal. I’m going to try to explain it. Getting an fundamental understanding of what a signal represents and can do for you is what give Datastar its power. It makes creating user interfaces much simpler and more maintainable.

Before we talk about signals, let’s talk about reactive programming because they are related. Reactive programming makes your application code automatically “react” to changes in data and propagate those changes automatically through the application. Instead of telling the computer how to do things step-by-step, you tell it what should happen when data changes and the computer figures out how to do it. It allows you to define a relationship between data sources and data consumers. When the data source changes, the data consumer is automatically updated. In a non-reactive system, you would have to manually update the data consumer when the data source changes. This is generally in the form of “on-change” Javascript events and functions to bind all the data and UI together.

Ok, Ok that is still too much jargon!!!!

## Understanding Reactive Programming via Spreadsheets

I think the best way to understand reactive programming is to think about a spreadsheet.

• A spreadsheet application like Microsoft Excel or Google Sheets is the best example here.
  • If you have any experience working with a complex spreadsheet in the engineering or financial realms, you have already worked with reactive programming.
  • I am NOT talking about using excel as a CSV viewer.
  • I am talking about using it as a tool to do calculations, and you “build up layers” of intermediate calculations to get to a final result.
    • Very often you have intermediate calculations you need for other calculations or just doing checks for mistakes. This leads to a series of calculations that are dependent on each other. This is represented in formulas in spreadsheet cells that reference other cells. For complex calculations, you can have a “pipeline” or spiderweb of calculations that are dependent on each other.
    • I have an engineering degree and worked for engineering firms while in college and after college, I have used Excel for some very complex calculations and engineering modeling for HVAC cooling and plumbing systems. Excel is an great tool for this.

The amazing thing about Spreadsheets is that it is reactive. When you change a value in a cell, all the dependent cells are automatically updated. This is the essence of reactive programming. In you define the relationships between the “cells” or data elements and the underlying framework progates changes when data changes. This is very powerful and can simplify your code and make it more maintainable.

Here is a rough schematic of that where the arrows represent the dependencies between cells:

Datastar gives you some of these some of these same capabilities in a web application via the concept of a signal.

I conceptually think of a Datastar signal as a link between “cell” or HTML elements. I did not make this connection at first.

• In Datastar, signals are used to update the UI when the data changes.
• It can also trigger back end posts/gets/puts/deletes.

Signals are part of the glue of a Datastar application. You place signals on the page and the UI can be automatically updated. See the Model Binding Example and the Signals change example

The server can send down updates to the “signals” (spreadsheet cells contents) or even send down a new HTML fragment that update the UI. In spreadsheet terms, this would be like adding new cells, charts, etc from the server.

There is more you can do with signals. If you read the docs and still don’t understand, I would re-read them. I had to read them a few times to get it.

# Actions - GETS/POSTS/PUTS/DELETES

When/if you start looking at HTMX you see that you can trigger actions on the server with a GET/POST/PUT/DELETE. This is the same in Datastar. You can trigger these actions with a signal.

HTMX and Datastar both trigger this server request to the server to update or get updated UI elements. The difference is that Datastar uses SSE to get the updates back to the client. I was scratching my head on this until I started reading more about it and looking at the examples.

SSE is very simple. It is just text which I maybe had read before but since I had no real experience doing development work I did not understand. I work daily with HTTP web services and have a firm grasp on how HTTP works.

You can add some “tags” to the HTML elements (button on click, input on change, etc) and then when the user interacts with the page, the server can send down updates to the signals.

From the Datastar examples :

<div id="contact_1">
  <label>First Name: John</label>
  <label>Last Name: Doe</label>
  <label>Email: joe@blow.com</label>
  <div>
    <button data-on-click="@get('/examples/click_to_edit/contact/1/edit')">
      Edit
    </button>
    <button data-on-click="@get('/examples/click_to_edit/contact/1/reset')">
      Reset
    </button>
  </div>
</div>

The Datastar Javascript library running in the browser connects to the server with a connection that is kept open (until the server closes it). The server can send down updates to the signals. The server can also send down new HTML fragments that update the UI.

Datastar and HTMX have a similar concept but Datastar is built out of the box to handle updating any part of the page using the “ID” of the element. This is possible in HTMX but requires some extra work/tags.

Basically, the Datastar “actions” can do anything that HTMX can do.

## Understanding SSE - It is just text

First let’s quickly understand SSE. At we will see SSE is just text. It is not some magical protocol. It is just text over HTTP with some special headers and browsers support it out of the box.

Datastar leverages SSE and the Javascript library expects and interprets the responses from the server in a certain way. The server can send down updates to the signals or new HTML fragments that will update the UI. The server can also close the connection when it is done.

For the authoritative source, refer to the Datastar SEE Reference

In Datastar, you add some “tags” to the HTML elements (button “on click”, input “on change”, etc) which causes the browser to send a request to the server to open an SSE connection. That connection stays open until the server closes it. The server can send down updates to the signals or new HTML fragments that will update the UI.

For most CRUD applications you will be sending down HTML fragments that will update the UI. Then close the connection. If you were making some sort of real-time dashboard you would keep the connection open and send down updates to the UI as the server finds changes in the data. The server might be monitoring a database or some other data source and sending down updates to the UI as they change.

Let’s first look at the simplest case that is most like the HTMX examples which is more inline with CRUD applications.

You will have some attribute on an HTML element that will trigger an SSE call to the server. For simplicity, let’s say it is a button click.

<button id="button1" data-on-click="@get('/example/buttonpress')">
  Click Me
</button>

That triggers an HTTP call by the browser with the SSE header of Accept: text/event-stream to the server.

GET /example/buttonpress HTTP/1.1
Host: example.com
Accept: text/event-stream
Cache-Control: no-cache

There are options to send extra data and Datastar will automatically send along any local signals on the page. This automatic signal sending is a feature of Datastar that is not in HTMX and I did not realize how powerful it can be. In the HTTP example above I am NOT showing any signals because they are not needed for this simple example.

• Here the browser will keep the connection open and listen for updates from the server.
• The server can send down updates to the signals or new HTML fragments that will update the UI.
  • In this example, we will focus on HTML Fragments
  • The server sends back a response with the event of Datastar-merge-fragments and the data of the new HTML fragment that will update the UI.
    • In this case, the server “knows” that its only job is to send back some HTML when the button in pressed and close the connection.
  • The HTTP response will look like this:

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: close

event: Datastar-merge-fragments
data: fragments <div id="button1">Button Pressed and removed.</div>

In the example above, the server sends back a new HTML fragment that will replace the button that was clicked. The Datastar JavaScript running in the browser will match the ID of the element and replace it with the new HTML fragment.

The server could have sent several fragments to update any part of the page. HTMX can do this but I think Datastar is built out of the box to handle this.

• What is an example of a case where the SSE connection is kept open and the server sends down updates to the signals?
  • Imagine a case, where you have a web page that is tracking the location of a food delivery vehicle.
  • The server is monitoring the GPS location of the vehicle and sending down updates to the signals to update the location of the truck on the map. The server can also send down new HTML fragments that update the UI.
  • The browser keeps an SSE connection open and the server can send down updates.
  • The HTTP response from the server will look like the following where there is some time elapsed between each of those event and data pairs.

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

event: Datastar-merge-fragments
data: fragments <div id="truckstatus">The Truck is under a bridge</div>


event: Datastar-merge-fragments
data: fragments <div id="truckstatus">The truck is at Jersey Mikes and the driver is enjoying a sandwich</div>

In HTMX you would have to implement polling which works but is not as efficient as SSE.

If you look at the Progress Bar Example you can see that there is an SEE endpoint there like this:

GET https://data-star.dev/examples/progress_bar/data

It sends back a stream of updates to both the title and div with id="progress_bar". As the browser receives the updates, it updates the UI in real-time. The browser keeps an SSE connection open and the server can send down updates to the signals. The server can also send down new HTML fragments that update the UI.

HTTP/1.1 200 OK
cache-control: no-cache
connection: keep-alive
content-type: text/event-stream
date: Thu, 16 Jan 2025 05:36:26 GMT
fly-request-id: 01JHPSSQHJMTZ82JYZXE5T43BM-sjc
server: Fly/3f202fc64 (2025-01-13)
transfer-encoding: chunked
via: 1.1 fly.io

event: Datastar-merge-fragments
retry: 1000
data: fragments <div id="progress_bar"><svg width="200" height="200" viewbox="-25 -25 250 250" style="transform: rotate(-90deg)"><circle r="90" cx="100" cy="100" fill="transparent" stroke="#e0e0e0" stroke-width="16px" stroke-dasharray="565.48px" stroke-dashoffset="565px"></circle> <circle r="90" cx="100" cy="100" fill="transparent" stroke="#6bdba7" stroke-width="16px" stroke-linecap="round" stroke-dashoffset="559px" stroke-dasharray="565.48px"></circle> <text x="44px" y="115px" fill="#6bdba7" font-size="52px" font-weight="bold" style="transform:rotate(90deg) translate(0px, -196px)">1%</text></svg></div>


event: Datastar-merge-fragments
retry: 1000
data: selector title
data: fragments <title>1%</title>


event: Datastar-merge-fragments
retry: 1000
data: fragments <div id="progress_bar"><svg width="200" height="200" viewbox="-25 -25 250 250" style="transform: rotate(-90deg)"><circle r="90" cx="100" cy="100" fill="transparent" stroke="#e0e0e0" stroke-width="16px" stroke-dasharray="565.48px" stroke-dashoffset="565px"></circle> <circle r="90" cx="100" cy="100" fill="transparent" stroke="#6bdba7" stroke-width="16px" stroke-linecap="round" stroke-dashoffset="554px" stroke-dasharray="565.48px"></circle> <text x="44px" y="115px" fill="#6bdba7" font-size="52px" font-weight="bold" style="transform:rotate(90deg) translate(0px, -196px)">2%</text></svg></div>


...

## Example of a Datastar Application

Let’s take a look at a high level of how a Datastar application might be structured. This is a very high level and I am still learning Datastar so don’t nitpick me if there are mistakes here.

Let’s imagine you have a page that allows you to track your food delivery.

• The driver has some application in his phone that reports up to a central server where they are.
• There is a web page I can go to that will allow me to track the driver up until the order goes into “delivered” status.
• That Datastar application might look like this:
  • The browser sends a GET request to the server to get the initial page at https://feedme.now/delivery/driver/location
  • The server sends back the full page HTML template.
    • This page has some specific HTML tags that presents a button that allows you to start the status updates of how far the driver is from their house. The page will automatically update as the driver gets closer.
  • The user presses the “Track Driver” button and the browser sends a GET request to the server to open an SSE connection to https://feedme.now/delivery/driver/location/_monitor (This can be any URL)
    • The browser will keep this SSE connection open until the server closes it.
    • The Datastar library is listening to those SSE events sent by the server.
      • They could come all at once or trickle in over a few minutes.
      • Since this is a delivery driver tracking it will probably take several minutes for the driver to get to the house.
    • In the simplest case, the server sends back “html fragments” in the SSE event and Datastar figures out how to update the DOM.
      • There will be an event every few minutes to update the UI with:
        • The driver is 3 miles away.
        • The driver is 2 miles away.
        • The driver is 1 mile away.
        • The driver has entered your driveway
        • The food was delivered. {Close connection}

The sequence diagram version of this follows.

# Rethinking Web Development

If you’ve done any web development in the past decade, it’s worth reconsidering how you approach projects and develop proof-of-concept ideas. You might be surprised at how much simpler and more maintainable your code can become. While having everything on the server is advantageous, it requires a different approach to project structure.

With Datastar, a significant portion of your application logic and state management can reside on the server. This shift in perspective may require you to rethink traditional web development paradigms.

Additional Considerations:

• Project Structure: Carefully plan how you’ll organize your server-side code to handle SSE connections, manage signals, and generate HTML fragments efficiently.
• State Management: Leverage Datastar’s signals to manage your application state primarily on the server. This can simplify your client-side code and reduce the need for complex frontend frameworks.
• Templating: Choose a templating engine that allows you to easily create and send dynamic HTML fragments. Consider using a template language that promotes code reusability and maintainability.
• Real-time Updates: Explore the power of SSE for real-time updates in your application. Think about how you can use real-time data to enhance the user experience.
• Security: As with any web application, security should be a top priority. Ensure that your server-side code is secure and protects sensitive data.

By rethinking your approach to web development and embracing the capabilities of Datastar, you can create highly efficient, maintainable, and real-time applications.

# Server Requirements

Your server-side setup will involve a few key components:

• An HTML templating system that’s organized to send HTML fragments for UI updates. This likely means breaking down your HTML into smaller, manageable chunks that can be generated and sent to the client.
• The concept of “routes” is central to all web frameworks. A route maps a URL to a function that handles requests and sends responses.
• In Datastar, you’ll often need a route to handle the initial HTML request and another to handle SSE requests. There are multiple ways to structure this on your backend.

The server must also handle SSE requests, GET/POST/PUT/DELETE requests, and send back the HTML fragments that update the UI.

## Additional Considerations

• SSE Endpoint: Establish a dedicated endpoint for handling SSE connections. This endpoint will be responsible for managing the persistent connections and sending updates to the client.
• Data Handling: Implement server-side logic to process incoming data, update signals, and generate the appropriate HTML fragments to send back to the client.
• Error Handling: Incorporate robust error handling to manage unexpected situations and ensure the stability of your application.
• Scalability: If you anticipate high traffic or require your application to scale, consider using a backend technology that can handle a large number of concurrent SSE connections efficiently.
• Deployment: Choose a deployment platform that supports SSE and can accommodate the requirements of your Datastar application.

By carefully considering these server requirements, you can build a solid foundation for your Datastar application and ensure its performance, stability, and scalability.

# Conclusion

Datastar offers a fresh approach to web development, streamlining real-time applications and minimizing front-end dependencies. While it demands a shift in perspective, its potential for simplicity, efficiency, and maintainability makes it worth exploring for modern developers. With its unified architecture and focus on server-driven logic, Datastar stands out as a promising alternative to traditional frameworks.

# Further Reading

• Hypermedia Systems Books
• Datastar Getting Started and Reference and Examples