React is winning by default and slowing innovation

I mean, yes, but you're the one making this comparison, saying that WCs lack reactivity etc.

Web Components are an extension of the DOM – a low level browser API. They are similarly low level. That's expected. I don't need or expect them to be something more.

I am happy that I can use any reactivity system I want to implement a Web Component. That's a feature, not a bug. Having implemented a reactivity system myself, I know that there isn't a perfect one, the design is full of tradeoffs, and I'd rather not have a blessed implementation in the browser, because it will inevitably turn out to be flawed, yet we won't be able to retire it because "we can't break the web". A blessed implementation like that would benefit from network effects just like React does, and would have all the same problems as React, plus the inability to rapidly innovate due to the browser's unique backwards compatibility concerns. I'd rather ship an extra 3KB and avoid all those problems.

There are a bunch of amber flags that immediately stand out, like this being an almost 4k line file with a commit history by only one person, and an idiosyncratic approach to naming and formatting. None of that is necessarily bad on its own, but this feels like code that is written by the author for themselves, rather than for any other potential readers of the code. It's a lot easier to write code if you're the only reader, because you can keep a lot of the code's context in your head, and you don't need to write it down in the same way.

I skimmed through the start of the file and then jumped up the bottom looking for an entry point. From there, the table state jumped out to me as a thread I could follow, so I started exploring that.

The first thing that jumped out at me was how much defensive programming you are doing. There are lots of "if state X is not null" or "if event is not null" sections where it's not clear from the types or the logic that these values can ever be null. This makes me a bit nervous, because if you don't know whether something can be null or not, the reader is going to find it even harder to tell.

The next thing I noticed was how difficult it is to follow state changes around. Part of this is state being set in multiple places at once (e.g. `state.tables` and as data attributes on elements), but also because you use both `.dataset.xyz` and `"data-xyz"` fairly interchangeably, which makes it difficult to jump to the usages of some bit of state if that uses a different syntax.

This got me (finally) to some of the DOM manipulation code, which is what I was just eager to see in the first place. I landed in the tables.populate function, and the most surprising thing that jumped out to me here is that every table seems to be special-cased with a bunch if-else statements, partly for the rendering of each row, and also for updating the payload. Searching through this code, it seems like this mechanism of switching on the type of each module/table is all over the place, and that updating one part of the code is going to have massive knock-on effects on other parts of the code as well.

I'm going to stop here because I need to get on and do other things. I agree with you that you have largely managed to avoid building your own framework, but I think this is very much to the code's detriment: a small amount of abstraction would go a long way here in terms of, e.g. isolating the different tables from each other, or managing state effectively.

I can fully believe that you find it easy to write and maintain this code, but I suspect that has a lot more to do with you being the sole maintainer of this code than it does the clarity of the code. I see people confuse these two ideas a lot, but it's important to separate them.

Like I said at the start, I'm grateful for the chance to see your approach, and if it works for you then my opinion if it doesn't really matter. But it unfortunately does not convince me of your claims about the benefits of this style of development.