Tags: tools

64

sparkline

Modern JavaScript for Ancient Web Developers

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.

sketch-to-fractal-comp on Vimeo

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

Should you learn [insert shiny new tool]? | Zell Liew

This ties in nicely with the new talk I’m doing on evaluating technology. Zell proposes a five-step process:

  1. Figure out what [insert tool] does.
  2. Figure out what sucks right now
  3. Determine if it’s worth the investment
  4. Learn it (if it’s worth it)
  5. Differentiate opinions from facts

Most of the examples he gives are tools used before deployment—I have a feeling that different criteria should apply when weighing up technologies written directly in user-facing code (HTML, CSS, and JavaScript).

The Five-Tool Designer » Mike Industries

Mike lists five tool skills he looks for in a designer (not that every designer needs to have all five):

  1. Visual Design & Animation
  2. Interaction Design
  3. Getting Things Done
  4. Teamwork
  5. Leadership

Swap the first one out for some markup and CSS skills, and I reckon you’ve got a pretty good list for developers too.

On Design Tools and Processes | Viljami Salminen

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 imagi­nary feel of control. Forget the boundaries presented by our tools and ways of thinking. Break out of the silos we’ve created.

Resilient Web and Tools — David Larlet

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?

Evaluating Tools For Building a Component Library | Chromatic

A comparison of a few different tools for generating pattern libraries.

Spoiler…

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.

In Praise of On Resilient Web Design by Jeremy Keith

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.

bitsofcode | Tools for Developing Accessible Websites

Ire rounds up a bunch of tools you can use to test accessibility, from dev tools to Tenon.

The Service Worker Lifecycle  |  Web  |  Google Developers

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).

The Web is not Fashionable. - The blog of Ada Rose Edwards

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.

Dan McKinley :: Choose Boring Technology

A somewhat contentious title but there’s some really smart thinking here about choosing and evaluating technology.

The slidedeck version is even clearer.

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.

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.

How to prototype in the browser | GDS design notes

This is a clever quick’n’dirty way of prototyping iterations on an existing site using dev tools and screenshots.

Chasing Tools - TimKadlec.com

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:

  1. Who benefits from the use of this tool and how?
  2. Who suffers and how?
  3. How does it fail?
  4. Does the abstraction feed the core?

Web development as a hack of hacks - QuirksBlog

PPK reads a Hacker News thread so you don’t have to.

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.

Declarative Design Tools | Jon Gold

Jon introduces a new tool with a very interesting observation: up until now, all our graphic design tools have been imperative rather than declarative

With our current tools we’re telling the computer how to design the vision we have in our head (by tapping on our input devices for every element on the screen); in our future tools we will tell our computers what we want to see, and let them figure out how to move elements around to get there.

» Introducing Drizzle Cloud Four Blog

A new pattern library tool, this time from the smart people at Cloud Four. It’s called Drizzle and it started life as a fork of Fabricator.