ROCA strikes me as a very close description to an ideal Rails-based application. In fact, when Stefan was describing the pattern, I said "duh, that's a Rails app" or something like that. But what he's trying to do here is useful, introducing a description that is technology-agnostic.
The main deviation from ROCA in my own apps is that unless utterly simple to accomplish, I don't try to accommodate non-JS browsers. Not as a matter of principle but rather of convenience. It is nice to aspire to 100% functionality in non-JS contexts, even with degraded user experience. I just don't know that it's practical in most cases.
"a set of rules to apply if the goal is to come up with a Web app that is actually on the Web as opposed to be tunnelled through the Web. We tried to come up with a catchy name, and finally arrived at ”ROCA”, a conveniently pronouncable acronym for “Resource-oriented client architecture”.
So rather than a manifesto, they're trying to devise a nomenclature, along the lines of how Ajax gave a name to non-page refresh server communication with the browser.
10 comments
[ 4.4 ms ] story [ 20.1 ms ] threadThe main deviation from ROCA in my own apps is that unless utterly simple to accomplish, I don't try to accommodate non-JS browsers. Not as a matter of principle but rather of convenience. It is nice to aspire to 100% functionality in non-JS contexts, even with degraded user experience. I just don't know that it's practical in most cases.
"a set of rules to apply if the goal is to come up with a Web app that is actually on the Web as opposed to be tunnelled through the Web. We tried to come up with a catchy name, and finally arrived at ”ROCA”, a conveniently pronouncable acronym for “Resource-oriented client architecture”.
So rather than a manifesto, they're trying to devise a nomenclature, along the lines of how Ajax gave a name to non-page refresh server communication with the browser.