Show HN: GolemUI – Declarative Form Engine • Hacker News Board

Re: Show HN: GolemUI – Declarative Form Engine

#21

Post by wtfdeveloper » Wed, Jul 01, 2026, 5:06 PM UTC

cadamsdotcom wrote: post #17

wtfdeveloper wrote: post #6

Earlier quoted context omitted.

haha! Fair point! We are three old school programmers and have no idea on design, so yes for the website ONLY, we let Claude designed for us... If any designers come over to the comment section, we would love to hear from you! We'd love to improve our website with your advice. On the other hand, the code, we started coding this more than one year ago and we have poured our souls on it. If you can bare the AI obvious…

My main advice would be to get rid of anything extraneous in the site. Animations should serve a purpose - for example, gamifying with a fireworks animation is useful if you think that communicates what you want about the product. Engineers know that rainbow borders on boxes are tricksy to implement but a cinch for agents. So rainbow borders are a loud way to say “we didn’t pay close attention to what we were buildin…

THANKS!

Well, we are very experienced developers, which is code for.. we are old... Old as from the time where websites had banners moving across the page, so that might have influenced our choices.

But these suggestions are gold to us as we have no expertise on design, so thanks AGAIN

Re: Show HN: GolemUI – Declarative Form Engine

#22

Post by criticalfault » Wed, Jul 01, 2026, 5:28 PM UTC

pavlov wrote: 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.

i have the same sentiment.

upon opening the site, I immediately got vibed feeling so I closed the tab.

Re: Show HN: GolemUI – Declarative Form Engine

#23

Post by manojlds » Wed, Jul 01, 2026, 5:36 PM UTC

pavlov wrote: 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.

Don't judge a book by its cover. In this case, a library by its website.

Re: Show HN: GolemUI – Declarative Form Engine

#24

Post by manojlds » Wed, Jul 01, 2026, 5:37 PM UTC

Why the name Golem?

Re: Show HN: GolemUI – Declarative Form Engine

#25

Post by recursive » Wed, Jul 01, 2026, 5:38 PM UTC

All the field relationships seem to be expressed in strings. This suggests that you might not be able to use auto-complete or build-time syntax or type checking on them. I like the general idea, but that would be a big downside if I'm understanding correctly.

Re: Show HN: GolemUI – Declarative Form Engine

#26

Post by wtfdeveloper » Wed, Jul 01, 2026, 5:42 PM UTC

manojlds wrote: post #24

Why the name Golem?

Golems are mythological creatures that are brought to life with clay.

For us, our library is the clay, and the result of what you code with it is the golem.

Re: Show HN: GolemUI – Declarative Form Engine

#27

Post by cadamsdotcom » Wed, Jul 01, 2026, 5:42 PM UTC

wtfdeveloper wrote: post #21

cadamsdotcom wrote: post #17

Earlier quoted context omitted.

My main advice would be to get rid of anything extraneous in the site. Animations should serve a purpose - for example, gamifying with a fireworks animation is useful if you think that communicates what you want about the product. Engineers know that rainbow borders on boxes are tricksy to implement but a cinch for agents. So rainbow borders are a loud way to say “we didn’t pay close attention to what we were buildin…

THANKS! Well, we are very experienced developers, which is code for.. we are old... Old as from the time where websites had banners moving across the page, so that might have influenced our choices. But these suggestions are gold to us as we have no expertise on design, so thanks AGAIN

You’re welcome! Happy that it was helpful and not tooooo unkind..

Design can tickle different bits of your brain compared to code! Quite often I can’t pin down and name just what’s wrong (those with the vocab can, of course)

But if you can describe the feeling in the back of your mind to an agent you’re golden.

Re: Show HN: GolemUI – Declarative Form Engine

#28

Post by seattle_spring » Wed, Jul 01, 2026, 5:44 PM UTC

recursive wrote: post #25

All the field relationships seem to be expressed in strings. This suggests that you might not be able to use auto-complete or build-time syntax or type checking on them. I like the general idea, but that would be a big downside if I'm understanding correctly.

If done properly, autocomplete w/ Typescript and string literals should work just fine.

Re: Show HN: GolemUI – Declarative Form Engine

#29

Post by skrebbel » Wed, Jul 01, 2026, 5:46 PM UTC

wtfdeveloper wrote: post #7

verdverm wrote: post #5

How is this a new paradigm? This idea for JSON -> form has existed for a decade, one example: https://github.com/eclipsesource/jsonforms

Correct, But there is more, paraphrasing the post itself: This library has a lot to offer. These are the main characteristics: 1. A JSON engine. The form is governed by a JSON definition that you can store in a DB, version, diff, or generate it with LLMs as a validated JSON. 2. We provide also 28 headless components (and growing) that you can style with CSS variables. We offer APIs so you can drop in Material, Shoela…

That's not what "paradigm" means.

Re: Show HN: GolemUI – Declarative Form Engine

#30

Post by wtfdeveloper » Wed, Jul 01, 2026, 5:47 PM UTC

recursive wrote: post #25

All the field relationships seem to be expressed in strings. This suggests that you might not be able to use auto-complete or build-time syntax or type checking on them. I like the general idea, but that would be a big downside if I'm understanding correctly.

You are correct, the reactive expressions are not statically checked at the moment, but we have an item in our roadmap to fix that. On the other hand, the runtime expressions evaluator does provide feedback in the form of error messages, so it doesn't fail silently.