Recent developments in the JavaScript framework space have me wondering if we should take a fresh look at progressive enhancement as it relates to JavaScript.
Progressive enhancement is a web design strategy that emphasizes accessibility, semantic HTML markup, and external stylesheet and scripting technologies. By using web technologies in a layered fashion, it provides access to the basic content and functionality of a web page using any browser or Internet connection, while also providing those with higher bandwidths, more advanced browser software, or more experience an enhanced version of the page.
If you’d like more of an overview, check out, What is progressive enhancement?.
Most of us familiar with the web standards movement have heard and agreed with this approach.
MVC: The Olden Days
In the olden days of web development everything was done by the server. The request was sent to the server, and the response was sent back with complete HTML. Life was good. The little JavaScript used was mostly just an enhancement to the server response, but it was often hard to write and only worked in some browsers.
We then moved into the era of AJAX. Browsers began making requests to the server via JavaScript without loading the whole page. Web developers and users liked this interaction, and we moved away from always having to refresh the page. Now, this put a dependency on JavaScript, but with the server still doing the view and controller work we could work around this dependency. Jeremy Keith came up with a concept that he called Hijax, a way of building functionality that would work easily with or without JavaScript. This required more code, but it seemed like an acceptable cost.
Enter Complex JavaScript Requirements
The complex JavaScript requirements came from users. They began seeing what was possible on the web and wanted more. Either implicitly or explicitly, they are the reason the web has become more interactive.
My first project involving a lot of complex JavaScript turned into an absolute mess. With no structure or good way to organize my code, things quickly spiraled out of control into over 10,000 lines of unstructured JavaScript carnage. It was at the same time one of the coolest and most fragile projects I have ever worked on. I knew then there had to be a better way to move forward.
Looking for architectural purity
I realize that true architectural purity does not exist on the web—primarily due to the many implementations and imperfections created by web evolution. For the last year, Rob Tarr and I have been looking for a JavaScript framework that works. Something that brings in the client-side interactions to work seamlessly with the server. We tried several frameworks, but they all seemed to be duplicating some of the view and controller work. This required every change to be made in a few different places, so it did not seem very DRY.
Enter backbone.js. As you probably know, backbone.js is a framework that moves the view and controller to the client-side. This takes the client/server architecture we have been building for years and puts the client code in the browser. Finally, we can have almost no duplication of code. I can have something wonderful in which to code, and I can know exactly which part of the system is responsible for what. Also, less code almost always means less bugs.
But this comes at a price. The JavaScript has moved from an enhancement layer to a core layer of the solution. Without duplicating everything in the view and controller on the server, those browsers without JavaScript enabled simply won’t work. This seems to violate everything that progressive enhancement stands for.
Where do we draw the line? Should we allow JavaScript to become a required part of the web? As supporters of progressive enhancement, do we ignore new developments like backbone.js? Do we duplicate entire layers of our code base? Is there a dissection between front-end and back-end code? What about the web applications behind authentication? Maybe we need to redefine progressive enhancement to exclude JavaScript?
Maybe the first step in answering all of this is to separate how we think about document-based sites and web applications as is suggested here.
I’m still working through my thoughts on this subject, and I want your opinions. I would love to write a follow-up based on our open dialog. Please share!
