sahil-kang

or perhaps it'll go down the QUIC path instead :)

context: QUIC was originally an acronym as well

fwiw, I normally think of LMDB when the idea of using the fs instead of a db crosses my mind

If I was to tackle a simplified view of the problem I think you're describing: your frontend devs should provide the markup template the backend would interpolate and return

In the scenario you've alluded to, your backend devs are currently producing json data and your frontend devs are interpolating that into markup in the browser. In the simplest case then, your frontend devs would just provide a markup template that can be interpolated with the json already being produced. In slightly less simple cases, they can provide a function to be called instead

The gist is that the logic of taking data and producing markup should remain in the frontend dev's wheelhouse

If I understand correctly, the main selling point of htmx is that _html_ is extended with the attributes from GP: the idea being that a bulk of the interactivity of SPAs can be achieved via hypertext alone

I think a more precise reading of GP's "changes just 4 things in browser behavior" is "changes just 4 things in html behavior"

I can understand the failure to build a critical mass of contributors, but can you share some examples of where your work was duplicated instead of built upon?

I’ve read through some of your async work in the past and from an initial glance, it seemed like you had the right idea by wrapping existing event libs and exposing familiar event loop idioms. At the very least, it seemed uncontroversial so I’m interested to see why others would choose not to build upon it.