I am positive that the future of web applications lies in simplification. Not simple as in too few options, or not very smart, but simple as in easy to understand.
The simplicity/complexity debate has mostly been debated on behalf of different languages, where ease of use has been pitted against (developmental) scalability and the verbosity of safety-measures and meta-data has been clashing with implicit information and quick deployment.
Instead of looking at which language offer the most suitable properties to development, I thought it interesting to instead look at what kind of protocols can be used, or created to simplify (in this case) Web-based applications.
Why so? Well, even the frameworks being used (Web-based (Generates the client (html/js) on the server for every action) or resource-based (respond to RESTive accesses and/or rpc calls from a separately downloaded html/js client) are in most cases tied to their implementation languages, with the possible exception of Rails becoming a de facto standard over almost the whole playing field (Trails, Grails, Symfony, et.c.).
But the power of Rails (from my admittedly shallow experience) is mostly due to either the expressiveness and clarity of Ruby itself, or from the strict opinionation when it comes to file structure, database management and mappings, et.c. Rails is still in some parts 'just' another JSP or ASP, in that it allows, even encourages mixing of presentation and logic, <%=foo %> wise. I know that there are a lot of RESTive parts to Rails, but I haven't had time to try them out. By what I've read, though, they seem to be more on the right path.
Much of the comments in the debate I've more or less started around the End of Web Server Frameworks center around the fact that people (this is my conjecture, of course) feel very naked without proper IDE integration and code generation, and most importantly readily accept any configuration-file hell and bloated Schrödingers codebases (which will resolve into either working or non-working client code only when you open the lid/actually run the service), as long as they don't have to suffer the indignity to actually _learn_ something that lives inside the browser.
As I said, my conjecture.
Say that you have a specific resource in each framework, which when called return a file (perhaps NOT XML for once? :) which describes the following;
1. Type of user authentication support + resource (To be able to make generic login widgets)
2. List of named, read-only data sources, organized by type
3. List of named, read-write data sources, organized by type
4. List of named, RPC endpoints, organized by type
Maybe this standard exists already, or something like it exists, that can be reused for this purpose. If so, please comment or mail me, because I've been searching standards organization and the like the whole weekend.
What do we gain by this? Well, it makes it possible to write generic widgets. Generic as in generically pluggable to any compatible server. And, quite frankly, it would make it possible to write generic clients for specific purposes, say resource editing, possible, so when you write your new fabulous service, you need only implement the common resource (tm :) description interface, and you can just pop in half a dozen existing clients that suit your purposes.
And as it happens, I'm in the process of contacting people to see if we can get a working group around this, either loosely coupled or under an organization which is compatible with the purpose in mind.
If you feel that you're interested, drop me a line, and we'll start something up :)
[Update 1: In response to a very good blog post by Alexander Klimetschek, I'd like to add that even though WADL indeed fits the bill in many respects, as I have formulated my ideas, what I'm really grasping after here is not so much a descriptive generic language, but a opinionated list of specific common services, to later be expressed in (perchance) WADL.]