Progressive Enhancement Is Dead

---------------- HTML static content way:

1. The new content will be fetched using ajax. Already some problems. From the server-side rendering, it needs to fetch it from the DB, then load it in the template. Using django, for instance, the view will fetch it and we'd show it using {{variables}}.

However, to fetch the data using ajax, it's not just the view making a query, it needs to have an API standpoint, i.e. /api/fetch-new-data/. So, already, the code is duplicated. Yes, the server-side could use the same API, but there's always the problem of returning JSON vs django-ORM-queries, etc.

2. Once the data is fetched (say in json), it needs to be rendered. How? Do you simply do a

    $.get('/api/whatever', function(data) {
        $('.some-div').append('
' + data + '
');
    });

. But usually we'd have a more complex html and thus we'd be using client-side template. So, the server-side templates need to be duplicated. There are various ways to do it, varying from complexity, but there is clearly some duplication here. And, bear with me, it's usually not a simple .append, more javascript needs to be done which can alter the data, etc.

------------------------- Javascript way

1. Load pure html. 2. Fetch initial data and render it using client-side template. (It can also be bootstrapped since it's in the same JSON format). 3. On scroll, fetch more data, and render it using the exact same code / client-side template. ----------------------

Lastly, bear with me that it's just a simple example. It's rarely 100% static content only. I.e. there would be forms with error validation, etc. If you want to do it the no-javascript way, you need to have it submit, reload the view with validation error, etc. Only then, you can add some javascript to enhance it. Contrast that to simply validate on javascript submit. Yes, obviously, the server needs to validate it, but that's part of the api, nothing needs to be re-rendered.

All in all, if you agree that the same code would do the pre-loading and the dynamic real-time stuff, you usually save yourself lots of headache and complexity.

I believe blogger had that problem as they show different views for the same content. When you switch between views, it dynamically updates it in javascript, rather than doing a page reload. Could it be made better by having a html/css content for no-js browser, sure thing. Would that duplicate the code? Sure thing. And again, there are different varying of complexity. Maybe that example wouldn't be too complex, but it's more code to maintain, to test, etc.

It's a bit late here, but hopefully you understand what I mean. And by the way, I'm still not 100% certain about what's the best approach. I know that I used to be pro html static first for backward compatibility and no-js users, and only javascript to enhance the page. But recently, I've tested it by doing it in javascript on the client and it's seriously so much faster and cleaner.

And yes, there are some good frameworks to deal with the duplication, but it adds lots of complexity. For instance, see airbnb Rendr which try to solve that exact problem that I'm talking about. I.e. being able to load backbone.js on the server during the pre-rendering stuff.

If only that were actually true. In reality, we're designing the interfaces for these applications using a presentation language made basically for desktop publishing. For interactivity, we essentially have one more or less shite language (http://bonsaiden.github.io/JavaScript-Garden/) to choose from. We're still arguing over the very basics on whether we should use callbacks, promises, generators, etc. for simple sequential operations. Hell, we're still trying to figure out how to get a reasonable call stack record to debug when working with any of these options. And God help you if you want to use a modern language that compiles to Javascript and have your debugger too.

But to address the author's original point, I think progressive enhancement is alive and well. While the majority of browsing is done on the desktop, I just think it makes way more sense to think first about presenting your basic content and then enhancing it than how you're going to strip out all the bells and whistles to get your design across on less capable platforms. In the long run, the former will probably save you more time and QA effort. It's just more natural to think about using capabilities when present then working around their absence.

And no one says your baseline should to a screen reader for all possible web apps. Just pick a the baseline that makes sense for what your doing, and enhance from there. At some point, it may make more sense to fork your platform and have separate implementations for different pieces of your interface. It doesn't have to be one monolithic project that magically enhances from mobile phone screen reader all the way up to VR cave.

Are you sure about your numbers? How do you know that people with javascript disabled are a minority? Or, more specifically, how do you measure that without requiring javascript?

I'm all for making web applications that need javascript. But let's do it for the right reasons, not because "everybody has javascript installed".