The juxtaposition of The HTTP Archive’s analysis and The State of JS 2020 Survey results suggest that a disproportionately small—yet exceedingly vocal minority—of white male developers advocate strongly for React, and by extension, a development experience that favors thick client/thin server architectures which are given to poor performance in adverse conditions. Such conditions are less likely to be experienced by white male developers themselves, therefore reaffirming and reflecting their own biases in their work.
My stack requires no maintenance, has perfect Lighthouse scores, will never have any security vulnerability, is based on open standards, is portable, has an instant dev loop, has no build step and… will outlive any other stack.
Chris is gathering end-of-year thoughts from people in response to the question:
What is one thing you learned about building websites this year?
- First impressions
- The Tab key
- Automated testing tools
- Screen reader testing
- Next steps
More on battling entropy:
Ever needed to change “just a small thing” on an old page you build years ago? I recently had the pleasure and the simple task of changing some colors in CSS lead to a whole day of me wrangling with old deprecated Grunt tasks and trying to get the build task running.
I like this mindset:
Be boring by default and enhance on the way.
This post really highlights one of the biggest issues with the convoluted build tools used for “modern” web development. If you return to a project after any length of time, this is what awaits:
I find entropy staring me back in the face: library updates, breaking API changes, refactored mental models, and possible downright obsolescence. An incredible amount of effort will be required to make a simple change, test it, and get it live.
Take a moment and think about this super power: if you write vanilla HTML, CSS, and JS, all you have to do is put that code in a web browser and it runs. Edit a file, refresh the page, you’ve got a feedback cycle. As soon as you introduce tooling, as soon as you introduce an abstraction not native to the browser, you may have to invent the universe for a feedback cycle.
Maintainability matters—if not for you, then for future you.
The more I author code as it will be run by the browser the easier it will be to maintain that code over time, despite its perceived inferior developer ergonomics (remember, developer experience encompasses both the present and the future, i.e. “how simple are the ergonomics to build this now and maintain it into the future?) I don’t mind typing some extra characters now if it means I don’t have to learn/relearn, setup, configure, integrate, update, maintain, and inevitably troubleshoot a build tool or framework later.
This was an absolute delight to read! Usually when you read security-related write-ups, the fun comes from the cleverness of the techniques …but this involved nothing cleverer than dev tools. In this instance, the fun is in the telling of the tale.
So my little mashup, which was supposed to be just 3 technologies ended up exposing me to ~20 different technologies and had me digging into nth-level dependency source code after midnight.
The technologies within technologies that Dave lists here is like emptying a bag of scrabble pieces.
The “modern” web stack really is quite something—we’ve done an amazing job of taking relatively straightforward tasks and making them complicated, over-engineered, and guaranteed to be out of date in no time at all.
The plumbing and glue code are not my favorite parts of the job. And often, you don’t truly know the limitations of any given dependency until you’re five thousand lines of code into a project. Massive sunk costs and the promise of rapid application development can come screeching to a halt when you run out of short cuts.
I love bookmarklets! I use them every day (I’m using one right now to post this link). Amber does a great job explaining what they are and how you can make one. I really like the way she frames them as your own personal dev tools!
A great little history lesson from Amber—ah, Firebug!
This is a great bit of detective work by Amber! It’s the puzzling case of The Browser Dev Tools and the Missing Computed Values from Custom Properties.
Who do I know working on dev tools for Chrome, Firefox, or Safari that can help Amber find an answer to this mystery?
A good explanation of the hydration problem in tools like Gatsby.
The divide between what you read in developer social media and what you see on web dev websites, blogs, and actual practice has never in my recollection been this wide. I’ve never before seen web dev social media and forum discourse so dominated by the US west coast enterprise tech company bubble, and I’ve been doing this for a couple of decades now.
Baldur is really feeling the dev perception.
Web dev driven by npm packages, frameworks, and bundling is to the field of web design what Java and C# in 2010s was to web servers. If you work in enterprise software it’s all you can see. Web developers working on CMS themes (or on Rails-based projects) using jQuery and plain old JS—maybe with a couple of libraries imported directly via a script tag—are the unseen dark matter of the web dev community.
Brad gets ranty …with good reason.
I’m really enjoying this end-of-the-year round-up from people speaking their brains. It’s not over yet, but there’s already a lot of thoughtful stuff to read through.
Only a few years ago, I would need a whole team of developers to accomplish what can now be done with just a few amazing tools.
And I like this zinger from Geoff:
What you need to build a great website is restraint.
I reckon a lot of websites have bad accessibility not because folks don’t care, but because they don’t know there’s an issue in the first place.
The headline is begging the question (I don’t think accessible websites are so hard to build), but I agree with Robin’s idea:
What if our text editors caught accessibility issues and showed them to us during development?
This is something that Hidde has been talking about recently too, looking at content management systems.
Beyond automatic accessibility testing: 6 things I check on every website I build - Manuel Matuzović
Six steps that everyone can do to catch accessibility gotchas:
- Check image descriptions
- Disable all styles
- Validate HTML
- Check the document outline
- Grayscale mode
- Use the keyboard
- Plan your scripts out on paper.
- Stop obsessing over tools.
- Focus on solving problems.
- Maintain a library of snippets that you can reuse.