It would be nice to actually see what the components look like before using them. Currently I can only see the code or examples of how to use them. Also seems like this might be entirely AI generated.
Good idea, thank you. I'll add examples in the documentation. Currently there are example repos that show all the components for each flavor: React, Vue, Svelte, Blazor, Nunjucks, HTML. Angular coming soon.
AI use is mixed: I write everything by hand in the specifications, and the components.tsv file, and in the Svelte version because it's my stack of choice. If you dig in, you'll see lots of hierarchies that are all hand-written to help Svelte caching, for example. I also research other major design systems, especially government-oriented public-sector systems such as GOV.UK and Reuters, and fold them in.
Then Claude Opus tranforms the Svelte version into the other stacks. Claude does a lot of the documentation text because I'm aiming for clear and consistent explanations, suitable for novice developers.
I'm developing Lily Design System because I work with multiple teams that each use a different tech stacks, each with their own ad hoc HTML tag names and semantic names. As a salient example, for a hospital form one team used terminology "health banner area" and another used terminology "medical red box". Lily is my attempt to converge these into something that works better internationally and across multiple stacks.
That said, I'm seeking help doing human proofing and improvements for the stacks, because we all know AI isn't perfect, and needs tuning, guardrails, expert feedback, and the like.
I wonder if this is because it's a larger model or maybe just because they can? Although with the latest Deepseek it's really tough to compete pricing wise. Inference speed and integration (e.g. Antigravity) might be their only hope here
It has to be a larger model, wouldn't make much sense otherwise. That isn't to say the price isn't artificially increased as well
The Antigravity harness is really well done, so I do agree it's their strong suit. Can't say the same about gemini-cli (though it has a really nice interface)
This is an interesting problem, one I've thought a lot about myself. On one hand, LLMs have the capacity to greatly help people, and I think, especially in the realm of gradually learning how to program, on the other hand, the non-determinism is such a difficult problem to work around.
One current idea of mine, is to iteratively make things more and more specific, this is the approach I take with psuedocode-expander ([0]) and has proven generally useful. I think there's a lot of value in the LLM instead of one shot generating something linearly, building from the top down with human feedback, for instance. I give a lot more examples on the repo for this project, and encourage any feedback or thoughts on LLM driven code generation in a more sustainable then vibe-coding way.
Having no knowledge about this isn't there a possibility that this is innocuous, that is that there is some difference in how each provider, such as T-Mobile or Verizon, etc., send the data about how many bars are available such that it needs to be bumped by one?
I looked at the usernames of the people that it mentioned and I don't think that it was actually mentioned on Reddit. It it seems like the front end is mostly AI generated.
I made something similar to this with WebGL shaders (the benefit being it works across browsers): https://real-glass.vercel.app - The tricky thing for me was making it refract real HTML elements behind
I considered WebGL, and I agree—a shader is more performant for real-time effects.
But WebGL comes with drawbacks:
- You need JS code running before anything shows up.
- Shaders can’t directly manipulate the DOM render. To make refraction work, you’d have to re-render everything into a canvas—which isn’t really “the web” anymore.
With the SVG/CSS approach, you can pre-render the displacement map (at build time or on the backend) and get the refraction visible on the very first frame. Plus, it integrates cleanly with existing, traditional UIs.
That said, this approach could definitely be improved. Ideally we’d have shader-like features in the SVG Filter spec (there was a proposal, but it seems abandoned). There are some matrix operations available in SVG Filters, but they’re limited—and for my first blog post I wanted to focus more on pedagogy, art, and technique than heavy optimization.
I actually see gpu utilisation in OP's website when I move things (m3 pro), but this other solution shows much less gpu utilisation (prob more efficient?).
reply