I, like many others, have found myself spending a lot of time lately reflecting on the state of the web and wanted to try and collect some thoughts on my concerns for our discipline today, the direction in which it is heading, and a reflection on the soul of what we do.

Web design: a short-history

So I have recently come to realise that I have been making websites for twenty years. The most surprising thing about this (for me) is that I still feel relatively new to the discipline (if we can call it that), following a brief first career as an archaeologist. In these twenty years, the shape of the web has changed beyond belief. I have seen our websites and pages evolve from the humble, linear hyperlink driven pages to table-based layouts; from floats to elastic-based design; through responsive web design and the rich, landscape of tools, techniques and technologies we see today.

So many of my early years in this industry were spent trying to negotiate limitations of the languages we had at our disposal (and the browser landscape available): the spacer.gif, float layout hacks (i still curse the double margin bastard in IE6); MooTools, Prototype then jQuery. It seems almost hard to recall how much energy was required in fighting for web standards and the separation of semantic markup, CSS and JavaScript; separating our content from our design and our behaviour.

In the face of this struggle – or perhaps in spite of it – the actual way, we worked remained largely unchanged. For a long period, we still worked mainly by putting files on a server and seeing what happened. With version control we discovered a greater maturity and ability to take greater responsibility for the work we were producing – and roll back if we fucked things up – and with the shift from SVN to Git we were able to work more collaboratively.

Our tools, for a long time, were limited. Photoshop for design, a text editor for the static files, an FTP client for putting these onto a server. But as we ironed out the limitations of the languages we were working with (notably with the onset of CSS3 and ES6) we started to shift our focus from overcoming the problems with our media to addressing the tools we used to create this.

Tools like Codekit, Hammer and Live Reload gave us simple tools to visualise our work in real time and handle complex pre-processing and optimisation but such tools were short-lived. In a short period of time tools like Less – and then Sass – helped us to work better and faster direct from the command line. Automating our workflow improved the code we produced and also the ways we began to think about code. Sass helped us to start (or at least made our job easier) abstracting our CSS through methodologies like BEM, SMACSS and OOCSS; methodologies which borrowed heavily from established principles of software development that were cascading (no pun intended) into our front-end workflows.

We started to break things down into smaller, reusable chunks, aided and abetted by the fragmentations possible and the onset of more reusable deliverables such as pattern libraries. With abstraction, we started front-loading more and more responsibility onto our HTML markup through data attributes and classes and use tools such as Grunt and Gulp to increasingly automate the testing and execution of the code we deliver.

Herein ends the history lesson … (I already told you I used to be an archaeologist).

Where are we now?

I am overwhelmed by the developments in our field over the last twenty years. The maturity within our discipline and the sophistication of the work we now produce is incomprehensible from the static, HTML files I was bashing out twenty years ago. But I think we need to be careful about the pace and our motivations for change and also consider what this comes at the expense of.

Discipline Insecurities and the confidence of others

As an archaeology student I remember being told by someone that ours was a “magpie discipline” – relatively junior in the field of humanities it lacked confidence in finding and driving its own way forward so borrowed heavily from others: initially its close relative geology but also the physical sciences, the social sciences and latterly the more abstract works of the humanities and philosophy.

We can see something similar in the web; from the humble float layout to the (still) widespread use of Photoshop; from the concept of Responsive Web Design to the adoption of complex software methodologies to produce our code. We have appropriated tools, techniques and ideas because 1) ours was a blank slate to make our own (aka making it up as we go along), 2) we lacked the historical foundations to guide our way forward, and 3) the medium we are working with was – and still is – incredibly fluid: we constantly need metaphors to help us verbalise and articulate the problems that we encounter as the digital landscape changes because this is a blank canvas; virgin territory yet to be defined.

In the early years of web design and development many of the ideas and approaches we borrowed were from the visual sciences; from desktop publishing, architecture and the arts. However, with time this has increasingly been the computing sciences. As CSS methodologies proliferated in the early 2010s, we started adopting naming and working conventions borrowed heavily from the construction of large-scale software products. We lapped up these approaches because we had no discipline security; no confidence in the way we were working so we looked elsewhere for guidance. But for me, this causes many problems because the requirements of coding up the CSS (and/or HTML and/or JS) for a 6-page client website was very far removed from coding up the complex user interface for an engineering product. It comes back to the perceived difference between websites and web applications: I personally feel there is a fundamental difference between these two (sorry Jeremy) and homogenising the goals, tools and methodologies of both have (I think) made things far more complicated than they need to be.

Fragmentation of roles and the triumph of engineering

Along with the increasing complexity, and maturity of our field has come the fragmentation of roles. Twenty years ago the designer very often was “the coder”; a web designer – as well as designing – had to put files onto a server, set up email and work with a CMS. Over time we saw this distinction break down, and we are seeing it fragment even further with the (necessary and perfectly valid) discussions around whether a front-end developer needs to know JavaScript let alone more complex tools and frameworks such as Vue, React and Angular.

It is virtually impossible to imagine a website now without JavasScript, not just in the way we deliver our front-end code and behaviour but also in the methodologies and tools we use to produce it. Indeed, the format we use in many of our libraries (both back-end and front-end) will now often leverage JavaScript notation to communicate between services and to store data in a structured format.

But what price this reliance? And what are the stages and dependencies of getting a file onto a website now? What tools are required? And who is driving the decision making behind these?

At Mud we have a fantastic front-end library that we use and this article is no way offered to criticise this. I am incredibly proud of the websites we produce using this library, the skills and enthusiasm of our team of developers, and the dedication they have shown into pushing our work forward. But this suite of tools that have been designed to modernise and streamline our work is not without its complexities and limitations.

Since it’s current inception in September 2017 our front-end library at Mud has had 347 commits. It currently has 22 third-party dependencies (one of which – our custom gulp build tasks – has a further 126 third-party dependencies). The capabilities and functionality of this library of tools have improved immeasurably since I cobbled together a simple example working with Sass five years ago. But has our striving for constant improvement come at a cost? And what is driving the evolution of our tools?

I’m not picking on this tool in particular and again, I am immensely in awe of the work our team at Mud produces. But I think this serves to highlight a systemic problem within our industry as I perceive it today and that is the obsession with tools and a lack of focus in their adoption.

The tool should never be the goal

At the risk of sounding like a Luddite, I do worry that the adoption of tools for producing websites often lacks focus and a clear reason for “why.” As a largely self-taught profession, we have often lent on our peers for guidance and direction. But how often is the context of this guidance comparable to our own? As I said earlier, can the efforts to produce code for enterprise website applications across large, distributed teams share some equivalence with the work many of us produce in creating small, brochure sites for small to medium-sized businesses and not-for-profits? Does one shoe fit all? And are we in danger of focusing too much on the “Pencils rather than the drawing”? The Process over the Product?

“The biggest difficulty in writing about creative activity, from writing itself to automobile-devouring, is that in most cases the articles or interviews that result seem to be unable to use above plain technical information and lists of preferred tools. I don’t want to fall into the same rut here by telling you which typewriter I use or what sort of carbon paper I think is best, since this information will not make the slightest different to how well you write.”
Alan Moore, Writing for Comics

When we adopt new tools at Mud I try to have a conversation about their interaction with our workflow and processes. In particular, I try to ask:

• will this tool make our work better
• will this tool make our work easier
• will this tool make our work faster

If a tool doesn’t address one of these three criteria we need to consider why is it deemed necessary?

Making money isn’t a dirty word

The main reason why I ask this question is that innovation is almost always a barrier to productivity (at least in the short-term). Tools should only ever be a solution to a problem. Yes, there will always be tools to give us marginal gains on the work we produce; for example, to shave a couple of milliseconds off the TTFB or knock a valuable few kb from our front-end assets. But this must always be placed within a value judgement of the time that is required to implement, adopt and perfect these tools.

Whether you are a freelancer or work in an agency or on a product, the primary commodity you sell is not lines of code but time. This is what our clients, partners and employers pay for. In theory, as our skills evolve and we gain experience our ability to produce code is improved (as well as our ability to frame our decision-making through gained knowledge and perspective). This is generally why senior developers cost more than junior developers: because they have invested time in knowing how to produce things quicker and better:

“But, what?” the woman sputtered. “How could you want so much money for this picture? It only took you a second to draw it!”
To which Picasso responded, “Madame, it took me my entire life.”
Pablo Picasso

So are our tools making our code better, or our work quicker? And are these the criteria driving their evolution and adoption? Or is the increasing complexity of our tools driven by a search for perfection, or an insecurity about our own methods and processes? And do we need to frame our decision-making process so that new tools are seen as a pragmatic enhancement rather than out of a sense of purity and pride for the products we create?

I blame CSS. Well, not really but when we were fighting for the adoption of web standards and the separation of markup, style and behaviour one of the strongest weapons in our arsenal was Dave Shea’s amazing CSS Zen Garden. This articulated the power of CSS and the various, experimental ways we can leverage it to control our layouts. From this conversation, we saw the evolution of new ways of creating websites and conversations about the legitimacy of specific naming conventions, classes vs ids, etc.

But one of the ways CSS Zen Garden was used to persuade people about the merits of a web standards approach was to suggest that we can retain the markup and replace the CSS. However in reality how many projects has this ever happened on? What is the realistic lifespan of a thing we produce? And do we tend to underestimate how disposable our code truly is?

With current web practices the markup, CSS and JavaScript are inherently linked. We may abstract CSS into classes and then our JavaScript into data behaviours but the three not only benefit from working together, they now fundamentally require it. As our code has become more fragmented – from pages to themes and from patterns to components – the integral way our CSS and Javascript operate has become wholly and mutually dependent. The role of pre- and post-processing tools means that to create a web page we must invest in – and indeed have become reliant on – the tools that are used to produce our finished templates. And this has led to a considerable increase in the complexities of putting our ideas out into the world (or onto a server). But missing in this conversation is the recognition of how long do we expect the things we create to live? What is the lifespan of a website? A page template? A component? An object? And how will our ability to maintain these elements be affected with time?

I don’t really do front-end development any more – I have managed to employ an amazing team of people far cleverer than me to negotiate many of these questions. But as a technical director I need to be aware of the complexities involved in moving between projects and the speed of picking up things where they were last left off one, three or five years later.

The Dangers of Knowledge Capitalism

Now excellence is a noble pursuit. The evolution of our discipline has benefitted immensely from the millions of hours our community has put into writing blog posts, sharing code and producing tools to make the work we produce the best it can possibly be. But the pursuit of excellence worries me, primarily because it champions dogmatism (SPACES NOT TABS) and idealism over creativity and pragmatism. Don’t get me wrong – working practices and standards are important. We work in ways that were not conceivable twenty years ago and our efforts proliferate into and improve the work of so many others.

However, I worry what this means to those entering our profession (as well as to a lesser extent old farts like me who struggle to keep up). I teach part-time on an MA in web design at the University of Greenwich. The course deliberately covers the principles that underpin good web design and development: from design theory, accessibility and User Experience through HTML markup, CSS and JavaScript to PHP and CMS development. It is necessarily a broad brush as for many of the students this will be their first experience of coding and producing websites. This broad brush also enables us (indeed requires us) to teach the foundations of our discipline. Because whilst the architecture and tools of our practice change regularly, the foundations some twenty years on still remain pretty solid.

Yet I have seen with increasing regularity questions from students not about the principles of our work, or even these underlying foundations but instead about our tools. And that concerns me. When I started making websites I had a copy of HTML Kit, an FTP client and a copy of Gimp image editor. Now I get questions about Node, Gulp, React, Sass, Tailwind, etc. These are perfectly valid questions – these students are looking at the marketplace and confused about the skills they need to progress. And what scares me is I don’t know the answer.

For years our discipline and community have thrived on the energy and enthusiasm of its participants freely giving their knowledge for public betterment. This was one of my attractions to working on the web. In my previous career knowledge was something that was owned and a commodity that was traded. People shared information but you were rarely allowed to publish it without the approval of its owner. I wrote a number of articles that were never published because they contained references to material that ‘belonged’ to somebody else who was unhappy with me sharing my thoughts. This – for me – was the complete antithesis of what the academic world should be. Indeed my first experiences making websites was in the hope that this would help democratise my PhD research and make the ideas and theories that I was creating more accessible to a broader audience (and hopefully in a more accessible language/format).

Our community is far more open and transparent than this and it has always benefited from the time, passion and devotion invested in it. That many of us are self-taught shows how accessible our discipline can be compared to the more formal career progressions of other, more traditional ‘industries’. Yet I worry about my inability to keep up. And if I can’t keep up how do we expect those just starting out? I worry that the pace of development and the fluidity of our tools ultimately alienate a large number of people from joining and contributing to the conversation.

Thoughts?

This isn’t so much a thesis as a collection of thoughts that hopefully share some coherence. In short, I worry about our over-reliance and obsession with tools because for many these are a barrier to our discipline. I worry that they may never really make our work better, faster or easier and that our attention is increasingly focussed not on the drawing but on the pencils. But I mostly worry that our current preoccupation with the way we work (rather than necessarily what we work on) is sapping my enthusiasm for an industry I love and care about immensely.

Many thanks to Heydon Pickering and Paul Robert Lloyd for commenting on an earlier draft of this post