Split

When I talk about evaluating technology for front-end development, I like to draw a distinction between two categories of technology.

On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with.

On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript: pre-processors, post-processors, transpilers, bundlers, and other build tools.

Personally, I’m much more interested and excited by the materials than I am by the tools. But I think it’s right and proper that other developers are excited by the tools. A good balance of both is probably the healthiest mix.

I’m never sure what to call these two categories. Maybe the materials are the “external” technologies, because they’re what users will interact with. Whereas all the other technologies—that mosty live on a developer’s machine—are the “internal” technologies.

Another nice phrase is something I heard during Chris’s talk at An Event Apart in Seattle, when he quoted Brad, who talked about the front of the front end and the back of the front end.

I’m definitely more of a front-of-the-front-end kind of developer. I have opinions on the quality of the materials that get served up to users; the output should be accessible and performant. But I don’t particularly care about the tools that produced those materials on the back of the front end. Use whatever works for you (or whatever works for your team).

As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs. And in any case, those two needs don’t even come into conflict most of the time. Like I said, from a user’s point of view, it’s irrelevant what text editor or version control system you use.

Now, you could make the argument that anything that is good for developer convenience is automatically good for user experience because faster, more efficient development should result in better output. While that’s true in theory, I highly recommend Alex’s post, The “Developer Experience” Bait-and-Switch.

Where it gets interesting is when a technology that’s designed for developer convenience is made out of the very materials being delivered to users. For example, a CSS framework like Bootstrap is made of CSS. That’s different to a tool like Sass which outputs CSS. Whether or not a developer chooses to use Sass is irrelevant to the user—the final output will be CSS either way. But if a developer chooses to use a CSS framework, that decision has a direct impact on the user experience. The user must download the framework in order for the developer to get the benefit.

So whereas Sass sits at the back of the front end—where I don’t care what you use—Bootstrap sits at the front of the front end. For tools like that, I don’t think saying “use whatever works for you” is good enough. It’s got to be weighed against the cost to the user.

Historically, it’s been a similar story with JavaScript libraries. They’re written in JavaScript, and so they’re going to be executed in the browser. If a developer wanted to use jQuery to make their life easier, the user paid the price in downloading the jQuery library.

But I’ve noticed a welcome change with some of the bigger JavaScript frameworks. Whereas the initial messaging around frameworks like React touted the benefits of state management and the virtual DOM, I feel like that’s not as prevalent now. You’re much more likely to hear people—quite rightly—talk about the benefits of modularity and componentisation. If you combine that with the rise of Node—which means that JavaScript is no longer confined to the browser—then these frameworks can move from the front of the front end to the back of the front end.

We’ve certainly seen that at Clearleft. We’ve worked on multiple React projects, but in every case, the output was server-rendered. Developers get the benefit of working with a tool that helps them. Users don’t pay the price.

For me, this question of whether a framework will be used on the client side or the server side is crucial.

Let me tell you about a Clearleft project that sticks in my mind. We were working with a big international client on a product that was going to be rolled out to students and teachers in developing countries. This was right up my alley! We did plenty of research into network conditions and typical device usage. That then informed a tight performance budget. Every design decision—from web fonts to images—was informed by that performance budget. We were producing lean, mean markup, CSS, and JavaScript. But we weren’t the ones implementing the final site. That was being done by the client’s offshore software team, and they insisted on using React. “That’s okay”, I thought. “React can be used server-side so we can still output just what’s needed, right?” Alas, no. These developers did everything client side. When the final site launched, the log-in screen alone required megabytes of JavaScript just to render a form. It was, in my opinion, entirely unfit for purpose. It still pains me when I think about it.

That was a few years ago. I think that these days it has become a lot easier to make the decision to use a framework on the back of the front end. Like I said, that’s certainly been the case on recent Clearleft projects that involved React or Vue.

It surprises me, then, when I see the question of server rendering or client rendering treated almost like an implementation detail. It might be an implementation detail from a developer’s perspective, but it’s a key decision for the user experience. The performance cost of putting your entire tech stack into the browser can be enormous.

Alex Sanders from the development team at The Guardian published a post recently called Revisiting the rendering tier . In it, he describes how they’re moving to React. Now, if this were a move to client-rendered React, that would make a big impact on the user experience. The thing is, I couldn’t tell from the article whether React was going to be used in the browser or on the server. The article talks about “rendering”—which is something that browsers do—and “the DOM”—which is something that only exists in browsers.

So I asked. It turns out that this plan is very much about generating HTML and CSS on the server before sending it to the browser. Excellent!

With that question answered, I’m cool with whatever they choose to use. In this case, they’re choosing to use CSS-in-JS (although, to be pedantic, there’s no C anymore so technically it’s SS-in-JS). As long as the “JS” part is JavaScript on a server, then it makes no difference to the end user, and therefore no difference to me. Not my circus, not my monkeys. For users, the end result is the same whether styling is applied via a selector in an external stylesheet or, for example, via an inline style declaration (and in some situations, a server-rendered CSS-in-JS solution might be better for performance). And so, as a user-centred developer, this is something that I don’t need to care about.

Except…

I have misgivings. But just to be clear, these misgivings have nothing to do with users. My misgivings are entirely to do with another group of people: the people who make websites.

There’s a second-order effect. By making React—or even JavaScript in general—a requirement for styling something on a web page, the barrier to entry is raised.

At least, I think that the barrier to entry is raised. I completely acknowledge that this is a subjective judgement. In fact, the reason why a team might decide to make JavaScript a requirement for participation might well be because they believe it makes it easier for people to participate. Let me explain…

It wasn’t that long ago that devs coming from a Computer Science background were deriding CSS for its simplicity, complaining that “it’s broken” and turning their noses up at it. That rhetoric, thankfully, is waning. Nowadays they’re far more likely to acknowledge that CSS might be simple, but it isn’t easy. Concepts like the cascade and specificity are real head-scratchers, and any prior knowledge from imperative programming languages won’t help you in this declarative world—all your hard-won experience and know-how isn’t fungible. Instead, it seems as though all this cascading and specificity is butchering the modularity of your nicely isolated components.

It’s no surprise that programmers with this kind of background would treat CSS as damage and find ways to route around it. The many flavours of CSS-in-JS are testament to this. From a programmer’s point of view, this solution has made things easier. Best of all, as long as it’s being done on the server, there’s no penalty for end users. But now the price is paid in the diversity of your team. In order to participate, a Computer Science programming mindset is now pretty much a requirement. For someone coming from a more declarative background—with really good HTML and CSS skills—everything suddenly seems needlessly complex. And as Tantek observed:

Complexity reinforces privilege.

The result is a form of gatekeeping. I don’t think it’s intentional. I don’t think it’s malicious. It’s being done with the best of intentions, in pursuit of efficiency and productivity. But these code decisions are reflected in hiring practices that exclude people with different but equally valuable skills and perspectives.

Rachel describes HTML, CSS and our vanishing industry entry points:

If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged.

I think there’s a comparison here with toxic masculinity. Toxic masculinity is obviously terrible for women, but it’s also really shitty for men in the way it stigmatises any male behaviour that doesn’t fit its worldview. Likewise, if the only people your team is interested in hiring are traditional programmers, then those programmers are going to resent having to spend their time dealing with semantic markup, accessibility, styling, and other disciplines that they never trained in. Heydon correctly identifies this as reluctant gatekeeping:

By assuming the role of the Full Stack Developer (which is, in practice, a computer scientist who also writes HTML and CSS), one takes responsibility for all the code, in spite of its radical variance in syntax and purpose, and becomes the gatekeeper of at least some kinds of code one simply doesn’t care about writing well.

This hurts everyone. It’s bad for your team. It’s even worse for the wider development community.

Last year, I was asked “Is there a fear or professional challenge that keeps you up at night?” I responded:

My greatest fear for the web is that it becomes the domain of an elite priesthood of developers. I firmly believe that, as Tim Berners-Lee put it, “this is for everyone.” And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.

I’ve described a number of dichotomies here:

  • Materials vs. tools,
  • Front of the front end vs. back of the front end,
  • User experience vs. developer experience,
  • Client-side rendering vs. server-side rendering,
  • Declarative languages vs. imperative languages.

But the split that worries the most is this:

  • The people who make the web vs. the people who are excluded from making the web.

Have you published a response to this? :

Responses

Hidde

‘For me, this question of whether a framework will be used on the client side or the server side is crucial.’ – @adactio on tech choices for which users pay the price vs those for which they don’t adactio.com/journal/15050

# Posted by Hidde on Wednesday, April 10th, 2019 at 3:22pm

Max Böck

This hits close to home for me. My pain with CSS-in-JS is not with JavaScript, it’s with client side rendering. As long as DX doesn’t come at the user’s expense: use whatever you like! 👍 adactio.com/journal/15050

# Posted by Max Böck on Wednesday, April 10th, 2019 at 4:27pm

Nick Dunn

Oh @adactio has nailed it again. On rendering, styling, the developer experience, performance, caring about your users and keeping the barrier-to-entry for building the web lower than tech bros.adactio.com/journal/15050

# Posted by Nick Dunn on Wednesday, April 10th, 2019 at 5:20pm

Chris Taylor

Jeremy, once again, explains what’s in my head better than I ever could.

Mark

Still thinking about this,adactio.com/journal/15050 Development tooling, right to repair, etc… they all come from good places but drawing the line between progress and dangerous complexity is hard.

# Posted by Mark on Thursday, April 11th, 2019 at 6:10pm

Nick F

Here @adactio eloquently expresses a lot of concerns I share about the current state of front-end development - in particular, trade-offs around developer vs user experience, and complexity as (often unintentional) gatekeepingadactio.com/journal/15050

# Posted by Nick F on Thursday, April 11th, 2019 at 8:42pm

Justin McDowell

Materials vs. tools. User experience vs. developer experience. Client-side rendering vs. server-side rendering. Front of the front end vs. back of the front end. Just a few of the many dichotomies on the web, and they themselves are an interconnected web: adactio.com/journal/15050

CSS-Tricks

On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with. On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript.adactio.com/journal/15050

# Posted by CSS-Tricks on Thursday, April 11th, 2019 at 11:17pm

giglobus j

css: On the one hand, you’ve got the raw materials of the web: HTML, CSS, and JavaScript. This is what users will ultimately interact with. On the other hand, you’ve got all the tools and technologies that help you produce the HTML, CSS, and JavaScript.adactio.com/journal/15050

# Posted by giglobus j on Thursday, April 11th, 2019 at 11:21pm

Craig Buckler

Essential reading for web developers by @adactio: adactio.com/journal/15050 “The performance cost of putting your tech stack into the browser can be enormous.” “By making React [or JavaScript] a requirement for styling something on a web page, the barrier to entry is raised.”

Tom Tinkerson

go read this thoughtful piece by @adactio I consider myself a frontend-designer, since I’m neither full stack (according to the CS view), nor front-of-frontend, but also not back-of-frontend only. but labels aside, I do care about the UX over DEVX.adactio.com/journal/15050

Dion Almaer

“Personally, I’m much more interested and excited by the materials than I am by the tools. But I think it’s right and proper that other developers are excited by the tools. A good balance of both is probably the healthiest mix.” Welcome, the tent is large adactio.com/journal/15050

mkirkpat

Great article summarising state of things, associated concerns, across building people-centred services from a developer pov…good to learn as someone who is not a dev, but is interested in code, leaness, inclusivity, openness in everything we build adactio.com/journal/15050

# Posted by mkirkpat on Friday, April 12th, 2019 at 9:37pm

Ignacio Villanueva

Split: “When I talk about evaluating technology for front-end development, I like to draw a distinction between two categories of technology. HTML, CSS, and JavaScript. This is what users will ultimately interact with.”adactio.com/journal/15050

Martin Thiemann

“In order to participate, a Computer Science programming mindset is now pretty much a requirement. For someone coming from a more declarative background—with really good HTML and CSS skills—everything suddenly seems needlessly complex.” adactio.com/journal/15050

@[email protected]

Of the many things to praise about @adactio’s new piece, one thing in particular I want to highlight is it helps to illustrate that progressive enhancement is good not just because it benefits users but also because it helps minimize needless complexity. adactio.com/journal/15050

James Young

Adactio: Journal—Split: “If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged.” adactio.com/journal/15050 by @adactio

Marco Hengstenberg

Herr @adactio Keith, I love your article!adactio.com/journal/15050 This is such an important article and most important to me is the final sentence: “But the split that worries the most is this: • The people who make the web vs. the people who are excluded from making the web.”

John Ossoway

Really interesting article from @adactio, grappling with interesting and important concepts around making the web. I’ve been trying to describe “front of the front end vs. back of the front end” for years, and finally here is the phrase I was looking for!adactio.com/journal/15050

Peter Chapman

Experiencing some real pain learning (unsuccessfully so far) styling in a JS environ (LitHTML), I appreciate this: adactio.com/journal/15050 Like my young daughter struggling over a new flip routine, I’m currently stumped.

Trinity Takei

How to Think Like a Front-End Developer by Chris Coyier | buff.ly/2UvoB4J “You could imagine two people called front-end developers meeting, and having nothing in common to talk about” — @adactio@chriscoyier calls this a “front-end identity crisis”.

Zach Leatherman

“Maybe the materials are the ‘external’ technologies, because they’re what users will interact with. Whereas all the other technologies—that mostly live on a developer’s machine—are the ‘internal’ technologies.”—@adactio writes:adactio.com/journal/15050

Adam Tomat

Absolutely love this article by @adactio “As a user-centred developer, my priority is doing what’s best for end users. That’s not to say I don’t value developer convenience. I do. But I prioritise user needs over developer needs.” Go read it 👇adactio.com/journal/15050

azu

Complexity reinforces privilege 複雑さは特権を強化する。 ReactやSSRなどフレームワークやツールによって二分されていく傾向が続いたばあいの問題 “Adactio: Journal—Sp…” adactio.com/journal/15050

# Posted by azu on Monday, May 6th, 2019 at 2:39pm

Matthew Cox

Interesting thoughts by @adactio on keeping the maker/hacker presence of the web instead of limiting ability-to-create to those with a CS degree. I totally agree, we should work to make it so that anyone with a text editor can create for the web. adactio.com/journal/15050

2 Shares

# Thursday, April 11th, 2019 at 7:41pm

# Shared by Aleksi Peebles on Saturday, April 13th, 2019 at 10:40am

5 Likes

# Liked by Trys Mudford on Thursday, April 11th, 2019 at 3:52am

# Friday, April 12th, 2019 at 12:40pm

# Liked by Sebas on Friday, April 12th, 2019 at 6:20pm

# Liked by Aleksi Peebles on Saturday, April 13th, 2019 at 10:54am

# Liked by Léonard Messier on Monday, May 6th, 2019 at 10:00am

2 Bookmarks

# Bookmarked by Chris Aldrich on Thursday, April 11th, 2019 at 1:31pm

# Bookmarked by Calum Ryan on Thursday, April 11th, 2019 at 10:59pm