Recent Code speaker Tim Kadlec responded, or at least took this piece as a starting point for some less satirical thoughts about the place of tooling in the Front End Engineering world:
Mostly, I think the evolution is healthy. We should be iterating and improving on what we know. And each build tool does things a little differently and different people will find one or the other fits their workflow a bit better. The problem is if we blindly race after the next great thing without stopping to consider the underlying problem that actually needs solving.
Tim provides a framework for thinking about whether and how to use a particular tool. I won’t quote any of it, I simply recommend you go read it.
But it isn’t just Tim who responded. One of the folks I admire most in our field (who’s also responsible for many of the tools we use, the over reliance on which I’ve been critical of at times) is Addy Osmani, who observes
Most acerbically, long time contributor to the Web PPK of Quirksblog fame more bluntly observed about Tim’s comment that “it’s not the ecosystem that’s the problem”,
I disagree. I think the problem is in fact the ecosystem — by which I not only mean the combined toolsets and the expectations they set, but also the web development community as a whole.
Again, it’s worth reading, because it challenges us to question a lot of assumptions about how we do things. He also references a related piece by Bastian Allgeier, who observes:
in the end it’s all about what works for you. What is the best, fastest and most stable tool to transfer your ideas from your brain, via your fingers, into your keyboard and finally into your computer?
To which PPK responds:
I disagree. It’s not about what works for you. It’s about what works for your users.
With which, I most definitely agree.
On this topic I honestly recommend you drop everything and go and watch Rich Hickey, the inventor of Closure, on Easy versus Simple. I based my Full Frontal presentation from 2012 on his ideas and I think there’s tremendous value in considering his thesis that what is easy for us as developers often gives rise to complex code bases that are difficult to maintain, and with attendant security and performance implications.
My take on all this?
I’m on the record as being pretty old fashioned about software engineering and the Web (I still, for the most part, stand by the above-mentioned presentation from Full Frontal in 2012). At our Code conference a couple of months back, I tried to tease apart some of these issues with not one but two round table discussions (one in each of Sydney and Melbourne) about how we should be architecting and engineering things for the Web.
There are really smart people I admire who build complex applications on the Web platform and who, in all honesty, know a lot more about this in a practical sense than me, who will argue very strongly that the sorts of things they are building simply aren’t feasible, or at the very least, would take a great deal more work and time to build, using the more traditional approach.
And I’m in no position to disagree with them. I simply don’t build things like that, and have no data points other than their – respected – position.
So, where does all this leave us? I know it sounds like a cliché, and I feel I’m repeating myself until I’m blue in the face (Tim Kadlec, too, makes the observation in the article I referenced above, as does Addy Osmani), but foundations matter.
These really are the foundations for everything that sits on top – whether it’s a framework, build tool or CSS pre- or post-processor (if you don’t understand CSS well enough to understand what your pre-processor is reducing, is it good engineering practice to even use it? Then again, most software engineers have long since lost the capability to understand the machine code produced by compilers. But I’m not sure the analogy holds).
My intuition is that there are likely differing kinds of architecture appropriate for different kinds of things we’re building on the Web platform. As yet, our understanding of what these kinds of things are is relatively nascent – we have things we call apps, and things we call pages – and I suspect over time these high level patterns will more clearly emerge, and with them a better understanding of the appropriate architectures and tooling.
Above all, I find these conversations, while sometimes tiring, also very valuable – they’re evidence of our capacity to critically appraise what we do, and how we do it. What’s certain is our field is not static. And while that provides challenges, it’s better than the alternative.
So softness and tenderness are attributes of life,
And hardness and stiffness, attributes of death.
The GNL Tao Te Ching, ©Peter A. Merel
Like to see and read more like this? Be the first to score invitations to our events? Then jump on our once-a-week mailing list where we round up the week’s best reading and watching on all things Web. And you’ll get a complimentary digital copy of our brand new magazine, Scroll.