but the question is: is it a guitar? Or is it a choose-a-phone? It's got a lot of stuff! How can we tell if they're frets or if they're miles of random patch cables?
Well, I probably don't mean complicated in the "complected" sense - but there's a lot of parts and a lot of new vocabulary for a lot of new types of parts and a lot of different possible ways to fit them all together and it wasn't clear at all how to decide when to use which ones, and I simply could not get the big picture in my head from all the description of all the minutia
> 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)