I think you are talking about graceful degradation. Not being able to gracefully degrade cannot be a reason for breaking this expectation. If you have other well thought out reasons for not doing it, then it is fine.

Gmail is a good example of having this feature and also having a fallback for people who cannot use js etc. It certainly can be done easily with the technology (and open source code) available today.

It can be done somewhat easily for a read-only presentation, assuming certain degree of discipline on the part of the frontend developer. However, should you require any complex logic without js and it’s practically inevitable, that you’ll end up essentially writing not one, but two, separate frontends — one client-side and one server-side.

To have transparent support for client-side and server-side applications otherwise, is a rather complex task. The only way to do it and handle any kind of complexity is to use server-side continuations to emulate client-side widgets. This means either using an intermediate layer instead of DOM, or coding to DOM and running against DOM server-side. Using continuations of course has its own set of issues — the state for each client has to be tracked and kept server-side (and one client may have several states), and it means that practically nothing can be cached (everything becomes dynamic). And with all of that trouble and added complexity, what are the benefits? Do we really need to support non-js clients to that degree? Not to mention, that there is practically no web-framework, in mainstream use, that gets it right.

And indeed, the alternative version that Gmail provides is much more simplistic, and by the way, it does not make any use of graceful degradation/progressive enhancement — it loads an entirely different Gmail frontend. I’m willing to bet, that it does not share a single line of code with the client-side version.

All that progressive enhancement gives you is search-engines visibility. It cannot be used to provide anything more than that.