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?
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.
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
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.
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.
This is a good batteries included form framework spec, but not a new paradigm. A new paradigm would be something like not filling forms at all and just process user input via an LLM. Or using voice input in a controlled way. Maybe an adaptive single input field that always knows what you need type.
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.
"new paradigm", "ground breaking". Yet I remember using JSON backed forms in back around 2010 and there's lots of them since. You've added a few handy UI features on top but it's hardly anything new. You're just ruining the useful features you do have with the overstated nonsense
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 should absolutely do that! If a library can't even be arsed to present itself in a reasonable way, how can you possibly trust it to do real work well?
And to be clear, I have a public website created (and designed) by Claude. But the key difference is that I used my brain, and iterated with Claude to make the style not look like AI slop.
Like anything with AI, you can't just fire off a prompt and expect a good anything (code, design, whatever). You have to put effort in ... and all signs show the people behind this library aren't putting their effort in the right place, if what you want is a library that actually addresses most user's needs ...
... and isn't just a a few devs solving for a niche case that can already be solved better with other solutions.
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 building when we built this” - or to be a bit more kind, “we shipped our first draft”.
It’s just like reading code. Why would you want any distractions?
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.
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!
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?
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.
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
In that case, it seems that the live demos in stackblitz have not been done properly.
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.
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.
This is a good batteries included form framework spec, but not a new paradigm. A new paradigm would be something like not filling forms at all and just process user input via an LLM. Or using voice input in a controlled way. Maybe an adaptive single input field that always knows what you need type.
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.
"new paradigm", "ground breaking". Yet I remember using JSON backed forms in back around 2010 and there's lots of them since. You've added a few handy UI features on top but it's hardly anything new. You're just ruining the useful features you do have with the overstated nonsense
That's not what "paradigm" means.
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.
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.
Don't judge a book by its cover. In this case, a library by its website.
Thanks! We are definitely learning from this post about things to do, is by far not our strong side
You should absolutely do that! If a library can't even be arsed to present itself in a reasonable way, how can you possibly trust it to do real work well?
And to be clear, I have a public website created (and designed) by Claude. But the key difference is that I used my brain, and iterated with Claude to make the style not look like AI slop.
Like anything with AI, you can't just fire off a prompt and expect a good anything (code, design, whatever). You have to put effort in ... and all signs show the people behind this library aren't putting their effort in the right place, if what you want is a library that actually addresses most user's needs ...
... and isn't just a a few devs solving for a niche case that can already be solved better with other solutions.
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
There are lots of skills available that enhance Claude's design capability, eg:
https://www.tasteskill.dev/
https://www.usehallmark.com/
https://layers.jamiemill.com/
https://impeccable.style/
Oh my god! Thanks so much! We are studying this immediately.
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 building when we built this” - or to be a bit more kind, “we shipped our first draft”.
It’s just like reading code. Why would you want any distractions?
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.
the feedback is actionable. Fix the styling. It looks awful, like it was made by a middle school student or something
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 hate it.