Our great sponsors
-
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
mnm-hammer
mnm implements TMTP protocol. Let Internet sites message members directly, instead of unreliable, insecure email. Contributors welcome! (Client)
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Not the author, but since nobody did, I feel compelled to mention htmx:
https://htmx.org/
> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView (https://www.phoenixframework.org/) solve the problem?
I don't think so because it has no reasonable way to know why a connection was dropped.
For example, imagine this simple scenario: you load the comment page for this post on HackerNews
HackerNews renders an HTTP response to your browser and your browser renders the page based on that HTTP payload.
You can be sitting here on the page for 10 minutes reading comments and even if HackerNews randomly went down 20 times for 10 seconds each time during those 10 minutes you would never know because your browser has everything it needed to render the page when it loaded. It's a done deal. The request was made and the response was served.
But now let's say you use LiveView. Let's also say you load all of the comments at once to keep the example the same.
Since there's a persistent websocket connection open at all times, in all 20 cases of HackerNews going down you're going to get a visual warning that the websocket connection was dropped. You also don't want to disable this visual warning because on slower devices it might take 2 seconds to load the page which is much different than an uncontrolled disconnect.
IMO this user experience is pretty bad. Why should users be concerned with the server's state after it has everything it needed to handle the request it asked for (loading the comment page). If they try to post a comment and the server is down then the user should see that error at the time of them making the comment (such as a custom 502 error page if the back-end is down).
The grandfather's comment of "it wasn't designed this way by accident" is spot on. The stateless web is a happy web. Sure you can sprinkle in websockets for progressive enhancements like broadcasting new content somewhere (which is awesome when done well), but websockets shouldn't be the basis for everything.
Make it HTML over WebRTC data channels and then we're talking about something special--totally P2P decentralized web browsing. Beaker Browser is working on stuff like this: https://beakerbrowser.com/
> Let the browser maintain a DOM tree that templates over a JSON object, then reactive-ly update and it's an amazing experience
Totally agreed. I even pulled off an Elixir library as a POC to show this concept, here's an example project: https://github.com/surferseo/live_data/tree/master/examples/... (most relevant part of API is here: https://github.com/surferseo/live_data/blob/master/examples/... and here: https://github.com/surferseo/live_data/blob/master/examples/...)
> HTML over WebSockets is nice, but what is better is reactive data binding over the socket. Let the browser maintain a DOM tree that templates over a JSON object, then reactive-ly update and it's an amazing experience. You have minimal data transfer, and minimal rendering updates. There is a great deal of power in having your UI be a stateless function over a giant JSON object.
Interesting that you're exploring this idea in the context of board games. I implemented[0] a similar idea while making a browser-based magic the gathering interface. Basically send commands to update the server state (a big JSON object), and the server does state diffs per client and sends lz compressed JSON patches. Worked quite well, but I haven't played with it for a couple years.
[0]: https://github.com/anderspitman/pojo_flow
I fooled around with a Spark java, j2html, and Bulma css web app for a prototype back in 2017 (2018?) and it killed me how nice it was. The only tooling I needed was Intellij and the app started in milliseconds along with supporting hot reloading.
Modern web development is a big reason, I left my job at the end of 2019 and went back to school.
I'm tempted to try something with Javalin(a fork of Spark), j2html + htmx, and Tachyons css now. I think together those would make a beautiful stack.
http://sparkjava.com
https://javalin.io
https://j2html.com
https://tachyons.io
I built a localhost web app, where the app runs locally and displays its UI in one or more browser tabs. [1]
It uses websockets & JSON to connect the SPA UI (in Vue.js) to the app (in Go). I can't imagine any advantages to generating HTML with Go (except perhaps less JS code :-)
https://github.com/networkimprov/mnm-hammer
> This made me wonder, why aren't we just always pushing the entire resource state over websockets.
Because this won't respect HTTP caching and you'll end up sending way more data than you need. Best instead to just send up URI and `GET/DELETE` verbs to indicate intent. I wrote about this: https://github.com/krainboltgreene/pubway.js#pubway
Oh, ASP.NET Web Forms were awesome! I remember it was so easy to onboard new developers: built-in state management between requests, WYSIWYG editor, high-level controls abstracting from HTML. Maybe because I miss ASP.NET so much :) I started working on https://github.com/pglet/pglet to have something like "ASP.NET on steroids" - server-side controls with React UI. However, it's not a HTML passing over WebSockets, but controls state which takes much less traffic with smaller latencies.
What advantage is this providing except job security for developers that have to port working HTTP/1.1 systems to HTTP/2&3 and WebSockets?
Have you used HTTP/1.1 comet-stream? I recommend you look at this sites source before you commit further: http://fuse.rupy.se