Tags: libraries

43

sparkline

“What have they done to my library?” - Caitlin Moran

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.

sketch-to-fractal-comp on Vimeo

Everyone in the Fractal Slack channel is currently freaking out about this. Veeeeery iiiiinteresting!

Designing Systems, Part 3: Components and Composition / Paul Robert Lloyd

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:

  1. Theory, Practice, and the Unfortunate In-between,
  2. Layers of Longevity, and
  3. Components and Composition

Pattern patter. — Ethan Marcotte

Ethan has been thinking smarty-thinky thoughts about patterns and pattern libraries.

Front-end Style Guides by Anna Debenham

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.

10 things I learned making the fastest site in the world

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.

Taking Pattern Libraries To The Next Level – Smashing Magazine

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.

You Can’t Get Comfortable Anymore in Web Development | Rey Bango

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.

Deep-Fried Data

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.

Down with the tool fetish - QuirksBlog

PPK responds in his typically strident way to posts by Tim and Bastian. I don’t agree with everything here, but I very much agree with this:

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.

MarkApp: Building apps with HTML

Here’s an interesting collection from Lea: small JavaScript libraries that do their configuration declaratively via HTML, rather than in JavaScript.

What is React?

I’m in a similar position to Remy:

I don’t use React. I don’t really gravitate towards larger frameworks, only because my daily work doesn’t require it, and I’m personally more interested in the lower level techniques and parts of the web and JavaScript.

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.

Progressive Enhancement for JavaScript App Developers | De Voorhoede

Build JS apps responsibly - cover your basics, render strategically and enhance into true apps.

Making And Maintaining Atomic Design Systems With Pattern Lab 2 – Smashing Magazine

A walkthrough of what’s new in Pattern Lab 2. It’s really interesting to see the convergent evolution of ideas here with what’s brewing in Fractal at Clearleft.

EmberCamp London Keynote 2016 // Speaker Deck

I really, really like what Ember is aiming for here:

First, we deliver the raw content, ensuring those on slow connections or without JavaScript get they’re after as soon as possible. Next, we load the minimum set of JavaScript needed to interactivity for that page, keeping transfer time and parsing time low. Once the user has an interactive page, we can start preemptively loading other parts of the application, including frequently-accessed data.

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.

Astrum - A lightweight pattern library for any project

One more tool for making pattern libraries. This one looks fairly simple and straightforward.

Designing Modular UI Systems Via Style Guide-Driven Development – Smashing Magazine

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.

Progressive Enhancement and Modern JavaScript ― Caolan

I think JavaScript frameworks have been blinkered to the needs of many developers (most websites are not SPAs or run by Node, nor should they be) for too long. We need to find a way to apply the lessons of modern frameworks to the rest of the web - it would be sad if everyone had to run JavaScript on their server and good-old resilient HTML was considered only as a fallback.

Design systems and Postel’s law | Journal | The Personal Disquiet of Mark Boulton

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.