On critical JS and progressive enhancement

"It's time to consider that JavaScript can be used as a critical component of any web app. Progressive enhancement slows down evolution."

I recently tweeted this bold statement, and, unsurprisingly, one of the answers I received mentioned the risks inherent in such a philosophy and advised me to favor a "progressive enhancement" approach.

It is absolutely impossible for me to disagree with such wise advice, especially when many of the front-end developers whose work inspires me advocate it.

Yet...

When you consider what is at the very core of a website, things haven't budged much in a decade. There may be cloud hosting and its cohort of acronyms (PaaS, DaaS etc.), JavaScript may run on the server, the command line may slowly be replacing FTP clients, and we may have tons of new technologies (YAML, CSS preprocessors, you name it), but, basically, browsers still send a request to a server, which responds back with good old HTML, which ultimately becomes a web page. And when I reflect on that state of affairs, I have the strange feeling that, somehow, things haven't evolved as much as they could have. At least, I know for a fact that I haven't really tried to be creative on the matter of this client/server/content triad.

I'm afraid progressive enhancement is responsible for holding my creativity back and, more generally, harming how the relationship between browsers and servers could evolve.

Please allow me a little digression to a) explain why I just said what I said and b) give you time to catch your breath because, oh dear, I know that what I just said is highly politically incorrect.

A few weeks ago, I released a side project, picni.cc, with what I consider a powerful yet simple API. While developing it, I was focusing a lot on what the various endpoints of the application would do for my users and left the task of releasing a nice website documenting it all in a simple and clear way, even for people with little coding experience, for later. In other words, when the project was first released, only the folks trained to read between the lines of quickly-put-together documents were able to use my API. I'm okay with that; it's part of the unfunded, ship-quickly-for-early-adopters side-projects game.

The project got very good feedback. I recently began "packaging" the website and that positive response kind of... boosted my ambition (I'm being really honest here), so I decided I would come up with something different. It's a great feeling to face a blank page and realize that you're free to build your site the way you want. And this feeling was vibrating quite strongly in me: I would not allow myself to release a load of dull docs.

So I started dreaming about how I would build this thing, how data would be collected and presented, and how users would navigate through the site. And every time I considered the core of my website, I was brought back to this status quo: a request is sent to the server, and a page is returned. And, well, no matter what I tried, it felt like the dullness couldn't be escaped. Because it felt like nothing special could come of that browser/server relationship.

But there's no really other way to build a website, right? Because, since I don't want my website to be inaccessible, I'm going to take into account people who don't have JavaScript enabled, so every page should be "buildable" in its entirety by the server. Only when this cardinal requirement is met can I start adding "enhancements". That's how good developers work.

And that's when it hit me: what if, for a split second, I allowed myself to consider that there could be a "critical JS" approach? What if, by some sort of magic trick, I could know for sure that everybody connecting to my website would have JS enabled? I'm not even talking about users ready for bleeding-edge experiments, crazy APIs and God knows what, just users with clients able to support JQuery 1.x. Yep, just that. How would you build a website if every person that connected to it did so with a browser able to run JQuery 1x, for sure, 100% guaranteed?

And I let my imagination go. I started humbly. "I would load the <head> of my document and an empty <div>, and then I would update only the content of that <div>. Wait, I could actually use only one <script> tag and load JS and CSS assets dynamically, in a way that improved performances for, say, mobile users." Nothing too disruptive as yet. The cool kids are already doing that.

So, let's go one step further. "If I don't reload my page, I mean, if a 'traditional web page' is built only once, upon instantiating the app (the website, if you like), I could try to get rid of server sessions. Wouldn't that be interesting? I could write a JavaScript lib that acts as a session handler and see where that leads us."

And then came the phase where I challenged myself: "What if I banned myself from using any server-side language in my templates? The server could become a gigantic API that I'd query to get data and inject it into templates. Wait, that would mean that anyone could also access that data in the same raw form as I do. I could easily make the whole content of my website consumable by others, without any "markup and styling opinion". Mmh, what if I also shared templates along with data? I should remove all "class" and other such styling attributes from my templates and find a way to let people style things the way they want, on the fly."

This sums up the first hour of dreaming.

I gave myself a full week.

And now, as you can guess, I'm coming back to my previous statement: progressive enhancement (PE) slows down evolution and inhibits creativity. When I landed back on earth, I realized that I could pretty much throw all my best ideas away because they could only work based on the assumption that people connecting to my website had JavaScript enabled.

And no one could guarantee that, obviously.

How could I take the risk of relying on the multitude of clients and their idiosyncrasies for my application to run correctly? And do I feel like endorsing that "critical JS" approach? Is it something I could preach? Am I able to answer that tough ethical question—and sharing it here with you is the very purpose of this article—of whether we can make new things, create new ways of doing things if that means leaving users at the door?

Going out and shouting, "The web platform is a Darwinist entity!" is not an easy thing.

After this week of daydreaming, there are a few things I'm fairly certain about concerning progressive enhancement, though. Here they are, rough, without any justification:

a) I don't think the word "enhancement" does justice to the depths with which JavaScript can alter the core of how a website operates, how people can communicate with content and how the relationship between clients and servers is defined.

b) I would like to start thinking "critical JS" first, and then do my best to find good, viable fallbacks for the users who may not be able to pass the jQuery 1.x test.

c) I sense strongly that PE is actually slowing down what I could do to improve mobile navigation on my projects: I could build websites that were a lot more efficient in that area if I completely ditched PE, which leads me to wonder why I should take care of users without JS at the cost of not doing my best for mobile users, a metaphysical question which can only be solved if you build a mobile version of your site, which I'm not going to do.

In conclusion, please allow me to hedge my point. The problem, in fact, is of course not the PE philosophy itself (which I purposely considered only in terms of its relationship with JavaScript in this article), but, obviously, a) discrepancies between browsers and b) a far more complex issue: do we open the doors of our applications to those who wish not to use the technologies required for them to work nicely (JavaScript here, but we could also talk about cookies)? After all, PE is merely an ethical approach to building "massively welcoming" web applications, and should not be held responsible for my frustration.

So, in the end, am I going to actually use a "critical JS" approach? My knowledge was built reading articles by people who advocate progressive enhancement. So, I'm not sure I'm ready to "kill the father" just yet. But I feel it's time for me to challenge him. I will do my best—and nothing more—to take care of the users who don't have JavaScript enabled, but it may not be an immediate priority as I want to spend more of my time experimenting rather than putting effort into "gracefully degrading" my work. And what non-JS users may lose is little more than just the few visual effects the word "enhancement" sometimes suggests: they may still get to the content, but they may miss the flesh and bone of the application.

And I guess I have to find a way to be okay with that.