The author doesn't understand the stupidity of wanting to re-implement HTTP over raw sockets... No, the future of HTML software is just HTTP version X... not raw TCP-IP...
The future of web software is HTML over WebSockets
171–180 of 337 posts
Re: The future of web software is HTML over WebSockets
#172Earlier quoted context omitted.
Got a question for you - I'm making a chat bot thing ( https://www.brian.bot/ ) and have added socket-based web chat... but I don't even know how to phrase the question of "how do I horizontally scale the socket connections". Webchat Server Slack. Once I have more than one server dyno (heroku), then I can't ensure that the Slack event hits the dyno with the corresponding socket connection. Thoughts / tips?
You can use a redis to distribute messages via PUB/SUB. The sockets subscribe to the events that are relevant to them. It can handle thousands of messages a second in a local environment and probably more in a dedicated hosting environment.
Seconding this approach. I've used PUB/SUB for this exact purpose.
When you need to send something through the websocket then publish a message via redis and have handlers in the code that are subscribed to that channel so every server can check if they have the websocket connection and whichever one has it will send the data through
Re: The future of web software is HTML over WebSockets
#173> the future of some web software
Don't get me wrong - we use Blazor server-side for several critical webapps now, but I would be the last person to suggest you use it (or anything like it) for all web applications. For instance, a Netflix-scale operation + Blazor server-side would almost certainly be a really bad mix.
For use cases where the maximum number of possible users is bounded by ~10-100k and within a 100ms latency domain, I think a very strong argument can be made for such technologies. The productivity uplift is pretty incredible when you can directly use your existing domain services to drive UI.
We also like the security implications of these sorts of technologies. The incremental disclosure of the client app is an excellent selling point for many of our customers.
Re: The future of web software is HTML over WebSockets
#174To me the future of web dev is SSR components with partial hydration on the client.
Use components as if you were doing front end on the server. No more crappy server templating engines with poor composition and no interactivity. You go straight from the DB to the component. Then only the absolute minimum JS needed for interactivity is sent to the client.
This is not so far away btw.
I made this work on Svelte although hydration is clunky and it was a bit convoluted.
Marko has been doing this since 2017 I believe and is running on Ebay.
AFAIK Imba 2 will have partial hydration too.
Re: The future of web software is HTML over WebSockets
#175I’m gonna be “that jerk on HN,” but this is that idea that just keeps getting rehashed every couple of years then fizzles out. The reason that it’s so attractive is because as developers we love to build and save time, and we think, “imagine what we could do if we didn’t have to ask for data from remote servers...” The problem is that stateful connections suck and create artificial complexity when you don’t need them…
> HTTP is a stateless protocol on top of a stateful socket connection. It wasn’t designed this way by accident.
The complexity benefit of having stateless HTTP transactions is vastly offset by the statefulness of TCP, TLS states, HTTP "sessions", cookies, browser storage & so on.
HTTP is hardly "designed" and plenty of its aspects were accidental.
Re: The future of web software is HTML over WebSockets
#176I love starting with HTML and creating a design that composes HTML fragments (partial HTML). It creates affordances. But relying on WebSockets as the communication strategy really reduces the number of use cases where this is sustainable in many dimensions. Perhaps, instead of following all of the advice in this article, start with HTML fragments via Content Negotiation. Compose UI experiences over stateless HTTP first. Then build upon that foundation instead.
Re: The future of web software is HTML over WebSockets
#177Earlier quoted context omitted.
How so? One of the most popular (if not the most) websites for developers out there is pretty much HTML + CSS. JavaScript is used, but minimally. "Modern" experience is not necessarily the same as "good" experience. Good old server side rendered pages are fine; SPAs are being built just because "we can", not because they are actually needed (sure, in some cases,SPAs are needed, e.g., chat sites).
Are you talking about Reddit, StackOverflow, or something else? I have yet to see a proper web app (not a blog/collection of static pages, but something that does something complex like let you manage inventory, do payroll, do your taxes, monitor sensors in real time, interact with geographical maps, or edit documents) that is done without JavaScript and has even OK UX. SPAs are great because of separation of concern…
> Why should web apps be inferior?
Inferior compared to what?
I'm not going to call your statement nonsense but unless you have proof that SPAs make up the majority of the websites/web apps online today, I'm afraid I must disagree.
Frontend dev is a hot mess of garbage JS cobbled together to make a psuedo native experience.
> but something that does something complex like let you manage inventory, do payroll, do your taxes, monitor sensors in real time, interact with geographical maps, or edit documents) that is done without JavaScript and has even OK UX.
This is not what the web was built for. The same things you mention dismissively (server side Static pages) are the core and norm ,by and large, the vast majority of what constitutes "the web"
Good, lightweight native apps can do all the above without breaking a sweat, and you can have multiple native clients for things you care about. I don't always have an internet connection but I still want to type my documents. I fire up word. Not google docs. I need to do some serious data wrangling - I fire up excel not google sheets. Need to do some networking for my router, wireshark. Need to read an ebook - adobe acrobat. Need to write some shader code - Sublime text.
So the way it looks to me that SPAs are trinkets - not at all mission critical beyond loading cat pictures faster or bending the web backwards to do things it wasn't supposed to. Server side static pages rule the web.
Complexity is just a good way to justify a large paycheck.
Re: The future of web software is HTML over WebSockets
#178Earlier quoted context omitted.
If the connectivity state doesn't matter to the user, why would you show it?
> If the connectivity state doesn't matter to the user, why would you show it? It's due to Live View triggering a visual indicator that the websocket connection isn't available. It's a combination of CSS and JS. You can turn this off but if you turn it off then you have no way to show an indicator when you do care (such as transitioning between pages or submitting a form). I don't think LV at the client level can be…
So just to your last point, no one can tell the difference between "you, the client, can no longer reach this particular server" and "this server no longer is up". You might be able to tell that it's the user's connection, rather than a netsplit somewhere, with some reasonable degree of confidence (ping the ISP, ping google, etc), but that's a lot of work, still just a percentage chance of being correct, for no real benefit.
To the rest...that's the point, it's just...CSS and JS. You can change it. You can show it or not, based on what the user is doing, or what view they have. Worst case, you can just hide it completely across everything, as you say, which is then no different from an SPA, except where functionality fails when you have no connectivity. Whether that leads to a better or worse user experience is dependent on the dev's handling of those failures.
Re: The future of web software is HTML over WebSockets
#179Earlier quoted context omitted.
> Wouldn't an intermediate layer such as e.g. Phoenix/LiveView ( https://www.phoenixframework.org/ ) solve the problem? I don't think so but if I'm wrong please correct me. 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…
> 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. You can restrict the visual warning to the first load only, it would be pretty distracting otherwise.
> You can restrict the visual warning to the first load only, it would be pretty distracting otherwise.
How would this work in practice while still showing it when you want it to be shown?
Re: The future of web software is HTML over WebSockets
#180I’m gonna be “that jerk on HN,” but this is that idea that just keeps getting rehashed every couple of years then fizzles out. The reason that it’s so attractive is because as developers we love to build and save time, and we think, “imagine what we could do if we didn’t have to ask for data from remote servers...” The problem is that stateful connections suck and create artificial complexity when you don’t need them…
This seems like a more complicated SPFjs over websockets that is deeply wedded to a particular Ruby framework.