For a small to medium sized project, this sounds like a sensible way to approach build tasks. It feels nice and close to the metal.
I’m not sure the particular use-case outlined here is going to apply much outside of AirBnB (just because the direction of code-to-Sketch feels inverted from most processes) but the underlying idea of treating visual design assets and code as two manifestations of the same process …that’s very powerful.
As part of an ongoing series where we ask industry professionals what they use to get the job done, we speak to Jeremy, technical director at Clearleft.
I couldn’t resist the smartarse answer about my “dream setup.”
Speaking as an ancient web developer myself, this account by Gina of her journey into Node.js is really insightful. But I can’t help but get exhausted just contemplating the yak-shaving involved in the tooling set-up:
The sheer number of tools and plugins and packages and dependencies and editor setup and build configurations required to do it “the right way” is enough to stall you before you even get started.
This ties in nicely with the new talk I’m doing on evaluating technology. Zell proposes a five-step process:
- Figure out what [insert tool] does.
- Figure out what sucks right now
- Determine if it’s worth the investment
- Learn it (if it’s worth it)
- Differentiate opinions from facts
Mike lists five tool skills he looks for in a designer (not that every designer needs to have all five):
- Visual Design & Animation
- Interaction Design
- Getting Things Done
Swap the first one out for some markup and CSS skills, and I reckon you’ve got a pretty good list for developers too.
Changing our ways of thinking and doing isn’t easy. Sometimes it’s necessary though, and the first step on this journey is to let go. Let go of our imaginary feel of control. Forget the boundaries presented by our tools and ways of thinking. Break out of the silos we’ve created.
David picks up on one of the closing themes of Resilient Web Design—how we choose our tools. This has been on my mind a lot; it’s what I’ll be talking about at conferences this year.
That’s part of my job to ease processes and reduce frictions. That’s part of my job to take into account from the early beginning of a product its lasting qualities.
There’s a very good point here about when and how we decide to remove the things we’ve added to our projects:
We spend our time adding features without considering at the same pace the removal of useless ones. And still the true resilience (or is it perfection Antoine?) is when there is nothing more to take away. What are you removing on Monday to make our Web more resilient?
A comparison of a few different tools for generating pattern libraries.
In this particular case, Fractal comes out on top:
It has the features we need, and I’m happier than I should be with how simple the directory and file structure is. The documentation has also been super helpful thus far. We’ve customized it with our client’s branding and are ready to roll.
I’m really touched—and honoured—that my book could have this effect.
It made me fall back in love with the web and with making things for the web.
Ire rounds up a bunch of tools you can use to test accessibility, from dev tools to Tenon.
Jake goes into the details of what exactly is happening when a service worker is installed or replaced.
This is easily the most complex part of working with service workers, and I think I’m beginning to wrap my head around it, but the good news is that, for the most part, you don’t really need to know the ins and outs of this to get started (and dev tools are now making it easier to nuke from orbit if this begins to bite).
This is such a great perspective on what it’s like to build for the web over the long term. The web will always be a little bit broken, and that’s okay—we can plan for that.
The Web has history. If you build with web technology it will stick around. We try not to break the web even if it means the mistakes and bad decisions we have made in the past (and will make in the future) get set in stone.
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.
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.
This is a clever quick’n’dirty way of prototyping iterations on an existing site using dev tools and screenshots.
I’ve been thinking a lot lately about how we evaluate technologies (it will be the subject of my next talk). Tim is thinking along the same lines. I like his list of four questions to ask when weighing up the pros and cons of any web tool:
- Who benefits from the use of this tool and how?
- Who suffers and how?
- How does it fail?
- Does the abstraction feed the core?
PPK reads a Hacker News thread so you don’t have to.