> Well, I probably don't mean complicated in the "complected" sense
Huh, funny you should say that because that's exactly how it struck me. Why is a URL route generating library and a new way of framing middleware-like functionality bundled under the same name as a vocabulary for expressing state transformations for the DOM?
Any sense of how easy it is to swap these pieces out? I would hate to have a Django-like scenario where it is, technically speaking, possible to swap out things like the ORM, templating, routing etc, but doing so pretty much ruins the benefits of using Django in the first place
I believe spanning disparate concerns doesn't necessarily add complexity - only size is certain to be added. Which isn't particularly wrong as long as the concerns are not coupled.
And maybe this stuff will become the new atoms that we build applications out of, and I'm just balking at all the unfamiliarity. I can't be sure, but initial impression is that they are not that - that they're just too oddly shaped to be generally useful.
Today, though, Rich's keynote was about the necessity of the restriction of choice to allow creativity to be possible. I don't know how to integrate that idea with the idea that very large cardinality isn't a problem. (Some of his examples of bad design were pieces of hardware with too many knobs or inputs)
For the record, my initial impression about Pedestal isn't particularly positive either. But I don't think one can judge its complexity only in terms of familiarity.
Probably the problem with "too many knobs" isn't the cardinality itself (how many is too many?), but that it typically is a sign that the designer hasn't realised the commonality and composability of the knobs/features.
Huh, funny you should say that because that's exactly how it struck me. Why is a URL route generating library and a new way of framing middleware-like functionality bundled under the same name as a vocabulary for expressing state transformations for the DOM?