In Louis’ recent forum topic, Are we in a scripting-dependency backlash?, he commented:
I think, in some sense, we are in somewhat of a scripting-dependency backlash, and it’s probably a good thing.
- I agree. So do several others including web gurus PPK (The problem with Angular) and Jeremy Keith (Angular momentum) and Jake Archibald (Progressive enhancement is still important).
- Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.
Let’s define the terms we’re discussing…
There has been a rise in the use of client-side frameworks. These provide server-side-like coding patterns such as MVC, template views, reusable components, form validation and more. AngularJS is probably the best known and most popular but it’s not the only solution.
It’s quick to mock-up sites and apps because client-side frameworks provide rich components and shortcuts.
- Client-side-only applications
- Internal corporate applications
- Sophisticated interfaces
There are other cases but the majority of public-facing web sites and applications do not fall into these categories. No one will stop you using a client-side framework but, when you have a hammer, everything looks like a nail. To quote Louis again:
Developers seem to be using flashy new tools just for the sake of it, and not because they are solving an actual problem.
What is Progressive Enhancement?
Progressive Enhancement (PE) is not a technology but a development approach. I wrote several tutorials and examples in 2009 but the concept has been discussed since 2003.
You establish a base level of user experience then add more advanced functionality when the browser supports it. Taking PE to a logical extreme:
- You create an HTML-only application where all important processing is done server-side. It would work in any browser; mobile devices, Lynx, IE1.0 or whatever you throw at it.
- You enhance the layout with CSS. CSS is PE-ready because browsers ignore properties they don’t understand. You can enhance it further using options such as media queries or @supports rules. The application still works everywhere but offers an improved experience for browsers with modern CSS capabilities.
SVG is supported.
Every browser receives the best application it can handle. It’s possible that no two browsers offer quite the same experience. Mobile-first responsive design and the lesser-used offline-first are examples of Progressive Enhancement techniques.
Let’s examine the criticisms of PE.
This is absolutely true.
PE critics then conclude:
MYTH: No One Uses Old Browsers
What do we mean by “old”? For most developers, it’s any browser released more than twelve months ago. Not everyone can use the latest and greatest applications:
- large organizations and government departments
- people with disabilities
- people in developing countries
- less affluent sectors of the community
- anyone with an iPhone 5.0 or Android 4.0 and below.
These sectors may not be important to you. But will they never be important?
Progressive Enhancement makes no assumptions about your audience. That’s not true for client-side frameworks. Those who can’t use your application will disappear from server logs. It quickly becomes a self-fulfilling prophecy: “no one using our app is on an old browser so we can carry on as-is…”
Progressive Enhancement embraces the fundamental strengths of the web. It’s possible to develop a site or application which works on any web-capable device anywhere in the world. The better that device, the better the user experience.
MYTH: Progressive Enhancement Makes Assumptions About Users and Devices
PE is about NOT making assumptions. You don’t presume anything — it’s the core premise of the technique.
MYTH: Progressive Enhancement Means Supporting Archaic Browsers
Progressive Enhancement critics presume you’ll spend all your time dealing with old browsers. In reality, it’s the opposite: you never need to deal with old browsers because appropriate fallbacks are in-place.
Supporting old browsers is a benefit of PE — not an objective. You can support the lowliest of browsers but you can establish whatever baseline you like.
For example, I’m currently working on an application where
MYTH: Progressive Enhancement Holds Back the Web
Or, more specifically, client-side frameworks are on the cutting edge and pushing the web forward.
Your client-side framework is only as good as the browsers it was developed for. AngularJS 2.0 is a complete re-write because features such as
Object.observe() and Web Components weren’t commonly available when AngularJS 1.x was released. The framework forces you to use older technologies but hides the implementation from you.
PE allows you to use any modern API without breaking your application. Best of luck upgrading from Angular 1…
This is partly true — but only when you’re starting to build your application. You have access to a range of controls which cut the initial development time. But you’re then stuck within the confines of that framework and that can lead to problems later.
The question may never arise for an app developed using PE techniques; you’re possibly supporting that browser already. Further enhancements can be added without a major re-write.
MYTH: Progressive Enhancement is Twice the Effort
This is the favorite quote of the critics. The only people who say PE is too much effort are those who’ve never tried it or somehow failed in the attempt.
innerHTML. Alternatively, we could use page 1 as a template for returned JSON data.
It’s a little more work but it’s certainly not double the effort. We have the benefit of a cross-browser fault-tolerant solution.
MYTH: Progressive Enhancement is Pointless — Websites Evolve or Die
The logic behind this argument is that websites eventually become obsolete. Therefore, you can use a framework which targets specific technologies at a specific point in time.
I wish. If your code’s good, it’ll be used far longer than you expected. Bad code lives even longer because no one wants to touch it.
But again, use Progressive Enhancement and you’re not making any presumptions other than the web will continue as a client/server-based HTML-based system. The web would need to fundamentally change for your app to fail — it would no longer be the web!
MYTH: Progressive Enhancement is an Old Technique Recommended by Old Timers
To quote Oddz:
- Some intermingle HTML and functionality like we used to do with
onclick handlers, e.g.
- They target specific browsers. There has been a resurgence of “best viewed in…” messages and
- They do not plan for the future.
Progressive Enhancement compliments the strengths of the web:
- it separates content, layout and functionality for easier maintenance
- you’re writing defensive, fault-tolerant, device-agnostic code for the web — not browsers
- you can support a wide range of devices
- your testing burden is reduced because your app remains operative on failure
- SEO and accessibility are baked-in (or require less effort)
- sites and apps will work on browsers released today, yesterday and tomorrow
- no one has disproved the benefits of Progressive Enhancement or proposed a better technique.
There’s only one downside: it’s evident many developers still don’t trust or understand Progressive Enhancement.