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.
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?
Depending on the DSL you choose (JSON or Programmatic) you declare reactivity slightly different, but pretty much, we have states and inlined expressions.
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.
So we see ourselves as the one shop stop for all your form needs.
Honest caveat, none of us have really used SurveyJS, so correct me if I'm off.
Biggest overlap is the JSON-schema idea, which is our first point here:
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 would be suprised to hear this, but we are actually thrilled to hear this! We are on our first weeks (v1.02), so if you have found a bug we would love to get our hands on it!
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.
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.
If done properly, autocomplete w/ Typescript and string literals should work just fine.
Why did your release jump from 0.17.0 (2026-06-08) to 1.0 in such a short time?
I guess you are implying how mature we are?
If so, I think you can see this on our github commit log:
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
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?
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.
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, 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.
So we see ourselves as the one shop stop for all your form needs.
As someone just starting out with the JS ecosystem, how does this compare to something like SurveyJs?
Honest caveat, none of us have really used SurveyJS, so correct me if I'm off. Biggest overlap is the JSON-schema idea, which is our first point here:
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.
But you can see that we do way more...
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.
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 styling front page, I think you would like the framework
Don't judge a book by its cover. In this case, a library by its website.
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.
Date range picker doesn't work...
You would be suprised to hear this, but we are actually thrilled to hear this! We are on our first weeks (v1.02), so if you have found a bug we would love to get our hands on it!
Would you consider raising an issue here? https://github.com/golemui/golemui/issues
You could be the first person to open an issue on this repo (other that the three of us)
It goes without saying that this does work in our machines.
worked for me.
Is there no file input type?
Good feedback! Is actually on the roadmap :)
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.
I hate it.