[hk__2]

Because it is. It can be very frustrating not to be able to fill a form on mobile with a 3G connection just because some random dev decided that downloading 150kb of JS to render a simple form is fine.

I mean it’s a form; we already have all the HTML elements already; why do you need React for? This is why nowadays we end up with Electron apps that take 6GB of RAM to display a chat.

[throwaway60320]

It's really not that simple.

What about complex validation rules? Do you really think it's user friendly to require them to send the whole form just to tell them "sorry no" 10 times over until they get it right?

What about multi-value selects, potentially with rules? E.g. form field like "choose up to 5 locations in the radius of 10km".

What about form fields like "pick a point on a map"?

Etc. Don't act like every form is 5 simple text inputs.

[rmbyrro]

Doing validation in the frontend is a bad idea.

You'll have to do in the server, if you're sane.

I bet Retool Forms does in the server.

You're worried the page will refresh with an empty form, if it fails. It's simple, just collect the data and return the form pre-filled using the value attribute, along with the error message.

If you don't want to refresh the page, you could even use something like htmx, which is a LOT simpler than React, but really not necessary for simple form submission.

[throwaway60320]

Of course you have to validate on the server. That's a given, always.

But you want to provide better UX to the user.

Htmx is not simpler than React. I can't deploy that without a server that knows everything about the frontend. React allows me to decouple. Templates are hell. I lived in it for many years, never again.

[sodapopcan]

Detractors of the "html over the wire" movement are always talking about it as if the people working on this stuff didn't live through the jQuery days and are blindly repeating them.

[lupire]

What's wrong with jQuery? All my homies (favorite websites) are jQuery.

[sodapopcan]

jQuery is still viable in many situations! My comment is directed at people who say you can't sanely build bigger things without React.

[recursivedoubts]

sometimes it is:

https://htmx.org/essays/a-real-world-react-to-htmx-port/

[throwaway60320]

Yeah until a manager comes and says "well great, it works, now let's do a mobile app like that"

[recursivedoubts]

https://hypermedia.systems/hyperview-a-mobile-hypermedia/

https://hyperview.org

https://htmx.org/essays/splitting-your-apis/

https://htmx.org/essays/two-approaches-to-decoupling/

https://htmx.org/essays/mvc/

[hk__2]

> Don't act like every form is 5 simple text inputs.

Well to be honest 99% of forms are 5 simple text inputs with a select. What was the last time you had to implement a "choose up to 5 locations in the radius of 10km", really?

> What about form fields like "pick a point on a map"?

Same thing: of course there are rich forms for which you need JS, but they are the exception, not the rule.

[_heimdall]

React isn't required for client-side validation or non-spec form inputs.

Doing form validation in event handlers for DOM events works very well, and a simple script tag or custom element is all that's needed to build a multi-value select.

[throwaway60320]

It's not simple. I made multi-page forms with dozens fields where your suggestion would lead to intangible mess of spaghetti code - I know because I worked with the web way before React. Even with the best coding standards and a team of seniors it's just too hard to maintain - and seniors usually don't write forms.

I really don't want to go back to the jQuery days. You do you, but don't say it's easier - it really isn't.

BTW you can just use Preact if you're worried about the bundle size. I do that, it's perfect and just a little performance impact, usually not visible in small apps.

[_heimdall]

Oh that's interesting, multi-page forms are actually my least favorite form use case for react.

I reach for a state machine whenever possible to manage the complex flow of the multi-page or multi-step form, even if react is still used for custom inputs.

[throwaway60320]

Check out XState, it's really great!

But it's not that necessary in my case, my forms are usually not complex statecharts, just a lot of individual and largely decoupled complex form controls - multiselects with rules, map pins, tag inputs with autosuggest, data grids etc.

[cabalamat]

> What about complex validation rules?

I wpould use my server-side form and database library, Bozen[1] to do this.

>

[1]: https://github.com/cabalamat/frambozenapp

[throwaway60320]

So the user would have to submit the form and be met with 10s of errors? I'd rather tell them immediately.

[rmbyrro]

Sure, and React is the best way to show a message in response to an input in a web form, right?

Let me tell you some news, they just launched an integration of this new HTML <form> thing with javascript, so you can have JS listening to inputs and displaying information anywhere on the page. Cool, isn't it?

Ah, but the sad part, again, is you don't get to download an unnecessary library for that. It comes baked and activated into all browsers by default. It doesn't make your resume shine, either...

[throwaway60320]

(P)React is the best way to do it in a maintainable, easy-to-reuse, easy-to-understand, extendable fashion, indeed. Show me something better and I'll jump on it.

I don't care about resumes, I own my consultancy. I care about quickly solving business problems for my clients, not making new problems in the process, and reusing the solutions. I am not paid hourly, I don't make money from fixing spaghetti code broken by adding a stateful form control elsewhere.

[endofreach]

Just saying: You can do input validation without JS using the pattern attribute.

[cabalamat]

If people typically get 10s of errors on a single form, it might well be better to split it up into several sub forms.