Read on to learn why.
Quick background
The web development community has been in love forever with the idea of writing code that can be shared across the server and the client. Or maybe that’s just me? Nope, not just me.
We’ve flirted with technology for a while now that we’ve hoped will achieve this holy grail, but recently between node.js and React.js it’s become a reality we can reach out and touch. (er, write. In JavaScript.)
Which means we’re up to the second Hard Problem In Computer Science: naming things.
I mean, instead of “transferring JSON to and from the server without a page refresh” we have AJAX. There’s no way “writing JavaScript that we can run on the Server and the Client” is going to fly.
So far, for lack of a better term, we’ve mostly been calling it “Isomorphic Javascript”. And then arguing about how that’s a terrible term for it.
Remember Progressive Enhancement?
It was a Good Thing. We started understanding how we could write web apps that were baseline-level functional without JavaScript, while being “progressively” enhanced with richer functionality as the visitors’ platform of choice (probably not IE6) supported it.
Apps like Flickr and Basecamp showed us the future, and jQuery helped us implement it ourselves. Capable browser? here’s a nice date picker! oh, no JavaScript? that’s cool, we’ll validate your input on the server.
Accessibility loved it! Good semantic markup makes screen readers happy.
Google loved it! Quality HTML is King for ranking in search results.
Users loved it! Apps were faster, and more interactive.
Web Developers loved it! … well … sort of.
Yes, it was great we could launch an MVP and progressively enhance it with fancy client-side coolness. And oh, all those plugins!
But… all of a sudden we’re writing all our code twice. For the client, and the server. We’re also testing our code twice. And designing two user experiences. And we’re forking our UI; some things work with JavaScript, others don’t.
Actually… that’s a lot of work.
Enter Progressive Javascript
The name works for me on a number of levels.
Firstly, it’s the best description I’ve heard of what’s going on.
Here’s the Wikipedia definition of Isomorphism:
Isomorphism is a very general concept that appears in several areas of mathematics. The word derives from the Greek iso, meaning “equal,” and morphosis, meaning “to form” or “to shape.”
So I guess Isomorphic Javascript has equal shape on the server and the client? Nope. It doesn’t. Different code paths will run; different features are available. It’s just that you can write one set of code that executes in both environment and shares as much as possible.
The JavaScript runs on the server. Then it’s sent to the client and continues. There it does more. Handles interactivity. Takes over.
Here’s a definition of Progressive:
Progressive; adj. happening or developing gradually or in stages.
Sounds pretty spot on to me.
Secondly, this whole concept seems like the natural evolution of what we were solving with Progressive Enhancement.
The Web Platform has come a long way. Chances are we’re supporting IE9 and wishing it was just IE10+. We’ve got grids for responsive resizing, and flex-box will soon help us forget we ever used tables for layout.
But mainly, it’s pretty safe to assume JavaScript will just work. Everywhere. On the client, and on the server (and the database, and your drone, and…)
There are still important reasons for server-side rendering. Deep links. Accessibility. Faster page loading. And, of course, SEO.
But since we can run JavaScript everywhere, we now have better solutions to the same problems we were encountering with Progressive Enhancement.
We can stop designing two user experiences. We can stop writing everything twice. And since we have less to worry about, we can be more productive. This will literally help us progress faster.
This is Progressive JavaScript.
Love it? Hate it? Have a better idea? Let me know on Twitter: @JedWatson