Dave stops feeding his site’s visitors data to Google. I wish more people (and companies) would join him.
There’s also an empowering #indieweb feeling about owning your analytics too. I pay for the server my analytics collector runs on. It’s on my own subdomain. It’s mine.
What happens when you’re AMP pages are slower than your regular pages …but you’re forced to use AMP anyway if you want to appear in the top stories carousel.
AMP isn’t about speed. It’s about control.
The elephant in the room here is pre-rendering: that’s why Google aren’t using page speed alone as a determining factor for what goes in the carousel.
I would urge front-end developers to take a step back, breathe, and reassess. Let’s stop over engineering for the sake of it. Let’s think what we can do with the basic tools, progressive enhancement and a simpler approach to building websites. There are absolutely valid usecases for SPAs, React, et al. and I’ll continue to use these tools reguarly and when it’s necessary, I’m just not sure that’s 100% of the time.
Wouldn’t it be great if every component in your design system had accessibility acceptance criteria? Paul has some good advice for putting those together:
- Start with accessibility needs
- Don’t be too generic
- Don’t define the solution
- Iterate criteria
document.querySelectorfirst got wide browser support and started to end jQuery’s ubiquity? It finally gave us a way to do natively what jQuery had been providing for years: easy selection of DOM elements. I believe the same is about to happen to frontend frameworks like Angular and React.
The article goes on to give a good technical overview of custom elements, templates, and the Shadow DOM, but I was surprised to see it making reference to the
is syntax for extending existing HTML elements—I’m pretty sure that that is, sadly, dead in the water.
This article by Ian Bogost from a few years back touches on one of the themes in the talk I gave at New Adventures:
“Engineer” conjures the image of the hard-hat-topped designer-builder, carefully crafting tomorrow. But such an aspiration is rarely realized by computing. The respectability of engineering, a feature built over many decades of closely controlled, education- and apprenticeship-oriented certification, becomes reinterpreted as a fast-and-loose commitment to craftwork as business.
This is a bit ranty but it resonates with what I’ve been noticing lately:
I’ve discovered how many others have felt similarly, overwhelmed by the choices we have as modern developers, always feeling like there’s something we should be doing better.
This is a really nice write-up of creating an accessible progressive disclosure widget (a show/hide toggle).
Where it gets really interesting is when Andy shows how it could all be encapsulated into a web component with a progressive enhancement mindset
Not only does the differentiation of terms create a divide within the industry, the term ‘web app’ regularly acts as an excuse for corner cutting and the exclusion of users.
We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.
I think we’re often guilty of assuming that because our tools are great solutions for some things, they’re automatically the solution for everything.
Let’s take a meandering waltz through what other people have to say about simplicity.
A good talk from from Chris Ferdinandi, who says:
A few common gotchas when using BEM, and how to deal with them.
Are many of the modern frontend tools and practices just technical debt in disguise?
Ooh, good question!
Onboarding. Reaching out. In terms of. Synergy. Bandwidth. Headcount. Forward planning. Multichannel. Going forward. We are constantly bombarded and polluted with nonsense speak. These words and phrases snag and attach themselves to our vocabulary like sticky weeds.
Words become walls.
I love this post from Ben on the value of plain language!
We’re not dumbing things down by using simple terms. We’re being smarter.
Read on for the story of the one exception that Ben makes—it’s a good one.
There’s a lot here that ties in with what I was talking about at New Adventures around the rule of least power in technology choice.
I’m not sure if I agree with describing CSS as being state-based. The example that illustrates this—a
:hover style—feels like an exception rather than a typical example of CSS.