Big ol’ Ball o’ JavaScript

Heydon Pickering published a fantastic post called Reluctant Gatekeeping: The Problem With Full Stack. I have about 3 blog post drafts covering similar ground and apparently we see very much eye-to-eye on this, so I thought it might be worthwhile to walk through Heydon’s post and layer on my commentary.

Much of my career as a web designer has been spent, quite happily, working alongside programmers, engineers, people with computer science degrees. In this symbiotic relationship, each party has a secure job with a well-defined role, and gets to work on the thing they are best at and enjoy the most.

I love the picture he paints here. A coding project involves many people working together writing different types of code to create a thing. Historically, roles were more-or-less determined by the languages they coded in. Backend developers tinkered away in PHP, Ruby, Java, and so on, while frontend developers authored HTML, CSS, and JavaScript. Through communication and collaboration, these different worlds meet and a user experience is born.

We all code, because we work on the web, but we code in different ways to achieve different and complementary ends. But that’s not so obvious to someone who doesn’t code at all: it’s easy to think coders are people who do all the code you’re not doing — because, to the untrained eye, all code is the same.

Hear, hear. I’ve written about my own experience with this misunderstanding.

When a previous employer discovered I wrote HTML, CSS, and presentational JavaScript, they moved me to sit with the engineers and back-end developers. Before too long I was being asked, “Hey, Brad. How long is that middleware going to take to build?” and “Can you normalize this database real quick?”

This was the beginning of my years’ long campaign to help people better understand the role of frontend design and to recognize it as a first class citizen of the web design/development process. I’m certainly thankful there are quite a few fellow travelers on this quest.

This misconception has unfortunate consequences, exacerbated by the non-coder often being the one who gets to choose and hire technical staff. The doctrine of capitalism dictates you should squeeze the most value out of the fewest resources. That’s how you make a profit. If you can find wage slaves willing to do All The Codez™, then you can significantly diminish your biggest overhead: people.

I can see full-stack development emerging as a result of capitalistic exploitation, but I tend to chock it up more to a lack of understanding. Think about job postings with their comical spray of languages, buzzwords and technologies. Think about recruiters spamming every frontend developer for an exciting Java opportunity. Earlier in my career, I was on teams where even our project manager didn’t have a good understanding of who does what code and why.

Problematic how? Well, HTML, CSS, JavaScript, Python, C#, and SQL may all be code, but they’re really quite different kinds of code and are suited to different kinds of people. Just taking the frontend technologies: HTML, a metalanguage, is closely associated with language, narrative and meaning: the realm of the writer. CSS codifies form, the purview of the typographer and graphic artist, while JavaScript (client-side in this case, but the real™ programming language to a computer scientist) deals in things like data transmission and events.

I love how Heydon associates each language with its purpose here. And absolutely while all these languages are code, they do wildly different things. This leads to confusion from the outside, which affects the coders themselves. Again, my own experience:

There’s a fundamental misunderstanding that all coding is ultra-geeky programming, which simply isn’t the case. HTML is not a programming language. CSS is not a programming language. But because HTML and CSS are still code, front-end development is often put in the same bucket as Python, Java, PHP, Ruby, C++, and other programming languages. This misunderstanding tends to give many front-end developers, myself included, a severe identity crisis.

“All code is the same” leads to confusion on the outside, which inevitably leads to the practitioners themselves becoming confused, self-doubting, and anxious. Fun!

This is all to say that, if you put someone in charge of all of these things, it’s highly likely they are going to be much weaker in some areas than others (I’m identifying a trend here; there’s no need to comment with “but I can do all the things”, thank you).

It’s tempting to think that being full-stack means giving equal weight to the whole spectrum. But that’s not how things work. It’s impossible to make everything a priority; inevitably things slip between the cracks.

Worse: they’ll tend to have little interest in improving in areas with which they don’t identify or for which they aren’t rewarded.

This is important. When confronted with the fact we can’t know and prioritize everything, we can take two paths. One path is to acknowledge our own weak spots and take steps to remedy them (by collaborating with people who can fill in those weak spots or to educate yourself). Another path is to write off those weak spots as “easy” or not-all-that-important. The former path comes from a standpoint of humility, while the the other path comes from a standpoint of (what could be perceived as) arrogance.

As an inclusive design consultant, one of the most glaring issues with making Full Stack Developers the gatekeepers of all-things-code is the pitiful quality of the HTML output. Most come from a computer science background, and document structure is simply not taught alongside control structure. It’s not their competency, but we still make it their job.

This mirrors my experience as a consultant. The “full-stack only” organizations I’ve encountered are quick to show off a dizzying array of testing suites, build processes, and optimization tools. And their markup and style architecture is almost always lacking (to put it nicely). That’s not to say those suites, processes, and tools aren’t important pieces of the puzzle; it’s just that they’re not the whole puzzle.

I don’t think [CSS-in-JS] makes the actual CSS intrinsically any better or worse — it’s just a different way to write it. But that’s not to say it doesn’t pose a grave cultural issue: Put CSS in JS and anyone who wishes to write CSS now has to know JavaScript. Not just JavaScript, but —most likely—the specific ‘flavor’ of JavaScript called React. That’s gatekeeping, first of all, but the worst part is the JavaScript aficionado didn’t want CSS on their plate in the first place.

This is well stated. I’ve gotten piled on for poking fun at the CSS-in-JS beehive (which is why Dave Rupert lovingly referred to me as “Beehive Brad”). It’s a different way of doing things, but yeah the technical differences aren’t huge.

Heydon rightfully points out that the real issue is that by sucking CSS into the big ol’ ball of JavaScript, suddenly anyone who isn’t skilled at JS is discouraged or locked out from contributing. CSS is a relatively friendly, approachable, readable language (I could ask my mailman to guess what background-color: blue does and he’d probably guess right), but by sucking styling into these complex JavaScript ecosystems we lose that approachability.

Modern JavaScript environments are intimidating, and it’s taken me a good long time to feel competent working within them. And that’s coming at this from 11 years as a professional web developer. I love CSS because it is a forgiving and readable, which makes it a great introduction to code for designers and other non-programmer team members. But with style blocks appearing next to componentDidMount(), linters yelling at you, and the whole build blowing up because you forgot to camelCase a style attribute doesn’t exactly lead to a welcoming environment for non-programmers.

While there are some gleeful Full Stack Developers, many are computer scientists given too many responsibilities, and over things for which they are not willing or qualified to be held accountable.

I agree with this. Heydon says a full-stack developer is “in practice, a computer scientist who also writes HTML and CSS” and I agree.

We need to address the undervaluing of HTML and CSS for what it is: gender bias. Even though we wouldn’t have computer science without pioneering women, interloping men have claimed it for themselves. Anything less than ‘real programming’ is now considered trivial, silly, artsy, female. That attitude needs to eat a poisoned ass.

This is an interesting point. I’d love to hear some other perspectives on this, but I’ll say from my own experience that when I’ve discussed my own struggles or poked fun at technology, the inevitable dog-pile that results is exclusively made up of men. It’s important to be able to talk openly and honestly about how this field can be hard, so this attitude (whether real or perceived) has negative effects:

When I talk about this stuff, I have a lot of people — even seasoned, prominent people — quietly whisper to me, “I think this stuff is hard too.” There’s something very depressing about that. I believe that openness and sharing is what makes the web industry amazing, which is why it’s unsettling that these conversations increasingly feel like they’re driven underground. It’s especially depressing when women and people of color tell me now they especially don’t want to say anything too loudly.

So yeah. Whether it’s explicit gender bias or not, it’s important to recognize that people are afraid to speak up about how they feel for fear of getting dog-piled on by a bunch of “real” developers. That needs to change.

One Big Ol’ Ball O’ JavaScript

Maybe this isn’t really about full-stack or backend vs frontend or any of that. Maybe it’s about the fact that this is all playing out inside of one language. Here’s Heydon’s last two points:

We need to revisit the separation of concerns principle. We simple can’t afford for people to have to know everything just to do something. It’s good that we conceptualize designs in terms of self-contained components now, but that can be a mental model without being a technology-specific land-grab.

Most of all, we need to educate people who don’t code at all just how many different things different types of code can do, and how different each is to understand and write. Hopefully, this way, more of us will be writing the kind of code that suits us best, and not spending our time anxious and demoralized because we don’t know what we’re doing.

I think it’s really challenging to talk about separation of concerns and that different code does different things when all the code is happening in JavaScript. I’m reminded of Atwood’s Law:

Any application that can be written in JavaScript, will eventually be written in JavaScript.

It’s fair to say that’s happening. But it seems like we’re taking it a step further:

Any code that can be written will eventually be written in JavaScript.

Backend logic? JavaScript. Styles? We do that in JavaScript now. Markup? JavaScript. Anything else? JavaScript.

Historically, different languages suggested different roles. “This language does style.” “This language does structure.” But now it’s “This JavaScript does style.” “This JavaScript does structure.” “This JavaScript does database queries.”

I’m confident developers will get their heads around it. They’ll figure out their swim lanes and understand which JavaScript does what. I’m more concerned about other team members who are now staring at a Big Ol’ Intimidating Ball O’ JavaScript. And I’m concerned for those recruiters and hiring managers who are even further removed from the day to day. Those job listings with a giant spray of buzzwords and technologies can now be winnowed down to a single word: JavaScript. Those recruiters have a hard enough time separating Java from JavaScript, so best of luck to them making sense of the complex JavaScript ecosystem.

How can we as an industry paint a nuanced picture of what goes into creating a successful web project when It’s All JavaScript? I feel that story is hard to tell. It’s definitely not impossible, but I think how to go about it is worth discussing.

In any case, thanks to Heydon for writing a really insightful post.