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!

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?

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

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.

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 :)

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

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!

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

Indeed, this is an old principle, we believe the key here is how we approach it, for instance, if you have a look at our DX layer (the gui.*) you will see how we bridge both worlds:

https://golemui.com/dx/form-definition/overview/

Have a look specially at the tags and selectors

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 :)

We are trying to signal that our product is ready to be used, is matured, but is v.1.0 as in this being the initial release... I don't think you would get two companies fully agreeing on their versioning strategy though...

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.

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

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.

We will indeed explore this approach, would be great to hear your thoughts too! Would you consider sharing some more insight by dropping a comment here? https://github.com/golemui/golemui/issues

Thanks! We are definitely learning from this post about things to do, is by far not our strong side

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.

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.

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

Oh my god! Thanks so much! We are studying this immediately.

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

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.

We respect that, we believe is groundbreaking, but also we are aware that as with any other slogan couyld be highly speculative.

However, I think if you look at our offering, perhaps you will agree that there is no one out there that positions themselves as the one stop shop for forms.

Good feedback! Is actually on the roadmap :)

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.

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