Web portal architecture using a LOT of jQuery

A while back I overheard some very experienced web developer describe an ideal (in his mind) architecture for a portal. I remember hearing these layers:

• Database (Using stored procedures)
• Application Server (using SOAP or REST)
• Web Server (using jQuery to talk to the application server)

The database and application layers made total sense and I have used the same paradigm in several projects, but I was intrigued by the Web Server. It sounded like it was all jQuery getting JSON or XML from the application server and somehow building a page.

This sounds like a very cool idea. Unfortunately, I never heard how it went. Does this sound like a good design? Would you design a site this way? I'm sure he had a non-javascript flavor that would build static HTML from the application server. Why not开发者_开发百科 just deploy the whole site in the non-javascript flavor?

Note: I overheard this discussion and didn't see any design drafts or anything, so I may have some facts jumbled.

There is already an application like that: GMail - it just doesn't use jQuery, but Closure, albeit it's the same principle you defined.

I doubt he was using jQuery to 'build' the page, but more likely to handle any interaction with the user. That is, a button that does something wouldn't refresh the entire page, but it would simply make the request to the server to do what needed to be done, and probably get a bit of html back that it would update a particular div, or perhaps subsequently make a call to refresh that div.

Using jQuery to retrieve 'page building information' and then using JS to dynamically build an html page would be slow - I went that route myself for a portion of a page, and even that small portion took forever to render. Javascript just isn't built for that level of performance - you want to handle that in compiled code on the server.