Speaking at JSDay 2019: Evolutionary UI
We’re also excited to announce that we’ll be giving this talk again at the O’Reilly Software Architecture Conference in Berlin in November.
Speaking at Full Stack Fest 2018: Heraclitus Slays Zalgo
This is a 5-minute lightning talk I gave at Fullstack Fest 2018, which combines my trademark uneducated armchair philosphy with some JS jargon.
The Greek philosopher Heraclitus once said:
Upon those that step into the same river, different and again different waters flow.
In this talk, I discuss how the problem of “releasing Zalgo” (h͢e̴ ̵wh͝o ẁa̧i̛t̕s͟ ̵b͠ȩhi̷n̡d t͡h̵e͡ ͡wall) when working with APIs that are unpredicably asynchronous no longer applies when using Promises. Since correct use of a
Promise involves lifting all operations that depend on the resolved value into the context of the value (using
.then()), your program cannot end up in an inconsistent state. This is in contrast to earlier approaches, such as using callbacks, that would have involved modifying outside state (a mutable identity) that is referred to by other parts of the program, thus creating the potential for a race condition.
Apologies up-front that I’m not particularly polished or easy to follow here. I decided to do this talk on a whim, and it essentially became a brain-dump of things I had been thinking about recently ¯\(ツ)/¯
Here are the articles and talks I refer to:
- Are We There Yet?, by Rich Hickey
- Designing APIs for Asynchrony, by Isaac Schlueter
- Intentionally unleashing Zalgo with synchronous promises, by Daniel Brain
Dividing Frontend from Backend is an Antipattern
We software developers have historically used the terms “frontend” and “backend” to describe work on client-side (e.g., browser) and server-side applications, respectively. This conceptual split has evolved into the creation of specialized developer roles for each, which is still the norm throughout the industry. In practice, this is an arbitrary split that is too often used to avoid work we don’t want to do. It creates team dynamics that make it unnecessarily difficult to integrate client and server-side functionality and deliver quality software. This is particularly harmful in modern teams, which face increasingly complex client-side work.
Dividing frontend from backend is an antipattern. If you are someone who still feels that there is merit to a hard distinction between these roles, this article is for you.
We already do the same work in the frontend and the backend
What does a frontend dev actually do that’s so different from a backender? The feeling seems to be that backend devs have historically done the more ‘serious’ programming, thinking about meaningful issues such as testability, maintainability, persistence, asynchronicity, state management, and API design, while their frontend colleagues flitted about making things look pretty. If frontend devs did any serious coding at all, it was probably some hacky, half-understood jQuery, cobbled together from various Stack Overflow posts. Many folks still think along these lines.
But we don’t just share the same problems — we also solve them in a similar way. Functional abstractions are emerging as universally useful, such that we can often use the same concepts and syntax in the client and the server. Just look at ReactiveX, now implemented in so many languages that you could easily build a project on the same reactive abstractions in the front and the back. Then there’s the revolution of declarative rendering, which has made the view layer far more testable and stable. On the architecture side, microfrontends have become so popular that we’ve added them to the ThoughtWorks Technology Radar alongside their backend equivalent, microservices. It doesn’t make sense to keep the distinction between frontend and backend development when we’re all doing such similar work.
We need to build broad frontend capability to future-proof our companies
At the end of the day, a lot of us simply dislike styling and other areas of frontend that come uncomfortably close to design. Last year I heard a conference speaker quip that she shouldn’t have to care about something as unimportant as ‘presentation logic’. We have evolved a culture of disdain for frontend which protects us from having to learn since it’s not ‘real coding’ anyway. It’s an attitude that makes it hard to keep up with the market and continue to create meaningful products for humans.
We should care about how our programs consumed
As proud craftspeople, we should care about how our programs are consumed, whether through an API or a UI. At ThoughtWorks, we think of our roles as fluid and non-exclusive areas of championship. For example, while we usually have dedicated QAs on our teams, we consider quality to be everyone’s responsibility. In the same way, we should take collective responsibility for the full stack of technologies we use, and thus ultimately for the quality of the product we produce. Successful engineering organizations understand this. Tech legend Kent Beck, the inventor of Extreme Programming and signatory to the original Agile Manifesto, has said that hanging on his office wall is a poster bearing the following sacred mantra: “Nothing at Facebook is somebody else’s problem”.
Contemporary frontend work has evolved in complexity to the extent that we should no longer separate frontend from backend roles. Frontend engineers now solve the same kinds of problems as their backend counterparts, using the same kinds of solutions, and it is harmful to continue arbitrarily dividing us.
To be clear, I’m not saying that we all need to be experts in everything. That would be impossible. Today’s technology stack goes down a long way, so being a genuinely balanced full-stack dev is probably not the most realistic of goals — but staying open-minded is. While it is perfectly valid to dislike a particular technology, such as CSS, the industry’s culture of contempt for frontend work feeds into the outdated divide between frontend and backend, and detracts from building fast-moving, competitive teams and companies.
Think of yourself as a developer first. Investigate frontend technologies, pair with UI specialists, evangelize your colleagues. Your team, your company, and your users will thank you.
Thanks to Nathan Zeplowitz, Luke Belliveau, and Robin Weston for their excellent constructive feedback.