Live data from Hacker News

Show HN: GolemUI – Declarative Form Engine

golemui.com

61–70 of 73 posts

Re: Show HN: GolemUI – Declarative Form Engine

#61

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?

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?

Re: Show HN: GolemUI – Declarative Form Engine

#62
post #60

Earlier 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.

correct! We are (obviously), using AI to assist us, but for the library code we are fully on top. And you can expect this to be the case for all the foreseeable future of the library

Re: Show HN: GolemUI – Declarative Form Engine

#63

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?

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?

we are good at:

- 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

#66
post #2

The 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.

Re: Show HN: GolemUI – Declarative Form Engine

#67
post #66
post #2

The 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.

Hey! Woah! Actually, this might seem dumb, but we did not think of that!

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

#69

The 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?

Re: Show HN: GolemUI – Declarative Form Engine

#70

The 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 have to admit I get very disappointed when I see new form abstractions that don't take this seriously — especially if they make bold claims like 'the new paradigm'!. The whole point of forms is that they're part of HTML. You should not need JavaScript to submit a form, period.

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

Post reply on HN