To be blunt, I feel we, the folks who have been involved with designing and developing for the web for a significant period of time–including me as I feel a strong sense of personal responsibility here–are in no small part responsible for it falling far short of its promise.
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.
John weighs in on the clashing priorities of browser vendors.
Imagine if the web never got CSS. Never got a way to style content in sophisticated ways. It’s hard to imagine its rise to prominence in the early 2000s. I’d not be alone in arguing a similar lack of access to the sort of features inherent to the mobile experience that WebKit and the folks at Mozilla have expressed concern about would (not might) largely consign the Web to an increasingly marginal role.
A trashcan, a tyepface, and a tactile keyboard. Marcin gets obsessive (as usual).
I’ve really come to appreciate that performance isn’t just some property of a tool independent from its functionality or its feature set. Performance — in particular, being notably fast — is a feature in and of its own right, which fundamentally alters how a tool is used and perceived.
This is a fascinating look into how performance has knock-on effects beyond the obvious:
It’s probably fairly intuitive that users prefer faster software, and will have a better experience performing a given task if the tools are faster rather than slower.
What is perhaps less apparent is that having faster tools changes how users use a tool or perform a task.
This observation is particularly salient for web developers:
We have become accustomed to casually giving up factors of two or ten or more with our choices of tools and libraries, without asking if the benefits are worth it.
From Xerox PARC to the World Wide Web:
The internet did not use a visual spatial metaphor. Despite being accessed through and often encompassed by the desktop environment, the internet felt well and truly placeless (or perhaps everywhere). Hyperlinks were wormholes through the spatial metaphor, allowing a user to skip laterally across directories stored on disparate servers, as well as horizontally, deep into a file system without having to access the intermediate steps. Multiple windows could be open to the same website at once, shattering the illusion of a “single file” that functioned as a piece of paper that only one person could hold. The icons that a user could arrange on the desktop didn’t have a parallel in online space at all.
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.
Font metrics help the computer determine things like the default spacing between lines, how high or low sub and super scripts should go, and how to align two differently sized pieces of text next to each other.
Ah, what a wonderful treasure trove this is! PDF scans of Apollo era press kits from a range of American companies.
- Official NASA
- Lunar Module
There’s something so fascinating about the mundane details of Isolation/Quarantine Foods for Apollo 11 Astronauts from Stouffer’s.
A handy browser extension for Chrome and Firefox:
“Hello, Goodbye” blocks every chat or helpdesk pop up in your browser.
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 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.
The sentiment is that front-end development is a problem to be solved: “if we just have the right tools and frameworks, then we might never have to write another line of HTML or CSS ever again!” And oh boy what a dream that would be, right?
Well, no, actually. I certainly don’t think that front-end development is a problem at all.
What Robin said.
I reckon HTML and CSS deserve better than to be processed, compiled, and spat out into the browser, whether that’s through some build process, app export, or gigantic framework library of stuff that we half understand. HTML and CSS are two languages that deserve our care and attention to detail. Writing them is a skill.