Tags: progressive

shawnbot/custom-elements: All about HTML Custom Elements

A good introduction to custom elements, one piece of the web components stack.

That said, when using custom elements—or anything involving JavaScript, for that matter—you should always design experiences for progressive enhancement, and plan for the possibility that JavaScript isn’t enabled or available.

Hmmm …that’s kind of hard when JavaScript is required to make custom elements work at all.

Adapting to Input · An A List Apart Article

Jason breaks down the myths of inputs being tied to device form factors. Instead, given the inherent uncertainty around input, the only sensible approach is progressive enhancement.

Now is the time to experiment with new forms of web input. The key is to build a baseline input experience that works everywhere and then progressively enhance to take advantage of new capabilities of devices if they are available.

The best of Google I/O 2016 | Andrew Betts

Andrew picks out his favourite bits from this year’s Google I/O, covering web payments, CSS containment, and—of course—Service Workers and progressive web apps, although he does note (and I concur):

I wish Google would focus as much attention on ‘normal’ sites that perform navigations as they do on so called ‘app-shell’ (which is just a new name for single-page apps, as far as I can tell), but then many people will be building SPAs and these recipes will make those apps fly. In news publishing we seem to flip flop between traditional page navigations and SPAs, but I’ve never found a SPA news site (or a native app) that I really like more than a normal website. Maybe a really good progressive web app will change that. But I’m not convinced.

Still, as he says:

All this really just underscores how flexible ServiceWorker is and that with it we can disagree on what the right solution is, but we can all get what we want anyway.

The Business Case for Progressive Web Apps - Cloud Four

Jason looks at the business reasons for and against building progressive web apps. In short, there’s everything to gain and nothing to lose.

Seriously, why would you not add a Service Worker and a manifest file to your site? (assuming you’re already on HTTPS)

The Progress of Web Apps | Microsoft Edge Dev Blog

The roadmap for progressive web apps from Microsoft; not just their support plans, but also some ideas for distribution.

EmberCamp London Keynote 2016 // Speaker Deck

I really, really like what Ember is aiming for here:

First, we deliver the raw content, ensuring those on slow connections or without JavaScript get they’re after as soon as possible. Next, we load the minimum set of JavaScript needed to interactivity for that page, keeping transfer time and parsing time low. Once the user has an interactive page, we can start preemptively loading other parts of the application, including frequently-accessed data.

That’s how you get the holy grail of resilience and performance:

Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.

I sincerely hope other frameworks are paying attention to this layered approach.

Oh, and I also like this observation:

There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.

Completely CSS: Progressively Collapsing Navigation | Kenan Yusuf

One way of implementing the growing/shrinking navigation pattern—an alternative to just shoving everything behind a hamburger icon.

Progressive Web Apps Dev Summit | hiddedevries.nl

Hidde’s write-up of the Progressive Web App Dev Summit:

It was exciting to hear about the technologies, and to see that a lot of them already work on a great deal of platforms. Most of the major browser vendors expressed how much they liked the idea, so it is realistic to say support will increase in the short term. This, and the fact that all PWA techniques can be regarded as a ‘progressive enhancement’ (with some leniency as to what that term means), entails that we can build Progressive Web Apps today.

Hopefully, we will do so responsibly. Native apps really only work on their particular platforms. PWAs, in theory, can be built to work universally. For everyone with a web enabled device. This is awesome! Major browser vendors are behind the idea, and I think as developers we should be, too.

Apps are dying by Cameron Moll

Cameron looks back on his 2007 Mobile Web Design book:

I don’t anticipate native apps will die off anytime soon. But I’m warming to the idea that they may be less relevant to the future of the web, and I reaffirm that “a browser will be — or should be — sufficient for interacting with web content.”

Progressive web apps are poised to be remarkably relevant to the future of the web. Let’s not screw it up.

Dev.Opera — Making progressive web apps even better: ambient badging and “pop into browser”

Andreas demoed these ideas yesterday. Proper ambient badging and a way of getting at URLs even if a progressive web app is running in fullscreen or standalone mode. Great stuff!

ManifeStation - Automagically create your Web App Manifest

If you’re going to make a manifest file for an existing site, start with this very handy tool. You give it the URL of your site and it then parses the content for existing metadata to create a best first stab at a manifest JSON file.

Resilience Poster Talk from Jeremy Keith by jessman5Stuff on Etsy

This beautiful poster could be the ideal decoration for your home or office.

You can download the original size (DIN A3) and print it to hang it on the walls in your office or wherever you want.

Enhancing Optimistically | Filament Group, Inc., Boston, MA

I love the thinking that Scott puts into all aspects of building on the web. Here, he outlines a really robust approach to cutting the mustard for progressive enhancement.

The web is catching up on mobile

A good impartial overview of progressive web apps, as described at the most recent Google I/O. This is very telling:

At the start I found the term a bit confusing as some PWA examples are single page applications (SPA) controlled by JavaScript. These apps are not strictly using progressive enhancement where JavaScript is added on top to enhance the experience.

The term also begs the question; what is the difference between websites and apps? It seems many of the new capabilities fit well for any dynamic website, not just apps.

Anyhow. It’s good to have an umbrella term to talk about these things.

Progressive Web App Dev Summit 2016 | Home

Google have asked me to moderate a panel on the second day of this event in Amsterdam dedicated to progressive web apps. Very brave of them, considering some of my recent posts.

Progressive web apps – let’s not repeat the errors from the beginning of responsive web design | justmarkup

Those who cannot remember the past are doomed to repeat it:

When people learned about responsive design, there were many wrong assumptions. The iPhone and early Android phones all had the same screen size (320x480px) and people thought it is a good idea to change the design based on these device-specific sizes.

We wouldn’t do that now, right? We wouldn’t attempt to create something that’s supposed to be a progressive web app, only to make it device-specific, right?

We are still at the beginning of learning about the best ways to build Progressive Web Apps. I hope it will make many more people aware of progressive enhancement. I hope that nobody makes the error again and concentrates on the device part.

as days pass by — Programmatic Progressiveness

Stuart’s ideas for Lighthouse sound a lot like the resilience validator tool that Scott mentioned recently.

This is our chance to help stamp out sites that don’t do things right, and help define that a progressive web app should actually be progressive.

If you have ideas on this, please file an issue.

PWA Discovery: You Ain’t Seen Nothin Yet | Infrequently Noted

Smart thinking from Alex on how browsers could better indicate that a website is a progressive web app (and would therefore benefit from being added to the home screen). Ambient badging, he calls it.

Wouldn’t it be great if there were a button in the URL bar that appeared whenever you landed on a PWA that you could always tap to save it to your homescreen? A button that showed up in the top-level UI only when on a PWA? Something that didn’t require digging through menus and guessing about “is this thing going to work well when launched from the homescreen?”

Progressively less progressive | Andrew Betts

I agree with everything Andrew says here. Progressive web apps are great, but as long as Google heap praise on mobile-only solutions (like the Washington Post doorslam) and also encourage separate AMP sites, they’re doing a great disservice to the web.

More features arrive regularly to make this “one web” even better and easier to maintain. Service worker, streams, app manifests, payment request, to name a few. But adding these features one at a time to large, mature applications like WaPo or FT or Nikkei is a slow and painstaking process. That’s why it’s taking us a long time for us to tick off all these new features, and why it seems like madness to try and build the entire app several times over.

However, by creating the concept of PWAs and marketing them as they do, Google is encouraging publishers to ‘start again’. And they’re doing exactly the same thing with AMP.

Going Offline With Progressive Web Apps

Dave turned Day Trip into a progressive web app.

Starting this week, Android users (~13% of our active user base) who use DayTrip more than once will eventually be asked if they want to install our web app to their Home Screen. That’s important real estate for a small startup like ourselves.

Progressive Enhancement and Modern JavaScript ― Caolan

I think JavaScript frameworks have been blinkered to the needs of many developers (most websites are not SPAs or run by Node, nor should they be) for too long. We need to find a way to apply the lessons of modern frameworks to the rest of the web - it would be sad if everyone had to run JavaScript on their server and good-old resilient HTML was considered only as a fallback.

Yet another blog about the state and future of Progressive Web App - The blog of Ada Rose Edwards

Bravo!

In the web developer community’s collective drive to be more App Like and compete with native apps we may lose or weaken some of the web’s strongest features and we need to consider carefully before we throw away urls or the entire browser chrome in an effort to look like and behave like the cool kids of native.

You can hear more of Ada’s thoughts on progressive web apps on a recent episode of JavaScript Air.

Not The Post I Wanted To Be Writing… – Infrequently Noted

Phew! Alex seems to have calmed down. He’s responding to my concerns about exposing URLs in progressive web apps, but thankfully without the absolutist rhetoric or insults. Progress!

DRY: Do Repeat Yourself - QuirksBlog

Y’know, I think PPK might be on to something here. It’s certainly true that developers have such an eversion to solving a problem twice that some users end up paying the cost (like in the examples of progressive enhancement here).

I will be pondering upon this.

turbolinks/turbolinks: Turbolinks makes navigating your web application faster

I really, really like the approach that this JavaScript library is taking in treating Ajax as a progressive enhancement:

Turbolinks intercepts all clicks on a href links to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using XMLHttpRequest, and then renders the HTML response.

During rendering, Turbolinks replaces the current body element outright and merges the contents of the head element. The JavaScript window and document objects, and the HTML html element, persist from one rendering to the next.

Here’s the mustard it’s cutting:

It depends on the HTML5 History API and Window.requestAnimationFrame. In unsupported browsers, Turbolinks gracefully degrades to standard navigation.

This approach matches my own mental model for building on the web—I might try playing around with this on some of my projects.

Progressive Web Apps and our regressive approach | Christian Heilmann

So remember when I was talking about “the ends justify the means” being used for unwise short-term decisions? Here’s a classic example. Chris thinks that Progressive Web Apps should be made mobile-only (at least to start with …something something something the future):

For now, PWAs need to be the solution for the next mobile users.

End users deserve to have an amazing, form-factor specific experience.

I couldn’t disagree more. End users deserve to have an amazing experience no matter the form-factor of their device.

Beyond Progressive Web Apps • cssence.com

Matthias Beitl takes a stab at trying to tackle the tricky UI problem of exposing the URLs of Progressive Web Apps. This stuff is hard.

Pakyow Web Framework

This looks like a really interesting server-side framework for Ruby developers. The documentation is nice and clear, and puts progressive enhancement at the heart of its approach.

No Really, For Everyone | Benjamin Listwon

A heartfelt call to web developers to consider the needs of the many and varied people trying to use what we build.

None of this is about Javascript. None of this is about CSS transforms or WebGL. None of this is about technology at all.

It is about making products that serve all users equally. It is about putting ourselves in others’ shoes. It is about trying to imagine the frustration and difficulty of using our products when the conditions aren’t what we’re used to. It is about being human.

Developing Dependency Awareness – Smashing Magazine

A typically superb article by Aaron. Here, he breaks down a resilient approach to building for the web by examining the multiple ways you could add a button to a page. There’s a larger lesson here too:

We don’t control where our web-based products go or how our users access them. All we can do is imagine as many less-than-perfect scenarios as possible and do our best to ensure our creations will continue to do what they’re supposed to do. One of the easiest ways to do that is to be aware of and limit our dependencies.

Building Web Apps for Everyone - O’Reilly Media

Here’s a fantastic and free little book by Adam Scott. It’s nice and short, covering progressive enhancement, universal JavaScript, accessibility, and inclusive forms.

Download it now and watch this space for more titles around building inclusive web apps, collaboration, and maintaining privacy and security.

Did I mention that it’s free?

Render 2016 - Jeremy Keith on Vimeo

Here’s another version of my talk Resilience—the same one I gave at Beyond Tellerrand—this time from the Render conference in Oxford.

Jeremy Keith on Vimeo

Here’s the video of the talk I just gave at the Beyond Tellerrand conference in Düsseldorf: Resilience.

Rebuilding the Perch UI - not your usual redesign

The Perch Control Panel is progressively enhanced. Almost all functionality of Perch is available even if you completely disable JavaScript, or if JavaScript fails to load.

An Event Apart News: The Contributions of Others: A Session with Jeremy Keith

Eric asked me some questions and I was only too happy to give some answers.

Progressive Web Apps have leapfrogged the native install model … but challenges remain

While many challenges remain, the good news is … it’s progressive. Developers can already see the benefits by sprinkling in these technologies to their existing websites and proceed to build on them as browsers and operating systems increase support.

RAFP: a proposal for performance measurements through requestAnimationFrame - QuirksBlog

Here’s an interesting proposal from ppk: use requestAnimationFrame to gauge how performant a browser in behaving and then enhance accordingly.

Introduction to Ember FastBoot by Tom Dale on Vimeo

I’m so happy that Ember is moving to a server-side rendering model. Not only that, but as Tom points out here, it’s crucial that the server-side rendering is the default and the client-side functionality than becomes an enhancement.

Web Manifest Validator

If you have a manifest.json file for your site, here’s a handy validator.

Progressive web apps: the long game

Remy sums up the psychological end goal of progressive apps (HTTPS + Service Worker + manifest JSON file) prompting an add to home screen action:

This high bar of entry will create a new mental model for our users.

If I add this app to my home screen, it will work when I open it.

It’s a shame that this charge to turbo-boast the perception of the web on mobile is a bit one-sided: I would love to see Apple follow Google’s lead here. But if Android succeed in their goal, then I think iOS will have to follow suit just to compete.

Bruce Lawson’s personal site  : One weird trick to get online — designers hate it!

I don’t care about Opera Mini (I’m not its Product Manager). In the same way, I don’t care about walking sticks, wheelchairs, mobility scooters or guide dogs. But I care deeply about people who use enabling technologies — and Opera Mini is an enabling technology. It allows people on feature phones, low-powered smartphones, people in low-bandwidth areas, people with very small data plans, people who are roaming (you?) connect to the web.

Web Progressions

This looks a good (free!) event in London all about the latest browser goodies, all wrapped in the “progressive apps” buzzword.

Alas, I’ll be making my way back from Indie Web Camp Düsseldorf the day this is on.

Introducing A11y Toggle

Here’s a bit of convergent evolution: Hugo’s script is similar to what I wrote about recently.

He also raises a point that Kevin mentioned:

I would like to investigate on the details and summary elements as they are basically a native implementation for content toggles.

For some reason details never got much browser love, even though it’s clearly paving a well-trodden cowpath.

Design is choice by Jaime Caballero

A lovely outlook on designing with progressive enhancement:

There will always be users coming from places you didn’t expect, using devices you didn’t test for.

Simon McManus - YouTube

Come for the videos of EnhanceConf. Stay for the skateboarding beagle.

An update (March 2016) on the current state & recommendations for JavaScript …

Making web apps? Care about SEO? Here’s Google’s advice:

Use feature detection & progressive enhancement techniques to make your content available to all users.

Maybe we could tone down the JavaScript / fuzzy notepad

Accept that sometimes, or for some people, your JavaScript will not work. Put some thought into what that means. Err on the side of basing your work on existing HTML mechanisms whenever you can.

If you’re going to override or reimplement something that already exists, do some research on what the existing thing does first. You cannot possibly craft a good replacement without understanding the original.

Remember that for all the power the web affords you, the control is still ultimately in end user’s hands.

Embracing simplicity by Adam Silver

The full text of Adam’s excellent talk at EnhanceConf.

EnhanceConf - Stefan Tilkov - How to embrace the browser - YouTube

The videos from EnhanceConf are started to go up already. Stefan’s talk really struck me—all the talks were great but this one had the most unexpected insight for me. It really clarifies a lot of ideas that I’ve been trying to articulate, but which Stefan crystalises by taking the long-zoom view.

Progressive Web Apps London

On the same day—and in the same city—as that Mobile @Scale event that Facebook are hosting, Google are hosting their own free event all about Progressive Web Apps, the buzziest of buzzwords.

Shame I can’t be in two places at once.

The New Web Typography › Robin Rendle

A wonderfully thoughtful piece on typography, Jan Tschichold and the web. This really resonated with me:

It’s only been over the past year or so in which I’ve recognised myself as a ‘Web designer’ with a capital W, as I now believe that something happens to information and technology, and even typography itself, when people pass through these interconnected networks and interact with hypertext.

It’s for these reasons that I don’t believe in “digital design” or “designing for screens” and it’s why I’m often attracted to one particular side of this spectrum.

Robin proposes three “principles, suggestions, outlines, or rather things-that-I-ought-to-be nervous-about when setting text on the web”:

  1. We must prioritise the text over the font, or semantics over style.
  2. We ought to use and/or make tools that reveal the consequences of typographic decisions.
  3. We should acknowledge that web typography is only as strong as its weakest point.

There’s an in-depth look at applying progressive enhancement to web type, and every single link in the resources section at the end is worth investigating.

Oh, and of course it’s beautifully typeset.

Keeping a smart home guest-friendly — Sensors and sensibility

In web development, we have this concept of progressive enhancement, which means that you start by building websites with the very most basic blocks - HTML elements. Then you enhance those basic elements with CSS to make them look better, then you add JavaScript to make them whizzy - the benefit being that if the JS or the CSS fail to load, you’ve still go the basic usable blocks underneath. I’m following this same principle in the house.

Related: this great chat between Jen Simmons and Stephanie Rieger.

Progressive Enhancement Gets a Conference, From the Notebook of Aaron Gustafson

Aaron interviews Simon who’s organising the upcoming EnhanceConf which is going to be ruddy good.

Ethical Web Development

I really, really like these principles. Time to add them to the list.

The accessibility stack: making a better layer cake » Simply Accessible

A great description of a solid architectural approach to building on the web (and not just for accessibility either).

EnhanceConf line-up by Simon McManus

This is shaping up to be a great affordable one-day event in London on March 4th. The format will be similar to Responsive Day Out.

I suggest you grab a ticket.

Words of Wisdom from @adactio - Matt Radford

A larger screen is now a progressive enhancement. Hell, with things like Siri and Google Now and Amazon’s Echo, we’re getting to the point where even a screen is an enhancement.

JavaScript web apps considered valuable · molily

A response to a rant I linked to recently.

The solution for bad JavaScript web apps is not to abandon them altogether, but to make better ones.

I couldn’t agree more. The tools have evolved and we now have frameworks and practices that allow us to render from the server and use the same code to render on the client, progressively enhancing from a solid robust base.

JavaScript is the best technology to build excellent interactivity in the browser. Still, the most important skill of a client-side JavaScript developer is to know when not to solve a problem with client-side JavaScript. It’s always more robust to solve a problem further down in the stack.

The problem is that I don’t see a willingness from developers to embrace this way of thinking. Instead I see it dismissed as being unrealistic or more expensive.

Still, it always takes time for behaviour to change so maybe things will only get better. I certainly hope so.

Don’t tell me what my browser can’t do! by Christian Heilmann

A great piece by Christian on taking a responsible, customer-focused approach to building on the web.

You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of giving a usable interface to end users. A button that does nothing when you click it is not a good experience. Test if the functionality is available, then create or show the button.

Yes, this is an argument for progressive enhancement. No, that does not mean you can’t use JavaScript.

You can absolutely expect JavaScript to be available on your end users computers in 2016. At the same time it is painfully naive to expect it to work under all circumstances.

Why I hate your Single Page App by Stefan Tilkov

A linkbaity title for a ranty post. But it’s justified.

My point is that from an architectural perspective, most single page apps are the result of making the wrong choices and missing important opportunities.

Reimagining Single-Page Applications With Progressive Enhancement – Smashing Magazine

Some really great thinking here by Heydon on how to make single page apps but using HTML for the views instead of relying on client-side JavaScript for the rendering. He explains the code he’s using, but what really matters here isn’t the specific solution; it’s the approach. Smart!

The Problem with Progressive Enhancement by Alex Lande

I think that “Do we want to support users without JS?” is the wrong question. Progressive enhancement has benefits that reach far beyond that user group.

Specifically:

  1. Performance—”Progressively enhanced behaviors like using links that point to real URLs, or server-side form submission handling, allow users to perform important actions before JavaScript loads.”
  2. Resilience—”If users can perform critical tasks when your JS breaks, it’s a minor inconvenience instead of a show stopper.”
  3. Business, Business, Business.

Photo upload and progressive enhancement for FixMyStreet / mySociety

Matthew describes a very nice bit of progressive enhancement for drag’n’drop file uploads (similar to the CSS Tricks article I linked to recently).

It uses the Dropzone JS which looks like it aligns nicely with the progressive enhancement approach.

What Progressive Web Apps Mean for the Web - Telerik Developer Network

A hands-on look at building a progressive web app with Service Workers, manifest files, HTTPS, and all that good stuff. This is nice and balanced, extolling the virtues but also warning about the potential difficulties in implementing this stuff.

One nitpick though: there’s talk of graceful degradation, and while I get that that’s the outcome, I think it’s better to think in terms of progressive enhancement, which is the approach.

Putting My Patterns through Their Paces ◆ 24 ways

Ethan demonstrates progressive enhancement at the pattern level using flexbox.

I’ve found that thinking about my design as existing in broad experience tiers – in layers – is one of the best ways of designing for the modern web.

Progressive Enhancement—Ain’t Nobody Got Time for that | GlückPress

Two sides of a debate on progressive enhancement…

Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:

If your content website breaks down from JavaScript issue — it is broken.

Joe Hoyle disagrees:

Unlike Rarst, I don’t value progressive enhancement very highly and don’t agree it’s a fundamental principle of the web that should be universally employed. Quite frankly, I don’t care about not supporting JavaScript, and neither does virtually anyone else. It’s not that it doesn’t have any value, or utility - but in a world where we don’t have unlimited resources and time, one has to prioritise what we’ll support and not support.

Caspar acknowledges this:

I don’t have any problem buying into pragmatism as the main and often pressing reason for not investing into a no-JS fallback. The idealistic nature of a design directive like progressive enhancement is very clear to me, and so are typical restrictions in client projects (budgets, deadlines, processes of decision making).

But concludes that by itself that’s not enough reason to ditch such a fundamental technique for building a universal, accessible web:

Ain’t nobody got time for progressive enhancement always, maybe. But entirely ditching principle as a compass for resilient decision making won’t do.

See also: Mike Little’s thoughts on progressive enhancement and accessibility.

The web will always be a moving target : Eclectic Dreams

Caution:

It would be convenient to think that because we live in a world where people’s browsers are regularly updating, that we live in a world where the web is in a reliable state.

Reminder:

The web is a continually moving target. It probably changed in the time it took me to write this. If you work with web stuff you need to embrace this fact. It will be the only constant in your career.

Do not panic:

On the web progressive enhancement is and will always be, the methodology of choice. It makes your site robust to the shifting sands of the web front end.

Universal React ◆ 24 ways

I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:

  • The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
  • In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
  • The next time a user clicks, rather than being sent to the server, the client-side app is in control.
  • If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.

YES!!!

Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

Progressive enhancement needs better advocacy • Zetafleet

A rousing call to arms for progressive enhancement. I agree with the sentiment, but I’m less comfortable making assumptions about the reasons why developers don’t use progressive enhancement:

However, what’s actually happening is that “universal access to content” is being subversively replaced with “universal access for a limited subset of users that I care about”.

Honestly, I think that plenty of developers just aren’t thinking about it—especially if they’re relying on a particular tool or framework to save them time and effort (which is not a crime). So that’s why I agree with the title of this piece: let’s talk about this more; let’s make sure developers understand what they’re doing when they make JavaScript a requirement for basic functionality.

I particularly like the point in here about content blockers like NoScript:

In fact, it’s probably more likely that a user will try browsing the Web today without scripting than at any other time since the 1990s.

Drag and Drop File Uploading | CSS-Tricks

This is a terrific example of progressive enhancement in action: going from a simple file input to a lovely interactive drag’n’drop interface.

The code uses jQuery but it could be easily adapted to vanilla JavaScript, and anyway, it’s not so much the code that matters, it’s the approach.

Blocked! - O’Reilly Radar

Following on from that Wired article I linked to about disabling JavaScript, Simon St. Laurent brings in another factor—content blockers on iOS:

Apple offers its users the power to turn off much of the Web: fonts, styles, scripts, and more.

He rightly points out that the answer to building a robust, resilient web has been here all along:

Turning off web fonts, CSS, and images will frustrate designers and limit user interface possibilities, but turning off JavaScript might mean that we have to reconsider the architecture of our applications. Without JavaScript, the Web returns to its foundations of HTTP requests returning pages, with links and form submissions as the backbone of application structure.

Bruce Lawson’s personal site  : Progressive Web Apps: ready for primetime

Bruce gives a great run-down of what’s involved in creating one of those new-fangled progressive apps that everyone at Google and Opera (and soon, Mozilla) are talking about: a secure connection, a service worker, and a manifest file.

Crucially, in browsers that don’t support it, you have a normal website. It’s perfect progressive enhancement.

Funnily enough, this here website—adactio.com—is technically a progressive app now.

At their simplest, Progressive Web Apps are application-like things hosted on your web server. If you’re as old as me, you might call them “web sites”

Instant Loading Web Apps With An Application Shell Architecture | Web Updates - Google Developers

Outlining the architectural thinking required to create what the Google devrel folks are calling progressive apps.

Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering…

Yay!

…but this is only one of many options.

Hmmm. In my opinion, sending usable HTML on first request isn’t an implementation detail—it’s crucial. But on the whole, this approach is very sensible indeed.

Google+ | Google Web Showcase - Google Developers

Paul gives the lowdown on the Google+ responsive relaunch. They set themselves this performance budget:

  • 60K of HTML,
  • 60K of CSS,
  • 60K of JavaScript,
  • 60 frames per second animations, and
  • 0.6 seconds latency.

And this bit is crucial:

One of our major rules was that all our pages needed to be both server-side and client-side rendered. With server-side rendering we make sure that the user can begin reading as soon as the HTML is loaded, and no JavaScript needs to run in order to update the contents of the page.

Best viewed with - Velocity Amsterdam 2015 // Speaker Deck

Are we doomed to see history repeat itself? With the amount of client-side MVC frameworks and the upcoming implementation of the ES6 syntax, will we soon be seeing a repeat of the “browser wars.” Will more websites only work in a select number of browsers with the capabilities to run their code?

Delivering Responsibly

The full transcript of Scott’s excellent presentation on performance and progressive enhancement.

EnhanceConf — Call For Proposals

There’s going to be a conference about progressive enhancement. It’ll happen in London in March of next year. You should speak at it.

You’ve got until December 20th to submit your proposal. What have you got to lose?

Official Google Webmaster Central Blog: Deprecating our AJAX crawling scheme

It’s official: hash bang URLs are an anti-pattern, and if you want your content indexed by Google, use progressive enhancement:

Since the assumptions for our 2009 proposal are no longer valid, we recommend following the principles of progressive enhancement.

Jeremy Keith - Responsive Field Day 2015 - YouTube

Here’s the 20 minute talk I gave at the inaugural Responsive Field Day in Portland.

Miranj: Collateral Damage

Websites should not come with minimum software requirements.

An Event Apart News: Enhance! by Jeremy Keith—An Event Apart video

Here’s the video of the talk I gave at An Event Apart last year.

Guess what it’s about. Go on, guess!

No! It’s about progressive enha… oh.

More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson

Aaron collects some recent examples that demonstrate

  1. why we should use HTTPS and
  2. why we should use progressive enhancement.

The tough truth of reality by Chris Taylor

Progressive enhancement is not about “what if users turn JavaScript off” but “what happens when the page is loaded in sub-optimal circumstances”.

A fictional conversation about progressive enhancement

So a web app is defined as a system that requires the JavaScript excesses for it to work. And the argument for the JavaScript excesses is that we need it to build web apps. That sounds a teeny bit circular to me.

Jeremy Keith – Enhance! – Beyond Tellerrand Düsseldorf 2015 on Vimeo

The video of my talk at this year’s Beyond Tellerrand. I was pleased with how this went, except for the bit 16 minutes in when I suddenly lost the ability to speak.

Making Charts with CSS | CSS-Tricks

What a lovely bit of progressive enhancement—styling data tables to display as charts.

Edge Conference 2015 - 5 Progressive Enhancement - YouTube

Here’s the video of the panel I participated in at Edge conference, expertly moderated by Lyza.

Thanks to the video editing, you can’t see the face I’m making when the guy from Facebook talks about user-agent sniffing as a totally cool and reliable way of working.

Designing with Progressive Enhancement — sixtwothree.org

The full text of Jason’s great talk at this year’s CSS Summit. It’s a great read, clearing up many of the misunderstandings around progressive enhancement and showing some practical examples of progressive enhancement working at each level of the web’s technology stack

It’s time to progress

Many believe we should leave the term “progressive enhancement” behind and start anew, but why not educate developers, clients and stakeholders and change many of the misconceptions surrounding it? Changing the name won’t change anything unless we address the real fundamental problems we have when describing the underlying concepts.

Why availability matters

A superb illustration of why playing the numbers game and dismissing even a small percentage of your potential audience could be disastrous.

It’s not 1% of people who always can’t see your site and 99% of people who always can. It’s 1% of visits. Almost all the people who don’t get your site correctly actually should have been able to. They don’t have JavaScript turned off. They’re not browsing on a WAP phone over a 2g connection from a shanty town. They’re you, in a cellar bar or a hotel room or waiting for the phone network to wake back up.

Thriving in Unpredictability - TimKadlec.com

This is the way to approach building for the web:

I want to make as few of those assumptions as possible. Because every assumption I make introduces fragility. Every assumption introduces another way that my site can break.

It’s progressive enhancement, but like Stuart, Tim is no longer planning to use that term.

as days pass by — Availability

Stuart writes up his thoughts on progressive enhancement following the great discussions at Edge Conf:

So I’m not going to be talking about progressive enhancement any more. I’m going to be talking about availability. About reach. About my web apps being for everyone even when the universe tries to stop it.

Progressive Apps: Escaping Tabs Without Losing Our Soul – Infrequently Noted

I really like Alex’s framing of best-of-breed progressively enhanced websites as “progressive apps” (although Bruce has some other ideas about the naming).

It’s a shame that the add-to-homescreen part isn’t standardised yet though.

Interface Experience Maps, From the Notebook of Aaron Gustafson

This sounds like it could be a very useful tool to introduce early in projects to get a shared understanding of progressive enhancement.

Dev.Opera — Making websites that work well on Opera Mini

Using Progressive Enhancement makes your site better for all users and enables the 275 million users of Opera Mini worldwide.

How we built the new gocardless.com — GoCardless Blog

A classic example of the holy grail of web performance and robustness—start with regular HTML sent from the server, enhance once it’s in the browser …if the browser is capable of it. In this case, it’s using JavaScript (React) on both the server and the browser.

A few quick links and thoughts on big web problems – Baldur Bjarnason

The system makes the website. Don’t blame the web developer, blame the organisation. A web developer embedded in a large system isn’t the one making the websites.

To make a progressively enhanced website that performs well and loads quickly even on slow connections, you need to first make an organisation that values those qualities over others.

Making a difference with performance by Jaime Caballero

This is a great blow-by-blow account of making an agency website perform better.

I love the side-by-side comparisons with other agencies, including Clearleft—the gauntlet has been thrown down!

The JavaScript-Dependency Backlash: Myth-Busting Progressive Enhancement

Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.