Mate, if you are proud and happy to code this way, congratulations. That code is an absolute nightmare tho. Your eyes are trained on it so you think this is as good as an ergonomic framework.

Thanks, but this is a server-side thing and has nothing to do with client-side DOM manipulation?! Sure, you can put stuff on the server and do HTTP over the wire. It's oftentimes the better solution. But there are apps/tools that are rightfully an SPA (like tldraw or excalidraw for example) and can run local-first and offline in a browser. You build the entire app in JS and you'd need a bit more than vanilla Web components for that if you want to avoid client-side state explosion.

First off, thanks for sharing this, because I've seen a lot of your comments on these sorts of threads about web development, and it's helpful to see what your approach looks like in practice.

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.