SocketCluster VS WHATWG HTML Standard

This is basically the principle behind https://socketcluster.io/ scalability; the sharding of channels across available brokers is pseudo-random. It uses a hash function for determinism but the distribution looks essentially random.

I started building something pretty obscure about 14 years ago; https://socketcluster.io/ an open source, WebSocket-based RPC + pub/sub library with a focus on in-order async stream-processing with backpressure monitoring.

It didn't start out like that. Initially, it was just another WebSocket library with a focus on making it easier to scale to multiple processes.

It's kind of mind-bending to me though that it still feels like it's "too early." You'd think that the ability to efficiently process RPCs and pub/sub messages from clients whilst maintaining ordering would be critical... Yet if you look around the industry; callback-based event handlers are still the norm for most application logic and people are still not using queues where they should be. People think of queues as some expensive/bulky system with overhead which requires additional architecture (e.g. RabbitMQ, Kafka, STOMP, NSQ) and always requires exactly-once delivery, they have not tried to make the idea a core part of their application logic. Software today is FULL of race conditions because of this blind-spot. Yet I still cannot communicate my message. It's too difficult to explain the benefits.

I've been advocating for this approach for years. You can't avoid race conditions without using some kind of queueing mechanism and you need backpressure to measure queue capacity. I built this into every aspect of https://socketcluster.io/ - From pub/sub channels, RPCs to event listeners.

It's interesting reading this.

Preventing these kinds of concurrency issues is exactly why I built https://socketcluster.io years ago. Though it solves the problem at the app layer rather than the storage layer.

But not many developers care about these race conditions it seems.

It's not just an issue with SQL but a more general issue with coding.

This is a great example because it shows how concurrent executions can lead to significant issues.

My project https://github.com/socketCluster/socketcluster has been accumulating stars slowly but steadily over 15 years. Now it has over 6k stars but it doesn't seem to mean much nowadays as a metric. It sucks having put in the effort and seeing it get lost in a sea of scams.

Well I built it up in parts and brought the parts together over time. SocketCluster has over 6k stars on GitHub. https://github.com/socketCluster/socketcluster

Saasufy itself isn't open source but I'm planning to sell licenses of the code. SocketCluster is a core component of Saasufy. The goal did evolve slightly; originally, it was to make it easier to build full stack applications. Now it's actually; lets you build entire full stack apps without code. That bigger goal has been achieved. I have some videos linked from the Docs page showing how it works.

https://socketcluster.io/ has had such stream implementation and backpressure management since at least 2019;.

https://github.com/SocketCluster/writable-consumable-stream

The problem with HTTP2 is that the server-push aspect was tacked on top of an existing protocol as an afterthought. Also, because HTTP is a resource transfer protocol, it adds a whole bunch of overheads like request and response headings which aren't always necessary but add to processing time. The primary purpose of HTTP2 was to allow servers to preemptively push files/resources to clients to avoid round-trip latency; to reduce the reliance on script bundles.

WebSockets is a simpler protocol built from the ground up for bidirectional communication. It provides a lot more control over the flow of data as everything passes over a single connection which has a single lifecycle. It makes it a lot easier to manage state and to recover cleanly from a lost connection when you only have one logical connection. It makes it easier to process messages in a specific order and to do serial processing of messages.

I considered the possibility of switching the transport to HTTP2 for https://socketcluster.io/ years ago, but it's a fundamentally more complex protocol which adds unnecessary overheads and introduces new security challenges so it wasn't worth it.

For WebSockets, using SocketCluster (https://socketcluster.io), it's possible to queue up all requests from the same client and then detect and respond to high backpressure spikes (e.g. by disconnecting the client and/or recording the incident).

You can combine different approaches like limiting the number of connections from a single IP within a certain timeframe and also limiting the backpressure.

The ability to measure and respond to extreme backpressure spikes on a per-end-user basis is highly valuable because backpressure in SocketCluster takes into account the processing time of client requests.

A common strategy that spammers use is to identify and invoke the most expensive endpoints in your system.

A lot of people still don't understand the value proposition of being able to process requests from clients in-order. It's also really good at preventing race conditions and makes your environment highly predictable.

HTML 5 still gets new features all the time: https://github.com/whatwg/html

But they'll never add new standard tags with hyphens.

I’ve tried replacing my modal components with the element, but had to reverse everything due to this issue: https://github.com/whatwg/html/issues/9936

In short: you can’t have an interactive popover (e.g. a toast notification) on top of a dialog modal.

I’d love to use the new native elements but we’re sadly not quite there yet.

Like the IETF, you mean? If I want to implement general internet-compatible timestamps, RFC3339 is right here: https://www.rfc-editor.org/rfc/rfc3339.

How about something big: TCP? RFC9293. It's here: https://www.rfc-editor.org/rfc/rfc9293.

HTML? Different organisation but the same idea, it's over here: https://html.spec.whatwg.org/multipage/

You're reading this web page because of standards organisations that gave everything away for free for anyone to implement.

To provide a comprehensive semantics overview, here are the HTML spec’s first paragraphs for all the 113 HTML elements (that is, not including MathML and SVG):

> What, to you, would constitute sufficient proof? Is it feasible to gather the evidence your suggestion would require?

Let me quote from my comment, again:

--- start quote ---

The guy pushing "intent to deprecate" didn't even know about the most popular current usage (displaying podcast RSS feeds) until after posting the issue and until after people started posting examples

--- end quote ---

I would like to see more evidence than "we couldn't care less, remove it" before a consensus on removal, before an "intent to deprecate" and before opening a PR to Chrome removing the feature.

Funnily enough, even the "browser consensus" looks like this: "WebKit is cautiously supportive. We'd probably wait for one implementation to fully remove support": https://github.com/whatwg/html/issues/11523#issuecomment-314...

BTW. Literally the only "evidence" originally presented was "nearly 100% of sites use JS, while 1/10000 of those use XSLT.": https://github.com/whatwg/html/issues/11523#issuecomment-315... which was immediately called into question: https://github.com/whatwg/html/issues/11523#issuecomment-315... and https://github.com/whatwg/html/issues/11523#issuecomment-315... and that's before we account for google's own docs saying they have a blind spot in the enterprise/corporate setting where people suspect the usage may be higher.

Also, as I say. I think the main issue isn't XSLT itself. XSLT is a symptom.

> LLMs are trained on wrong autogenerated documentation: a downward spiral for hallucinations! (Maybe this one could then force users go look for the official docs? But not sure at this point…)

On this, I think, we should have some kind of AI-generated meta-tag, like this: https://github.com/whatwg/html/issues/9479

I have a little bit of skepticism about the move by Google (and you should usually be very skeptical, any time Web standards or Web "security" are talked about, lately), but...

The gaudy retro amateur '95 design of this page might suggest the idea "anyone only cares about this for strange nostalgia reasons".

Content-wise, I think this argument is missing a key piece:

> Why does Google hate XML?

> RSS is used to syndicate NEWS and by killing it Google can control the media. XSLT is used worldwide by [multiple government sites](https://github.com/whatwg/html/issues/11582). Google are now trying to control LEGISLATION. With these technologies removed what is stopping Google?

Google wanting RSS/Atom dead, presumably for control/profit reasons, is very old news. And it's old news that Big Tech eventually started playing ball with US-style lobbying (to influence legislation) after resisting for a long time.

But what does the writer think is Google's motivation for temporarily breaking access to US Congress legislative texts and misc. other gov't sites in this way (as alleged by that `whatwg` issues link)? What do they want, and how does this move advance that?

We can imagine conspiracy theories, including some that would be right at home on a retro site with animated GIFs and a request to sign their guestbook, but the author should really spell out what they are asserting.

I don't see any evidence of that claim from the materials I have available to me. [0] is the Github Issue I mentioned. [1] is the WHATNOT meeting notes linked to from that GH Issue... though I have no idea who smaug is.

[0] <https://github.com/whatwg/html/issues/11523>

[1] <https://github.com/whatwg/html/issues/11146#issuecomment-275...>

Gecko currently has much deeper integration of the XSLT engine with the browser internals: The XSLT engine operates on the browser DOM implementation. WebKit and Chromium integrate with libxslt in a way that's inherently bad for performance ( https://github.com/whatwg/html/issues/11578#issuecomment-321... )

Just Firefox XSLT is faster, better, cheaper than Google's (and JS), same, old Firefox extensions were to powerful Google could compete with Firefox (or block adblocks).

JS is very needed for ads, tracking and other strings attaching - and XSLT is not for that - but would make JS mostly obsolete in many cases.. (only "cross-browser functionality for XSLT is incomplete with certain features like having open issues" ).

Google pay Mozilla to criple Firefox. It's money from ads, to not let the web be free. Right now, how much $ and CPU power a JS engine could cost, for that, is irrelevant - except for the final user !

https://news.ycombinator.com/item?id=44994459 - with answering lame question of a developer not having a clue what is all about the XSLT.