We have to talk about JavaScript
It seems that almost weekly concerns about the complexity of the ecosystem around JavaScript, build tools and frameworks bubble over. Certainly, the JavaScript and Front End development world is a lot more complex than even a few years ago.
The latest round kicked off with Jose Aguinaga musing on “How it feels to learn JavaScript in 2016“. Depending on your feelings about the state of JavaScript in 2016, it’s inflammatory, amusing, or depressing. But it certainly started some conversations.
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
I encourage folks to adopt this approach to keeping up with the JavaScript ecosystem: first do it, then do it right, then do it better.
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.
Sadly (and as the moderator I’ll take responsibility for this), the conversation sort of went around and around two “strange attractors”. There were those who fell into the JavaScript/React camp, and those more traditional developers who think in terms of the traditional layered (HTML/CSS/JavaScript) architecture.
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.
But, what I think we often miss is that not everything on the Web is like that. Or if it is, it often shouldn’t be – time and again, things that could be plain old web sites use complex JavaScript approaches for reasons I simply cannot fathom.
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.
Understanding core technologies like CSS (many of the criticisms of CSS are really a reflection of the misunderstanding of the technology by the critic) and even HTML (it can do a lot of heavy lifting around accessibility, and just plain old better user experiences), as well as JavaScript, and the DOM.
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.
What’s certainly beyond doubt is that we’re building very complex, sophisticated and often important things on the Web, and yet the Web as a platform, and its enabling technologies like HTML, CSS, JavaScript and the DOM, are still often perceived by those in the computing fields as they were two decades ago: as “toys”– anaemic and under-powered.
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
Want more?
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.
Great reading, every weekend.
We round up the best writing about the web and send it your way each Friday.