Your teams should be working closer to the web platform with a lot less complex abstractions. We need to relearn what the web is capable of and go back to that.
Let’s be clear, I’m not suggesting this is strictly better and the answer to all of your problems. I’m suggesting this as an intentional business tradeoff that I think provides more value and is less costly in the long run.
The paradigm shift that web development is entering hinges on the fact that while React was a key enabler of the Single-Page-App and Component era of the web, in practice it normally tends to result in extremely poor products. Built-in browser APIs are now much more capable than they were when React was first invented.
It’s like CSS exists in some bizarre quantum state; somehow both too complex to use, yet too simple to take seriously, all at once.
In many ways, CSS has greater impact than any other language on a user’s experience, which often directly influences success. Why, then, is its role so belittled?
Writing CSS seems to be regarded much like taking notes in a meeting, complete with the implicit sexism and devaluation of the note taker’s importance in the room.
I might just be pattern-matching, but I recognise myself in what Robin describes here:
No one can explain what you do. Let’s face it, you don’t do a great job explaining it either. People come to you for advice on issues that they introduce with “I’m not entirely sure how to describe this problem or what exactly I’m looking to do here, but…” Your colleagues and your communities genuinely value your contributions even as they remain entirely mystified by the exact contour of your position.
These definitions work for me:
A front-of-the-front-end developer is a web developer who specializes in writing HTML, CSS, and presentational JavaScript code.
A back-of-the-front-end developer is a web developer who specializes in writing JavaScript code necessary to make a web application function properly.
Chris shares his thoughts on the ever-widening skillset required of a so-called front-end developer.
Interestingly, the skillset he mentions half way through (which is what front-end devs used to need to know) really appeals to me: accessibility, performance, responsiveness, progressive enhancement. But the list that covers modern front-end dev sounds more like a different mindset entirely: APIs, Content Management Systems, business logic …the back of the front end.
And Chris doesn’t even touch on the build processes that front-end devs are expected to be familiar with: version control, build pipelines, package management, and all that crap.
I wish we could return to this:
The bigger picture is that as long as the job is building websites, front-enders are focused on the browser.
Look. Observe. See.
I can relate to this.
I’m not trying to convince anyone they aren’t a full-stack developer or don’t deserve that particular merit badge — just that the web is a big place with divergent needs and ever-morphing stacks that all require different sets of skills.
Are many of the modern frontend tools and practices just technical debt in disguise?
Ooh, good question!
An excellent thorough analysis by Chris of the growing divide between front-end developers and …er, other front-end developers?
The divide is between people who self-identify as a (or have the job title of) front-end developer, yet have divergent skill sets.
On one side, an army of developers whose interests, responsibilities, and skill sets are heavily revolved around JavaScript.
On the other, an army of developers whose interests, responsibilities, and skill sets are focused on other areas of the front end, like HTML, CSS, design, interaction, patterns, accessibility, etc.
It’s a terribly clickbaity (and negatively phrased) title, but if you turn it around, there’s some good advcie in here for deciding where to focus when it comes to dev technology:
- Programming languages are different, but design smells are alike.
- Frameworks are different, but the same design patterns shine through.
- Developers are different, but rules of dealing with people are uniform.
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.”
A good ol’ rant from Robin.
HTML and CSS and JavaScript have always been looked down upon by many engineers for their quirks. When they see a confusing and haphazardly implemented API across browsers (HTML/CSS/JS), I see a swarming, writhing, and constantly improving interface that means we can read stuff that was written fifteen years ago and our browsers can still parse it.
Before jumping to conclusions, read the whole thing. Robin isn’t having a go at people who consider themselves full-stack developers; he’s having a go at the people who are only hiring back-end developers and expecting them to automatically be “full stack.”
The technologies you use, the tools you build with, are just that: tools. Learn to use them, and learn to use them well. But always remember that those tools are there to serve you, you are not there to serve your tools.
In the past, when I brushed off new advances or updates to technology and processes I preferred to stick with a simple path of “it still works fine,” but in doing so I realize now that I have l lost a lot beginning with the ability to function with current best practices in certain areas of my skill sets and the degradation a few projects, especially Airbag.
This resonates a lot—we’ve been working on something similar at Clearleft, for very similar reasons:
We rode the folk knowledge train until it became clear that it was totally unscaleable and we struggled to effectively commute know-how to the incoming brains.
At Made By Many, they’ve sliced it into three categories: Design, Technology, and Product Management & Strategy. At Clearleft, we’re trying to create a skills matrix for each of these disciplines: UX, UI, Dev, Research, Content Strategy, and Project Management. I’m working on the Dev matrix. I’ll share it once we’ve hammered it into something presentable. In the meantime, it’s good to see exactly the same drivers are at work at Made By Many:
The levels give people a scaffold onto which they can project their personalised career path, reflecting their progression, and facilitating professional development at every stage.
Mike lists five tool skills he looks for in a designer (not that every designer needs to have all five):
Swap the first one out for some markup and CSS skills, and I reckon you’ve got a pretty good list for developers too.
Following on from her great conversation with Jen on The Web Ahead podcast, Rachel outlines a strategy to avoid feeling overwhelmed by the deluge of tools, frameworks, libraries, and techniques inundating front-end developers every day:
Learn your core skills well. Understand HTML and CSS, be able to build a layout without leaning on a framework. Get a solid understanding of how a website actually gets from the server to a browser, an understanding of security and accessibility. These are the basics, the constants. These things change slowly. These things sit underneath all the complexity and the tooling, the CMSs and the noise of thousands of people all trying to make their mark on this industry.
She also makes this important point:
As you are doing this don’t forget to share what you know.