Yes, that's what they're doing. And Russia/Belarus too, before the war. Also, not just EU companies - the EU branches of US companies I worked for had 1/2 of the teams in Ukraine/Russia/Belarus.
Sorry but this sounds like they just didn't know how to write React and didn't take the time to learn it. You can write React and have 2 runtime dependencies in total - react and react-dom. Or you can go for preact and have exactly 1 runtime dependency - preact. Everything you need is there.
Time-to-interactive has never been a problem for me. My code-splitted bundles are so small they're pre-loaded quicker than the server-rendered HTML code. And builds? My apps - even big ones - build in single digit seconds (using swc or esbuild), and small ones like forms we're talking about in less than a second. The only thing that takes long time is TypeScript typechecking, I do that in a separate task in my CI while the build is long done and tests are in progress at the same time.
I'm not saying all this is super easy - obviously it's the product of using React literally since it's first public beta release. But it's also not impossible to do, and setting up a htmx and a server to run it on is IMHO similar complexity.
The biggest mistake people do - they use stuff like create-react-app with a bunch of absolutely unnecessary cruft. And then they follow some tutorials made by a dude who knows React for 2 months. Just read the React docs (except for the create-react-app part) and you're good to go.
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.
(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.
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?
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?
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.
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.
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.
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.