And yes, I did create something like this but I wanted to include also a router (like Mithril) and a standardized way to handle state, both global and local... and I ended up with https://h3.js.org -- yep, probably not many people use it but I have been using it for months for personal projects and I keep tinkering to improve a little bit whenever I find I need to polish some rough edges or support additional use cases.
Like others said, I wonder how long it will take for bloat to creep in. For now though yes, I agree that you really don't need much code to build a fully functional SPA. And creating your own micro framework really helps you understand how things really work, without relying on someone else's abstraction.
A noble goal. I like that you are avoiding compilation and tooling.
In this world of bloat, it is so refreshing to see someone doing The Right Thing.
For example, Opera 12 (Presto) has full modern DOM support with .createElement and such, but I doubt your framework would work with it?
There are hundreds of browsers and engines out there, and I want to support them all. Would your framework degrade gracefully in a browser you've never tested before?
Also, how do you deal no-JS users? I read through the documentation, but could not seem to find one?
This is a noble and audacious goal, but I suspect that it would either take enormous resources, or the least common denominator approach.
OTOH supporting, say, the 3 major browser engines that serve > 99% of the audience is sort of achievable, and also practical.
b) I believe the remaining 1% matters, perhaps more than the others. (See wheelchair analogy.)
c) Yes, it does take a least common denominator approach at first, but you can build a lot on top of that, carefully, without upsetting even such classics as Netscape, Mosaic, and IE4.
Would you say that one developer working part time for a couple of years is "enormous resource"?
IE4 had an early DOM but it was different from the current one, and JS syntax was different too.
Writing DOM-modifying code that does useful things on IE4 as well as on current browsers is possible, but requires a lot of extra code and testing for little gain, and will encounter browser bugs if you do anything complicated, so you can't just drop in a thoroughly-portable framework, you need to test as well.
If what you mean is you'd like graceful fallback to a decent non-JS page on ancient browsers, that's doable, but then it doesn't matter if the JS framework only supports 99% of browsers. Just make sure to disable the framework on browsers too old to use it. (You'll still have a hard time with CSS on Mosaic.)
Can you explain, what technique you use to update DOM (I'm lazy to walk through code base), is it proxy object like Solidjs, or something like "uhtml". How do you manage to dispose event listener internally (is memory leak possible around that?)
---
Just read some docs it seems like using Proxy!
But, what would you say to those that say, “Great- another year, another JS framework”?
Specifically, why would I want to use this instead of Vue? What does it buy the average developer?
I find it kinda interesting too so I might try it for my next project...thats how it goes.