Read on Twitter
People's reactions to Hotwire are making me think back to Rails as She is Spoke, & @gilesgoatboy's point in it that Rails generally chooses @dhh's development ~aesthetic~ over OO purity when the two come into conflict.
There's a lot of genuine theoretical purity to many API-backed app-shell SPAs and that purity *does* make them easier to reason about in some ways.
But it comes at a *heck* of a practical cost. Some of this is in pageweight, tooling, etc. But a lot of the cost is day-to-day.
But it comes at a *heck* of a practical cost. Some of this is in pageweight, tooling, etc. But a lot of the cost is day-to-day.
To get the theoretical purity of an API-backed app-shell SPA, you need to think about your API design and FE state layout ALL THE TIME, FROM THE JUMP. That is one heck of a cognitive load.
So the question is, is it PRODUCTIVE cognitive load for YOUR team? for YOUR app?
So the question is, is it PRODUCTIVE cognitive load for YOUR team? for YOUR app?
My experience is that for 90% of teams/products, it's not productive cognitive load. I'm not going to get into why at this time. Either you also are Team I Want To Never Bikeshed About Redux Layouts Again, or you aren't, and I'm not gonna convince you in this thread.
I'm more interested in why some folks see the # of tools Hotwire gives you/makes you consider out of the box as complexity, and other folks (like me) see it as simplicity.
One of my constant frustrations with most component-based SPA frameworks is that *not everything is a component.* Sometimes you need a model or a controller.
We fake this with "container components" but it's always awkward.
We fake this with "container components" but it's always awkward.
Another is that, actually, there kind of is a difference between partials/views and components. It's fuzzy, but I want to be able to think of "the edit view of a Post resource" differently than I think of "a component from the design system."
Most teams solve this by having a lot of internal conventions about how you do containers, how you do page components, etc. And I posit that this is not seen as "complexity" because it's familiar. It's difficult for developers to see things they think are obvious as "complex."
So when Hotwire calls these different kinds of things out as different, it *seems* complex, but (to me), really all it's doing is surfacing buried concepts and giving them names. (which to me is complexity reduction.)
And similarly, folks who are really used to the state management + API design dance of most SPAs may not always see them as "complexity." They're normal, so they recede into the background. But to others, they're "complexity" because they take SO MUCH TIME.
Anyway, as @tef_ebooks keeps pointing out, "simple" and "complex" are, when used by programmers, mostly synonyms for "I like this aesthetically" and "I hate this aesthetically."
