Two years and counting at Google
It's been an incredible two years at Google! The first year was amazing, but the second year was even better. I spoke at Google IO, traveled to numerous countries giving presentations, and saw Web Intents become a real project. I even got misquoted on TechCrunch! I also spent more time in Liverpool and worked with developers throughout the UK. I'm excited about the future and continuing to improve the user experience on the web. Read More
I lead the Chrome Developer Relations team at Google.
We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.
Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.
I love to learn about what you are building, and how I can help with Chrome or Web development in general, so if you want to chat with me directly, please feel free to book a consultation.
I'm trialing a newsletter, you can subscribe below (thank you!)
Web Intents: A fresh look
Web Intents is a new project designed to solve the problem of web application integration. Inspired by Android's intent system, it allows developers to build features without needing to integrate with every possible 3rd party service. Web Intents lets users choose their preferred service for actions like image editing or sharing. The project has been revised with a simplified API to make integration easier for developers, requiring minimal code. Service registration is done via a new tag, and client initiation is also streamlined. Check out the examples at http://examples.webintents.org/ and share your thoughts as we work with Mozilla to refine this game-changing approach to web development. Read More
window.name
This post discusses how to use window.name
for cross-domain communication between windows/iframes, especially before the onload event. It explains a simple method using window.open
to set the name and retrieve it in the opened window. It also addresses IE compatibility issues by base64 encoding/decoding the data and provides code snippets for both encoding and decoding, handling IE's character restrictions and lack of built-in base64 functions.
Read More
WebMessaging is broken
WebMessaging (postMessage) seems simple but has quirks. Different browsers handle data differently (structured clones vs. strings). The biggest problem is sending messages to a newly opened window/iframe. You can't just send a message immediately; you have to wait for the window to load and signal back. This adds complexity, requiring the new window to postMessage back to the opener, which then sends the actual data. A workaround involves passing data via window.name, but this has security implications as the data's origin is uncertain and the name persists, potentially exposing data. Read More
Landing my first WebKit patch. OnPopState Lock and Load.
I found and fixed a bug in WebKit! My LeviRoutes framework needed to simulate 'onpopstate' events for testing, but WebKit's createEvent(\"PopStateEvent\")
was broken. After some digging in the WebKit source code, I found the problem in Document.cpp, added the missing PopStateEvent handling, created a test case, and submitted a patch. It got reviewed and accepted! Now my fix is part of WebKit, used by tons of people, and I can finally get back to LeviRoutes.
Read More
HTML5 History needs another event
I love the HTML5 History API, it makes developing applications with a consistent URL scheme across server and client super simple, however it doesn't come without its problems. When developing the [LeviRoutes URL routing](https://github.com/PaulKinlan/leviroutes) framework it became obvious that we need some changes to the specification as-is. The [Mozilla documentation](https://developer.mozilla.org/en/DOM/window.onpopstate) reports that onpopstate is called whenever the history object changes, unfortunately this is not the case, and is not the case with the spec either, the [HTML5 Spec](http://www. Read More
App Cache and HTML5 History
Whilst developing our latest app (https://github.com/PaulKinlan/ioreader) for a Google IO, we ran into several large is limitations with AppCache and HTML5 History that I wanted to share (and at somepoint hopefully solve). Putting the current discussion of the issues with AppCache aside for a couple of minutes, there is no provision in HTML5 History to include pages "pushStated" into the current App Cache Group Consider this flow: We have a multi paged app with pages A and B when rendered from the server sharing the same AppCache and thus in the same group. Read More
When are we going to see the death of SVG?
I have mixed feelings about SVG. I find it complex and requiring specific tools, and its integration with the web is clunky. It feels like a context switch between HTML and SVG DOM. However, SVG is scalable, vector-based, and has powerful graphical capabilities like filters and paths, enabling things not possible with regular web technologies. I wish path could be a CSS property, simplifying its usage and allowing text or even block elements to be rendered along a path. This would be more efficient than embedding SVG within HTML elements. Read More
IO Question: How long did it take to develop the app? #io2011
At Google I/O 2011, we showcased a mobile web app. Many asked about its development timeline. Work began on March 3rd, with core coding starting on March 25th. While the calendar time was just over a month, the effort was spread across four engineers, each dedicating about 20% of their time to their respective UI using the FormFactorJS framework. This setup facilitated isolated development, with the flexibility to inject custom code per form factor and a common base controller in controller.js. We also developed and leveraged two frameworks, LeviRoutes and FormfactorJS, to efficiently consolidate common logic and specialize the controller according to form factors. Read More
Google IO Q: How can you use the Google Fonts API on mobile while optimizing performance?
At Google IO, we were asked how to optimize Google Fonts for mobile performance. We focused on visual appeal by using mobile-friendly fonts like Droid Sans and Lato. To minimize requests, we leveraged App Cache, storing the CSS and font files for faster subsequent loads. While the Web Font API abstracts URLs, we found the font URLs within the CSS response and cached them. Although subsetting fonts is possible, we didn't use it given the potential character range needed for news articles. Read More
Google IO Q: Would one build a different HTML 5 app for keyboard devices and mobile (touch) devices? Why or why not?
Another question that we didn't get to answer in our talk - Mobile web development: Zero to Hero - is basically the premis of the entire talk. We believe that in a large number of cases that it is entirely possible to build applications using one semantic document structure, a large swathe of common core logic whilst specializing for a given formfactor. From our talk, you can see that the User Interface is optimised for smartphone, tablet, desktop and TV - we believe that there are qualitatively different user interaction patterns in each form that it is important that you optimise for the different experiences, but for the developer experience it is not easy (or possible in some cases) to keep having to build one new app for each category of device that you want to target. Read More
IO Question: How are you dealing with AppCache relatively small storage limits?
During our Google IO talk on Mobile Web Development, we received a great question about handling AppCache storage limits in modern browsers. Our approach was straightforward: we primarily used AppCache for program code, including CSS and JS, along with the main page. Our application's size remained manageable, helped by minifying the JS in our production build using uglifyJS. Although we could have compressed the CSS, we prioritized ease of development. If space became an issue, our plan was to AppCache only form-factor specific code and assets, but thankfully, that wasn't necessary. Read More
IO Question: WebSQL is dead or dieing, IndexedDB isn't there yet, what do you think about libraries like Lawnchair?
During my "Mobile Web Development: From Zero to Hero" talk at Google I/O, a question came up about client-side data storage now that WebSQL is deprecated. While IndexedDB is on the horizon, what are developers using today? I shared my preference for Lawnchair, a simple key-value store abstraction that's easy to use and perfect for many situations. While I didn't use it in the IO Reader app due to late-stage project constraints and the sufficiency of localStorage, I generally prefer using such libraries. I'm interested in hearing from others. What data storage wrappers or techniques do you prefer when building web apps? Read More
Badgemator .... it is all in the how you tell people about your app
Badgemator is a web app that simplifies the process of creating badges for your Chrome Web Store listing. It generates a single script tag that you can embed on your website. This tag displays a badge to Chrome users who haven't installed your app, encouraging them to visit your store listing. Badgemator automatically fetches your logo and other details, and you can customize the badge's appearance with CSS. The project is open source, and contributions are welcome! Read More
The skinny on LeviRoute JS routing framework
I've created LeviRoutes, a client-side JavaScript routing framework inspired by Rails. It's simple, fast, and focuses solely on handling URL changes. LeviRoutes works with HTML5 History APIs, hashchange events, and even gracefully degrades for older browsers. It supports named parameters like "/:category" for dynamic routing, allowing you to treat the URL as a controller input. Check it out on GitHub! Read More
So what is happening with Web Intents?
I've been working on Web Intents, a project to simplify client-to-client service discovery and communication on the web using technologies like IFrames and SharedWorkers. It addresses the current issue of apps needing to integrate with third-party services, which restricts user choices. However, I recently discovered a similar project, Web Introducer, also by a Googler. It tackles the same problems with more in-depth security considerations. So, I'll be shifting my focus to contribute to Web Introducer. Web Intents remains a valuable example of using SharedWorkers and messaging effectively within web apps. More on Web Introducer and SharedWorkers coming soon! Read More
I've seen the future of the web. It's in the background
Hey everyone, I've been playing with the dev channel of Chrome and discovered something huge: background pages for web apps! This means your web app can now run even when the browser is closed, or even after system start-up. It's crazy powerful. You enable this by adding the "background" permission to your app manifest and then using a simple window.open()
call with a special third parameter. The background page's state can be toggled with window.close()
. Communication between the background page and your app is done using SharedWorkers. Oh, and Appmator now supports this too!
Read More
Dutch GTUG
The Chrome Web Store is launching in the Netherlands with integrated support for Dutch sellers! Join the Dutch GTUG on March 2nd, 2011 at 7pm at Google Amsterdam for an event about HTML5 and the Chrome Web Store. I'll be showcasing new HTML5 features and discussing how to leverage the Chrome Web Store to reach more users. The event includes Q&A and lightning talks, so come prepared to demo your projects! Space is limited, so sign up now! Read More
My first year in Google
My first year at Google has been an incredible journey. It's been a whirlwind of experiences, from joining the company after selling my Twitter web-app to working alongside industry experts like Chris Messina and Tim Bray. I started as a Developer Programs Engineer for iGoogle and Google Chrome in London, and later transitioned to a Developer Advocate role. My first month at the Mountain View campus was an intense learning experience. I've traveled extensively, presented at various events (including Google Developer Days in Munich, Moscow, and Prague), and contributed to the launch of the Chrome Web Store. I'm excited to see what the future holds, including speaking at Google IO and working with more developers outside of London. Read More
I will be working @ @Techhub on 13th of Jan
This Thursday, January 13th, 2010, I'll be working from TechHub in London with @mahemoff as part of my resolution to work more closely with developers outside of Google UK HQ. Stop by and say hello between 9:00 am and 3:30 pm if you're in the area! Read More