I've rejoined Mastodon! Driven by the potential Twitter costs and wanting more control, I'm now self-hosting my instance for about the same price as a Twitter Blue subscription. I'll keep using Twitter for learning, but I'm excited about Mastodon's open, interoperable nature and its excellent PWA. Come find me on Mastodon!

I've created a tool called "Now Stable" using Browser Compat Data (BCD) to help developers determine when web APIs become stable across different browsers. This addresses the challenge of keeping up with browser updates and helps developers confidently choose APIs for their projects. The tool allows users to select their target browsers (e.g., Chrome, Safari, Firefox) and see a chronological list of when APIs became available across those browsers. I'm looking for feedback on how this tool can be improved and how developers would use this data.

This blog post discusses the current state of web API permissions and argues for a more restrictive "off-by-default" approach. It highlights the Principle of Least Privilege and observes that most websites don't utilize Feature Policy or Permissions Policy effectively. The author suggests that instead of asking "what should I turn off?", developers should ask "what should I enable?". The post details the different permission models, the complexity of managing numerous permissions, and the benefits of a deny-all-then-enable approach. It also acknowledges the drawbacks and the need for tooling and guidance to facilitate this shift in thinking. The author concludes by advocating for intentionality in permission management and encouraging a discussion on the topic.

HTML5Rocks, a beloved resource for web developers, is shutting down. This post reflects on the site's history, its impact, and the reasons behind its decline. Key factors include the shift away from "HTML5" as a buzzword, changing team priorities, lack of a focused content plan, and challenges with community management. Despite the shutdown, the author expresses gratitude for the experience and the connections made, highlighting the lessons learned about content creation, developer engagement, and the open-source community.

The Chrome and Web Developer Relations team is significantly expanding in 2022. Open roles span program management, Chrome extensions, CSS, rendering, DevTools, web performance, the Privacy Sandbox, and web ecosystem. The team is seeking program managers, developer relations engineers, technical writers, and infrastructure specialists to contribute to various initiatives, including Chrome Dev Summit, Google I/O, web.dev, and improving the overall web platform.

I'm so excited by the renewed interest in web development sparked by Wordle! It's a simple, fun game that highlights the power of the web. It's accessible, fast, user-friendly, and has inspired countless developers to create their own versions and variations. This post celebrates Wordle's impact, lists various Wordle-inspired projects (including different language versions, framework implementations, and even tools), and encourages readers to share their own discoveries.

I missed the trajectory of React's rise. Blinded by my focus on technical details, I failed to see the bigger picture of market demands and developer needs. I need to improve my ability to identify these trends earlier.

This blog post discusses the top challenges faced by web developers in 2021 based on a quarterly survey. The findings reveal that the top pain points remain consistent with previous years, including browser compatibility, testing, documentation, debugging, framework usage, and security/privacy concerns. The survey data highlights the difficulties developers face in keeping up with evolving web standards and the ever-expanding ecosystem of tools and frameworks. Cross-browser compatibility and testing remain significant hurdles. While initiatives like Compat 2021 aim to address these challenges, their impact is yet to be fully realized. The data consistently shows the need for improved developer tooling and a more streamlined web development experience.

I sincerely apologize to the Safari team for misrepresenting their compatibility score in our Chrome Dev Summit presentation. Due to a combination of personal circumstances, a reliance on outdated Safari Tech Preview data from wpt.fyi, and the rush leading up to the event, we displayed an incorrect improvement score (64 => 85 instead of 64 => 92). This was my mistake, and I take full responsibility. While we attempted to rectify the situation, it was too late to change the presentation. Our intent was never malicious, but rather to highlight the collaborative effort to improve web compatibility. I've learned valuable lessons from this experience: triple-check data, consult with relevant engineers, focus on stable release data, and communicate with browser teams transparently. Going forward, we'll prioritize broad browser support and emphasize the user experience in stable releases.

With Chrome nearing version 100, there's a concern about whether user agent checks relying on "Chrome 10" will break. Analysis of HTTP Archive data suggests this is unlikely, with most instances of "Chrome 10" in JavaScript code being comments or workarounds rather than version checks. While client-side checks seem safe, server-side checks remain a concern, highlighting the need for User Agent Client Hints. If you know of tools that might be affected by the Chrome 100 user agent change, please get in touch.