Hacker Newsnew | past | comments | ask | show | jobs | submit | wtfdeveloper's commentslogin

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!


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


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


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


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


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


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: