Is it just me or is every new framework or library selling itself as “blazing fast”? There are a lot of things you can optimize for in software, but it seems like performance always gets top billing. There’s a whole profession dedicated to it: you’ll find performance consultants in every language, from browsers to ops to back-end to front-end and everything in between. There’s a lot to learn and they’re really good at what they do. There are tons of N+1 queries to optimize away, caches to persist, bytes to shave off downloads, and memory allocations to… uh, not allocate, I suppose.
But beyond the low-hanging fruit, being on constant high alert for performance is usually a sucker’s game. What you’re doing is optimizing, and optimizing is usually best done at the very end, and only when you’ve done your measurements. Don’t make me quote Knuth at you. I’ve heard of a lot of people having strict performance budgets for their site, which might make sense on the face of it (and for some projects) but as with all optimization, there’s always going to be a tradeoff. And we need to be careful that the tradeoff isn’t developer speed or happiness.
Given a choice between one library that’s optimized for ergonomics and another that’s optimized for speed, I’m going to pick the ergonomical one pretty much every day. In my long and illustrious career, I’ve only built a handful of applications where rendering and UI speed really was a significant factor for the business, or the sheer scale made it important. Sometimes user happiness will demand you optimize something. But even then, the correct way to do it is to create and flesh out features as quickly as you can, and then benchmark and fix them afterwards.
I do think most developers are aware of the dangers of premature optimization, but for some reason scaling and performance stories have become the lurid tabloid stuff of software, and framework authors aren’t immune to it. We’re all gawping at outliers like Facebook’s cross-datacenter race conditions or Twitter’s various rewrites, treating them like amazing feats of heroism. Then we go off and try to emulate our heroes by unrolling our loops and sharding our databases, sacrificing simplicity and maintainability on the dark altar of performance. If it were up to me, I’d want there to be more stories in the vein of “how we made our tests more maintainable” or “how to implement a code readability budget” or something — and for libraries to throw off the yoke of millisecond comparison tables and compete more on iteration speed and happiness. Most software is plenty fast already and a far bigger differentiator is how quickly you can build stuff with it.
I’m not saying it’s irrelevant: application performance will always be a factor and as good developers we should be mindful of it, but let’s work together to try and make the tired cliché of “blazing fast” apply more to the person behind the keyboard than the software library.