[sodapopcan]

Heex and components are essentially one-in-the-same. Heex enabled components upon its release and now the framework is (rightfully) pushing components.

Forms I agree with, though I don't feel that pain too badly. Having to be more explicit than just passing in raw parameters to an update function actually has its benefits (though I'm sure better forms are coming along).

Agreed that the framework is moving faster than the available literature on it, though people are doing their best and are doing a pretty good job of keeping up.

What is it about the boilerplate that annoys you? It's quite a bit less than Rails, though that's my only point of comparison unless you're going to unfairly compare it to a microframework. There aren't any generated files that I'm not thankful I can easily edit if I need to.

[blueblahvlah]

W.r.to boilerplate - I have no reference point/comparision to other frameworks.

When the project grows with more contexts, components and forms, one will end up with a bunch files which differ only in Module.func_names.

Phoenix < 1.7, View files which are required for controllers are boilerplate which contain 3-4 lines. In the end there will be a folder with view files which don't will have similar content unless any view specific functions are added.

[h0l0cube]

It seems like essential complexity to me. I think maybe there's some ceremony around explicitly casting, validating, etc. with Ecto, but it would be hard to hide that without 'magical' assumptions and making it more inflexible. But I agree View files always felt a little redundant for many use cases where the template doesn't really need to make any function calls – and from memory, function calls in LiveView templates is not performant and causes the whole DOM to be regenerated when values change.