WEBVTT 00:00.000 --> 00:16.840 Hello, welcome to my talk called push-based hypermedia with data star. 00:16.840 --> 00:23.680 My name is Patrick Mascha, I come from Montreal in Quebec, which is in Canada. 00:23.680 --> 00:29.680 I'm fluent in English and French, so you can ask me questions in both languages. 00:30.040 --> 00:40.000 I do most of my work in PHP and TypeScript on an OpenBSD laptop, and I work as an independent consultant. 00:42.000 --> 00:50.000 So before we start a few definitions, multi-page applications, those are the old style of applications on the web, 00:50.000 --> 01:01.360 where each page is a different address on the web, and you add a little bit of JavaScript here and there, 01:01.360 --> 01:04.480 just add a little bit more interactivity. 01:04.480 --> 01:12.080 Then we have single page applications, which is what most of the web has evolved to these days, 01:12.080 --> 01:19.600 where you basically were recreating native style applications in a web context. 01:19.600 --> 01:24.640 These typically require you to have two separate applications, you're back in annual frontend, 01:24.640 --> 01:30.240 that communicate together to be able to display content on the page. 01:31.440 --> 01:39.040 Hypermedia is any non-linear media that contains links to other hypermedia documents, 01:39.040 --> 01:46.080 or non-textual documents like videos and images. 01:48.240 --> 01:58.320 HTTP as the engine of application state is a concept where the server is in charge of the state of the client. 01:59.040 --> 02:08.640 And more importantly, every possible interactions that the client can do are indicated by the server in the request. 02:09.920 --> 02:18.880 This term has become more popular lately with the rise of HTML, which is a library for to do dynamically 02:18.880 --> 02:24.960 transclude HTML from the server in the page without reloading the page. 02:26.880 --> 02:30.400 There's a very good book on hypermedia on the HTML's homepage. 02:31.440 --> 02:37.520 I did a similar talk at EuroB's DeCon in Dublin called Puffy does real-time hypermedia. 02:37.520 --> 02:42.240 The link is in the page. 02:42.240 --> 02:51.280 Now, reactivate HTML, it's what primitives do we need to write reactivate HTML in a declarative way. 02:52.480 --> 02:59.520 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 03:01.840 --> 03:04.560 in the application. We already have that with the web, the browser. 03:05.520 --> 03:14.560 It's one thing that makes writing the declarative code a lot easier in UI is signals. 03:15.200 --> 03:21.920 They allow you to only type parts of the UI that automatically reacts to changes to. 03:26.000 --> 03:32.880 And we also need the attributes in our HTML to be able to respond to those changes and update themselves. 03:33.840 --> 03:41.120 And we need dynamic transcutions to be able to include new content on the page that wasn't loaded before. 03:42.640 --> 03:47.040 Typically, people do dynamic transcutions with HTML's. 03:48.720 --> 03:58.720 And the signals part will be done with alpine.gs or another reactive DSL library for HTML. 03:59.200 --> 04:08.400 Data star is a new library and framework that tries to kind of bridge a gap between the two. 04:10.960 --> 04:26.560 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. 04:27.120 --> 04:31.440 Transclusions are also supported, but we'll get to that a bit later. 04:34.800 --> 04:39.600 By the way, signals are on their way to maybe becoming a JavaScript standard. 04:39.600 --> 04:45.760 So at some point, they will be included in web and will be able to remove that from the data star code base. 04:49.280 --> 04:55.120 So data star can be used right completely local applications pretty easily. 04:56.080 --> 05:05.520 Here I have a simple calculator, so I can insert content, I can insert new numbers and do a calculation. 05:08.320 --> 05:20.800 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. 05:20.800 --> 05:26.800 And it will dynamically update the signal if the input changes and the input if the signal changes. 05:29.440 --> 05:37.760 We then bind an event handler with data dash on dash click to the every button we have here. 05:39.600 --> 05:50.560 We update the value, we append the text of the button to the value of the signal, which updates the 05:50.560 --> 05:58.800 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. 06:00.400 --> 06:09.600 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 06:09.600 --> 06:21.440 attribute you want. You can also use the bundle to add a suffix to that so that you don't have any conflicts. 06:22.480 --> 06:32.160 And finally, well the nice thing about that is it's compatible with any HTML parser and value it validator. 06:32.560 --> 06:50.160 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. 06:50.320 --> 06:57.760 Now don't use eval in production, but for a simple calculator demo like this it's perfectly suitable. 06:59.120 --> 07:07.840 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. 07:07.840 --> 07:37.760 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. 07:37.840 --> 08:07.360 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 08:07.360 --> 08:32.240 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. 08:32.240 --> 08:56.240 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. 08:56.240 --> 09:14.240 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 09:14.240 --> 09:23.240 send arbitrary data down. It's very lightweight and efficient. There is a problem with 09:23.240 --> 09:29.240 HTTP one where the browser will only allow you to have six 09:29.240 --> 09:41.240 SSE streams per address at the per browser, but that is a browser-level limitation and not a server-level limitation. 09:41.240 --> 10:04.240 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. 10:04.240 --> 10:24.240 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. 10:24.240 --> 10:34.240 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. 10:34.240 --> 10:43.240 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. 10:43.240 --> 10:57.240 Retry tells us the client how long to wait for until to reconnect if there's a disconnection and data is your actual data. 10:57.240 --> 11:09.240 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. 11:09.240 --> 11:23.240 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. 11:23.240 --> 11:38.240 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. 11:38.240 --> 11:51.240 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. 11:51.240 --> 12:00.240 I maintain SDK tests in shell so you can easily test the SDK or developing on any platform. 12:01.240 --> 12:14.240 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. 12:14.240 --> 12:29.240 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. 12:29.240 --> 12:47.240 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. 12:47.240 --> 13:09.240 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. 13:09.240 --> 13:24.240 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. 13:24.240 --> 13:36.240 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. 13:36.240 --> 13:55.240 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. 13:55.240 --> 14:17.240 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. 14:17.240 --> 14:26.240 Right, so you can see the testing suite, the SDK just got published on NPM, I consider it still a beta. 14:26.240 --> 14:33.240 I'm still fixing problems as I go along. 14:33.240 --> 14:49.240 Now, we're going to network applications, so here's a quick example, if I enter what is 2 plus 2, 3. 14:49.240 --> 15:04.240 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. 15:04.240 --> 15:21.240 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. 15:21.240 --> 15:31.240 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. 15:31.240 --> 15:40.240 So get allows you to start a get request and it'll be an event stream. 15:40.240 --> 15:56.240 The server receives a request and then parses the signals and then can choose to respond in with either zero or infinite events. 15:56.240 --> 16:07.240 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. 16:07.240 --> 16:19.240 And then I merge in the new, with after to answer after the form a, a new element. 16:19.240 --> 16:34.240 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. 16:34.240 --> 16:44.240 And then we have to close the stream. So that's basically what you wind up doing it in data star. 16:44.240 --> 16:54.240 So I gave a link to it more so you can find out a little bit more how it works. 16:54.240 --> 17:02.240 I want to talk a little bit about a GUI concept called immediate mode versus retain mode. 17:02.240 --> 17:23.240 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. 17:23.240 --> 17:28.240 And then change what is shown on the page. 17:28.240 --> 17:41.240 This is, this can be very efficient in terms of the graphical calculations, but it's also more complex, it requires more memory. 17:41.240 --> 17:51.240 And is, in my mind, sometimes the premature optimization. 17:51.240 --> 18:10.240 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. 18:11.240 --> 18:15.240 So you need to be, you need to handle interrupts and all of that. 18:15.240 --> 18:21.240 Make sure your request isomorphic, an identity. 18:21.240 --> 18:24.240 And that's, that can be complicated a handle. 18:24.240 --> 18:35.240 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. 18:35.240 --> 18:50.240 This is more demanding in terms of graphical and computer graphical computations, but it is, it doesn't require a lot of memory. 18:50.240 --> 19:00.240 And depending on what platform you're doing this, it can be efficient enough for most applications. 19:00.240 --> 19:10.240 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. 19:10.240 --> 19:12.240 State of mind. 19:12.240 --> 19:23.240 So, have, so for that we will explore command query responsibility segregation CQRS. 19:23.240 --> 19:38.240 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. 19:38.240 --> 19:48.240 And then the client sends separate mutations requests that say, hey, the client did this sort of client change that. 19:48.240 --> 19:59.240 And then the view is recomputed in consequence and sent down the wire through the service sent event stream. 19:59.240 --> 20:10.240 I find that for like a little demo like this, reactive signals on the back end with something like alien signals works very well. 20:10.240 --> 20:26.240 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. 20:26.240 --> 20:40.240 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. 20:40.240 --> 20:49.240 And it's very easy to get into real time applications because you're constantly streaming down the updated view. 20:49.240 --> 20:57.240 And it's the client doesn't have to pull information, doesn't have to ask for updates. 20:57.240 --> 21:01.240 So this presentation itself is the data store application. 21:01.240 --> 21:09.240 I've been moving around the slides with the arrows, so that's a simple event hammer again. 21:09.240 --> 21:15.240 You can do multi-line scripts inside of data handlers. 21:15.240 --> 21:19.240 The slides themselves as simple HTML files. 21:19.240 --> 21:29.240 And a data store request is started whenever a new page was opened on the client and starts to watch her. 21:29.240 --> 21:39.240 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. 21:39.240 --> 21:45.240 I can show there's a video for people who are watching this after and don't have video. 21:45.240 --> 21:49.240 There is a video on peer tube of what I'm about to do. 21:49.240 --> 22:03.240 So I have here my text editor opened on this page. 22:03.240 --> 22:11.240 And I can modify text here at a second smiley face. 22:11.240 --> 22:17.240 Save and we see appearing on a page in real time. 22:17.240 --> 22:23.240 I also, from that point it's easy to start adding in more features. 22:23.240 --> 22:39.240 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. 22:39.240 --> 22:45.240 Oops, forgot about the area. 22:45.240 --> 22:49.240 Add some text, save, the text appears here. 22:49.240 --> 22:59.240 And if I update my text editor, the text appears here as well. 22:59.240 --> 23:07.240 And it's now what's a little bit probably a little bit hard to see on the screen. 23:07.240 --> 23:09.240 But it's there. 23:09.240 --> 23:13.240 There we go. 23:13.240 --> 23:29.240 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. 23:29.240 --> 23:37.240 Datastar's whole tries to make day to problems easy and simple. 23:37.240 --> 23:45.240 It makes cases like real time updating synchronizing states between clients. 23:45.240 --> 23:57.240 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. 23:57.240 --> 24:03.240 And there's also a link to a drone game developed by scenario labs. 24:03.240 --> 24:11.240 That does has a web component game with a signal that's being updated by merge signal. 24:11.240 --> 24:19.240 And that allows, and it's pretty impressive how efficient it is. 24:19.240 --> 24:25.240 Try to open out on your phones because it does use a motion control. 24:25.240 --> 24:31.240 So setting up work cues for heavy operations is like a easy second step with Datastar. 24:31.240 --> 24:39.240 Since you're already separating your, your, your views for your limitations. 24:39.240 --> 24:47.240 And there are a bunch of problems that you often have in single page applications that are really not an issue in Datastar. 24:47.240 --> 24:51.240 It's such as oversharing state from the server on the client. 24:51.240 --> 25:00.240 You never know what, when or what information is going to become, could be, could become a security problem. 25:00.240 --> 25:06.240 So you generally don't want to overshare by default. 25:06.240 --> 25:14.240 And so like live updating access control and stuff like that, it becomes very easy with Datastar. 25:14.240 --> 25:18.240 And like I've said before, the performance is very good. 25:18.240 --> 25:23.240 There are examples on the website that show live live stream. 25:23.240 --> 25:30.240 The, asking videos by data just like frames that are sent to the sort of, 25:30.240 --> 25:33.240 it sends to the client and merged in real time. 25:33.240 --> 25:36.240 And they are very fast. 25:36.240 --> 25:39.240 So this is the end of my presentation. 25:39.240 --> 25:41.240 Thank you all for listening. 25:41.240 --> 25:48.240 I have a few links here. 25:48.240 --> 25:56.240 You can start us on GitHub, join the Discord, or ask me questions by mail or in person. 25:56.240 --> 26:00.240 It will be my pleasure to answer an English or French. 26:00.240 --> 26:02.240 Yes, see? 26:02.240 --> 26:06.240 If you want, you have four minutes for a Q&A. 26:06.240 --> 26:08.240 Any questions? 26:08.240 --> 26:09.240 Yes. 26:09.240 --> 26:18.240 So I'm just wondering, with mobile devices and other kind of things, 26:18.240 --> 26:23.240 it happens a lot that you disconnect or for some reason. 26:23.240 --> 26:27.240 So anything built in for missed messages, it's far out of the gap. 26:27.240 --> 26:33.240 So the question was, what happens when there are disconnects in a situation like mobile, 26:33.240 --> 26:35.240 where it happens very often? 26:35.240 --> 26:43.240 Well, the service and event standard has built in reconnection protocols. 26:43.240 --> 26:50.240 And that's part of the retry line in the event is how much time to wait before you retry. 26:50.240 --> 26:56.240 And it will automatically do exponential back off of the retries. 26:56.240 --> 27:02.240 And retries are a difficult thing to handle when you're in like a more of a retained mode. 27:02.240 --> 27:09.240 In immediate mode, it's really not a question since you're always updating the data state. 27:09.240 --> 27:14.240 Any more questions? 27:14.240 --> 27:20.240 Okay, thank you, Patrick.