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.
An insightful and incisive appraisal of technology adoption. This truth hits hard:
React and the component model standardises the software developer and reduces their individual bargaining power excluding them from a proportional share in the gains. Its popularity among executives and management is entirely down to the fact that it helps them erase the various specialities – CSS, accessibility, standard JavaScript in the browser, to name a few – from the job market. Those specialities might still exist in practice – as ad hoc and informal requirements during teamwork – but, as far as employment is concerned, they’re such a small part of the overall developer job market that they might as well be extinct.
I get it. React feels good and it’s sticky. But all frameworks eventually fizzle out.
Thanks to Web Components, large companies are realizing you don’t need to rebuild buttons and other UI primitives every few years. Teams don’t need to argue about frameworks anymore. You can have your cake and eat it too!
I think this may be the best long-term argument for web components:
Any org that goes all in on a single framework will eventually find themselves swimming upstream to hire talent to maintain legacy code and avoid framework rot. But you can reduce this burden (and the associated costs) by using Web Components in your design system.
Are you a web dev that’s into progressive enhancement, accessibility, design systems, and all that good stuff?
You should come and work with me at Clearleft.
The value you want form a CSS expert is their CSS, not their JavaScript, so it’s absurd to make JavaScript a requirement.
Absolutely spot on! And it cuts both ways:
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.
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.”
I recently put the call out for freelance front-end devs on Twitter, and my experience mirrors Chris’s.
Not having a personal website was a turn-off. I don’t know if it matters industry-wide or not, but I’m one person with my own opinions and I’m the one making the call so it mattered here. A personal website is the clearest place I can get a sense of your taste, design ability, and writing ability.
This is a fun—and useful—way of improving the interview process. The Rubik’s Cube examples brought a smile to my face.
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.