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.
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
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.
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.
Just wanted to say I'm impressed with the speed of progress! There's clearly a lot of passion being poured into the project, and I appreciate that folks are responding really quickly to things. It looks like you've already fixed most/all of the things I noticed, and added Firefox to the test suite[0]. Nice!
We take very seriously the feedback from the community, so don't hesitate also to open a discussion if you have proposals or any other comments:
https://github.com/golemui/golemui/discussions
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
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.
If you don't even know what tools exist in the ecosystem, how can you possibly know that your tool even scratches a new itch ... let alone "creates a new paradigm"?
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...
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?
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
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.
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:
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.
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?
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 :)
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.
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
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.
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.
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.
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.
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.
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!
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.
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.
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 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.
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.
We've banned this account. If you want to use a different (non-trollish) username, and commit to following the site guidelines (which you broke with this comment), we'd be happy to unban it.
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.
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.
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.
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.
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!
Just wanted to say I'm impressed with the speed of progress! There's clearly a lot of passion being poured into the project, and I appreciate that folks are responding really quickly to things. It looks like you've already fixed most/all of the things I noticed, and added Firefox to the test suite[0]. Nice!
[0] https://github.com/golemui/golemui/pull/215
Hey mattstir,
I did the fix and very happy to help, but thanks to you for reporting it!
If you see any other issues, please, open it in Github and we'll try to fix it asap: https://github.com/golemui/golemui/issues
We take very seriously the feedback from the community, so don't hesitate also to open a discussion if you have proposals or any other comments: https://github.com/golemui/golemui/discussions
That's impressive! A quick glance shows me there's a commit that added almost 2500 lines of code.
https://github.com/golemui/golemui/commit/861b182556fab44d1c...
But that doesn't mean vibe-coded. Just hints at LLM assistance which, imo, is fine.
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
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...
If you don't even know what tools exist in the ecosystem, how can you possibly know that your tool even scratches a new itch ... let alone "creates a new paradigm"?
Love SurveyJS. It's often overlooked - but a really solid choice!
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/
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
I'm saying the version from 0.17.0 -> 1.0.
While other projects, such as Astro Starlight for documentation and Hugo CMS, have not yet reached 1.0.
https://starlight.astro.build https://gohugo.io
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...
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?
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?
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 :)
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.
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.
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
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 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?
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 :)
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?
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
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.
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!
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.
The docs don't appear to cover progressive enhancement. Is this an oversight?
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?
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
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!
I always prefer declarative ways over all others, looks good to me!
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.
Is there no file input type?
Good feedback! Is actually on the roadmap :)
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.
no direct support for svelte is a major turn off
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.
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.
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.
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
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
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.
Because the two sets of skills aren't related. Library and design work are not the same thing. That's why
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.
[flagged]
We've banned this account. If you want to use a different (non-trollish) username, and commit to following the site guidelines (which you broke with this comment), we'd be happy to unban it.
https://news.ycombinator.com/newsguidelines.html