So, not to shit on your parade my dude, but it is, in fact, hard. Should your users do silly things like open it on a phone like I just did. As a non exhaustive list:
* Your font rendering is catastrophically bad, because it doesn't take DPI into account. It's a blurry, low quality mess.
* You don't handle taps, because you made it with a PC without considering other users. I can therefore not tap on anything. Is it all mobile devices? Is it just Firefox? Is it just that device? Surely that's an easy problem to solve, it and doesn't involve dozens of interop hacks! Scrolling that main page does work though, thankfully the horrible bad UI toolkit does the job for you.
* Layout: congrats, you've remade Clay. It's mostly a solved problem for the past twenty years, although modern layout needs like "rescaling your UI because your users aren't in 1920x1080" seem to be unneeded. Flex and grid layout have plenty of open source implementations, I'm sure Claude can copy it.
* Your text is not selectable or copyable, but I'm going to be graceful and say that maybe it's because it doesn't handle taps either and that it definitely works on desktop. Right?
* People that have accessibility needs seemingly can go fuck themselves, since your entire website is just a canvas. How hard could it be to integrate with the DOM for ARIA elements anyways? (Trick question, it's impossible.). And when that's done, you get to redo it for AccessibilityKit on Apple platforms, UIA on Windows, AAF on Android, AT-SPI on Linux... Don't worry, they're all very similar APIs, how hard could it be to have one model that integrates with them all? (Watch out, trick question again. Especially if you intend to do it _well_).
* I haven't tested it (remember, doesn't work on a mobile device?), but you do restore text input, in the way that is expected by platforms, right? Android has lifecycle events like PAUSE and STOP, as well as activity recreation like it just did upon going to low battery mode as I was typing. Firefox restored this very long comment. You would do the same, right? It is the responsibility of an UI framework: two way binding of inputs is a recipe for UI nightmares.
It took me longer to type this than to collect all of these issues. That was from just the first 30 seconds of interacting with your toy.
Maybe, just maybe, some people are smarter than you, and have spent more time working on the subject than you, and you should be ever so slightly more humble. That the complexity and the performance of current UI toolkits is not an accident that needs to be fixed by geniuses like you gracing us with your previously undiscovered research. Or keep jerking yourself off, unilaterally declaring that people don't need shadows, transparency, or other very niche features like animations, and ignore the world around you, I'm not your dad.
https://www.nicbarker.com/clay does everything you're doing, except better, and it's _still_ not good enough.
* Your font rendering is catastrophically bad, because it doesn't take DPI into account. It's a blurry, low quality mess.
* You don't handle taps, because you made it with a PC without considering other users. I can therefore not tap on anything. Is it all mobile devices? Is it just Firefox? Is it just that device? Surely that's an easy problem to solve, it and doesn't involve dozens of interop hacks! Scrolling that main page does work though, thankfully the horrible bad UI toolkit does the job for you.
* Layout: congrats, you've remade Clay. It's mostly a solved problem for the past twenty years, although modern layout needs like "rescaling your UI because your users aren't in 1920x1080" seem to be unneeded. Flex and grid layout have plenty of open source implementations, I'm sure Claude can copy it.
* Your text is not selectable or copyable, but I'm going to be graceful and say that maybe it's because it doesn't handle taps either and that it definitely works on desktop. Right?
* People that have accessibility needs seemingly can go fuck themselves, since your entire website is just a canvas. How hard could it be to integrate with the DOM for ARIA elements anyways? (Trick question, it's impossible.). And when that's done, you get to redo it for AccessibilityKit on Apple platforms, UIA on Windows, AAF on Android, AT-SPI on Linux... Don't worry, they're all very similar APIs, how hard could it be to have one model that integrates with them all? (Watch out, trick question again. Especially if you intend to do it _well_).
* I haven't tested it (remember, doesn't work on a mobile device?), but you do restore text input, in the way that is expected by platforms, right? Android has lifecycle events like PAUSE and STOP, as well as activity recreation like it just did upon going to low battery mode as I was typing. Firefox restored this very long comment. You would do the same, right? It is the responsibility of an UI framework: two way binding of inputs is a recipe for UI nightmares.
It took me longer to type this than to collect all of these issues. That was from just the first 30 seconds of interacting with your toy.
Maybe, just maybe, some people are smarter than you, and have spent more time working on the subject than you, and you should be ever so slightly more humble. That the complexity and the performance of current UI toolkits is not an accident that needs to be fixed by geniuses like you gracing us with your previously undiscovered research. Or keep jerking yourself off, unilaterally declaring that people don't need shadows, transparency, or other very niche features like animations, and ignore the world around you, I'm not your dad.
https://www.nicbarker.com/clay does everything you're doing, except better, and it's _still_ not good enough.