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

[throwaway60320]

Sure, you do you. I spent 10 years working with jQuery and am very thankful to leave that very far behind me.

BTW: jQuery is 85.1 kB minified and 29.7 kB gzipped. Preact (same API/dev experience as React, minimal performance impact) is 11.4 kB minified and 4.5 kB gzipped. Who has the smaller JS bundle now?

[sodapopcan]

So did I and you’re side-stepping my initial comment by responding to my response that people can use jQuery if they want. I no longer use it myself nor, btw, did I say anything about its size.

[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/

[throwaway60320]

Why though? It's much easier to do a simple API (or use a pre-made one like this one) from the web and the app. And no need to change the backend code on design updates.

I just don't get what you're chasing after. All this seems more complex (to develop, to maintain, to operate, to manage) than what I'm doing with (P)React (Native) and APIs.

And where are the thousands of pre-made components like React has?

[recursivedoubts]

well, an extended answer is offered in the essays linked above, but, to take some numbers from https://htmx.org/essays/a-real-world-react-to-htmx-port/, here's why:

- no reduction in app ux

- code base reduced by 67% (21,500 LOC to 7200 LOC)

- total JS dependencies reduced by by 96% (255 to 9)

- web build time reduced by 88% (40 seconds to 5)

- Time-to-interactive reduced by 50-60%

- htmx allowed them to display much larger data sets

- memory usage reduced by 46% (75MB to 45MB)

the essays above also discuss why to split your apis (disentangle web app churn from your general purpose data API) and how to avoid duplicating logic (the mvc essay)

i take pains to reiterate in the essays and book that htmx isn't right for every application, but it is a good architectural choice for some, and many more than most web developers who are used to reactive-style programming would think

there are not thousands of pre-made components for htmx because there are no components for htmx: there are rather components for HTML. those components should integrate with htmx in the HTML-standard manner: events & form participation