Progressive enhancement used to be the only viable option because most (by percentage) of the browsers hitting your site kinda sucked. Thus, it made sense to give them an experience of some sorts but enhance that experience for those that could deal with it.
Now, we even have a decent browser from the IE family. It feels like the days of IE5 :)
Since the tables have turned, we then get this crazy idea that we can build for the rich majority…. and regressively degrade for the poor buggers who aren’t able to up their browser due to crazy IT departments or illegal Windows versions. Lord of the shims and polyfills. We have been doing some fun work to make this work in an automated fashion, but that is for another time.
When you start building applications on top of WebSockets (and degrading) you also start to think about different architectures. WebSockets gives us a rich, fast, bi-directional pipe between the client and server. Whether you are a Socket.IO lover with Node++, or an Enterprise sort on Kaazing, you can start to deal with a very simple messaging API (that degrades).
Suddenly, you are building with a rich client MVC framework (enjoying Backbone and the like) but instead of mapping back to REST (which Backbone makes easy) why not deal with publishing and subscribe to topics?
No more polling. Instant real-time. These messages can piggy back and even go straight to the land of MOMs (JMS, Stomp-iness, etc). Now on the server you have loosely coupled processes that consume messages and do their work. Scaling out with a loosely coupled messaging infrastructure is so much easier to deal with that RPC madness.
I am having some fun with this type of infrastructure, and I am curious indeed to see where it leads. You?