Wonder why some technical decisions were made. E.g. i can make a dynamic form builder with Zod in ~1 week without AI. Why not do that? Why a custom engine?
Show HN: GolemUI – Declarative Form Engine
61–70 of 73 posts
Re: Show HN: GolemUI – Declarative Form Engine
#62Earlier quoted context omitted.
Let me paraphrase a previous reply: ___ You can see our first commit here https://github.com/golemui/golemui/commits/main/?since=2025- ... Note the date! 2025-09-01, that is the date of our first commit, 1962 commits later we published v1.0 So you can see this has been well thought ___ So the answer to how much has the library code vibe code is none of it... That said, this is not an excuse for those bugs! We are alr…
That's impressive! A quick glance shows me there's a commit that added almost 2500 lines of code. https://github.com/golemui/golemui/commit/861b182556fab44d1c... But that doesn't mean vibe-coded. Just hints at LLM assistance which, imo, is fine.
Re: Show HN: GolemUI – Declarative Form Engine
#63Wonder why some technical decisions were made. E.g. i can make a dynamic form builder with Zod in ~1 week without AI. Why not do that? Why a custom engine?
Also a lot of the responses claim "we're not good web devs", yet you have a decade of experience. which is it? are you guys good or not?
- Library design - Forms - Components
We have more than 50 years experienced combined in there.
We are terrible at
- Web Design
I hope that settles it :)
Re: Show HN: GolemUI – Declarative Form Engine
#64Re: Show HN: GolemUI – Declarative Form Engine
#65I always prefer declarative ways over all others, looks good to me!
Yes, that is basically the whole idea, to have all the benefits of a JSON like core BUT to give a dx layer on top that allows forms to be semantically defined.
Re: Show HN: GolemUI – Declarative Form Engine
#66The overuse of blue and purple gradient fills on the landing page is a telltale sign of AI slop. I’m sorry, maybe it’s shallow, but that makes me close the tab.
Re: Show HN: GolemUI – Declarative Form Engine
#67The overuse of blue and purple gradient fills on the landing page is a telltale sign of AI slop. I’m sorry, maybe it’s shallow, but that makes me close the tab.
With a name like "Golem", I could see a more earthy color scheme with a much more subtle (essentially unnoticeable) use of gradients feeling real nice with this product.
After the rollercoaster of what this post have been, I can guarantee you that we will indeed consider this very seriously.
Check the website in a few weeks, I would hope that by them we have had enough time to intake all the feedback from this post, specially from this comment.
:)
Thanks
Re: Show HN: GolemUI – Declarative Form Engine
#68Re: Show HN: GolemUI – Declarative Form Engine
#69The docs don't appear to cover progressive enhancement. Is this an oversight?
First let me admit that we are still giggling after seeing who send su this question! Big fans! :)
That being said... GolemUI is a client-side form runtime, the visibility rules, validation, computed fields, and repeaters all run in JS.
But we would be very interested in hearing from the community and specially ... from you! Do you think we are missing a big use case? Any advice?
Re: Show HN: GolemUI – Declarative Form Engine
#70The docs don't appear to cover progressive enhancement. Is this an oversight?
Hi Richard, First let me admit that we are still giggling after seeing who send su this question! Big fans! :) That being said... GolemUI is a client-side form runtime, the visibility rules, validation, computed fields, and repeaters all run in JS. But we would be very interested in hearing from the community and specially ... from you! Do you think we are missing a big use case? Any advice?
I think about the woman in this story — https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven... — as an industry, we've lost our way if we don't care enough about people like her to make our apps work reliably. Not everyone has JavaScript: https://www.kryogenix.org/code/browser/everyonehasjs.html
Moreover, validation is something that belongs on the server. Client-first approaches to form validation are at best duplicative (because you need to repeat the validation on the server) and at worst dangerous (because it tricks you into thinking that's unnecessary).
I also notice that one of the first forms on your website doesn't adhere to common accessibility guidelines — the email field is marked invalid as soon as you start typing. Ordinarily, you shouldn't validate a field until it has been blurred.
So what I'd like to see from people building form abstractions is a) a full stack approach, b) progressive enhancement, and c) adherence to accessibility guidelines.
FWIW this is how we think about forms in the Svelte project: https://svelte.dev/docs/kit/remote-functions#form