The problem here is all the OS features are discarded. Can't insert password from password manager because to do so the page would need to access to passwords. Can't use the user dictionary because to do so would be a privacy issue. Doesn't support CJK and other languages that require an input method editor. etc....
It also means a platform's features are not duplicated so your app's behavior sticks out as having a different experience from everything else the user does making it frustrating.
That said, if you want see an app in WebGL/WASM where the browser is rendering everything there's https://earth.google.com as a high end example. It has most of the issues just mentioned as well as the fact that nothing is selectable by default. Want to copy a name so you can paste it into your search engine of choice. NO! Want to right click on a foreign name to find out how to pronounce it? NO! etc....
This is also the first thing I noticed. Cannot copy with CTRL-C, cannot swipe left to get back (though that might just be a event listener problem), right click menu doesn't show any of my usual options, etc.
Also I feel first open time is super slow in my browser
What this needs is a demo of something that you can't do natively in a browser. Recreating HN is great, but it shows why it's not as good as HTML+CSS (slower, bigger, no native browser features). This sort of project has the potential to really demonstrate the power of WASM and WebGPU, but in something that's not a game.
You say frameworks "inherit the limitations of HTML/CSS", so show something that can be done when you don't have those limits.
Why doing something that looks like a web page... inside a web browser that can do it natively? I guess that seeing the same this as a standalone application would be much more impressive (if I understand well, that's what it is supposed to do?). As a demo in a browser I'd rather expect a "regular" GUI with buttons, fields, scrollable sections, radio buttons, etc.
This said, not sure why, but loading it takes ages.
It seems insanely...bad to me. I loaded the HN demo. I can literally see the rows of items loading as if I'm on dial-up.
I can't select any of the text on the homepage demo. In the comments page, text selection doesn't behave like I would expect, in too many ways to describe here.
I right click and can't do anything, unless I right click on an item. And then my only options are "Open", "Open in New Tab", and "Copy Link".
The scrolling on the page doesn't have the normal rebound that you get when you try to scroll past the extents of the page on a trackpad.
Pinch to zoom doesn't work.
Cool that it's handwritten and that you can hot reload and write it on a phone, but as an end user I would _hate_ if I was asked to use an application built on this.
This is a good experiment. What does it take to have a wasm powered corss platform architecture for apps. So far tauri had done something, but requires a humongous backend (system webview).
If we can reach this goal in under 1mb or 2, this is a massive improvement to the SoTA. Experiments such as these are what get is there. kudos.
Why did you write a layout and rendering engine to run on a browser, which is a layout and rendering engine already? As socalgal2 points out, you’re losing many important features.
The name seems very un-searchable and already overused (I found several other web Uniforms while testing searching for yours, which I didn't find). The demo seemed low framerate or something on Chrome Android, and apparently my main, Firefox Android, doesn't support WebGPU by default.
1 commit repo. Not amazed by that at all, totally uninteresting. Not even care of showing the process, this is not open source, this mediocrity at its highest
The problem here is all the OS features are discarded. Can't insert password from password manager because to do so the page would need to access to passwords. Can't use the user dictionary because to do so would be a privacy issue. Doesn't support CJK and other languages that require an input method editor. etc....
It also means a platform's features are not duplicated so your app's behavior sticks out as having a different experience from everything else the user does making it frustrating.
That said, if you want see an app in WebGL/WASM where the browser is rendering everything there's https://earth.google.com as a high end example. It has most of the issues just mentioned as well as the fact that nothing is selectable by default. Want to copy a name so you can paste it into your search engine of choice. NO! Want to right click on a foreign name to find out how to pronounce it? NO! etc....
This is also the first thing I noticed. Cannot copy with CTRL-C, cannot swipe left to get back (though that might just be a event listener problem), right click menu doesn't show any of my usual options, etc.
Also I feel first open time is super slow in my browser
What this needs is a demo of something that you can't do natively in a browser. Recreating HN is great, but it shows why it's not as good as HTML+CSS (slower, bigger, no native browser features). This sort of project has the potential to really demonstrate the power of WASM and WebGPU, but in something that's not a game.
You say frameworks "inherit the limitations of HTML/CSS", so show something that can be done when you don't have those limits.
Why doing something that looks like a web page... inside a web browser that can do it natively? I guess that seeing the same this as a standalone application would be much more impressive (if I understand well, that's what it is supposed to do?). As a demo in a browser I'd rather expect a "regular" GUI with buttons, fields, scrollable sections, radio buttons, etc.
This said, not sure why, but loading it takes ages.
I have been dreaming about this for ages, ditching the DOM and building everything in WASM for example. This is insanely great.
It seems insanely...bad to me. I loaded the HN demo. I can literally see the rows of items loading as if I'm on dial-up.
I can't select any of the text on the homepage demo. In the comments page, text selection doesn't behave like I would expect, in too many ways to describe here.
I right click and can't do anything, unless I right click on an item. And then my only options are "Open", "Open in New Tab", and "Copy Link".
The scrolling on the page doesn't have the normal rebound that you get when you try to scroll past the extents of the page on a trackpad.
Pinch to zoom doesn't work.
Cool that it's handwritten and that you can hot reload and write it on a phone, but as an end user I would _hate_ if I was asked to use an application built on this.
> I can literally see the rows of items loading as if I'm on dial-up.
I noticed this too. I think it's actually just that whatever they are doing for layout is not stable on the first frame.
The comments load differently than HN for whatever reason too so you end up seeing suspense placeholders.
Both are bad UX.
What about accessibility tho?
This is back to Flash.
This is a good experiment. What does it take to have a wasm powered corss platform architecture for apps. So far tauri had done something, but requires a humongous backend (system webview).
If we can reach this goal in under 1mb or 2, this is a massive improvement to the SoTA. Experiments such as these are what get is there. kudos.
Cool hack. But taking a step back:
Why did you write a layout and rendering engine to run on a browser, which is a layout and rendering engine already? As socalgal2 points out, you’re losing many important features.
The interesting claim is the <2MB native runtime. A packaged Mac or iOS build would make a stronger case than the HN clone.
The name seems very un-searchable and already overused (I found several other web Uniforms while testing searching for yours, which I didn't find). The demo seemed low framerate or something on Chrome Android, and apparently my main, Firefox Android, doesn't support WebGPU by default.
That's exactly what companies want: truly closed-source website.
Surely you could ask Claude to decomp the WASM blob it sends you (lol).
1 commit repo. Not amazed by that at all, totally uninteresting. Not even care of showing the process, this is not open source, this mediocrity at its highest
Firefox on Android... Not supported
Firefox in general I think because same on Linux
This is the future for ads. no inspect element to zap an ad.
This ability can and will be added for wasm as well
Would be difficult, every implementation will need a different approach to tackle. Think of it. how do you block certain pixels in a stream of pixels
For starters, a LLM could look at them.
Very nice demo! I love these type of optimizations
[flagged]