Recently, there has been a resurgence of the old debate between “front-end” and “back-end” developers. Only this time, it seems to have given rise to a stronger animosity.
Most prominently, PPK’s post on the problem with Angular seems to stem from a cultural tension, rather than a technical one. When he argues that “Angular’s fundamental proposition blurs the line between front-end and back-end”, he alludes to how he believes templating belongs on the server, not in the browser. However, what he is really referring to is his proposition that Angular is targeted at “corporate IT departments”.
More vehemently, Rob Ashton claims that “enterprise IT back-enders” have “ruined JS” with complex abstractions and suggests that:
Perhaps we could slowly take back control of codebases from those enterprise-bound fiends with their beans, their orms and their patterns and practise based proxy factory factories.
Meanwhile, Matthew Gertner argues that this invasion has blurred the definition of front- vs back-end developer. He suggests redefining “back-end” developers who cross over as “full-stack”, and “front-end” as strictly limited to “the parts of the app relating to user interface, rather than those that happen to be running in the browser’s JavaScript VM”.
While a noble attempt, this redefinition seems problematic to me and here I have to agree with PPK:
Anything that’s written in HTML, CSS, or JavaScript needs an appreciation of the many environments it could run in.
Moreover, all it does is shift the barrier, robbing front-end developers from the right to participate in the deeper JavaScript codebase, which would often be key to improving the user experience they are supposed to focus on.
And what do we call developers who span both sides of this new boundary?
I have always been intrigued by the insistence on a strict separation. At the same time, I realise the schism isn’t imaginary: we have tried hard to blur any artificial boundary in the teams I work in at the Guardian, but our job ads are still segregated between back-end (“software engineer”) and front-end (“client-side developer”).
Surely it’s all software?
I’d like to argue most arguments have nothing to do with front-end and back-end developers.
Instead, I’d like to argue it’s all about engineers and craftsmen.
Historically, the web front-end was a noisy, brittle environment, a heterogeneous platform cobbled together on top of poor primitives and unreliable constraints: low bandwidth, fragmented browser standards, CSS layout hacks, JavaScript lacking most features expected from a language even at the time, etc.
As a result, engineers didn’t tend to take it seriously, preferring instead to focus on the more reliable back-end. Perhaps it was also more aligned with the formal teachings of the Computer Science background they were often coming from (though not necessarily).
Meanwhile, the front-end appealed to craftsmen (and women), smart and creative individuals who are sometimes self-taught or issued from an artistic background. Indifferent to the platform’s imperfections, they instead saw it as a fantastic space of creation, universally shared by nature, more visually expressive and with lower barrier to entry than previous forms of programming.
Gradually, as the web developed, browsers matured and standardised, and the front-end grew in complexity, possibilities and expectations. As engineers started to glimpse the opportunity offered by the web, they began to address many of its challenges. It is no coincidence that frameworks like Angular or React came out of engineering powerhouses like Google and Facebook.
These frameworks, along with richer asset pipelines, performance tools or compile-to-JS languages, are merely a sign of the maturation of the front-end from an engineering standpoint.
From here, we can see that the slightly over-dramatic clash PPK and Ashton describe isn’t one between “back-end” and “front-end” developers. It is one between the mentalities of engineers and craftsmen.
Engineers are “concerned with applying scientific knowledge, mathematics, and ingenuity to develop solutions for technical, societal and commercial problems” (Wikipedia).
In software, this is often associated with raising the level of abstraction to solve a more generic problem than the one at hand. Engineers rely not just on personal experience, but on the wider experience of the industry (e.g. theory, design patterns) ideally based on proofs or factual evidence.
The focus on abstractions tends to result in more resilient, maintainable and scalable software.
Here, it is worth distinguishing what PPK and Ashton describe as “enterprise developers” from engineers. Nowadays, I suspect most engineers are just as repulsed by Enterprise Java jobs as front-end developers. While still omnipresent in the industry, they represent a legacy that isn’t aspired to. Good engineers frown upon complicated or excessive abstractions; they strive for simpler ones that best fit the context instead.
In contrast to engineers, Craftsmen are “workers skilled in a particular craft” (Oxford Dictionary).
Owing to their own experience, or that of their peers, they have developed an acute understanding of the possibilities and constraints of their medium. Unencumbered by rigid abstractions or constraining concerns of “correctness”, they know what rules to play by and when to bend them to break new grounds and produce original work very efficiently.
By focusing on the outcome rather than the journey, a craftsman also tends to achieve a more empathetic, usable and human experience.
This spirit of creativity, pragmatism and speed is best illustrated by extreme examples like the demoscene (and its fascinating JavaScript offspring), but it also permeates the work of most web developers.
Another way to frame their differences would be to see craftsmen as delivering immediate value, while engineers deliver value over time.
Needless to say, some projects may be more appropriate to one or the other, but the key to successful durable projects, on the web or elsewhere, will be a combination of both.
You can’t make large scale, maintainable, resilient software without engineering.
You can’t do experiments, come up with innovative ideas and software without craft.
This is why I would work hard to avoid any “Us vs Them” rhetoric. Much the opposite, I would argue all developers should aim to achieve a combination of engineering and craftsmanship.
Engineers should strive for creativity, think out of the box, break rules when needed or better, know when to compromise on purity and keep in touch with the end value at all times.
Craftsmen should embrace higher levels of abstraction, and they should aim for maintainability, DRY and learning new patterns and languages, which will only give them more power to express themselves and to create efficiently.
I am grateful to Phil, Patrick, Ian and Oliver for reviewing drafts of this post. Any remaining errors, however, are mine alone.