What’s exciting to me here is not “AI turned a PDF into an app” so much as what made that possible: components, tokens, utilities, and enough design-system clarity to give the model something useful to work with. That’s a big part of the story so many people miss. If your system is inconsistent, vague, or poorly documented, AI is just going to amplify that mess.

Paul’s teardown is a good illustration of how far modern front-end practice can drift from the simple, robust platform primitives we already have.

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Reading this reminded me of a pair of pieces I’ve linked to before: Making radio buttons and checkboxes easier to use and There can be only one: Options for building “choose one” fields.

We have spent an astonishing amount of time and energy overcomplicating a control HTML already gives us, often in the name of developer experience or styleability. More often than not, all we’re really doing is trading resilience for ceremony.

I particularly appreciated how plainly this post describes a mismatch a lot of teams create for themselves: wrapping largely-static content in an app shell, then shipping a pile of JavaScript just to re-assert what the server already knew. MDN’s new approach feels refreshing, despite being grounded in age-old best practices: Keep the content first-class, treat interactivity as optional (and isolated), and only ship what the page actually needs.

There’s a lot to like here, but more than anything I love seeing MDN embrace an architecture that’s truly aligned with the platform it documents.

It’s one of those tools that immediately makes me want to crack open a demo and start playing. What’s especially nice is that it doesn’t ask you to invent some parallel configuration universe if you don’t want to; it can just inspect the variables you already have and give you a UI for experimenting with them. That makes it feel less like a framework and more like a really practical enhancement to the way many of us already work.

progressive enhancement is not about preventing failure, it’s about defining what must always work.

I also want one of those ”Wat als de JavaScript uit staat?“ stickers.

First off, I agree with his core message: designers should understand the medium they are working in, be it web or an OS-specific UI. That’s where my agreements end, however.

They pat themselves on the back, believing they’ve mastered digital design. Meanwhile, a developer glances at the file, sighs, and codes the button in five minutes.

Condescention toward designers aside, this also assumes a high degree of competency and understanding of nuance on the engineering side which — in my experience — is not guaranteed. I cannot tell you how often I’ve designed an interface that calls for a button to submit a form and I get back a div with a click handler that can’t accept focus and has no design considerations for hover, focus, etc. In other words, if I provided a design with a single button on it, I get that button exactly. Sometimes exactly to those explicit dimensions, text overflow be damned.

There needs to be an acknowledgement and appreciation that designers know their craft and (generally) have good reasons for being overly prescriptive. Do some designers stray into realms of self-indulgence… absolutely! But so do engineers.

I think where we need to get to is a place where handoff provides enough information to inform the engineer of the totality of what’s needed. Sure, to a seasoned engineer that may seem overly detailed, but to a junior engineer it can be incredibly helpful in learning all of the considerations of something as seemingly simple as a button. And even a seasoned engineer might learn a thing (or three) from annotations regarding accessibility and such. Communication is the key to success here.

Also, some prototyping in a tool like Figma can help with catching issues — like keyboard traps, for instance — before they are codified into code. Making changes in Figma or other design tools is generally a lot cheaper that doing it in code. Back of the napkin math — which is generally agreed upon across the industry — is that catching & fixing an accessibility issue in design costs about $100. In development, it’s like $1,000. If it sneaks into production, it’s gonna be more like $10,000.

To be clear, I’m not disagreeing with the piece in its entirety — designers should learn their medium (which is coding to a degree but also UX expectations) and Figma’s not the medium — but I think there’s more nuance to it. I also dislike the us vs. them framing; we’re all in this together.

The incident was caused when a bug in CrowdStrike’s code made it out into production. The results were catastrophic: It caused roughly 8.5 million servers to crash. Hospitals weren’t able to serve the people that needed them. Airline passengers were stranded. People couldn’t access their money in banks. Folks in distress could not get the emergency services they needed. On top of that, the financial fallout is estimated to be somewhere around US$10 billion.

Bugs happen. I’d hate to be the person who was responsible for that particular bug (or the people in the quality assurance team that should have caught it), but the reality is that none of us who write code write perfect code. We all make mistakes and sometimes those mistakes make it into production. Other times, the code we write works perfectly during development and testing, but causes an unexpected issue in production. Sometimes only in very specific “edge case” circumstances that we didn’t have the foresight to consider.

Which brings me to the lesson I took away from the CrowdStrike incident: minimize the impact dependencies can have on your customers’ ability to complete critical tasks. In other words, develop dependency awareness.

The web is a hostile operating environment. Sometimes network connections are slow to resolve or time out completely, which may cause issues with your JavaScript, may result in broken images or videos, or could make it so your user never receives your CSS. Sometimes 3rd party scripts ship bugs that can hose your site completely. Sometimes a customer’s browser plugin can wreak havoc on your site by adjusting markup or injecting code. If any (or all) of those things were to happen, could your customers still accomplish their key tasks? Could they even understand your site at all?

This is why it’s so critical to start with a fully-functional website that relies only on semantic, accessible HTML and regular ol’ links and form submissions. They aren’t sexy, but they’re solid. Then progressively enhance that experience to improve things when the CSS is downloaded. And improve some more when your JavaScript executes properly. Build an awareness for the kinds of dependencies you have in your code so you can ensure there is always a fallback.

When I think about building robust websites like this, I often think of the Chrysler Imperial. The 1964-1966 model is one of the few cars that has been outright banned from entering demolition derby events. It is just too well built. It just takes the hits and keeps on driving. We should aspire to that kind of resilience in the websites we build.

Bugs happen. Can your site withstand them? Or will you let the failure of a single dependency (a.k.a., site fragility) ruin your customers’ day?

https://www.youtube.com/watch?v=-9GGDOUDLhc&start=7&end=17

# Sharing, the Old-fashioned Way

When it comes to sharing, there are myriad ways to do it. If you’re at all familiar with my work, it should come as no surprise that I always start with a universally-useable and accessible baseline and then progressively enhance things from there. Thankfully, every social media site I commonly use (with the exception of the Fediverse) makes this pretty easy by providing a form that accepts inbound content via the query string.¹ You can try LinkedIn’s to see it in action.

Each service is a little different, but all function similarly. I support the following ones in this site:

Using this information, I created a partial template for use on any page in this site (though I mainly use it on blog posts right now). Each link includes useful text content (e.g., “Share on __”) and a local SVG of the service’s icon. Here’s a simplified overview of the markup I use:

<ulclass=“social-links social-links–share”><liclass=“social-links__item”><ahref=“{{ SHARE URL }}”class=“social-link”rel=“nofollow”><svg>{{ SERVICE ICON }}</svg><bclass=“social-link__text”>Share on {{ SERVICE NAME }}</b></a></li></ul>

You can check out the baseline experience on this very page by disabling JavaScript.

It’s worth noting that I have chosen not to enforce opening these links in a new tab. You can do that if you like, but on mobile devices I’d prefer the user just navigate to the share page directly. You may have a different preference, but if you decide to spawn a new tab, be sure your link text lets folks know that’s what will happen. I do include a rel="nofollow" on the link, however, to prevent search spiders from indexing the share forms.

If you test out these links, you’ll notice many of the target forms will pick up a ton of information from your page automatically. By and large, this info is grabbed from your page’s Open Graph data (stored in meta tags) or Linked Data (as JSON-LD). You can write that info to your page by hand or use a plugin to generate it for you automatically. There are a ton of options out there if you choose to go the later route (which I’d recommend).

# Enhancement Level 1: Popup Share

If you played around with any of the various share forms, you probably noticed that they are, by and large, designed as discrete interactions best-suited to a narrow window (e.g., mobile) or popup. To provide that experience, I’ve long-relied on a little bit of JavaScript to launch them in a new, appropriately-sized window:

functionpopup(e){var $link = e.target;while($link.nodeName.toLowerCase()!=“a”){$link = $link.parentNode;}e.preventDefault();var popup = window.open($link.href,“share”,“height=500,width=600,status=no,toolbar=no,popup”,);try{popup.focus();e.preventDefault();}catch(e){}}var screen_width =“visualViewport”in window? window.visualViewport.width: window.innerWidth,$links = document.querySelectorAll(“.social-links–share a”),count = $links.length;if(screen_width >600){while(count–){$links[count].addEventListener(“click”, popup,false);$links[count].querySelector(“.social-link__text”).innerHTML +=" (in a popup)“;}}

The first chunk defines a new function called popup() that will act as the event listener. It takes the event (e) as an argument and then finds the associated link (bubbling up through the DOM as necessary in that while loop). Once it finds the link, the function opens a new popup window (using window.open()). Then, to check if the popup was blocked, it attempts (within the try…catch) to focus it. If the focus succeeds, which means the popup wasn’t blocked, the script prevents the link from navigating the user to the href (which is the default behavior, hence e.preventDefault()).

The second block defines a couple of variables we’ll need. First, it captures the current screen_width using either the window’s visualViewport (if available) or its innerWidth (which is more old school). Next it grabs the social links ($links) and counts them for looping purposes (count).

The final block is a conditional that checks to see if the screen_width is wider than 600px (an arbitrary width that just feels right… your mileage may vary). If the screen is wider than that threshold, it loops through the links,² adds the click handler, and adds some text to the link label to let folks know it will open a popup.

And with that, the first layer of enhancement is complete: Users with JavaScript support who also happen to be using a wider browser window will get the popup share form if the popup is allowed. If the popup isn’t allowed, they’ll default to the baseline experience.

# Enhancement Level 2: OS Share

A few years back, browsers began participating in OS-level share activities. On one side, this allowed websites to share some data—URLs, text, files—to other apps on the device via navigator.share(). On the other side of the equation, Progressive Web Apps could advertise themselves—via the Manifest’s share_target member—as being able to receive content shared in this way.

Sharing a URL and text is really well supported. That said, it’s only been around a few years at this point and some browsers require an additional permission to use the API.³ For these reasons, it’s best to use the API as a progressive enhancement. Thankfully, it’s easy to test for support:

if(“share”in navigator){// all good!}

For my particular implementation, I’ve decided to swap out the individual links for a single button that, when clicked, will proffer the page’s details over to the OS’s share widget. Here’s the code I use to do that:

var $links = document.querySelector(”.social-links–share"),$parent = $links.parentNode,$button = document.createElement(“button”),title = document.querySelector(“h1.p-name,title”).innerText,$description = document.querySelector(‘meta[name=“og:description”],meta[name=“description”]’,),text = $description ? $description.getAttribute(“content”):“”,url = window.location.href;$button.innerHTML =“Share <svg>…</svg>”;$button.addEventListener(“click”,function(e){navigator.share({ title, text, url });});$parent.insertBefore($button, $links);$links.remove();

The first block sets up my variables:

• $links - A reference to the list (ul) of sharing links;
• $parent - the parent container of that list;
• $button - the button I’m going to swap in for the links;
• title - The page title (either from the page’s h1 or title element);
• $description - A reference to a meta description element;
• text - The text content of that description, if one is found; and
• url - The URL to be shared.

The second block sets up the button by inserting the text “Share” and an SVG share icon and setting an event listener on it that will pass the collected info to navigator.share().

The third and final block swaps out the link list for the button.

# Putting It All Together

The final step to putting this all together involves setting up the conditional that determines which enhancement is offered. To keep everything a bit cleaner, I’m also moving each of the enhancements into its own function:

!(function(window, document, navigator){functionprepForPopup(){// popup code}functionpopup(){// popup event handler}functionswapForShareAPI(){// share button code}if(“share”in navigator){swapForShareAPI();}else{prepForPopup();}})(this,this.document,this.navigator);

With this setup in place, I can provide the optimal experience in browsers that support the web share API and a pretty decent fallback experience to browsers that don’t. And if none of these enhancements can be applied, users can still share my content to the places I’ve identified… no cookies or third-party widgets required.

You can see (and play with) an isolated demo of this interface over on Codepen.

# Where it all started

I had the original idea for “projections” way back in 2019. Inspired by OS X’s Dashboard Widgets and Adobe AIR, I’d begun to wonder if it might be possible to project a component from a website into those kinds of surfaces. Rather than building a bespoke widget that connected to an API, I thought it made sense to leverage an installed PWA to manage those “projections.” I shared the idea at TPAC that year and got some interest from a broad range of folks, but didn’t have much time to work on the details until a few years later.

In the intervening time, I kept working through the concept in my head. I mean in an ideal world, the widget would just be a responsive web page, right? But if that were the case, what happens when every widget loads the entirety of React to render their stock ticker? That seemed like a performance nightmare.

In my gut, I felt like the right way to build things would be to have a standard library of widget templates and to enable devs to flow data into them via a Service Worker. Alex Russell suggested I model the APIs on how Notifications are handled (since they serve a similar function) and I was off to the races.

I drafted a substantial proposal for my vision of how PWA widgets should work. Key aspects included:

• A declarative way to define and configure a widget from within the Web App Manifest;
• A progressively enhanced pathway for devs to design a widget that adapts to its host environment, from using predefined templates to using custom templates to full-blown web-based widgets (with rendering akin to an iframe);
• A collection of recommended stock templates that implementors should offer to support most widget types;
• Extensibility to support custom templates using any of a variety of templating languages; and
• A complete suite of tools for managing widgets and any associated business logic within a Service Worker.

# Widgets became a reality

After continuing to gently push on this idea with colleagues across Microsoft (and beyond), I discovered that the Windows 11 team was looking to open up the new Widget Dashboard to third-party applications. I saw this as an opportunity to turn my idea into a reality. After working my way into the conversation, I made a solid case for why PWAs needed to be a part of that story and… it worked! (It no doubt helped that companies including Meta, Twitter, and Hulu were all invested in PWA as a means of delivering apps for Windows.)

While the timeline for implementation didn’t allow us to tackle the entirety of my proposal, we did carve out the pieces that made for a compelling MVP. This allowed us to show what’s possible, see how folks use it, and plan for future investment in the space.

Sadly, it meant tabling two features I really loved:

• Stock/predefined templates. A library of lightly theme-able, consistent, cross-platform templates based on common data structures (e.g., RSS/Atom, iCal) would make it incredibly simple for devs to build a widget. If implemented well, devs might not even need to write a single line of business logic in their Service Worker as the browser could pick up all of the configuration details from the Manifest.
• Configurable widget instances. Instead of singleton widgets, these would allow you to define a single widget type and replicate it for different use cases. For example, a widget to follow a social media user’s profile could be defined once and the individual instances could be configured with the specific account to be followed.

I’m sincerely hopeful these two features eventually make their way to us as I think they truly unlock the power of the widget platform. Perhaps, with enough uptake on the current implementation, we can revisit these in the not-too-distant future.

To test things out, I decided to build two widgets for this site:

1. Latest posts
2. Latest links

Both are largely the same in terms of their setup: They display a list of linked titles from this site.

# Designing my widget templates

Given that they were going to be largely identical, I made a single “feed” template for use in both widgets. The templating tech I used is called Adaptive Cards, which is what Windows 11 uses for rendering.

Adaptive Card templates are relatively straightforward JSON:

{“type”:“AdaptiveCard”,“$schema”:“http://adaptivecards.io/schemas/adaptive-card.json”,“version”:“1.6”,“body”: [{“$data”:“${take(items,5)}”,“type”:“Container”,“items”: [{“type”:“TextBlock”,“text”:“[${title}](${url})”,“wrap”:true,“weight”:“Bolder”,“spacing”:“Padding”,“height”:“stretch”}],“height”:“stretch”}],“backgroundImage”: {“url”:“https://www.aaron-gustafson.com/i/background-logo.png”,“verticalAlignment”:“Bottom”,“horizontalAlignment”:“Center”}}

What this structure does is:

1. Create a container into which I will place the content;
2. Extract the first five items from the data being fed into the template (more on that in a moment);
3. Loop through each item and
   • create a text block,
   • populate its content with Markdown to generate a linked title (using the title and url keys from the item object)
   • Set some basic styles to make the text bold, separate the titles a little and make them grow to fill the container; then, finally
4. Set a background on the widget.

The way Adaptive Cards work is that they flow JSON data into a template and render that. The variable names in the template map directly to the incoming data structure, so are totally up to you to define. As these particular widgets are feed-driven and this site already supports JSONFeed, I set up the widgets to flow the appropriate feed into each and used the keys that were already there. For reference, here’s a sample JSONFeed item:

{“id”:“…”,“title”:“…”,“summary”:“…”,“content_html”:“…”,“url”:“…”,“tags”:[],“date_published”:“…”}

If you want to tinker with Adaptive Cards and make your own, you can do so with their Designer tool.

# Defining the widgets in the Manifest

With a basic template created, the next step was to set up the two widgets in my Manifest. As they both function largely the same, I’ll just focus on the definition for one of them.

First off, defining widgets in the Manifest is done via the widgets member, which is an array (much like icons and shortcuts). Each widget is represented as an object in that array. Here is the definition for the “latest posts” widget:

{“name”:“Latest Posts”,“short_name”:“Posts”,“tag”:“feed-posts”,“description”:“The latest posts from Aaron Gustafson’s blog”,“template”:“feed”,“ms_ac_template”:“/w/feed.ac.json”,“data”:“/feeds/latest-posts.json”,“type”:“application/json”,“auth”:false,“update”:21600,“icons”:[{“src”:“/i/icons/webicon-rss.png”,“type”:“image/png”,“sizes”:“120x120”}],“screenshots”:[{“src”:“/i/screenshots/widget-posts.png”,“sizes”:“387x387”,“label”:“The latest posts widget”}]}

Breaking this down:

1. name and short_name act much like these keys in the root of the Manifest as well as in shortcuts: The name value is used as the name for the widget unless there’s not enough room, in which case short_name is used.
2. You can think of tag as analogous to class in HTML sense. It’s a way of labeling a widget so you can easily reference it later. Each widget instance will have a unique id created by the widget service, but that instance (or all instances, if the widget supports multiple instances) can be accessed via the tag. But more on that later.
3. The description key is used for marketing the widget within a host OS or digital storefront. It should accurately (and briefly) describe what the widget does.
4. The template key is not currently used in the Windows 11 implementation but refers to the expected standard library widget template provided by the system. As a template library is not currently available, the ms_ac_template value is used to provide a URL to get the custom Adaptive Card (hence “ac”) template. The “ms_” prefix is there because it’s expected that this would be a Microsoft-proprietary property. It follows the guidance for extending the Manifest.
5. The data and type keys define the path to the data that should be fed into the template for rendering by the widget host and the MIME of the data format it’s in. The Windows 11 implementation currently only accepts JSON data, but the design of widgets is set up to allow for this to eventually extend to other standardized formats like RSS, iCal, vCard, and such.
6. update is an optional configuration member allowing you to set how often you’d like the widget to update, in seconds. Developers currently need to add the logic for implementing this into their Service Worker, but this setup allows the configuration to remain independent of the JavaScript code, making it easier to maintain.
7. Finally, icons and screenshots allow us to define how the widget shows up in the widget host and how it is promoted for install.

When someone installs my site as a PWA, the information about the available widgets gets ingested by the browser. The browser then determines, based on the provided values and its knowledge of the available widget service(s) on the device, which widgets should be offered. On Windows 11, this information is routed into the AppXManifest that governs how apps are represented in Windows. The Windows 11 widget service can then read in the details about the available widgets and offer them for users to install.

# Adding widget support to my Service Worker

As I mentioned earlier, all of the plumbing for widgets is done within a Service Worker and is modeled on the Notifications API. I’m not going to exhaustively detail how it all works, but I’ll give you enough detail to get you started.

First off, widgets are exposed via the self.widgets interface. Most importantly, this interface lets you access and update any instances of a widget connected to your PWA.

# Installing a widget

When a user chooses to install a widget, that emits a “widgetinstall” event in your Service Worker. You use that to kickoff the widget lifecycle by gathering the template and data needed to instantiate the widget:

self.addEventListener(“widgetinstall”,(event)=>{console.log(</span><span class="token string">Installing </span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>event<span class="token punctuation">.</span>widget<span class="token punctuation">.</span>tag<span class="token interpolation-punctuation punctuation">}</span></span><span class="token template-punctuation string">);event.waitUntil(initializeWidget(event.widget));});

The event argument comes in with details of the specific widget being instantiated (as event.widget). In the code above, you can see I’ve logged the widget’s tag value to the console. I pass the widget information over to my initializeWidget() function and it updates the widget with the latest data and, if necessary, sets up a Periodic Background Sync:

asyncfunctioninitializeWidget(widget){awaitupdateWidget(widget);awaitregisterPeriodicSync(widget);return;}

The code for my updateWidget() function is as follows:

asyncfunctionupdateWidget(widget){const template =await(awaitfetch(widget.definition.msAcTemplate)).text();const data =await(awaitfetch(widget.definition.data)).text();try{await self.widgets.updateByTag(widget.definition.tag,{ template, data });}catch(e){console.log(</span><span class="token string">Couldn’t update the widget </span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>tag<span class="token interpolation-punctuation punctuation">}</span></span><span class="token template-punctuation string">, e);}return;}

This function does the following:

1. Get the template for this widget
2. Get the data to flow into the template
3. Use the self.widgets.updateByTag() method to push the template and data to the widget service to update any widget instances connected to the widget’s tag.

As I mentioned, I also have code in place to take advantage of Periodic Background Sync if/when it’s available and the browser allows my site to do it:

asyncfunctionregisterPeriodicSync(widget){let tag = widget.definition.tag;if(“update”in widget.definition){registration.periodicSync.getTags().then((tags)=>{// only one registration per tagif(!tags.includes(tag)){periodicSync.register(tag,{minInterval: widget.definition.update,});}});}return;}

This function also receives the widget details and:

1. Looks to see if the widget definition (from the Manifest) includes an update member. If it has one, it…
2. Checks to see if there’s already a Periodic Background Sync that is registered for this tag. If none exists, it…
3. Registers a new Periodic Background Sync using the tag value and a minimum interval equal to the update requested.

The update member, as you may recall, is the frequency (in seconds) you’d ideally like the widget to be updated. In reality, you’re at the mercy of the browser as to when (or even if) your sync will run, but that’s totally cool as there are other ways to update widgets as well.¹

# Uninstalling a widget

When a user uninstalls a widget, your Service Worker will receive a “widgetuninstall” event. Much like the “widgetinstall” event, the argument contains details about that widget which you can use to clean up after yourself:

self.addEventListener(“widgetuninstall”,(event)=>{console.log(</span><span class="token string">Uninstalling </span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>event<span class="token punctuation">.</span>widget<span class="token punctuation">.</span>tag<span class="token interpolation-punctuation punctuation">}</span></span><span class="token template-punctuation string">);event.waitUntil(uninstallWidget(event.widget));});

Your application may have different cleanup needs, but this is a great time to clean up any unneeded Periodic Sync registrations. Just be sure to check the length of the widget’s instances array (widget.instances) to make sure you’re dealing with the last instance of a given widget before you unregister the sync:

asyncfunctionuninstallWidget(widget){if(widget.instances.length ===1&&“update”in widget.definition){await self.registration.periodicSync.unregister(widget.definition.tag);}return;}

# Refreshing your widgets

Widget platforms may periodically freeze your widget(s) to save resources. For example, they may do this when widgets are not visible. To keep your widgets up to date, they will periodically issue a “widgetresume” event. If you’ve modeled your approach on the one I’ve outlined above, you can route this event right through to your updateWidget() function:

self.addEventListener(“widgetresume”,(event)=>{console.log(</span><span class="token string">Resuming </span><span class="token interpolation"><span class="token interpolation-punctuation punctuation">${</span>event<span class="token punctuation">.</span>widget<span class="token punctuation">.</span>tag<span class="token interpolation-punctuation punctuation">}</span></span><span class="token template-punctuation string">);event.waitUntil(updateWidget(event.widget));});

# Actions

While I don’t want to get too into the weeds here, I do want to mention that widgets can have predefined user actions as well. These actions result in “widget click” events being sent back to the Service Worker so you can respond to them:

self.addEventListener(“widgetclick”,(event)=>{const widget = event.widget;const action = event.action;switch(action){// Custom Actionscase“refresh”:event.waitUntil(updateWidget(widget));break;}});

For a great example of how a widget can integrate actions, you should check out the demo PWAmp project. Their Service Worker widget code is worth a read.

# Result!

With all of these pieces in place, I was excited to see my site showing up in the Widget Dashboard in Windows 11.

You can view the full source code on GitHub:

• “Feed” Adaptive Card Template
• Widget definitions in the Manifest
• Widgets code in my Service Worker

I’m quite hopeful this will be the first of many places PWA-driven widgets will appear. If you’s like to see them supported elsewhere, be sure to tell your browser and OS vendor(s) of choice. The more they hear from their user base that this feature is needed, the more likely we are to see it get implemented in more places.

# Addendum: Gotchas

In wiring this all up, I ran into a few current bugs I wanted to flag so you can avoid them:

• The icons member won’t accept SVG images. This should eventually be fixed, but it was keeping my widgets from appearing as installable.
• The screenshots members can’t be incredibly large. I’m told you should provide square screenshots no larger than 500px ×500px.

I’ve worked on the web for a long time. When I say a long time, I mean a long time. As in my first browser was on the command line old. As in my first back-end development was a CGI script old. With my nearly three decades of building dozens upon dozens of projects for the web, the one skill I’ve found most valuable is the ability to bridge the gaps between the worlds of design, user experience, and development.

Each of these fields attract practitioners from different education and/or hobbyist backgrounds. This can be a point of tension, as folks in each camp tend to see their own field as having the greatest influence on a web project’s success. The reality is that web exists in the nexus of these fields, relying equally on what each of these practices bring to the table. I have found that the most valuable people in any web project are those that understand enough of each field to be able to operate in that nexus, ensuring each team is communicating effectively with the other teams and that everyone is working together toward a shared goal.

Which brings me to Stephanie Stimac’s Design for Developers. This book is an invaluable resource for developers looking to level up in their understanding of what it takes to build for the web today. It provides a crash course in design and user experience in a way that will both improve your fluency with these topics and give you the necessary skills to become productive in these spaces as well. Beyond that superficial perspective, however, this book provides the foundation for leveling up your career and becoming the person who thrives in the space between design, user experience, and development.

Stephanie is the perfect person to provide you with these insights as well. Not only is she an excellent communicator, she also has years of working experience as a designer, developer, user experience practitioner, and an educator. She’s even worked behind the scenes on web browsers and the web standards they implement, giving her an incredible depth of understanding when it comes to the web and the tools we rely on to build it.

Whether you’re a longtime developer looking to grow a new branch on your skill tree or you’re starting out and looking to get a solid foundation in what it takes to build for the web, Design for Developers is sure to provide you with a wealth of knowledge to help you on your way.

Your app should work in a read-only mode without JavaScript.

That’s gonna be super useful for something I have planned!

I also love how succinctly he nails this section:

So, if progressive enhancement is no more expensive to create, future-proof, provides us with technical credit, and ensures that our users always receive the best possible experience under any conditions, why has it fallen by the wayside?

Because before, when you clicked on a link, the browser would go white for a moment.

JavaScript frameworks broke the browser to avoid that momentary loss of control. They then had to recreate everything that the browser had provided for free: routing, history, the back button, accessibility features, the ability for search engines to read the page, et cetera iterum ad infinitum. Coming up with solutions to these problems has been the fixation of the JavaScript community for years now, and we do have serviceable solutions for all of these — but all together, they create the incredibly complex ecosystem of modern-day JavaScript that so many JavaScript developers bemoan and lament.

All to avoid having a browser refresh for a moment.

I believe ‘good developer experience’ needs to be re-imagined as the enabling of developers to deliver reliable and first rate end user experiences — for as many users as possible, and for as long as possible. With this goal in mind, I think we’d be hard pressed to find a better starting point than the fundamentals of the web platform — that is, web browsers, HTTP, HTML, CSS, and JavaScript. These technologies have existed for decades in a near total state of backwards compatibility, while also consistently evolving to offer web developers ever more powerful techniques to deliver exceptional user experiences.

In particular, I was impressed with how they held the line on the importance of robustness in tools like this (from the “Choose the right tools and technology” section):

Before their reassessment, the team needs to … allow users who have issues using services with Javascript or have Javascript disabled. The team must build services for all users and cannot depend on client-side Javascript.

Which yielded results in their reassessment:

The panel was impressed that:

• the team has worked around the limitations for progressive enhancement of the service, resulting from the use of a serverless Single Page Application (SPA) architecture, which is a historical technology choice inherited from NHS loginthe team has ensured the service now works for all applicants without requiring JavaScript to be enabled
• the team has used the third party Paycasso identity verification mobile application to automate many parts of the process for validating an identity document, presenting a significant improvement versus the current remote identity check process via video link
• the team has used the no JavaScript route through the service which re-uses the business logic for the SPA route despite the UI forms being separately maintained for both routes

The assessment also provides guidance for further improvements to be made. Love this!