The Internet of Things is a mess. Yep, I said it. I know you’ve thought it but maybe not said it. Devices for all their usefulness can be utterly frustating when you have to go through the find-me-use-me dance:

  1. I need this app from this store. Downloading….
  2. Wow, that looks like something from 2012. Why is the text so small?
  3. Humm, can’t find the device.
  4. Where is my router login?
  5. Yep, I see you in the DHCP logs.
  6. Direct input of IP into app.
  7. Spinner….spinner…..spinner frozen
  8. Hey I can control the device (maybe)

That above isn’t even a hypothetical: it’s the pain stacking series of events I recently went though with a Blu-Ray player. Yeah, a Blu-Ray player.

I know what you’re going to say: put disc in, play movie. But that’s not the point. I hate remotes. The device hates remotes (which is why the manufactor is saying plastered on the box “Look at our cool control app!”).

User experiences for devices with API and embedded web servers could be a amazing. Flow me on a magical journey where we talk about the future.

What if devices just told us via the Physical Web?

In a perfect world devices just tell me they exist near me. I don’t need your native app, I don’t need to find an IP address: things just work.

Luckily we have the up-and-coming wonderfulness that is the Physical Web. I heart the Physical Web and when I’m not handing out beacons, I’m using them myself. The case I propose isn’t far outside of many of the examples you’ll see on the page.

You see, in a perfect world of increasingly cheap and updatable hardware would it not be lovely if the audio visual receiver that powers your TV just told you it existed? No app to download, just the local IP of that device that serves it’s own little progressive web app for you to use.

The funny thing is, how close are we really to that idea? Not to far: even my old Yamaha A/V receiver serves it’s own web control app (outdated and not updated, but that could be overcome).

That’s the world I want to live in. Because it requires less to do. But it has to work better and seamless and the Physical Web can jump that divide.

It’s easy to download a native app Justin

No it’s not. Not for the babysitter who comes over to watch my kids and wants to control the TV (or frankly anything in my house they may want to use).

The temporary user doesn’t care about the native app; they just want something nearby to work and if they’re on my local network (which if you’re in my house, the creds are an NFC tap away at the door), then chances are you can control things without the native app for 20 devices that exist.

Sample case: the great A/V receiver PWA

I’ve chosen an A/V receiver primarily because that’s what I’ve been working on lately. It’s not an unknown to me; I had reversed the POST commands from Yamaha’s web panel a while back (DevTools is your friend), so I knew I could make the receiver respond to commands.

The kicker is the case above is legitally the one I wanted to overcome, albeit I didn’t necessarily want to swap the firmware off the device, add Eddystone or a better web server (I suppose that’s for another day).

The basic approach I started with was to simply:

  1. Add Physical Web beacon to receiver pointed to locally served PWA.
  2. Run PWA on small web server in house.
  3. People visit house and use device.
  4. Profit.

From a technology standpoint, this is not rocket science. I’m just bolting on existing and new things to some devices I already have in the house. Again, in my perfect world, devices do this themselves.

As such I generated this setup (seen here testing the night before locally just to get the juices flowing):

One polymer init, a couple imports, and a quick api wire up as a web componenet later and I’m rocking. It’s amazing what you can do at 1am.

You can do this manufacturers

Why show the simple sample above? Because it was rudimentary to implement the required functionality. If I can swing it in an hour, surely you can o-magical device manufacturer?

From a device manufacturer standpoint, given the increasingly awesome IoT base platforms to build products on, you can indeed pull this off. I know you can. You have many of the subsystems needed to not only serve your PWA or broadcast an Eddystone-URL, but to update that app as well.

You’ve got the API, you’ve got the hardware, now let’s bring a better user experience to so many users out there.

I believe in you.

Random Notes and Thoughts

  1. Remote controls are easier, but damn if I can sort the 27 of them we have floating in the house at this point. I’m positive I have one from a TV I used to own in college. Why, beats me.

  2. “Remotes are for old people.” I love young people and their notions that at 36 I’m old.

  3. Damn it, I’m 36. Totally forgot that until just now.

  4. Yeah, security. I know. We’d have to talk about it (but we can sort that out).

  5. For something like an A/V receiver, there are a lot of moving parts. Most of the apps I’ve tried don’t hold the state of those configurations. My labels are not my wife’s labels are not my guests labels for inputs for instance. Data lives in it’s little silos and it’s a horrible experience. What was lost was understanding what the user would actually want to accomplish and even when apps exist they fall short because data and the sharing of the data or even state is still important (and can’t be ignored).

  6. Lost track of how many times I’ve re-labeled the inputs in the Yamaha app. Ugh.

  7. Did not push repo this morning. Will push Yamaha sample this week.


“Who here has built an offline web app?”

I raised my hand as I sat in that small breakout circle. This was the first Chrome Dev Summit in November 2013. I had expected others to raise their hand, but alas, I found myself soon explaining a desktop offline web app with a small group of people who had come to discuss the topic with Jake Archibald and Alex Russell.

What followed was a conversation about building blocks and roads less taken. The web app in question I hadn’t designed for mobile on the onset, but rather for desktops in remote offices with poor connectivity. The app I had built for a client was responsive across devices but originally designed only for desktops, progressive in it’s approach to features that the user may or may not have had available, used an app shell and a whole lot of other tricks.

The app was robust and fast in use. Users love it and three years later, with a few more updates and features, the app is still in use daily.

That web app would be close to what we call a progressive web app today. Yet desktop progressive web apps haven’t been spoken about much since the onset of the overarching term has started to take a foothold. The examples are often focused on the mobile web side of life.

Is there a place for the desktop progressive web app? Isn’t desktop dead?

In a land of mobile devices, desktop isn’t dead for all of us

There is a lot of data out there that shows mobile is no longer a choice but a necessity. The mobile web is sometimes the only experience some people will experience with our web applications, particularly as use by millennials grow. Mobile cannot be ignored.

That said, desktop internet use isn’t dead. In the United States, 75% still use a desktop for browsing. Other reports put the number lower.

Beyond the consumer experience of the web, desktop takes on a different form.

My job on a good day is to build applications for organizations and teams to make them more efficient (paperwork being the not-so-good days). They’re the sort of apps that live behind closed doors and policy; you’re not going to see them as a consumer on your device of choice.

This is often the OMG-IE-undead-versions-are-in-use-here sort of locations. People will tell you the web is ancient in these organizations, in that it-belongs-in-a-museum kind of way.

For some, that may very well be the case (and on my not-as-awesome days, I too have to fire up IE7/8 in a VM to work). But in my experience, more and more are converting to evergreen browsers in these organizations.

The reasons are much more varied than you would expect in a business setting, from basic value propositions and investment to simply user preference of using something that is nicer and offers them the features they’re used to using outside of the office.

If the foothold of progressive web apps grows in the mobile world that many users use on a daily basis, there is little doubt they’ll be a need for them in the desktop corporate landscape.

Your assumptions about the desktop might be skewed

As web developers we use the desktop browser different than an average user. We use the desktop to develop and we sometimes fall prey to assumptions about the platform from that experience. You’ve probably experienced this when testing for mobile on the desktop. We open DevTools and we use device emulation to test, expecting a one for one experience.

We know that this approach for mobile devices is ill conceived; what works smoothly on our desktop testing environment is not the same as on device. This is why we have things like remote debugging and network throttling to help us test a close as possible to what our users might experience.

Yet that assumption also informs our perspective on the overall capabilities of desktop browser experiences. Users have powerful machines and faster internet connections right? If I assume this, then I might not look at the overarching APIs and features that make up the progressive web app experience as something that my desktop web app might need.

A case in point is after a PWA talk I gave recently. A kind person came up to explain that desktop progressive web apps didn’t make sense.

“Why would I use those features for the desktop? My users don’t need offline, they’re always connected to the LAN. Seems like a mobile-only approach.”

That’s a valid question in my opinion. Do desktop systems and the types of the connections they experience need the sorts of benefits that Service Worker bring? Is the progressive web app approach only for mobile?

Desktop’s can suffer the same ills as any mobile device, no matter how fast you think your LAN or uplink may be. Our assumptions about the desktop experience are like mobile; we believe in a perfectly fast and always connected world that does not exist.

Searching my own experience with desktops and connections has been a mixed bag; for every wonderful organizational setup there has been the slow on-premise gateways, bad WLAN and satellite uplinks, remote offices that are simply neglected. This doesn’t even account for the mobile laptop user in the field who is at the mercy of shaky connections.

Even my own corporate office with it’s redundant connections and failover couldn’t help but go offline when the local utility company mistakenly used a backhoe in the wrong location and chopped cables in half last month.

When turn to look at hardware, just how fast are those desktops? Is that old desktop under the desk four years old? Is it bogged down with stacks of corporate software that the end user despises but has no control over (I’m looking at you horrible antivirus software)? Is it an entry level Chromebook? Is that so called fast LAN connection happenstance wifi hanging by it’s PoE wire from the vent?

Even with best laid plans, problems will occur. Skips and pops and drops ruin productivity whether it’s from a network issue or whether the machine is bogged down outside the user’s control.

If we as web developers have the means to use the latest web technologies that mitigate these issues then why not give your users a faster more resilient experience? As Alex Russell points out in his article Service Workers and PWAs: It’s About Reliable Performance, Not “Offline”, “It’s hard to stress enough how much better reliable performance is.” Why can’t we do the same for the desktop?

Don’t short change the progressive web feature set on desktop

We can create reliable performance for our desktop web apps today using Service Worker given its offline and resilient nature, but that’s only part of the progressive web application story.

Desktop web apps have in my experience suffered from three pain points that progressive web app features can help resolve today:

  1. Poor task re-engagement. I’ve seen a variety of re-engagement on the desktop over the years, but they don’t quite work to the effect you’d want in practice. In page notifications can go ignored when there isn’t focus or others relied on plugins. Today we have Push Notifications and they work rather well in re-engaging with tasks that need to be updated by users in approval workflows (among other approaches).
  2. Data sync operations. With Service Worker, we now get Background Sync that can allow us to do give our users a more robust experience after they save work. No longer are they stuck waiting for operations to complete.
  3. No TLS. One of the beauties of Service Worker is that it requires TLS. Why is that good for your desktop web app? Because I’ve heard this more times then I can count over the years. “That app is internal, we don’t need TLS.” Yeah, not so secure and frankly there is no excuse for this. But slowness! Psssft. Just watch Emily Schechter take down the HTTPS myths.

These three pain points standout for me based purely on some internal data for apps I’ve rolled out this year. Your milage will of course vary, but in two cases the Push Notifications implementations alone have seen task response time improvements by seeing engagement of ~40% on notifications range in comparison to email notifications (which are often ignored).

These sorts of features weren’t just made for the mobile web: they can increase the usage desktop web applications but also increase the overall performance of your users.

“But Justin, I can’t use all these features and I can’t just roll out a new copy of my app tomorrow.” Which leads me to this very important point.

Don’t lose focus of what progressive means

I’ve heard the following two definitions repeated to me in the last month:

  1. Progressive = responsive
  2. Progressive = my browser isn’t supported, site won’t load

Before you balk at these definitions, consider they likely came about in response to examples that initially shipped as lacking the progressive approach (they only worked in browser X). Early examples and experiments are great by the way, just don’t take them as forever ongoing cannon.

The definition of progressive is “happening or developing gradually or in stages”. Which is to say progressive enhancement, core in the progressive web app story, is about making sure that if a user doesn’t have that feature your application still works.

This is true on any device form factor. Getting into the mindset of “only work when all is there” is not reasonable in my experience; you can dictate all you want but users will gravitate to what they want to use. In the example I explain at the beginning, it was progressive through and through; if you used Firefox without File API, the app still worked. If you used Safari on iOS, the app still worked.

Further, focus on those gradual steps, desktop, mobile or wherever your platform may be. A great example of this during Thao Tran’s segment in the Progressive Web App Summit keynote where she speaks about differing and at times pain-point specific implementations that resolve user frustrations.

You don’t have to replace your entire application tomorrow. Progressive requires forward thinking. Spend the time, do the engineering, develop your progressive implementation. Your clients, your users, and your fellow developers will thank you.

Oh that pesky desktop icon and window

When I initially wrote this draft for this piece back in July, I hadn’t considered the desktop icon problem or window mode. On mobile, the PWA experience gives you that icon-on-homescreen appeal and that app-like single window. On desktop currently this isn’t the case (though it does work fine on Chrome OS).

There are some technical hurdles around this which is why we haven’t yet seen it. That said, I question the assumption that desktop PWA requires a desktop icon. Yes, it’d be a nice option. But how do people use the web on desktop today?

Simply walking around an office floor might tell a better story. Tabs rules the day and I would question a icon-to-window only approach on the desktop. We want our webs apps robust and user friendly and if we have to adhere to the icon and window approach on desktop, possibly that’s an anti-pattern.

For me today, writing PWAs for the desktop in corporate environments, the icon and launcher conundrum is simply not a showstopper. That doesn’t mean we should have a conversation about the concept of icons and desktop OS launchers.

Desktop icon conundrum expanded

After I published the initial version of this piece Kenneth Christiansen, Chrome/Blink and web platform hacker extraordinaire, reached out to have a conversation about the concept of the icon and the notion of what it means on the desktop to end users.

“I still think that the icon makes sense on desktop in some cases,” Kenneth wrote. “Apps like a calculator, or hangouts/instant messaging, or a file manager are nice to have around at the same time as your regular browser tabs.”

I wholeheartingly agree on that; some things make sense to have and icon and window. But how do we handle this from a usability perspective? How do we determine to start a progressive web app in a tab or window?

“Maybe on desktop we want to be able to move between all states and just have the OS remember and maybe use the display: mode as the default for the icon”, Kenneth wrote. “‘standalone’ and ‘fullscreen’ is about maximizing real estate; on desktop starting in a tab and be able to move to standalone or fullscreen easily and then remember that choice when launched from a desktop launcher seems okay to me.”

This seems to me a like a reasonable approach. The concept that you may start in a tab (as if typing an existing url by memory or address bar recall) gives the user a reasonable approach to the fictionless web that they know; they don’t have to change their expection of what will happen when they hit enter, the progressive web app simply loads.

The notion that the application display mode would hint or offer a state switch is intriguing. Consider a possible basic flow of what that might look like:

  1. Vist Calculator site.
  2. Install Calculator PWA.
  3. Calculator supports launching in standalone mode, click here to default to that mode.

By the time the user makes the selection in item 3 above, the last used mode will be used when launching from the launcher (tab, standalone, full screen, et cetera). The user could of course change this via the UI (the ability to set to a different window mode) and when manually loading from a tab, things will stay in a tab like always regardless of mode (no change in user expectation).

Further, a tab or PWA could be marked allowing the changing of display mode at any time, allowing the user a great deal of power to work the way they want.

This is one such senario; Kenneth and I tossed around ideas like tab marking and the concept of a display: floating mode (which could very well be standalone). We both agree that the icon in launcher for PWAs in Chrome OS is particularly nice (if you haven’t tried it, you should, it’s a very clean and smooth integration that feels very natural).

The careful reader might say “umm, Justin, why discuss this further? You just said that you didn’t much care about the icon in the previous section.” This is true; for me an icon is not the end all be all experience that defines the PWA experience.

However that’s not the case for all users. For many an icon is how you start to work or play on the web. From emerging markets where the desktop is now just arriving after years of mobile only, to kids brought up on tablets, to people who simply don’t recall URLs, icons and their OS launcher is a mainstay.

Remember we build for users all over the world, not just ourselves or our contained corporate environments.

The story of progressive web apps is at the beginning, let us not leave the desktop behind

Progressive web apps are just now coming into focus. Examples and more examples abound. Paradigms and approaches are growing, browser vendors are actively engaged, the Progressive Web App Dev Summit showed what a future might look like for so many web applications.

My fear is that in our excitement we leave the desktop behind in this conversation, that people see the progressive web app story as only framed by the initial mobile focus. This would be a travesty and defeat the purpose of the power that these new features bring to the web as a whole.

Progressive web apps are going to be amazing for users. Let’s just make sure we don’t forget desktop web experience in the midst of change.


I’ve done a lot of speaking and mentoring over the years at many venues. This will be the first time I can say the President of the United States will be hosting the event.

President Barack Obama will host the seventh annual Global Entrepreneurship Summit (GES) at Stanford University, June 22-24, 2016. GES is a reflection of the U.S. government’s commitment to utilize entrepreneurship as a foundational tool to ensure more communities around the world are economically prosperous, secure and globally connected. The 2016 GES is the seventh annual gathering of entrepreneurs at all stages of business development, business leaders, mentors, and high-level government officials.

Just so happens I’ll be mentoring startups as a Google Developer Expert and a mentor for Google Launchpad. I was kindly invited by the Google for Entrepreneurs team and I’ll be mentoring in their Lounge as part of the multi-day event on June 23rd.

If you’re attending, swing on and say hi. If you’re not, you can always reach out on the social networks.


One of the benefits of a progressive web app is that we don’t break the paradigm of history or the expectation of our users. Links exist right in the top bar as they always have, easy to copy, paste, and place any where you may so please.

Alas, what may simply be a blue link in an email doesn’t have the same luster on the social networks of your choice with progressive web apps. Ever pasted one to see what happens? You will probably not be overcome with joy, seeing the default metadata that’s set in your shell.

The situation is pretty clear: our pwa link may work entirely fine when visited, but the default information is probably what we don’t want when it comes to specific things a user might share. What’s a web developer to do?

I’ve got this hammer, errr, JavaScript

A betting person might say “Well bots are totally super smart now, I hear machine learning is all the rage, surely the bot can run my JavaScript.”

Alas, in my testing I found that was not the case. I tested a variety. Facebook, Slack, Twitter, LinkedIn, Google+. Nope, not a single one would read the dynamically set tags. A cursory glance over similar questions on Stack Overflow also shows people with similar problems and results.

Time to put that hammer down. What else can we do?

When you’ve got a shell, everything is data

If we can’t run JavaScript to inject metadata to appease the bots, we need some rewrite magic. We need some static pages. Well, sort of, but I’ll get to that.

“But Justin, I don’t want to have two sets of content I have to maintain, that would be a massive pain in my backside.”

Alas, that would indeed be a pain random web developer. No one wants to do that. If only we had separated concerns, like if our data wasn’t tied to our design or something like that.

Humm…sounds a lot like what we have with our progressive web app shell doesn’t it?

What if we had a different, statically generated shell that simply used our data or endpoint to fill that shell for the social linkbot? Then we would wouldn’t need to duplicate our data. We could even do something better: we could make it the most barebones set of data ever, as we only need it for them.

We could make the linkbot experience faster for our end user.

Sounds like a reasonable plan. Let’s build that.

Let’s spork a repo to 11

In my case, I built our corporate progressive web app running on Google App Engine using the H2 Push approach (see http2push-gae). This wasn’t a stretch (our site/app has run on GAE for years), but I really like what the Google Chrome team have come up with. It’s a clean, fast, effective way to get a lot of perf without much overhead.

We’re going to fork it make it work with our data and our hungry linkbots.

First thing we have to do is come up with a list of bots. This is the list we settled on, purely based on Google Analytics data we had (in no particular order):

bot_list_hunt = [ 

Since we’re using the Python variety, what we really need to do is simply test our user agent (gasp!) to see if we’re a bot:

bot_list_search = '(?:%s)' % '|'.join(bot_list_hunt)

if re.search(bot_list_search, self.request.headers.get('User-Agent')):
  # keep reading, more code incoming

Sidebar: Google+ uses the user agent from the user who is about to share your link and appends the url you see escaped in that list. Hence, the escaped url, which is what I found to be the most reasonable way to test for someone sharing on Google+.

Now it’s simply a matter of taking the target the user is looking at and translating it into data to feed into a static template.

We just need to know which data to load. In our case, we know this by looking at self.request.path. We house our data under our web root in a super secret folder we call data (I know, unguessable isn’t it?). Since our data is generated via Hugo, the Go-based static site generate, paths within the progressive web app actually house the same routes, just with data pre-appended (as we’re loading JSON into our app shell). We can simply build a path like:

name = os.path.join(os.path.dirname(__file__), 'dist/static/data/', self.request.path.lstrip("/"), 'index.json')

Now that we know which JSON to load, we open the file, read it it, parse the JSON and pass it to our webapp2 template:

f = open(name, 'r');
c = f.read()
data = json.loads(c)
bot_template = os.path.join(os.path.dirname(__file__), 'dist/static/bots/index.html')
return self.response.write(template.render(bot_template, data))

Sweet simplicity. In testing it looks like this on the App Engine console:

App Engine console says we have a bot winner!

We’re on the right track. Now let’s give that bot some data so our PWA can be in further awesome.

Just the facts, server

Linkbots want really one thing: metadata. Some want their specific thing (ala Facebook and Twitter), others will use just about whatever it can find (Slackbot, Google+, LinkedIn). Why this matters is because you don’t have to serve much of anything. Just serve the head of your document with the proper tags.

We settled on this for the corp site (a more slim example can be found in my zuperkulblog-progressive-hugo repo):

<!doctype html>
<html lang="en">
  <meta charset="utf-8">
  <meta name="description" content="" />
  <meta itemprop="name" content=" - Stickman Ventures">
  <meta itemprop="headline" content=" - Stickman Ventures" />
  <meta itemprop="description" content="">
  <meta itemprop="image" content="">

  <meta name="twitter:card" content="summary_large_image">
  <meta name="twitter:site" content="@teamstickman">
  <meta name="twitter:title" content=" - Stickman Ventures">
  <meta name="twitter:description" content="">
  <meta name="twitter:creator" content="">
  <meta name="twitter:image:src" content="">

  <meta property="og:type" content="article" />
  <meta itemprop="og:headline" content="" />
  <meta property="og:title" content=" - Stickman Ventures" />
  <meta property="og:description" content="" />
  <meta property="og:site_name" content="Stickman Ventures" />
  <meta property="og:url" content="" />
  <meta property="article:published_time" content="" />
  <meta property="article:modified_time" content="" />
  <meta property="og:image" content="" />

Yeah, that’s it. There is no body, no styles, nada. The bots have all they need in those tags and the beauty of this is, the overhead is minimal.

Testing our results

Testing in this case either can happen through an ngrok tunnel to the local dev server or you can always push versioned revisions to App Engine before switching over to production.

Testing the links themselves is fairly simple. Facebook has their share debugger and Twitter has their card validator. These are valuable tools on our quest for making sure our metadata shell and matching work.

To test this working. I used my forked and hacked up clone of Rob Dobson’s zuperkulblog-progressive, zuperkulblog-progressive-hugo.

Twitter metadata for the win.

As you can see Twitter now very much thinks our progressive web app is much happier as opposed to the non-bot version.

The rest of the social networks don’t seem to have a means to test, but we didn’t have any issue just dropping links in random share boxes and testing the metadata pull. One issue to keep in mind (which is why ngrok can be useful, as it rotates domain names in use when restarted) is metadata caching (which most of the services do in some form).

You’re missing a bot and it has me worried

The careful reader will note that I’ve talked about linkbots, the one’s that share things on the places we all like to have social interactions. There is a very important, very large, and very unignorable bot that’s absent from this list: Googlebot.

Googlebot is in it’s own sphere. One, it’ll run JavaScript. Two, it’ll read dynamic structured data you inject. Three, you shouldn’t make pages specific to Googlebot like I’ve done for these other bots (you can in certain cases, ala AMP, but that is a topic for another progressive web app day).

The short answer is that Googlebot will read and index our progressive web app just fine if we take a couple of things into account. In my corporate case, our site has specific pages of static text, blog entries, random labs and code. These show up in a standard sitemap.xml file at the root, with no special instructions. The only pieces of magic code we’ve used is to swap page titles and meta descriptions with some simple JavaScript on route changes.

Skeptical this gets indexed? Yeah, we were to. That’s why we tested it:

Testing corporate search.

Tada! Magic! Googlebot happily sees our data changes and if we search for words in our injected pages, we can see Googlebot happily indexing our site. On our tiny production corporate page to boot.

Risk is fun.

Long and Short: Do you need special pages for Googlebot when it comes to progressive web apps? In this first small test, Google seems to have no problem indexing. When in doubt, follow Google’s WebMaster guidelines, but I’m continuing to test to see what PWAs need when it comes to seach.

Solid results, more to come

One of the hallmarks of progressive web apps are that they should be linkable (it’s what makes the web awesome right?). The thing about linkable is that means that they should also play nice with where people paste links, including in our social networks. Social network use bots to grab a better idea of what that page is about to inform the user, so our progressive web apps should probably take this into account.

This example uses App Engine, but you could no doubt apply it to your technology of choice. Want to test it out? I’ve dropped an update to my ongoing hugo + progressive mashup, zuperkulblog-progressive-hugo.

In our next installment, I’ll be talking more about the nature of the word “progressive” and why you should put down the pitchforks and torches.


Some folks ask me if I still work on NFC related things. The short answer, yes.

The longer answer is that I pestered friend and fellow Google Dev Expert https://twitter.com/kennethrohde to send me over an early Chromium build that he’s been working on that his work on webNFC:

Testing WebNFC is awesome.

A couple of things to note:

  1. The app in the screenshot was an app that Kenneth built in Polymer for testing (and works pretty well).
  2. If you’re not following Kenneth on Twitter, you probably should be. :-)

No ETA when that lands, but I thought a screenshot might make some folks happy. The response on Twitter leads me to believe so.