Hello. I am Paul Kinlan.

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.

Web compatibility is a major developer concern. While projects like Compat 2021 aim to address these issues, data-driven analysis is crucial for understanding the web's evolving compatibility landscape. This post highlights Browser Compat Data (BCD), a valuable resource from Mozilla that offers detailed compatibility information for web APIs. BCD bridges the gap between raw Web Platform Tests data and user-friendly tools like caniuse.com. I've created a demo app, "The Web Of...", utilizing BCD to visualize API availability across different browsers at specific points in time. This data empowers developers to make informed decisions about API usage, assess compatibility across browser engines, and track the overall progress of web compatibility. The availability of such data opens up possibilities for new metrics like a "CompatIndex" to quantify web compatibility. Contributions to the BCD project are encouraged to further enhance this valuable resource.

As a data-driven manager, I needed a way to track the performance of our team's numerous NPM packages. Frustrated by the lack of an obvious API, I discovered a hidden gem in the NPM registry documentation. Using this, I created a Google Sheet with custom functions to pull download stats directly. The sheet allows you to track both scoped and non-scoped packages, view data in a table or column format, and easily create charts to visualize trends. Check out the linked sheet and accompanying code to build your own NPM downloads dashboard!

We've been using surveys like the MDN Developer Needs Survey and our own quarterly surveys to understand web developer challenges and prioritize our efforts. These surveys highlighted issues like web compatibility, testing, and documentation, leading to improvements like our Web Compat initiative and increased focus on MDN documentation. While valuable, these surveys don't offer granular feedback on specific projects or proposals. Direct feedback is essential, but our current approach is informal and inconsistent. To address this, we've partnered with C SPACE to create the Web Developer Insights Community – a dedicated group of ~1000 web developers who'll provide direct feedback to our questions. This community allows open communication among developers while limiting Chrome team influence. We're excited about this new channel for gathering actionable developer insights and encourage you to join if you're interested.

I integrated the Squoosh CLI into my web app to optimize images. Although Squoosh offers a great CLI, I needed its functionality within my app. Leveraging my experience with FFMPEG in web apps, I adapted the Squoosh CLI code, replacing Node.js dependencies with web APIs. Now, I can call Squoosh's 'run' method directly in my app to resize and compress images. This unofficial solution works for now, but a dedicated browser API would be ideal for broader integration in CMS platforms, performance analysis tools, and other web applications.

Optimizing images for the web is crucial for Core Web Vitals, but the process is overly complex. While tools like Squoosh and web.dev guides offer help, developers still struggle with image optimization. This difficulty stems from needing to consider file size, resolution, codec support, lazy loading, and more. CDNs offer a solution but introduce centralization. To simplify this, I created a prototype tool (https://just-gimme-an-img.vercel.app/) that generates optimized HTML for images, handles AVIF conversion, creates multiple image sizes, and does it all client-side using Squoosh's CLI. The tool aims to make image optimization easier and more accessible, especially for common use cases like hero images. I'm hoping this sparks further discussion and improvements in image optimization tooling to simplify the process for all developers.

I'm sharing my raw, unedited thoughts on modern web development here. Consider this a living document of my ideas, some old, some new, all evolving over time. Expect errors and feel free to provide feedback (@paulkinlan@google.com, @paul_kinlan). The list of ideas will be kept up-to-date below.

I'm excited to announce that I'm starting "Office Hours" to connect directly with web developers. Following a successful run at Chrome Dev Summit, I'm opening my calendar for anyone to schedule a meeting with me. I'm happy to discuss anything from JavaScript, CSS, and performance to career advice. I'm especially eager to connect with developers in underrepresented regions. Book a meeting and let's chat!

I built a simple tool, shortcut.cool, to create custom launchers for Android using the web. It leverages the power of PWAs, service workers, and the web app manifest, specifically the shortcuts feature. The tool allows you to define a set of .new domain shortcuts, which then get encoded into the URL. This URL points to a dynamically generated manifest file that Chrome uses to install the PWA with the specified shortcuts on your home screen. The project is a bit of an experiment and has some limitations, like the inability to update existing PWAs and potential security concerns from URL-encoded data. However, it’s a fun example of how the web can be used to create quick, personalized tools.