Tags: progressive

270

sparkline

Cascading Web Design with Feature Queries ◆ 24 ways

24 Ways is back! Yay! This year’s edition kicks off with a great article by Hui Jing on using @supports:

Chances are, the latest features will not ship across all browsers at the same time. But you know what? That’s perfectly fine. If we accept this as a feature of the web, instead of a bug, we’ve just opened up a lot more web design possibilities.

i is=”the walrus”

In which Brian takes a long winding route through an explanation of why the is attribute for custom elements is dead before he demonstrates the correct way to use web components:

<!-- instead of writing this -->
<input type="radio" is="x-radio">

<!-- you write this -->
<x-radio>
<input type="radio">
</x-radio>

Sadly, none of the showcase examples I’ve seen for web components do this.

Salva de la Puente - What is a PWA

Here’s a nice one-sentence definition for the marketing folk:

A Progressive Web App is a regular website following a progressive enhancement strategy to deliver native-like user experiences by using modern Web standards.

But if you’re talking to developers, I implore you to concretely define a Progressive Web App as the combination of HTTPS, a service worker, and a Web App Manifest.

Collapsible Sections

The latest edition of Heydon’s Inclusive Components is absolutely fantastic! The pattern itself—toggling sections of content—is quite straightforward, but then there’s a masterclass in how to create a web component that still allows the content to be accessible in older browsers. The key, as ever, is progressive enhancement:

Whether implemented through web components or not, progressive enhancement not only ensures the interface is well-structured and robust. As we’ve seen here, it can also simplify the editorial process. This makes developing the application and its content more inclusive.

Netflix functions without client-side React, and it’s a good thing - JakeArchibald.com

A great bucketload of common sense from Jake:

Rather than copying bad examples from the history of native apps, where everything is delivered in one big lump, we should be doing a little with a little, then getting a little more and doing a little more, repeating until complete. Think about the things users are going to do when they first arrive, and deliver that. Especially consider those most-likely to arrive with empty caches.

And here’s a good way of thinking about that:

I’m a fan of progressive enhancement as it puts you in this mindset. Continually do as much as you can with what you’ve got.

All too often, saying “use the right tool for the job” is interpreted as “don’t use that tool!” but as Jake reminds us, the sign of a really good tool is its ability to adapt instead of demanding rigid usage:

Netflix uses React on the client and server, but they identified that the client-side portion wasn’t needed for the first interaction, so they leaned on what the browser can already do, and deferred client-side React. The story isn’t that they’re abandoning React, it’s that they’re able to defer it on the client until it’s was needed. React folks should be championing this as a feature.

Building a CSS-only image gallery (with fallbacks)

A great step-by-step walkthrough of building a really nice image gallery without any JavaScript.

The end result is really impressive but there’s still the drawback that the browser history will be updated every time you click on an image thumbnail (because the functionality relies on ID attributes referenced via :target). Depending on your use-case, that may or may not be desirable.

Network Information API

It looks like this is landing in Chrome. The navigator.connection.type property will allow us to progressively enhance based on connection type:

A web application that makes use of a service worker to cache resources during installation might have different bundles of assets that it might cache: a list of crucial assets that are cached unconditionally, and a bundle of larger, optional assets that are only cached ahead of time when navigator.connection.type is 'ethernet' or 'wifi'.

There are potential security issues around fingerprinting that are addressed in this document.

Progressive Web Apps? No, we are building Alien Web Apps | Condé Nast Technology

There’s a lot of misinformation on the internet as to how to build a PWA and how “appy” and SPA-y one must be.

Yes!

This simply isn’t true. Disappointingly, It is what most of the documentation, blog posts and public discourse seem to imply.

Preach it!

I’m so, so happy to see some pushback against the misinformation that progressive web apps automatically imply client-side rendered single page apps built from scratch. There’s so much value to be had in turbo-charging an existing site into a progressive web app.

But what we don’t need is yet another TLA like Alien Web Apps.

How much storage space is my Progressive Web App using? | Dean Hume

You can use navigator.storage.estimate() to get a (vague) idea of how much space is available on a device for your service worker caches.

Infusion: An Inclusive Documentation Builder

Two of my favourite things together at last: pattern libraries and service workers. Infusion is a tool for generating pattern libraries that also work offline.

Thinking about it, it makes total sense that a pattern library should be a progressive web app.

Tame your Service Worker before your Progressive Web App go into the wild by Maxim Salnikov

There are some great service worker optimisation tips in these slides.

Basic grid layout with fallbacks using feature queries

A really nice example of progressive enhancement: creating a layout with inline-block, then flexbox, then Grid.

Betting on the Web

Along the lines of John’s recent post, Henrik makes the business case for progressive web apps.

He also points out how they can be much better than native apps for controlling hardware.

They can be up and running in a fraction of the time whether or not they were already “installed” and unlike “apps” can be saved as an app on the device at the user’s discretion!

Essentially they’re really great for creating “ad hoc” experiences that can be “cold started” on a whim nearly as fast as if it were already installed.

A Progressive Web Approach to a Networked Economy - Web Directions

John makes the point that unless you’re one of the big, big players, your native app is really going to struggle to find an audience. But that’s okay—a progressive web app might be exactly what you need.

In short, using native apps as a path to reaching a large number of potential customers and benefitting from crucial network effects is close to impossible.

But, in the meantime, the Web has responded to the very significant impact that native apps had on user behaviour.

For me, the strength of the web has never been about how it can help big companies—it’s about how it can amplify and connect the niche players.

Categories land in the Web App Manifest | Aaron Gustafson

Manifest files can have categories now. Time to update those JSON files.

Yes, That Web Project Should Be a PWA · An A List Apart Article

A fantastic piece by Aaron who—once again—articulates what I’ve been thinking:

Your site—every site—should be a PWA.

He clearly explains the building blocks of progressive web apps—HTTPS, a manifest file, and a service worker—before describing different scenarios for different kinds of sites:

  • Informational
  • Periodical
  • Transactional
  • Social
  • Software
  • Institutional

Progressive Web Apps may seem overly technical or beyond the needs of your project, but they’re really not. They’re just a shorthand for quality web experiences—experiences that can absolutely make a difference in our users’ lives.

Highly recommended!

A Progressive Roadmap for your Progressive Web App - Cloud Four

Jason lists the stages of gradually turning the Cloud Four site into a progressive web app:

And you can just keep incrementally adding and tweaking:

You don’t have to wait to bundle up a binary, submit it to an app store, and wait for approval before your customers benefit.

Progressive Progressive Web Apps - Tales of a Developer Advocate by Paul Kinlan

Paul goes into detail describing how he built a progressive web app that’s actually progressive (in the sense of “enhancement”). Most of the stuff about sharing code between server and client goes over my head, but I understood enough to get these points:

  • the “app shell” model is not the only—or even the best—way of building a progressive web app, and
  • always, always, always render from the server first.

CSS: Current, Soon, Someday (Web Directions Code 2017) // Speaker Deck

Oh, how I wish I could’ve been at Web Directions Code in Melbourne to see this amazing presentation by Charlotte. I can’t quite get over how many amazing knowledge bombs she managed to drop in just 20 minutes!

Progressively Enhancing CSS Layout: From Floats To Flexbox To Grid – Smashing Magazine

A great example of progressive enhancement in action.

You can perfectly use CSS grid layout today if you don’t expect exactly the same appearance in every single browser, which isn’t possible to achieve nowadays anyway. I’m well aware that this decision isn’t always up to us developers, but I believe that our clients are willing to accept those differences if they understand the benefits (future-proof design, better accessibility and better performance). On top of that, I believe that our clients and users have — thanks to responsive design — already learned that websites don’t look the same in every device and browser.