Hello, welcome to my talk called push-based hypermedia with data star.
My name is Patrick Mascha, I come from Montreal in Quebec, which is in Canada.
I'm fluent in English and French, so you can ask me questions in both languages.
I do most of my work in PHP and TypeScript on an OpenBSD laptop, and I work as an independent consultant.
So before we start a few definitions, multi-page applications, those are the old style of applications on the web,
where each page is a different address on the web, and you add a little bit of JavaScript here and there,
just add a little bit more interactivity.
Then we have single page applications, which is what most of the web has evolved to these days,
where you basically were recreating native style applications in a web context.
These typically require you to have two separate applications, you're back in annual frontend,
that communicate together to be able to display content on the page.
Hypermedia is any non-linear media that contains links to other hypermedia documents,
or non-textual documents like videos and images.
HTTP as the engine of application state is a concept where the server is in charge of the state of the client.
And more importantly, every possible interactions that the client can do are indicated by the server in the request.
This term has become more popular lately with the rise of HTML, which is a library for to do dynamically
transclude HTML from the server in the page without reloading the page.
There's a very good book on hypermedia on the HTML's homepage.
I did a similar talk at EuroB's DeCon in Dublin called Puffy does real-time hypermedia.
The link is in the page.
Now, reactivate HTML, it's what primitives do we need to write reactivate HTML in a declarative way.
We do need to use it to be able to input new data, which, and we need to be able to react to events that happen
in the application. We already have that with the web, the browser.
It's one thing that makes writing the declarative code a lot easier in UI is signals.
They allow you to only type parts of the UI that automatically reacts to changes to.
And we also need the attributes in our HTML to be able to respond to those changes and update themselves.
And we need dynamic transcutions to be able to include new content on the page that wasn't loaded before.
Typically, people do dynamic transcutions with HTML's.
And the signals part will be done with alpine.gs or another reactive DSL library for HTML.
Data star is a new library and framework that tries to kind of bridge a gap between the two.
And so it gives you a global store of reactive signals that you can embed inside your HTML on reactive expressions that live inside the attributes and events that you bind in your HTML.
Transclusions are also supported, but we'll get to that a bit later.
By the way, signals are on their way to maybe becoming a JavaScript standard.
So at some point, they will be included in web and will be able to remove that from the data star code base.
So data star can be used right completely local applications pretty easily.
Here I have a simple calculator, so I can insert content, I can insert new numbers and do a calculation.
How this works is that you have an input to which we data dash bind dash count, which means that we bind a signal with the name count through the input.
And it will dynamically update the signal if the input changes and the input if the signal changes.
We then bind an event handler with data dash on dash click to the every button we have here.
We update the value, we append the text of the button to the value of the signal, which updates the
input. And you'll notice there's this DSL and data star who acts as signals, which is the dollar symbol followed by its name.
You'll also notice that in data star every custom attribute uses the data set standard in HTML, which allows you to write any custom
attribute you want. You can also use the bundle to add a suffix to that so that you don't have any conflicts.
And finally, well the nice thing about that is it's compatible with any HTML parser and value it validator.
Now finally, our equal button will still have an on-click event handler, but this time it will evile the value of the of the calc variable and just put that back inside the calc signal.
Now don't use eval in production, but for a simple calculator demo like this it's perfectly suitable.
If you play with this on the web it might very very very well migrate. There's no since not much ever handling I'm doing in this very simple demo.
Now talk a little bit more about data star itself. It started with the creator Delaney Gillilin that wanted to make HTML is more easily extendable, but his the changes he made to the HTML source code were not accepted upstream and so instead of fighting with it, he decided to just start from scratch.
Right, a whole new framework. Luckily, the end result is only about five kilobytes and it is very accessible so much so that most of the functionality is implemented as plugins and so with and we offer a suit of standard plugins that bring up the weight of the framework to vow for keen kilobytes if you activate them all and there's an easy bundle on bundler on the internet to
deactivate the plugins on the fly and download a new bundle. So the data star engine itself, which is its core, handle signals and does data set attribute parsing and expression evaluation and it allows you to load new plugins of course.
But all the rest of the functionality is set of plugins and all the what we saw in the conculator app, that was all plugins. Notably, they actually do it plugins. We're going to go see the back end plugin now, which allows for the dynamic transitions we talked about earlier.
But first, we're going to talk about service and events. So our service end event stream is a standard part of the HTTP, it allows you to create a unique directional stream of data from the servers as a client and
send arbitrary data down. It's very lightweight and efficient. There is a problem with
HTTP one where the browser will only allow you to have six
SSE streams per address at the per browser, but that is a browser-level limitation and not a server-level limitation.
And so if you, and it's not a limitation in HTTP too. So if, and since SSE is just HTTP, you can easily add a proxy in front of any HTTP one server to turn it into HTTP too and get rid of that limitation.
So a server-cent event consists of separate new line-delimited lines with a final line termination at the end to indicate the end of the event, which will empty the buffer on the server and send the event down to the client.
So it's all text so like, and my BSD presentation I wrote as SSE events in C and K stage. It was very simple.
But events and ID lines are optional, but they just give more information on the event. They're useful when you're dealing with interrupts.
Retry tells us the client how long to wait for until to reconnect if there's a disconnection and data is your actual data.
So data star uses server-cent events to receive data information from the server and will do specific actions depending on the event it receives.
And every request in data star is a server-cent event request. This doesn't add much complexity to the base application except you need to know how to format the events.
And for that we offer various SDKs because one another feature of data so I sense your sending stuff from the server or you can write your server in any language you want.
I maintain the type script SDK, but there are SDKs for go, PHP, Rust, and other languages, and more people are adding SDKs all the time.
I maintain SDK tests in shell so you can easily test the SDK or developing on any platform.
So the five types of server-cent events in data star are merge fragments, are main workhorse, which will use to merge HTML from the server on the page.
For that we use video morph, which is very efficient. It allows you to append, it allows you to morph in HTML just do like the minimal merging necessary.
It allows you to remove fragments, then you have merge signals, this allows you to update signals on the client from the server and then the client will recalculate what it needs to.
This is very useful when you start tracking web components, the lady does a lot of stuff with video games and dashboards, where you usually have a web component that takes care of the rendering and he just streams signal frames down in a signal and has that be shown to the screen.
And it is very efficient, because surprisingly the browser is very well optimized for just putting HTML in the page, and so it's very, very fast.
And this is a shape of a data star event, a merge fragment, so we have the type of the event, we have the retry, this is in milliseconds.
And then here we're giving two optional elements which is merge mode and selector, so merge mode append will append the element to the end as a children of the element with the idea of main.
And then the fragment is what the actual HTML we want to put in. If we're using morph, this is even simpler, since we don't have to specify the merge mode or the selector, we've shot to make sure that the top level of fragment has an ID that is present in our page.
Right, so you can see the testing suite, the SDK just got published on NPM, I consider it still a beta.
I'm still fixing problems as I go along.
Now, we're going to network applications, so here's a quick example, if I enter what is 2 plus 2, 3.
Well, the teacher starts answering and said, oh, your answer is wrong, okay. Well, let's update that to 4 teachers answering the answer is correct.
So what happened here? First of all, we bound a question signal to the input and an event handler to the send button. This, so when you see at and we're, that's an action plugin.
So it's just a, it's a function that, it's a special function that has access to some of the data stars internals and it's usually part of a plugin.
So get allows you to start a get request and it'll be an event stream.
The server receives a request and then parses the signals and then can choose to respond in with either zero or infinite events.
It creates a stream and then you can see here where I make sure before that I remove any previous answers that were on the page.
And then I merge in the new, with after to answer after the form a, a new element.
I waited a bit and then I start adding more dots with every event until finally, I check if the answer is right and I, I merge in the correct response.
And then we have to close the stream. So that's basically what you wind up doing it in data star.
So I gave a link to it more so you can find out a little bit more how it works.
I want to talk a little bit about a GUI concept called immediate mode versus retain mode.
So a lot of single page applications operated what we call retain mode where the every part of the interface is retained in memory and we only update this specific parts that need to be updated.
And then change what is shown on the page.
This is, this can be very efficient in terms of the graphical calculations, but it's also more complex, it requires more memory.
And is, in my mind, sometimes the premature optimization.
You also, like the previous application we saw was kind, it wasn't really, it was kind of a retained state application because you need to remember that you have already put in a answer and you need to delete it before you insert a second element.
So you need to be, you need to handle interrupts and all of that.
Make sure your request isomorphic, an identity.
And that's, that can be complicated a handle.
Now immediate mode is that whenever data is that influences the view changes, you recalculate the whole view and you update what the person sees.
This is more demanding in terms of graphical and computer graphical computations, but it is, it doesn't require a lot of memory.
And depending on what platform you're doing this, it can be efficient enough for most applications.
That's, and any more fun on browser is so efficient that we just recommend that most data applications operate in more of an immediate mode.
State of mind.
So, have, so for that we will explore command query responsibility segregation CQRS.
So we'll have one, a main view function that is called by a request and is in charge of updating the view whenever something depends on changes.
And then the client sends separate mutations requests that say, hey, the client did this sort of client change that.
And then the view is recomputed in consequence and sent down the wire through the service sent event stream.
I find that for like a little demo like this, reactive signals on the back end with something like alien signals works very well.
But, or sometimes maybe you'd really only all you need is a file watcher, but for bigger applications, event queueing is really where you want to go.
So this kind of reframes front end development as a little bit more like a video game where you have an event loop that's constantly updating the view depending on stuff that changes.
And it's very easy to get into real time applications because you're constantly streaming down the updated view.
And it's the client doesn't have to pull information, doesn't have to ask for updates.
So this presentation itself is the data store application.
I've been moving around the slides with the arrows, so that's a simple event hammer again.
You can do multi-line scripts inside of data handlers.
The slides themselves as simple HTML files.
And a data store request is started whenever a new page was opened on the client and starts to watch her.
That watches the files on the server and if the files change, then it streams down and update and the state of the interface is updated.
I can show there's a video for people who are watching this after and don't have video.
There is a video on peer tube of what I'm about to do.
So I have here my text editor opened on this page.
And I can modify text here at a second smiley face.
Save and we see appearing on a page in real time.
I also, from that point it's easy to start adding in more features.
I've turned this into like a live editing website where I have every HTML node is highlighted and I can click on them and go update.
Oops, forgot about the area.
Add some text, save, the text appears here.
And if I update my text editor, the text appears here as well.
And it's now what's a little bit probably a little bit hard to see on the screen.
But it's there.
There we go.
So that kind of stuff, that kind of use case gets pretty simple with Datastar when you've accepted a sort of like event based mutation system.
Datastar's whole tries to make day to problems easy and simple.
It makes cases like real time updating synchronizing states between clients.
I could have on, you'll see on the, there are links here at the bottom for a data star website with a ton of examples.
And there's also a link to a drone game developed by scenario labs.
That does has a web component game with a signal that's being updated by merge signal.
And that allows, and it's pretty impressive how efficient it is.
Try to open out on your phones because it does use a motion control.
So setting up work cues for heavy operations is like a easy second step with Datastar.
Since you're already separating your, your, your views for your limitations.
And there are a bunch of problems that you often have in single page applications that are really not an issue in Datastar.
It's such as oversharing state from the server on the client.
You never know what, when or what information is going to become, could be, could become a security problem.
So you generally don't want to overshare by default.
And so like live updating access control and stuff like that, it becomes very easy with Datastar.
And like I've said before, the performance is very good.
There are examples on the website that show live live stream.
The, asking videos by data just like frames that are sent to the sort of,
it sends to the client and merged in real time.
And they are very fast.
So this is the end of my presentation.
Thank you all for listening.
I have a few links here.
You can start us on GitHub, join the Discord, or ask me questions by mail or in person.
It will be my pleasure to answer an English or French.
Yes, see?
If you want, you have four minutes for a Q&A.
Any questions?
Yes.
So I'm just wondering, with mobile devices and other kind of things,
it happens a lot that you disconnect or for some reason.
So anything built in for missed messages, it's far out of the gap.
So the question was, what happens when there are disconnects in a situation like mobile,
where it happens very often?
Well, the service and event standard has built in reconnection protocols.
And that's part of the retry line in the event is how much time to wait before you retry.
And it will automatically do exponential back off of the retries.
And retries are a difficult thing to handle when you're in like a more of a retained mode.
In immediate mode, it's really not a question since you're always updating the data state.
Any more questions?
Okay, thank you, Patrick.