3 ms·
That's reasonable criticism of my criticism. I would defend myself by saying that it feels like the opposite is also true. I built up a strawman and struck it
by 015a 5y ago
That's reasonable criticism of my criticism.
I would defend myself by saying that it feels like the opposite is also true. I built up a strawman and struck it down, but the recommendations in the original blog post, and here, are defined in extremely abstract terms, then defended with "you can do it however you want, there's no rules" such that every team who implements it will do it differently, and inevitably most will spend years landing on ten bad ways of doing it, never reaching the nirvana of what was promised in the abstraction.
I do like the idea; but in a limited capacity, and I'd caution teams from planning an entire application around it. I'd stick to fragments of pages which are highly data-driven, and be more cautious around layout and structure.
- hakunin 5y agoIn case anyone else feels that this article leaves enough wiggle room to accidentally end up with something like 015a described, here are the 3 rules I implied in answering the above post: 1. All structure and content goes to backend. 2. Find good names for size-adaptive sections. 3. Responses to write requests can be anything. I think 1 and 3 are covered in the article, but elaborating on them is probably out of its scope. And 2 is more of a general programming advice.