Increasingly, this is actually an argument in favor of vanilla web components.

The WC ecosystem has grown a lot, and one of the great things about native web components is that they can be consumed by most major frameworks at this point. There are also many mature component sets you can pick from, like shoelace, etc... you can mix and match components from different offerings, something that's not practical with React/Angular (for example).

I can use a select from Ionic, a breadcrumb from Shoelace, and a date picker from Lightning and it'll all just work.

Doing vanilla Javascript development doesn't mean "don't use any libraries" (well, it might to purists, but whatever) it means stick to using standards based technologies with libraries and accelerators.

For example, I use many of the techniques described by the site, but I prefer to use lit-html library (NOT lit framework) for rendering.

Sometimes I use the vaadin router for routing, sometimes the Ionic router, sometimes my home grown one.

I use a little library I wrote called ApplicationState for cross component shared state, because I don't like state being coupled to my DOM structure.

Sure, this requires a deeper understanding than "batteries included" frameworks, but the advantages outweigh the negatives IMHO.

If you use a bunch of libraries for routing, UI, authentication, the only thing thats left is the rendering.

And quite frankly I don't see why Id want to reinvent the wheel there.

{#each notes as note} {note.content} {/each

is exactly what Id want to implement for example if I were writing JS functionality to render a collection.

And Svelte for example doesnt restrict you from using vanilla JS whenever you want either

It's not reinventing the wheel, it's more like not putting snow chains on your wheel when it's summer.

Does your "nice reactive table with search" retain its current state (including scrolling!) if I click on a link that opens another page, and then back out?

Does it let me link to page N of results?

As a user, I find that, in practice, it's these kinds of things that frustrate me far more than the lack of instant reactivity, whereas simple form with a submit button and a paginated table below works just fine.

Implementing state isnt very difficult.

I think youre thinking of a very static use case again. Link to page number doesnt make too much sense when the data changes (and do you really want to refresh the whole page just to change the table data?), but yes thats easy to implement to.

It would just look something like let pageNum = params.page

<Table defaultPage={pageNum}/>

Now think about if you need to implement a more complex table in an admin UI that lets you filter / sort, delete/add rows, etc. Thats where reactivity is really really nice. All you have to do is something like items = items.filter(i -> i.name.startsWith(input)) and youre done.