With bundler like esbuild, all JS code, including 3rd party libraries can be bundled into a single file. You don't need an extra round trip for a library.
JSX is redundant, at best. VanJS demonstrated ordinary JavaScript syntax is as good as JSX, if not better. How can something feel sugar-ish if it's actually more verbose than ordinary JS code? Plus, you can't really execute JSX code in browser's developer console.
> How can something feel sugar-ish if it's actually more verbose than ordinary JS code?
I personally find XML much easier to parse than a lot of nested callbacks and I especially like that content is always inside tags, rather than another argument as part of the library's functions. p("Hello, world") is readable enough, but as soon as you start adding html attributes, it becomes less legible to me:
I'm certain some people probably prefer the former over the latter, but I much prefer how JSX/XML reads. I can immediately tell where the content starts and in formatted code, I think it's a lot easier to see visually where things start and end, because of closing tags, instead of just a parentheses.
The fact that you have to manually maintain the binding between states and UI elements and propagate state changes to UI elements is exactly the thing offered by VanJS, or other popular reactive frameworks (despite with a much larger bundle size)
In the example I linked, the VanJS state cannot contain an element reference.
This would lead to unexpected results. So you have to be careful with state management, regardless of whether it's automated or not. There are similar pitfalls, including performance issues, with any state management system, hence dedicated state management solutions like Redux exist to address this.
The core of the argument is that complexity sometimes cannot be avoided. You can quickly wind up with moving this complexity elsewhere, e.g. by pulling in an additional library dependency. This results in having to learn, master and manage additional dependencies. Whether that's fundamentally better than the explicit and straight forward way depends on the scope of the project and its specific requirements. There's no silver bullet in any case and pros and cons with every approach.
Tbh I can't follow your logic here. You mentioned that in VanJS there are things that need to be careful with. But the same is true for other frameworks, even for plain Vanilla JavaScript. Thus what exactly the point that you're trying to make?
Complexity can't be avoided for extremely complex use cases. But that doesn't mean a simple solution that can work for most of the use cases has no value.
https://vanjs.org is another example in that direction. It illustrates that it's even possible to have a full-fledged solution of composing complex reactive DOM tree with just plain JavaScript functions.
