Van11y (for Vanilla-Accessibility) is a collection of accessible scripts for rich interfaces elements, built using progressive enhancement and customisable.
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 in an intriguing promise (there’s no code yet):
A PWA typically requires writing a service worker, an app manifest and a ton of custom code. Progressier flattens the learning curve. Just add it to your html template — you’re done.
My name is Jeremy Keith and I endorse this message:
I love the modern JS platform (the stuff the browser does for you), and hate modern JS tooling.
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 is a superb twenty minute presentation by Trys! It’s got everything: a great narrative, technical know-how, and a slick presentation style.
Conference organisers: you should get Trys to speak at your event!
I’d like to see more of this thinking – maybe we could call it the future owners test – in contemporary responsible tech work. We mustn’t get so wrapped up in today that we overlook tomorrow.
This is a great way to use a service worker to circumvent censorship:
After the visitor opens the website once over a VPN, the service worker is downloaded and installed. The VPN can then be disabled, and the service worker will take over to request content from non-blocked servers, effectively acting as a proxy.
A great presentation on taking a sensible approach to web development. Great advice, as always, from the blogging machine that is Chris Ferdinandi.
The web is a bloated, over-engineered mess. And, according to developer and educator Chris Ferdinandi, many of our modern “best practices” are actually making the web worse. In this talk, Chris explores The Lean Web, a set of principles for a simpler, faster world-wide web.
A spot-on summary of where we’ve ended up with web components.
Web Components had so much potential to empower HTML to do more, and make web development more accessible to non-programmers and easier for programmers.
Somewhere along the way, the space got flooded by JS frameworks aficionados, who revel in complex APIs, overengineered build processes and dependency graphs that look like the roots of a banyan tree.
Alas, that’s true. Lea wonders how this can be fixed:
I’m not sure if this is a design issue, or a documentation issue.
I worry that is a cultural issue.
Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”.
This is an excellent new tool for showing exactly what kind of tracking a site is doing:
Who is peeking over your shoulder while you work, watch videos, learn, explore, and shop on the internet? Enter the address of any website, and Blacklight will scan it and reveal the specific user-tracking technologies on the site—and who’s getting your data. You may be surprised at what you learn.
Best of all, you can inspect the raw data and analyse the methodology.
There are some accompanying explainers:
This is such an excellent presentation! It really resonates with me.
Kyle Jacobson is a developer who’s been working with the web for over 10 years, and he talks about lessons from the past that can make the future of the web not only easier to develop using battle-tested technologies, but also one friendlier for humans.
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.
RFC 8890 maybe the closest thing we’ve got to a Hippocratic oath right now.
A community that agrees to principles that are informed by shared values can use them to navigate hard decisions.
Many discussions influenced this document, both inside and outside of the IETF and IAB. In particular, Edward Snowden’s comments regarding the priority of end users at IETF 93 and the HTML5 Priority of Constituencies were both influential.
This is a really good description of the role of a front-end developer.
That’s front end, not full stack.
Before the hagiographical praise for working with an iPad Pro, Robin nails the fundamental shape of the design process:
I had forgotten that there are two modes of design, just as there is in writing.
The first mode is understanding the problem, getting a ten-thousand foot view of the land. It’s getting people to acknowledge that this really is the problem we need to agree upon. This work needs to happen in a sketchbook in the form of messy, back-of-the-napkin drawings or in writing. All this helps you to form a proper argument and focus your thoughts.
The second mode of design is taking that ten-thousand foot view and zooming all the way in to the hairs on the back of the rabbit; figuring out the precise UI and components, the copywriting, the animations, the everything else. This should be done in a design tool like Figma or Sketch. And this is when we should be talking about color palettes, icons, design systems, and consistency.
The problem with almost all design work is that first phase never really happens. People don’t take that ten thousand foot view of the problem and are focusing instead on the pixels; they’re trapped by the system they know too well.
Yes, yes, yes! Spot on:
I think people get stuck in that second mode because productivity in design is often tied to “how many pages or frames did I design today?” when productivity should instead be thought of as “how did my understanding of the problem change?
A wonderful introduction to the indie web—Ana really conveys her sense of excitement!