That library was a Pandorica of fabulous, interwoven randomness, as rich as plum cake. Push a seed of curiosity in between any two books and it would grow, overnight, into a rainforest hot with monkeys and jaguars and blowpipes and clouds. The room was full, and my head was full. What a magical system to place around a penniless girl.
Paul finishes up his excellent three part series by getting down to the brass tacks of designing and building components on the web …and in cities. His closing provocation has echoes of Heydon’s rallying cry.
If you missed the other parts of this series, they are:
Ethan has been thinking smarty-thinky thoughts about patterns and pattern libraries.
Anna has just published a lovely new version of her excellent little book on pattern libraries. EPUB, MOBI, and PDF versions are yours for a mere $8.
Behind the amusing banter there’s some really solid performance advice in here. Good stuff.
Client Side Rendering (CSR), or as I call it “setting money on fire and throwing it in a river” has its uses, but for this site would have been madness.
Here’s an epic brain dump by Vitaly on the challenges of putting together a pattern library and then maintaining it.
Sacrificing consistency for usability is fine. A slightly open-ended, inconsistent but heavily used pattern library is better than a perfectly consistent pattern library that is never used.
We should be asking why we need a framework or a tool before just dropping it in. It’s not to say that you shouldn’t learn new things. YOU ABSOLUTELY SHOULD BE CONTINUOUSLY LEARNING! But you should ensure that you have a solid base to work from.
Another typically excellent talk from Maciej, this time to the Library of Congress. Digital preservation, surveillance, machine learning …it’s all in there, and it makes for grim reading, but there’s also optimism:
My dream for the web is for it to feel like big city. A place where you rub elbows with people who are not like you. Somewhere a little bit scary, a little chaotic, full of everything you can imagine and a lot of things that you can’t. A place where there’s room for chain stores, room for entertainment conglomerates, but also room for people to be themselves, to create their own spaces, and to learn from one another.
It’s not about what works for you. It’s about what works for your users.
If a very complicated set-up with seven brand-new libraries and frameworks and a bunch of other tools satisfies you completely as a web developer but slows your sites down to a crawl for your users, you’re doing it wrong.
If serving your users’ needs requires you to use other tools than the ones you’d really like to use, you should set your personal preferences aside, even though it may make you feel less good. You have a job to do.
But it’s worth remembering this caveat too.
I’m in a similar position to Remy:
But, like Remy, I’m interested in knowing what are the ideas and techniques embedded within large frameworks that will end up making their way into the web stack:
What I want to know is: what should I be taking away from React into my own continued evolution as a web developer?
There are some good responses in the comments.
Build JS apps responsibly - cover your basics, render strategically and enhance into true apps.
I really, really like what Ember is aiming for here:
That’s how you get the holy grail of resilience and performance:
Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.
I sincerely hope other frameworks are paying attention to this layered approach.
Oh, and I also like this observation:
There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.
One more tool for making pattern libraries. This one looks fairly simple and straightforward.
Striking that balance between the reusability of modular components and maintaining a big-picture vision of the overall design:
We should always strive to use patterns in an application. For example, consistent use of colors and font sizes can quickly indicate to the user elements in the UI that can be interacted with. However, avoid using a pattern just because it has been implemented before; rather, use it because it really solves the problem at hand.
Marvellous insights from Mark on how the robustness principle can and should be applied to styeguides and pattern libraries (‘sfunny—I was talking about Postel’s Law just this morning at An Event Apart in Boston).
Being liberal in accepting things into the system, and being liberal about how you go about that, ensures you don’t police the system. You collaborate on it.
So, what about the output? Remember: be ’conservative in what you do’. For a design system, this means your output of the system – guidelines, principles, design patterns, code, etc etc. – needs to be clear, unambiguous, and understandable.