Personally I feel like Elm itself is not to blame, but rather we as community have not yet figured out a good and scalable way to deal with forms. Because they come in a lot of different shapes and forms, it’s often easier to have a case-by-case solution rather than a universal one.
I very much agree with this. My last job where I used React was building out huge forms, 20-50 dynamic fields, for use in insurance. We went with an approach of defining the fields with JSON and then building a massive custom framework for rending, updating, validating, and swapping out the fields contextually. The was a rewrite, of a rewrite, of a rewrite of a desktop app.
Even after 3 rewrites it was still complicated and difficult to manage. The first thing that would have been easier about writing it in Elm is that Elm is easier to refactor so we might have been able to do refactors instead of rewrite. The second thing that would have been easier in Elm is catching errors with Elm’s static types. We spent a lot of time trying to debug edge case errors that just wouldn’t have existed in Elm.