I really enjoyed this chat with Marc:
I recently sat down with Jeremy Keith for a spontaneous conversation that quickly turned into a deep dive into something we both care a lot about: events, community, and why we keep putting ourselves through the joy and pain of running conferences.
This episode of the Shop Talk Show is the dictionary definition of “rambling” but I had a lot of fun rambling with Chris and Dave!
Start a blog. Start one because the practice of writing at length, for an audience you respect, about things that matter to you, is itself valuable. Start one because owning your own platform is a form of independence that becomes more important as centralized platforms become less trustworthy. Start one because the format shapes the thought, and this format is good for thinking.
I think this is a terrific idea from Bobbie—be one of 25 people to get a brand new hardcover non-fiction book in the mail for just $25 and then join in the discussion afterwards.
Alas, it’s not available in the UK but US friends, check it out.
This looks like an excellent—and free!—online event centred on privacy and safety. It’s got Eva PenzeyMoog, Robin Berjon and more!
I love this: Terence takes eleven years to reflect on a comment I made on stage at an event here in Brighton. It’s all about the longevity of the web compared to native apps:
If you wrote an app for an early version of iOS or Android, it simply won’t run on modern hardware or software. APIs have changed, SDKs weren’t designed with forward compatibility, and app store requirements have evolved.
The web has none of that. The earliest websites are viewable on modern browsers.
As wrote at the time, I may have been juicing things up for entertainment:
Now here’s the thing when it comes to any discussion about mobile or the web or anything else of any complexity: an honest discussion would result in every single question being answered with “it depends”. A more entertaining discussion, on the other hand, would consist of deliberately polarised opinions. We went for the more entertaining discussion.
But I think this still holds true for me today:
The truth is that the whole “web vs. native” thing doesn’t interest me that much. I’m as interested in native iOS development as I am in native Windows development or native CD-ROM development. On a timescale measured in years, they are all fleeting, transient things. The web abides.
The problem I’ve regularly encountered in my work is that I don’t get to do my job the way I think is best for both me and my employer or client. The employer, who isn’t the web development expert, almost always has a clear idea of what real web development is supposed to look like: Single-Page-Apps and React (or React-like frameworks).
An intimation that it wouldn’t be the right solution for this particular problem is taken as an admission of incompetence.
I’ve experienced this. And I think this observation is even more true when it comes to recruitment.
I’ve already had some thoughtful responses to yesterday’s post about trust. I wrapped up my thoughts with a request:
I would love it if someone could explain why they avoid native browser features but use third-party code.
I can’t speak for the industry, but I have a guess. Third-party code (like the referenced Bootstrap and React) have a history of smoothing over significant cross-browser issues and providing better-than-browser ergonomic APIs. jQuery was created to smooth over cross-browser JavaScript problems. That’s trust.
Very true! jQuery is the canonical example of a library smoothing over the bumpy landscape of browser compatibilities. But jQuery is also the canonical example of a library we no longer need because the browsers have caught up …and those browsers support standards directly influenced by jQuery. That’s a library success story!
Charles Harries takes on my question in his post Libraries over browser features:
I think this perspective of trust has been hammered into developers over the past maybe like 5 years of JavaScript development based almost exclusively on inequality of browser feature support. Things are looking good in 2022; but as recently as 2019, 4 of the 5 top web developer needs had to do with browser compatibility.
Browser compatibility is one of the underlying promises that libraries—especially the big ones that Jeremy references, like React and Bootstrap—make to developers.
So again, it’s browser incompatibilities that made libraries attractive.
Jim Nielsen responds with the same message in his post Trusting Browsers:
We distrust the browser because we’ve been trained to. Years of fighting browser deficiencies where libraries filled the gaps. Browser enemy; library friend.
For example: jQuery did wonders to normalize working across browsers. Write code once, run it in any browser — confidently.
Three for three. My question has been answered: people gravitated towards libraries because browsers had inconsistent implementations.
I’m deliberately using the past tense there. I think Jim is onto something when he says that we’ve been trained not to trust browsers to have parity when it comes to supporting standards. But that has changed.
Charles again:
This approach isn’t a sustainable practice, and I’m trying to do as little of it as I can. Jeremy is right to be suspicious of third-party code. Cross-browser compatibility has gotten a lot better, and campaigns like Interop 2022 are doing a lot to reduce the burden. It’s getting better, but the exasperated I-just-want-it-to-work mindset is tough to uninstall.
I agree. Inertia is a powerful force. No matter how good cross-browser compatibility gets, it’s going to take a long time for developers to shed their suspicion.
Jim is glass-half-full kind of guy:
I’m optimistic that trust in browser-native features and APIs is being restored.
He also points to a very sensible mindset when it comes to third-party libraries and frameworks:
In this sense, third-party code and abstractions can be wonderful polyfills for the web platform. The idea being that the default posture should be: leverage as much of the web platform as possible, then where there are gaps to creating great user experiences, fill them in with exploratory library or framework features (features which, conceivably, could one day become native in browsers).
Yes! A kind of progressive enhancement approach to using third-party code makes a lot of sense. I’ve always maintained that you should treat libraries and frameworks like cattle, not pets. Don’t get too attached. If the library is solving a genuine need, it will be replaced by stable web standards in browsers (again, see jQuery).
I think that third-party libraries and frameworks work best as polyfills. But the whole point of polyfills is that you only use them when the browsers don’t supply features natively (and you also go back and remove the polyfill later when browsers do support the feature). But that’s not how people are using libraries and frameworks today. Developers are reaching for them by default instead of treating them as a last resort.
I like Jim’s proposed design princple:
Where available, default to browser-native features over third party code, abstractions, or idioms.
(P.S. It’s kind of lovely to see this kind of thoughtful blog-to-blog conversation happening. Right at a time when Twitter is about to go down the tubes, this is a demonstration of an actual public square with more nuanced discussion. Make your own website and join the conversation!)
Speaking of hosting your own reading list, Maggie recently attended an indie web pop-up on personal libraries, which prompted these interesting thoughts on decentralised book clubs—ad hoc reading groups:
Taking a book-first, rather than a group-first approach would enable reading groups who don’t have to compromise on their book choices. They could gather only once or twice to discuss the book, then go their seperate ways. No long-term committment to organising and maintaining a bookclub required.
This looks like an excellent (and very reasonably-priced) online event happening on November 12th with three panels:
September 25th, online:
We’ll discuss and brainstorm ideas related to wikis, commonplace books, digital gardens, zettelkasten, and note taking on personal websites and how they might interoperate or communicate with each other. This can include IndieWeb building blocks, user interfaces, functionalities, and everyones’ ideas surrounding these. Bring your thoughts, ideas, and let’s discuss and build.
The French have a wonderful phrase, lesprit de l’escalier. It describes that feeling when you’ve stormed out of the room after an argument and you’re already halfway down the stairs when you think of the perfect quip that you wish you had said.
I had a similar feeling last week but instead of wishing I had said something, I was wishing I had kept my mouth shut.
I have an annoying tendency to want to get the last word in. I don’t have a problem coming up with a barbed quip. My problem is wishing I could take them back.
This happened while I was hosting the conference portion of UX Fest last week. On the hand, I don’t want the discussions to be dull so I try to come up with thought-provoking points to bring up. But take that too far and it gets ugly. There’s a fine line between asking probing questions and just being mean (I’m reminded of headline in The Onion, “Devil’s Advocate Turns Out To Be Just An Asshole”).
Towards the end of the conference, there was a really good robust discussion underway. But I couldn’t resist getting in the last word. In the attempt to make myself look clever I ended up saying something hurtful and clumsy.
Fucking idiot.
I apologised, and it all worked out well in the end, but damn if I haven’t spent the last week on the staircase wishing I could turn back time and say …nothing.
The intent is for this website to be used by self-forming small groups that want to create a “watching club” (like a book club) and discuss aspects of technology history that are featured in this series.
I’m about ready to rewatch Halt And Catch Fire. Anybody want to form a watching club with me?
I’ll be moderating this online panel next week with Emma Boulton, Holly Habstritt Gaal, Jean Laleuf, and Lola Oyelayo-Pearson.
There are still some spots available—it’s free to register. The discussion won’t be made public; the Chatham House Rule applies.
I’m looking forward to it! Come along if you’re interested in the future of design teams.
What will the near-future look like for design teams? Join us as we explore how processes, team structures and culture might change as our industry matures and grows.
Myself and Stuart had a chat with Brian about browser engine diversity.
Here’s the audio file if you’d like to huffduff it.
I see that someone dropped one of my grenades into the toilet bowl of Hacker News.
Did you hear the one about two Irishmen on a podcast?
I really enjoyed this back-and-forth discussion with Gerry on performance, waste, and more. We agreed on much, but we also clashed sometimes.
Join your favorite authors on Zoom where you can have spirited discussions from the privacy of our own quarantined space!
A great initiative from the folks at Mule Design. As well as chatting to talented authors, you can also chat to me: this Thursday at 4pm UTC I’ll be discussing Resilient Web Design.
Jen kicked off a fascinating thread here:
It’s come up quite a few times recently that the world of people who make websites would greatly benefit from the CSS Working Group officially defining ”CSS 4”, and later “CSS 5“, etc.
The level is discourse is impressively smart and civil.
Personally, I don’t (yet) have an opinion on this either way, but I’ll be watching it unfold with keen interest.
Some photos from a lively discussion between Alex Russell and me at View Source in Amsterdam led Remy to create this meme generator.
You can see some results here and here.
This is not to be confused with a certain other photo which has led to its own memification here and here.