1) It does too much too quickly. There's no acclimatisation ramp.
2) The examination area's too small. Almost every document is too large & has multiple pages. Navigation through documents is broken, with some not draggable back to the booth if clicked on.
3) Question responses are likewise too small for their dialogue boxes. They need to be in one box, either with larger boxes or smaller fonts.
This is an advert for zgui, disguised as a critique piece.
From the article itself:
> Disclosure: I ported GPUI’s current Linux renderer to wgpu2, I built the benchmark harness used below, and I work on zgui, a signal-based Rust framework that appears in the charts.
Not sure I agree there (re 'advert disguised as a critique'). It's ok to have opinions that lead you to develop something different, and then share data to back up those opinions. The author is very open about zgui.
The argument is made in bad faith, what does it mean to scale in the scope of UIs? What is a complex UI? Do 99% of apps ever hit issues related to this?
If the title were written in a way to say that their library is built for complex UI interfaces and here's how it compares to gpui then it would be a different story.
IMHO it's up to your own expertize to judge whether it's a good or a bad argument, which is distinct from the motivation of the author in making it. It's again perfectly normal for people overstate the relevance of minor advantages in their thing.
What I'm saying is: "Hey, this is shilling for !" is not a problem and I find it strange to call that out. "This isn't actually a big deal, don't fall for it" is of course perfectly fine to point out.
I mean, I don't disagree but hn is a forum, if someones likes to point this out I don't see it as a bad thing. Considering the brainrot from AI and infinite content, reading something like "hey this thing has some whatever agenda behind it" can zap my brain into actual critical thinking instead of content ingestion. But that's just me :)
[Your text] --> [List of numbers (tokens)] --> [List of [List of numbers describing a concept/term/thing/job/item/etc] (embedding)]
That final thing (List of embeddings) is what gets fed into the LLM, so that it can produce (List of embeddings most likely to follow afterwards), which is then turned back into text.
> and their worth
Tokens are priced based on the model you're using. In general, expect to pay more when you need to use larger models. (Note: Exceptions exist, but treat them as exceptions)
The space as it is now prices tokens based on:
- how many tokens it needs to process (input),
- how many it needs to generate (output), and
- how often you send the same chunks of text that their system already has on file (cached).
> and harnesses
A harness is something that adds in tools & directions for the LLM, so that it can do its tasks. In a dumbed-down semi-visual summary:
---
[Text about what the LLM should be & what they're allowed/not allowed to do]
[Text about available tools & how to call them]
[Your text here]
---
The harness, if its part of a program/app, then looks at what the models generate in response, and does the (file writing/reading, tool calls, web searches, subagents, etc.), based on the formatted output that the LLMs should produce.
> and what exactly all of those things accomplish
Depends on the goal of the user. Some use them as assistants, most use it for coding.
1) This decision was made pre-AI, where human familiarity mattered. Since the devs that would've used this were familiar with JS, that was what they were stuck with.
2) You're targeting to the wrong person. Blame the managers at Netscape for pushing Brendan Eich into creating JS, rather than letting him use Scheme as the scripting language. From there, it would've made sense to allow Scheme to be compiled into bytecode.
> It doesn't fulfill its primary purpose of being a (fun) game.
A fun game isn't made when you're working on the engine & tech.
It is only made when everywhere else has been done, & when the feedback mechanisms are tightened. This will never happen in the prototyping stage, because the point is to make the thing exist in the first place.
------
This comment is the same Reddit-style one-off critique that makes no actual sense when placed at the grindstone, made by people that have never actually tried to make one with OR without.
??? I don't see anyone claiming they made a game, let alone a "fun" one, you're replying to something that is not in this thread. The claim was that the agent wrote a program with clearly defined constraints and it works according to spec because it dutifully tested it and iterated on incorrect code. It's not bugged, it doesn't crash or anything like that.
> why do they need someone else's vibe coded stuff?
Because even if vibecoded, the initial work has already been done, and it would be absolutely foolish to outright dismiss it just because it doesn't meet puritanical standards.
> How is any of this serious?
It isn't & shouldn't be. The upfront demand for "serious" is what kills public projects in the first place, where they all come from an experimentation perspective.
There is no public project out there that (from its first commit) was fully serious: Each & every one of them were offshoots & experiments, testing to see if the thing was possible in the first place.
Likely because the ball isn't a single static 3D object. There are likely improvements that can be made on that front by periodically generating the inner layers of the ball as a single asset.
2) The examination area's too small. Almost every document is too large & has multiple pages. Navigation through documents is broken, with some not draggable back to the booth if clicked on.
3) Question responses are likewise too small for their dialogue boxes. They need to be in one box, either with larger boxes or smaller fonts.
reply