HN Explorer

Show HN: GolemUI – Declarative Form Engine (golemui.com)

41 points by wtfdeveloper ↗ HN
We're a team of three friends who have been working with forms and Open Source for a decade, and we joined forces together to create something where we can apply all of our experience.

We recently released GolemUI, an Open Source library to generate forms dynamically from JSON definitions, with a typed layer to simplify authoring.

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, Shoelace, or your own components.

3. A DX typed authoring layer on top to write forms programmatically, that generates JSON. So you don't have to write it.

4. The same definition can render the UI components in React, Angular, Vue, Lit, or Vanilla JS.

5. We also have a deterministic MCP that has tools for to validate the model's output, generate JSONs or code, and ensure that the definition returned by the LLM is always valid.

You can find more information here:

Happy to hear any feedback from you and answer any questions!

30 comments

[ 2.6 ms ] story [ 49.2 ms ] thread
pavlov
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.

bpev
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.
wtfdeveloper
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

verdverm
How is this a new paradigm?

This idea for JSON -> form has existed for a decade, one example: https://github.com/eclipsesource/jsonforms

rjrjrjrj
The basic idea of declarative forms goes back way further than that. I wrote a Perl library that generated a form from Oracle table metadata 30 years ago, and I very much doubt I was the first one to think of it.

I haven't looked at Golem specifically, but every other approach I've seen breaks down for complicated UIs. User-friendly validation and conditional forms require procedural logic. Invariably the declarative format (JSON in this case) ends up with up with a bunch of programming constructs.

nu11ptr
As someone just starting out with the JS ecosystem, how does this compare to something like SurveyJs?
bushido
Love SurveyJS. It's often overlooked - but a really solid choice!
cmoski
Date range picker doesn't work...
recursive
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.
hungryhobbit
I knew this would be yet another garbage copycat library the moment I saw "new paradigm" in the title. When I actually looked at the webpage, I found I was not at all wrong.

P.S. I genuinely don't want to hate on the work of motivated devs, creating something useful for the community, and trying to share it. That's a great thing, and we want more of it!

But when some asshat comes in with an ai slop library that's redundant with a dozen other solutions (all of which people actually use in production to solve problems) ... and claims that they are creating new paradigms ... it feels to me like that makes things harder for every real new contribution.

All the stuff we want is signal, and crap like this just adds ego-based noise that blocks the signal.

nilirl
Ok, I love it.

Can you simplify how form dynamism works? I skimmed the docs and saw 'states', but it didn't immediately click how it works.

Do we build a tree of rules outside of the components? Are states attached to each component, bottoms-up, and then the form tree is managed by the library?

wtfdeveloper
Depending on the DSL you choose (JSON or Programmatic) you declare reactivity slightly different, but pretty much, we have states and inlined expressions.

If states didn't click initially that's fine, you can still cover a lot of ground using inlined expressions: https://golemui.com/dx/features/states/inline-when/

Basically you can nest the states, so you can build a tree of states that way.

Or you can leverage the DX to have fully reactive components.

todotask2
Why did your release jump from 0.17.0 (2026-06-08) to 1.0 in such a short time?

If I use Tailwind, BEM or Boostrap, how hard it will be to customise? Flowbite have a few pre-made UI.

Shoelace UI is based on Web Components, now that it got bigger:

https://webawesome.com/docs/components/

mring33621
Lots of my previous employers had "data structures to forms" tech. It's very useful.

GolemUI looks like a nice open source version of this idea.

Thank you!

charucharu
How do you handle schema migrations? If someone has thousands of JSON form definitions stored in a database and the component API changes, is there a migration strategy or versioning system built in?
smcleod
This looks very much like many slopped up UIs I've seen over the past few years. Not saying the code is, but the design itself looks vibe coded?
mattstir
How much of this is vibe coded? The widget demos about halfway down seem half-baked; the currency input allows letters and letter inputs visually disappear when you unfocus it. The calendar input appears to select the day before the one I clicked. The markdown editor places hashes after the text on the current line rather than making the current line a header. The dropdown search doesn't seem to work (typing "R" shows React and AngulaR, but typing "Re" doesn't show any options).

All of those are fixable of course, and the idea is neat! It's just a bit of a rough showcase, at least on Firefox.

vivzkestrel
no direct support for svelte is a major turn off
ramon156
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?
[deleted]
(comment deleted)
lanycrost
I always prefer declarative ways over all others, looks good to me!
wtfdeveloper
Thanks!

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.

rich_harris
The docs don't appear to cover progressive enhancement. Is this an oversight?
wtfdeveloper
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?

rich_harris
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

wtfdeveloper
Hi Rich,

thank you for taking the time to write this out. This is exactly the kind of harsh but true reality check we were hoping to get by posting here..

With regards to the accessibility point, you're right, marking the email field invalid as you type is not accessible. GolemUI allows you to specify different validation trigger modes via form config: 'blur', 'change', 'submit' and 'eager'. We should change that to 'blur' in our demo.

Regarding server-side vs. client-side validation, we fully agree. Because our library is strictly a frontend tool, we see them as complementary features that can coexist.

With regards to progressive enhancement and the full-stack approach, well, is a much harder architectural hurdle for how our engine currently works, but you have given us some food for thought. We will think about these features.

Seriously, thank you for the feedback!