Tag: web platform

I have been playing with Declarative Partial Updates in Chrome, a small new primitive that lets the server mark a region of a page and later stream a template that replaces it. It turns out a lot of the things we reach for a framework to do, live regions, streaming SSR, islands, even an HTMX-style experience, fall out of it with little or no client-side JavaScript. So I built a pile of demos and started wondering out loud whether we still need the virtual DOM.

A run of recent posts on aifoc.us that I did not plan as a series but which turned into one. The thread is that the web a model sees is staler and thinner than the one you ship, and I have mostly been trying to find ways to see it.

ua-tracer is a tiny site that attempts to show you what a user agent fetches, follows, and executes when it loads a page. I built it because we have almost no visibility into what bots and AI agents actually see when they crawl the web.

Where my head is at with LLMs and the future of the web... Quite focused actually.

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 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.

This post discusses the importance of developer satisfaction, particularly for web developers, and how the MDN Web Developer Needs Assessment has influenced Chrome's web platform priorities for 2020. My hypothesis is that improving the web platform will lead to increased developer satisfaction, more content creation, and happier end-users. Based on the MDN survey data, key areas for improvement include browser compatibility, testing, documentation, debugging, framework integration, and privacy & security. Chrome is committed to working with the web ecosystem to address these challenges and increase developer productivity and satisfaction. We'll share more specific plans in the coming weeks and welcome your feedback on these focus areas and how Chrome can better engage with the developer community.

How should Web and Chrome Developer Relations work?

It's the end of the road for Flash and plugins on the web, what do we do now on the web?

This post explores the concept of "reverse polyfilling" – creating polyfills for features removed from web browsers. I argue that as the web platform matures, pruning less-used features is necessary for performance and maintainability. While this might seem disruptive to developers, reverse polyfills, combined with the principles of the Extensible Web, offer a solution. By focusing on core primitives and building higher-level features with JavaScript (potentially leveraging technologies like WebAssembly), we can create a more adaptable and efficient web platform. Reverse polyfills will become essential for both removing legacy features and implementing new ones, contributing to a progressively enhanced web experience.

Best pratices for web development defined and delivered

This is the web platform

The Modern Web shown