35

I just got back from a conference in Boston called An Event Apart.

A really popular theme amongst the speakers was the idea of progressive enhancement - a site's content should go in the HTML, and JavaScript should only be used to enhance behavior.

The arguments that the speakers gave for progressive enhancement were very compelling. Not only is it a solid pattern for supporting older browsers, and devices on a network with low bandwidth, but HTML fails much more gracefully than JavaScript (i.e. markup that is not supported is just ignored, while if a browser throws an exception while executing your script - you are hosed).

Jeremy Keith gave a particularly insightful talk about this.

But what about single page web apps like Backbone and Angular? The whole design behind these frameworks seems to push the developer toward moving content out of the HTML, and into something like a JSON API.

I can not seem to gel these two design patterns: progressive enhancement vs. single page web apps. Are there instances when one is better than the other? Or are they not even antagonistic technologies, and I am missing something here with my mental model?

gnat
  • 21,442
  • 29
  • 112
  • 288
SeanPlusPlus
  • 453
  • 4
  • 7
  • They have two different use cases. Yes, there is overlap when the server is doing the heavy lifting. – BobDalgleish Apr 30 '14 at 23:20
  • 5
    I think it's fair to say that browser requirements for Single-Page Applications are more stringent than those for "ordinary" web applications, by design. – Robert Harvey Apr 30 '14 at 23:44
  • 3
    you should ask Jeremy Keith to give you an real world example where progressive enhancement actually worth the hassle of pleasing 1-10% total internet people and ask the data of other 90% of user, are they actually care about progressive enhancement or if they happy if they can visit website with IE 5.0 or without javascript – kirie May 06 '14 at 03:02
  • 1
    If the type of folks who disable JS/images/etc are not in your core target demographic, then there's no valid business reason to pursue Progressive Enhancement. – Graham May 06 '14 at 14:19
  • 1
    Support for 'devices on a network with low bandwidth' is actually and argument for SPA, not against it! In SPA you only make one large request, where without JS you have it every time! – Dmitri Zaitsev Jul 28 '14 at 08:09
  • Also there are sophisticated libraries to provide old browsers support in JS. – Dmitri Zaitsev Jul 28 '14 at 08:12

6 Answers6

22

It seems to me that single-page apps draw a line in the sand of progressive enhancement. Where before we might try to work around the fact that implementations and features vary between browsers going back for decades, SPAs assume that there's a certain baseline that we can reasonably agree most visitors of a given site will meet. I don't think the two are at odds. You can still continue to progressively enhance after the SPA starts, like starting with a <video> tag, then layering your own feature-rich player on top of that.

Then there are visitors with scripting disabled, but they know what they're getting into. I don't see why developers should bend over backwards for those visitors, aside from a "You need scripting for this site" note. If we allow that, why not also cater to visitors with CSS disabled? How about images disabled? These are core web technologies. They should not expect to have a fully functional web experience when they go picking and choosing pieces.

To ensure I don't get away without a car analogy, I should not expect my car to work if I decide I don't like certain features. I could tell civil engineers, "I disabled my headlights, so please make sure to install street lights every 125 feet everywhere I might visit." Without headlights, my car would work a lot of the time, but some places I'll be unable to visit.

Collin Allen
  • 352
  • 1
  • 4
  • 3
    `I don't see why developers should bend over backwards for those visitors`. If Your contract specifies that you need to provide an accessible version of your website, it may be more difficult to use a SPA. Also what about SEO? – Simon Bergot May 06 '14 at 07:39
  • 7
    @Simon: You can make a SPA accessible as well (see e.g. http://stackoverflow.com/questions/15318661/accessibility-in-single-page-applications-aria-etc ). Likewise for SEO (if SEO matters, which will depend on the app). – sleske May 06 '14 at 12:24
  • 2
    Some of your analogies are a bit of a straw man. Disabling Javascript has a security purpose; it would be hard to argue that adding headlights to a care makes it less safe. – Robert Harvey Dec 31 '14 at 20:09
  • 1
    True, disabling scripting has security benefits. But for most visitors, the additional security afforded by making that choice isn't worth it. Without scripting, Facebook refuses to work, LinkedIn breaks, Pinterest breaks, Instagram loads a blank page, etc. If the major players require it, your SPA can too. – Collin Allen Jan 02 '15 at 07:40
  • Only knowing FB and LinkedIn, there is no good reason for those sites to break without JS except to placate developers who don't want to put in the effort to make an acceptably functioning website (or to coerce users into accepting less secure browsing practices which may benefit their bottom lines). If they were full-on web applications like Plunker you might have a point, but most "web apps" are only "apps" in the sense that they are built on some kind of framework. In terms of use, they are just web sites with more bells and whistles than they used to have. – Dissident Rage Sep 19 '16 at 19:34
7

SPA is most beneficial if you are creating an application that does not fit the classical request/response pages model. There are a recent trend where regular websites are written as a SPA even when they fit just fine into the request/response cycle of the web, IMHO what they are doing are foolish endeavours. What the likes of these websites are doing is poorly reimplementing a web browser with lots more bugs and less features.

The idea of progressive enhancement and SPA is not mutually exclusive for these foolish single-page appli-websites. You simply need the javascript to do some content negotiation (i.e. Accept header) so they receive JSON resource that the Javascript on the SPA can render themselves instead of a pre-rendered HTML pages. The issues with this kind of website SPAs is obvious, you have to have duplicate implementation of the website's rendering on both the server and on the client.

For true web applications, i.e. one that truly have to be an SPA as they don't fit into the standard request/response pattern; progressive enhancement is much more difficult for true applications because they are really just using a browser as a technology platform for writing an application portably. Scripting language is an essential part of a true web application, not just one that can be optionally bolted for enhancements. Some progressive enhancements techniques still can work though (e.g. replacing flash video/audio with <video>/<audio> tag) but true web applications will require javascript as a baseline.

Lie Ryan
  • 12,291
  • 1
  • 30
  • 41
  • +1, but it isn't always easy to decide whether something "truly" requires an SPA. For example, business applications that are mostly data entry, with a wide range of complexity in the forms. If most of the forms are simple, an SPA is not "truly" required, so there's still tension between SPA and non-SPA solutions. – sinelaw May 06 '14 at 22:15
  • @sinelaw: Most business applications generally should not be an SPA. There are a few exceptions, e.g. Spreadsheet, Word Processing, but those are the odd ones out. Indicators that you need SPA: if you need to push data from the server to client, not just for one or two notificationss, but as crucial element of the application, e.g. game, stock tracking, chat app; if your application does not have a sensible concept of a "Page" or the concept of "Page" have been totally contorted in the app, e.g. Office applications. Business applications that works mostly on forms better remain as non-SPA. – Lie Ryan May 07 '14 at 00:18
  • Agree. Another indicator for an SPA: if developing an SPA is cheaper than developing a "classic" website. Business apps a targeting specific audience can sometimes impose requirements such as "use a modern browser", so that progressive enhancement carries little benefit. – sinelaw May 07 '14 at 13:53
  • @sinelaw: Building an SPA is almost never cheaper than developing a multi-page sites; especially if you're not catering older browsers anyway. – Lie Ryan May 07 '14 at 18:36
  • If your team consists of SPA experts with little background in server-centric projects, it will be cheaper. – sinelaw May 08 '14 at 00:49
  • Have you heard about isomorphic javascript? You can build this kind of apps that work both on client and on server side. Look at this for example: https://github.com/iam4x/isomorphic-flux-boilerplate – Totty.js May 22 '15 at 16:24
2

I believe single page web-apps and progressive enhancement are almost antagonists. If the html is computed on the client from data retrieved from a json api, it can hardly degrade gracefully. It can however offer a richer and more pleasant user interface.

You can set up a bot which will crawl you application and save a static version. This technique can be used to serve HTML to browsers without javascript (used by blind people or search engine bots). This is an investement, so it really comes down to your requirements.

Are you making an HR management web-app for a specific compagny? You don't need graceful degradation, and a SPA may be more simple to build. The company may enforce the usage of a specific browser, so you may have less tests to do.

Are you making a public website for an association with accessibility requirements and search engine visibility needs? Then consider building the HTML on your server. Or making an SPA with a static version, depending on your budget.

sleske
  • 10,095
  • 3
  • 29
  • 44
Simon Bergot
  • 7,930
  • 3
  • 35
  • 54
1

I think it depends how far you want to go with Progressive Enhancement - it's a design paradigm rather than a hard-and-fast set of rules.

If you're using a SPA framework, I think allowing Javascript is a given. However the Javascript you write to enhance your page must be smart enough to deal with whatever HTML the framework can create.

You can also benefit from other PE techniques such as taking advantage of the latest CSS features for a recent browser release, or HTML5 to HTML4 degradation.

philicomus
  • 27
  • 4
  • 1
    Part of progressive enhancement is that basic content should be available without javascript. I'm not sure how to write a SPA without javascript. – Alan Shutko May 01 '14 at 16:37
  • @AlanShutko Perhaps with iframes. Multiple pages, but technically the URL isn't changing... ;) – Izkata May 02 '14 at 00:48
  • 1
    Yes, I guess I was thinking more in terms of HTML 5 vs HTML 4, and things like browser-specific CSS (e.g. you may want to use a very recently implemented feature only available in the latest version of Chrome but which degrades to a more primitive control in older browsers). Doing without javascript would be tricky in a SPA, but that is just one part of the concept of progressive enhancement. – philicomus May 02 '14 at 08:00
  • Progressive Enhancement could be as simple as using css3 when it's available for rounding corners. The basic idea has nothing to do with JavaScript. – Daniel Little May 06 '14 at 01:25
1

Progressive enhancement and a Single Page App can co-exist. The two most compelling arguments I've heard for building apps in this way are:

  • Fault tolerance in situations where the HTML file downloads in full but referenced scripts fail to download completely thanks to network connectivity that drops in and out (possible on mobile networks)
  • Potential for improved perceived performance on initial page load (by reducing Start Render times)

Server-side rendering (this is for users, not just SEO reasons) and cutting-the-mustard are two techniques that can help build progressively enhanced Single Page Apps with modern client-side JS frameworks.

Some client-side JS frameworks are easier to get working with server-side rendering than others (beware some server-side rendering solutions and framework combinations do not produce working SPAs as the server-rendered page is only intended for search engine consumption, not end-users).

At time of writing, React.js and Ember (with the upcoming FastBoot) are the two I'm aware of that have or are trying to make server-side rendering a first class citizen; the server-side rendered page is still a working SPA when it's parsed on the client browser.

Eliot Sykes
  • 11
  • 1
0

I'm of the view that the reduced page load is probably quite a good for servers, and the network. I'd love to see more SPAs used correctly.

I'm off the view though that this requires two things:

1) setting up all of your links as standard request/response links on initial load, let your SPA framework/library then replace these with an updated (interactive) version once the browser loads and the JS engine identifies that SPA support is available. This truly is progresive enhancement; the JS is loaded on top of the existing html website, and this is better for search engines, assistive technologies, and older browsers.

and

2) The server needs to be responsive to routes like /foo/bar/json and foo/bar by serving the correct format; realistically if you're wrapping everything in layouts and partials to get the first page, you should be able to get everything via layouts and partials for the 2nd and subsequent pages as well.

There's a fair bit of work here; admittedly, but if you've got control over the full stack it does balance the two technologies.

Crispen Smith
  • 101
  • 1