Link tags: tasks

Reflections on software performance - Made of Bugs

I’ve really come to appreciate that performance isn’t just some property of a tool independent from its functionality or its feature set. Performance — in particular, being notably fast — is a feature in and of its own right, which fundamentally alters how a tool is used and perceived.

This is a fascinating look into how performance has knock-on effects beyond the obvious:

It’s probably fairly intuitive that users prefer faster software, and will have a better experience performing a given task if the tools are faster rather than slower.

What is perhaps less apparent is that having faster tools changes how users use a tool or perform a task.

This observation is particularly salient for web developers:

We have become accustomed to casually giving up factors of two or ten or more with our choices of tools and libraries, without asking if the benefits are worth it.

I finally made sense of front end build tools. You can, too.

I still find the landscape of build tools completely overwhelming, but I found this distinction to be a useful way of categorising the different kinds of build tools:

Build tools do two things:

1. Install things
2. Do things

So bower, npm and yarn install things, whereas grunt, gulp, and webpack do things.

I think.

It is as if you were doing work

Stop dilly-dallying and just get this work done, okay?

Using NPM as a Build Tool | gablaxian.com

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.

ifttt / About ifttt

This intrigues me. “If this, then that” sounds like a good approach to loosely joining some small pieces.