Demythstifying Web Components

The following is an attempt to stomp out the seemingly endless FUD that circulates about Web Components, most of which is purely manufactured by attacking tangential, opinionated choices of frameworks that happen to use Web Components in a way that differs from the opinions of other frameworks.

Level Setting

Don’t let me catch you claiming a Web Component is anything but the following, or I’ll send Kam Chancellor to lay you out:

Web Components are an amalgam of APIs from two W3C specs (Custom Elements and Shadow DOM) that enable the creation of encapsulated, declarative, custom elements, which serve as standard, reusable, interoperable vehicles of discrete, stateless functionality.

Myth 1: “Web Components are at odds with Framework X”

This is probably the most fallacious statement about Web Components.

Continue reading

Scaling Decentralized Apps & Services via Blockchain-based Identity Indirection

Blockchain Scalability

Developers of apps and services, blockchain-based or not, must always consider efficiency and scalability in determining how to best serve the needs of their users. This is especially true when you add new or emerging technologies to the equation. In the realm of blockchain-based apps and services, scalability considerations are magnified by the distributed nature of the underlying system.

In order to maintain the unique guarantees of a blockchain, transactions must be processed with a mechanism that ensures consensus, then propagated across the network. These constraints introduce three major scalability challenges:

  1. Propagation over a distributed system
  2. Consensus processing of transactions
  3. Data duplication size and cost

Continue reading

Recapping the W3C Blockchain Standardization Workshop @ MIT

I had the opportunity to both co-chair and present at the W3C’s blockchain workshop at MIT in Boston this week. More than 100 of the best and brightest from the standards and blockchain worlds met to discuss potential Web standards opportunities for blockchain tech.

I have been working toward the establishment of a large-scale, user-sovereign, blockchain identity system for many years, and with an initiative now underway at Microsoft, this event was instrumental in better understanding the views of other organizations we intend to work with in bringing this system to users, companies, and governments across the globe.


There were many areas of standardization discussed that touched on blockchain-based identity systems, but perhaps the most specific, actionable area of standardization the group identified was extension of the existing Web Auth spec to include the APIs, features, and flows necessary to enable blockchain-based identity authentication in browsers. This is something I will begin to explore with other implementers and interested organizations from the W3C workshop who committed to do so with us.

The workshop was a great opportunity to start an important discussion about systems that could move the Web far beyond what it is today. I look forward to reporting back on the progress of our explorations as we move forward!

The Nickelback Persistence Conjecture

“The Hammer’s Coming Down”

In my work with open source blockchains, distributed hash tables, and peer-to-peer systems in the area of identity, I have run across people making this statement from time to time, often in an effort to minimize open source, decentralized, distributed systems vs their centralized or proprietary counterparts:

“The data on these decentralized, distributed systems will only be persistently available if people continue to run them.”

These folks often add:

“This is a serious concern because the people running these systems must have an economic incentive to keep them running.”

I’ve never spent more than an eye-roll of my time on people who make these statements because they’re pure fallacy, but a random assault committed on my eardrums (Britney Spears – Oops I Did it Again) in the admission line at Google I/O 2016 inspired me to finally drop the hammer on this FUD. I’m sure you’re wondering how Britney Spears, Nickelback, and fallacious statements about decentralized, distributed systems are all related: slow your roll, I’ll get there.

Continue reading

S(GH)PA: The Single-Page App Hack for GitHub Pages

SPA woes

For some time now I have wanted the ability to route paths for a gh-pages site to its index.html for handling as a single-page app. This ability is table stakes for single-page apps because you need all requests to be routed to one HTML file, unless you want to copy the same file across all your routes every time you make a change to your project. Currently GitHub Pages doesn’t offer a route handling solution; the Pages system is intended to be a flat, simple mechanism for serving basic project content.

If you weren’t aware, GitHub does provide one morsel of customization for your project site: the ability to add a 404.html file and have it served as your custom error page. I took a first stab at doing an SPA hack by simply copying my index.html file and renaming the copy to 404.html. Turns out many folks have experienced the same issue with GitHub Pages and liked the general idea: The issue that some folks on Twitter correctly raised was that the 404.html page is still served with a status code of 404, which is no bueno for crawlers. The gauntlet had been thrown down, but I decided to answer, and answer with vigor!

One more time, with feeling

After sleeping on it, I thought to myself: “Self, we’re deep in fuck-it territory, so why don’t I make this hack even dirtier?!” To that end, I developed an even better hack that provides the same functionality and simplicity, while also preserving your site’s crawler juice – and you don’t even need to waste time copying your index.html file to a 404.html file anymore! The following solution should work in all modern desktop and mobile browsers (Edge, Chrome, Firefox, Safari), and Internet Explorer 10+.

Template & Demo: If you want to skip the explanation and get the goods, here’s a template repo (, and a test URL to see it in action:

Continue reading

The Web Beyond: How blockchain identity will transform our world


Jane wakes up to the sound of her alarm clock – it’s 6:13 AM. “Oh great, what am I in for today,” she thinks. Jane’s alarm clock is normally set for 6:30 AM, but her identity agent detected a traffic accident that is projected to add 17 minutes to her commute. Jane’s identity agent, acting on her behalf, changed her alarm while she was sleeping. All three – Jane’s identity, the identity of her alarm clock, and the identity of her agent – are connected via a self-sovereign, decentralized, blockchain-anchored identity system.

Jane gets ready and grabs a yogurt from the fridge as she heads out the door. The yogurt was delivered yesterday, after her fridge detected she was out. Her fridge’s identity has been granted limited access to initiate purchases for her. In this case, Jane has opted to be notified for confirmation of any purchases her fridge initiates; yesterday Jane swiped “Confirm” when the identity management app on her phone asked if the fridge could execute a purchase of some groceries. The fridge executed a payment over the blockchain using Jane’s identity-linked blockchain wallet and the wallet linked to the grocery store’s identity. That’s right, the grocery store has a blockchain-anchored identity as well. Starting to get the picture?

Jane needs to get to a downtown office building where she is scheduled to meet a contact on the 12th floor. Jane doesn’t have a car, so she asks her identity agent to fetch her one by leveraging the many identity crawlers dedicated to indexing sharing economy identity data. These crawlers are always hard at work, real-time indexing the (user allowed) blockchain identity data changes of every person, place, device, and intangible entity on Earth. In this case, there are hundreds of drivers in Jane’s general vicinity who have granted popular ride sharing identity agents access to read and update their identity’s ride sharing fields. Jane uses her preferred crawler’s app to send signed, encrypted requests directly to providers of sharing economy services. The crawler identifies a driver whose identity shows a ride sharing status of “Available,” with a geolocation value that indicates he is close to Jane. Jane taps “Request a Ride” on the app and it immediately sends a message to the communication endpoint listed on the driver’s blockchain identity. The driver’s blockchain sharing economy app alerts him that a new ride request was received and asks whether he wants to accept. The driver accepts and is sent Jane’s current geolocation.

Upon arriving at her destination, Jane authorizes a payment of her driver’s identity-linked blockchain wallet. She enters the office building and heads directly for the elevators, bypassing a lengthy check-in procedure in the ground floor lobby. Jane taps her phone against an NFC pad, which instantly identifies her via a challenge/response verification of her identity assertion. The elevator system’s blockchain-anchored identity has been given access to the appointment schedules of the various software systems used by the companies that reside in the building. It uses Jane’s identity datastore to locate the appointment entry, which was created by her contact. Within this entry is a signed directive to allow Jane’s identity to access the elevator and take it to the 12th floor. Jane enters the elevator and the button for the 12th floor is already lit up. Just for fun, Jane tries hitting other buttons. But alas, she was not granted access to other floors, so the buttons don’t light up and she isn’t able to access them.

Jane walks up to the front desk and alerts the attendant that she has arrived for her meeting. The attendant directs her to verify her identity once more, via the guest terminal. Jane is greeted by her contact and smiles at the thought of how efficient and interoperable the world has become, thanks to the universal blockchain-based identity system.

Continue reading

A Renewed Call for App-to-App Interaction APIs

Cow, come in cow

The battle ground of app-to-app interaction history is littered with abandoned ideas, half-solutions, and unimplemented APIs. The current, consumer/provider interaction paradigm for apps and services is a mess of one-off, provider-defined systems that each use their own transaction mechanisms and custom data structures. This makes it hard to do simple things across N providers, like save something to a user’s preferred storage service without jumping through provider-specific code and UX hoops.

I’d like to restart the conversation about bringing legit, app-to-app interaction APIs to the Web. There have been past spec attempts, namely Web Activities and Web Intents, but I’ll argue that while they get a lot right, they all fail to deliver an A+ solution.

Continue reading

Element Queries, From the Feet Up

Everybody’s looking for Element Queries

What are Element Queries? At a high level, I’d describe them as pure, unfiltered, rocket fuel for hyper-responsive layouts and components. More technically, they are Media Queries scoped to individual elements. Element Queries would allow you to attach Media Query break-points based on the dimensions and characteristics of an element itself, instead of the page’s viewport.

Developers have wanted Element Queries for a long time. Here’s a list of articles that convey the need, along with a few attempts to make them real:

Continue reading

Cross-Browser, Event-based, Element Resize Detection

UPDATE: This post has seen a significant change from the first version of the code. It now relies on a much simpler method: a hidden object element that relays its resize event to your listeners.

DOM Elements! Y U No Resize Event?

During your coding adventures, you may have run into occasions where you wanted to know when an element in your document changed dimensions – basically the window resize event, but on regular elements. Element size changes can occur for many reasons: modifications to CSS width, height, padding, as a response to changes to a parent element’s size, and many more. Before today, you probably thought this was mere unicorn lore, an impossible feat – well buckle up folks, we’re about to throw down the gauntlet.

Continue reading

The Oft-Overlooked Overflow and Underflow Events

A Primer on Overflow and Underflow

To level-set, I’ll define and describe what overflow and underflow are in the context of the web. Overflow is a rather simple concept you’re probably familiar with: when an element’s content takes up more space than it allows, given style or box model constraints, it causes a scrollbar to appear or the content to be cut off from view (if you set overflow: hidden;). Underflow is the less common case you probably don’t think about: an element currently in an overflown state leaves that state as a result of the element growing in size or a reduction of the amount of content within it – visually, the scrollbars disappear and all content is visible within the element. As it turns out, Firefox and WebKit browsers offer events that alert you of changes between these two flow states.

What if I told you

Continue reading

© 2017 Back Alley Coder

Theme by Anders NorenUp ↑