Birbla

Discussion summary

GolemUI is a declarative form engine that received mixed reactions, with some criticizing its website design and lack of Svelte support. The creators explained the name as a metaphor for their library being like clay that brings code to life.

What the discussion says

  • Critics dislike the website design and branding choices.
  • Some users are disappointed by the lack of Svelte support.
  • Others appreciate the metaphor behind the name Golem.

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • The docs don't appear to cover progressive enhancement. Is this an oversight?
    by rich_harris
  • 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?

    by wtfdeveloper
  • 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!

    by mring33621
  • THANK YOU!

    Being three devs here on a table reading comments and feeling nervous, is great to hear this kind of feedback, we really did pour our souls here.

    by wtfdeveloper
  • 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?
    by smcleod
  • I too am immediately fatigued by the insta-landing pages people pump out. react-create-app or whatever. no thought whatsoever because "design is a solved problem".

    pause for sighing.

    Ok that said, I mean it makes sense, people aren't good at all things, and getting a project to the finish line is laudable. Let's not flippantly dismiss the project because it uses trendy purple.

    For what it's worth, I would absolutely dismiss a project if the text content was entirely AI. But the design, well, I'm confident 90% launched projects use some JS SPA template thing. It's the state of the industry.

    by apsurd
  • Well, If we have learned something from this post today is that we are terrible designers web designers :)

    We take this as actually great feedback, as we are indeed not good at all at web design, so we will try to improve it using all the feedback in this thread.

    That being said, you can bet we have pour our souls on the library code for this project.

    You can easily see this by looking at our commits.

    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 that the actual code for the library has been build very carefully, I think if you give it a go at our (not so great) website, and you actually see the features, that will impress you

    by wtfdeveloper
  • 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?
    by charucharu
  • I don't think there is a simple answer to that, if moving from a big project to GolemUI or any other platform, the key would be to do it iteratively, first starting with a POC and then slowly intaking the rest of forms, if you were to consider doing a POC with GolemUi we will more than happy to help with this obviously :)
    by wtfdeveloper
  • 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?

    by nilirl
  • 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.

    by wtfdeveloper
  • 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?
    by ramon156
  • 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?
    by ramon156
  • How is this a new paradigm?

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

    by verdverm
  • 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.

    by rjrjrjrj
  • 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.

    by wtfdeveloper
  • 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/

    by todotask2
  • 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

    by wtfdeveloper
  • As someone just starting out with the JS ecosystem, how does this compare to something like SurveyJs?
    by nu11ptr
  • Love SurveyJS. It's often overlooked - but a really solid choice!
    by bushido
  • 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...

    by wtfdeveloper
  • 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.

    by mattstir
  • 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 already working on the fixes, many thanks for raising this!

    by wtfdeveloper
  • 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.
    by recursive
  • 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.
    by wtfdeveloper
  • If done properly, autocomplete w/ Typescript and string literals should work just fine.
    by seattle_spring