Yes, I've done this with Htmx. Send the input content to the server and respond with the new <datalist> html that gets automatically swapped in.

Really simple engineering.

Does this mean that every time the user types something, they have to wait a roundtrip from the server for completion? Wouldn't this make this useless for average-to-fast typers?

Htmx sounds like a lovely idea, but doesn't it introduce a ton of latency compared to client-side operations?

Well, they "wait" for a fraction of a second maybe. And you put it behind a typing delay so it responds only when the user is ready.

Also, many autocompletes do a round trip anyway. The htmx version just returns the html already rendered, rather than, say, JSON that requires further processing and injecting.

Here are a couple of Go templates from a sample project that show it:

    {{define "autoc_data" -}}
        {{- range . -}}
            <option>{{.}}</option>
        {{- end -}}
    {{- end}}
    
    {{define "autoc" -}}
        <input name="{{.Id}}" id="{{.Id}}" type="text" list="{{.Id}}_data"
            hx-get="/autoc/{{.Id}}/search" 
            hx-trigger="keyup delay:300ms"
            hx-target="#{{.Id}}_data">
        <datalist id="{{.Id}}_data">
            {{- template "autoc_data" -}}
        </datalist>
    {{- end}}

In response to `/autoc/<id>/search`, the server just responds with a list of strings matching the user's input, formatted with the `autoc_data` template. Htmx injects that into the `<datalist>` directly.

It's how any search engine does autocompletes... you can't possibly store all the queries clientside. Whether you're sending a tiny JSON or a tiny HTML snippet back doesn't really make much of a difference. It's usually fast enough, especially if you debounce/throttle the user input so you're not sending the query on every keystroke.

That’s how almost all autocompletes work

Unless you have the data on the client side already, which isn't the case for Htmx.

True, but then you are required to load all possible values for all autocompletable input fields at page load, which in many cases is unreasonable.

As mentioned, many (most even?) autocompletes do it on the fly, and probably without you realising.

In my experience type ahead is most useful on datasets that are generally too large to load the whole dataset locally. There are certainly times when a list is too long to fit in the available space, but unlikely to grow unbounded, but such large lists that are known not to grow in an unbounded manner are rare in my experience.

Both of those frameworks require javascript to be enabled for anything requiring an event handler.