Hacker News new | past | comments | ask | show | jobs | submit
nananana9 | on: We should be more ambitious with the software we build
You don't need most of this. Give me 30 minutes, it will be easier to just build it than describe it.
nananana9 | parent
This is as far as I got in 30 minutes: https://ghostdisk.github.io/ui https://github.com/ghostdisk/ui

Text glyphs/UI images are all in 1 atlas, you can render the entire UI as 1 draw call and only re-render when something changes. I haven't checked if Claude chose to re-render the whole screen or just part of it, you can design it either way.

Layout can be as simple or as complex as you want it to be - this example does both flex and grid-style layuts, flex supports start/end/center/stretch on both main/cross axes, as well as a flex prop.

For the API you can either go immediate mode or retained - this one is retained since explaining to Claude how to do the IM version properly would take longer than doing it myself, but the layout algorithm can be the same regardless of which route you go for the user-level API.

You only need scrolling/overflow on top of that and this is enough for the majority of widgets you may need.

My point is none of this stuff is hard. This is 700 lines of Claude code, if you write it yourself it would be 400, and will have better performance characteristics than most UI libraries out there.

Edit: Added scrolling too, there's a 100K scrollable virtual list in the demo. Again - this stuff is not hard.

well_ackshually | root | parent
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.

Rohansi | root | parent | next
Many native UI toolkits also suffer from some the issues you shared. Depending on what you compare with you'll find fewer layout options, limited or no text selection, poor style and animation support, etc. People say browsers are inefficient but it's actually impressive how well browsers manage to run all of the badly optimized websites out there.
nananana9 | root | parent
What this toy shows you is that both points in your original comment are moot.

  1. "fucking over my battery consumption and asking for my GPU to spin" - it renders frames on demand
  2. "2D sucks to make, 2D eats half of your frame time by just existing and slicing those triangles" - frametime is in the microseconds when a frame does need to be rendered, and no triangles need to be sliced because shaders exist.
Let me remind you of what we were arguing about - whether or not you can render UI with a GPU API, without blowing up your computer. I would love to hear how handling taps, adding a mobile-friendly layout to the demo, handling selection or accessibility would change the calculus on that.

In the midst of your ad hominem, your argument seems to have changed from "don't use a GPU API" to "making a production grade UI library is hard", which I'm more than happy to give you.

well_ackshually | root | parent
You just don't get it, do you? What I'm saying is that your approach can _never_ lead to a good UI toolkit. You've made a funny toy that renders three boxes that can never work in the real world. Not only is your frame time in the milliseconds on a browser (on a 5080 too), you've made a toy prototype that covers 1% of the necessary features, claimed that it's entirely complete and declared yourself winner (and that implementing the rest would have zero impact on that performance, lol)

It's now been three times you ignore the reality of the world, loudly proclaim yourself winner then proceed to drop 90% of what is necessary. No shit, you can draw empty boxes in 2ms and badly shape text in 3.

>I would love to hear how handling taps, adding a mobile-friendly layout to the demo, handling selection or accessibility would change the calculus on that.

Because now for half of these, you are involving the CPU again, with endless back and forths. Keep repeating it until you have something that works and congratulations, you have more or less exactly what browsers do today.

Considering the hubris, the loud proclamations that you're right and that the whole world around you is wrong, the complete ignorance of the state of the art and the insistence on badly reimplementing things from scratch, the "you don't need those features actually", let me guess, game engine developer?

rfgplk | root | parent
His approach is actually correct (well, aside from doing it in the browser). I wrote a custom, fully from scratch Vulkan UI rendering engine, works more or less exactly as described above. Crazy efficient and performant. Removing VSync I can hit ~100k fps on a dingy 4 year old GPU. For instance in benchmarking opening a window is a _sub microsecond action_. Doing the same in Qt is what... milliseconds? Literally? Also all of the things you described is because... browsers are bad. Or people are incompetent. Drawing fonts is a single draw call and yes, you can and should cache absolutely anything. All the fonts I used are 100% cached. Oh and btw it isn't a toy UI framework but fully production ready.