Hello.

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!

This post discusses the challenges web developers face due to the constantly evolving web platform. It highlights the difficulty in keeping up with changes, browser inconsistencies, and the lack of clear documentation. It then outlines the efforts made to address these issues, focusing on improving communication about the web platform, enhancing compatibility and interoperability across browsers (Compat 2021, Interop 2022), and investing in better documentation like MDN's Browser Compat Data. These initiatives aim to create a more stable and predictable web development experience, fostering innovation.

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.

This post discusses Progressive Web Apps (PWAs) and why companies like Microsoft and Google are embracing them. While PWAs offer instant access to content and cross-device compatibility, a key concern is their isolated nature, making it difficult for them to share data and resources. This contradicts the core principles of the web, which should be linkable and interoperable. The increasing isolation of PWAs, along with the broken functionalities of basic web operations like copy/paste and drag/drop, contributes to the creation of unintended data silos on the modern web.

I've been exploring solutions to connect web apps and overcome the limitations of isolated experiences. Web Intents was a good start, but ultimately fell short. The Share API helps, but we need a more general solution for IPC and service discovery. My latest experiment builds on the Tasklets API and Comlink, allowing seamless communication between windows and web workers. It simplifies the complex postMessage API and makes it easy to expose and consume APIs across different contexts. I've created a service discovery mechanism where a 'middleman' site keeps track of available services. Clients can request services based on criteria, and the middleman facilitates the connection. Once connected, the client and service communicate directly, bypassing the middleman. This approach simplifies the developer experience and makes it much easier to build interconnected web experiences. Check out the demos and let me know your thoughts!

It's nearly impossible to get consistent get data in and out of a web app on the client

Web Components, specifically Custom Elements, offer exciting possibilities for web development. However, the current ecosystem is still evolving and has potential downsides. The practice of namespacing custom elements (e.g., <amp-*>, <iron-*>) creates "walled gardens" that can lock developers into specific frameworks. While understandable in the early stages, this approach hinders interoperability and leads to duplicated functionality. Ideally, we should move towards a shared vocabulary of elements (like <aspect-image>) where developers choose the implementation, not the vendor-specific element name. This requires a standardized process for defining element names, interfaces, and functionality. Imagine a world where component creators define the contract (e.g., class ShareButton extends HTMLElement { ... }) and users choose their preferred implementation. This model puts developers in control and fosters a more open and interoperable web. Furthermore, meta platforms (like Facebook or WeChat) could play a role by intercepting customElements.define calls and replacing JavaScript elements with native implementations when possible. This approach requires careful consideration, but it could lead to a more streamlined and integrated user experience.

Wrinkles, Crinkles and lumpy bits.

I'm still passionate about making web apps easily discoverable and interlinked, even though Web Intents didn't take off as I'd hoped. We web developers boast about the power of the URL, but we're not leveraging it effectively for inter-app linking, which is hindering the web's potential. Recent experiences building a QR code reader and seeing how other apps integrate them highlighted this issue. The web's strength is its zero-install nature, allowing instant access to functionality. However, many web apps erect barriers like landing pages and login forms, negating this advantage. These barriers act like app store install pages, killing the linkability and ease of use that makes the web great. While capturing user data is important, we need to prioritize frictionless usage, perhaps by adopting concepts like "tourist" or "shadow" user accounts. Native apps are exploring app constellations, while we on the web already have the tools but aren't utilizing them effectively. We must allow users instant access if we want truly linkable web apps.