Webpacker used to configure Webpack indirectly, which lead to a complicated secondary configuration process. This was done in order to provide default configurations for the most popular frameworks, but ended up creating more complexity than it cured. So now Webpacker delegates all configuration directly to Webpack's default configuration setup.

apart from [Websockets], which is unnecessarily complex for non-browser applications

This isn't to say that on a case by case basis there aren't modules that are grossly overcomplicated.

@adisos if reform-rails will not match, I suggest to use: https://github.com/orgsync/active_interaction I've switched to it after reform-rails as it was not fully detached from the activerecord, code is a bit hacky and complex to modify, and in overall reform not so flexible as active_interaction. It has multiple params as well: https://github.com/orgsync/active_interaction/blob/master/spec/active_interaction/modules/input_processor_spec.rb#L41

I find reform's implementation a bit too complicated too (lots of layers of abstraction, including going through the representable gem for a lot of things)

I found the code a little bit complicated. Why to instanciate instance variables in this class instead to do a hash that could be used like this form.models[:first_model]; form.model[:second_model]?

The change is too consequential to be developed in situ.

One of the primary tasks of engineers is to minimize complexity. JSX changes such a fundamental part (syntax and semantics of the language) that the complexity bubbles up to everything it touches. Pretty much every pipeline tool I've had to work with has become far more complex than necessary because of JSX. It affects AST parsers, it affects linters, it affects code coverage, it affects build systems. That tons and tons of additional code that I now need to wade through and mentally parse and ignore whenever I need to debug or want to contribute to a library that adds JSX support.

do I really have to do something like that in order to have my local modules working? it's quite impracticable to explain it to a team! there's nothing a little bit more straightforward?