Web app using jQuery standalonne vs. server-side presentation framework

I am starting to rewrite the front-end of a demo trading application as a rich web client (the current implementation is in Silverlight - you can see it here). I am considering two options for the rewrite:

1. Standalone Ja开发者_如何学PythonvaScript-based client using a framework such as jQuery UI
2. Hybrid client using a client-side framework such as jQuery UI plus a server-side framework such as ASP.NET MVC3, JSF, GWT etc.

What's your opinion on the pros and cons of each approach? I am primarily looking for the ability to apply good architectural principles (such as MVC and eventing) to create a clean modular design that is easy to understand and maintain.

Edit: Looking at the responses, I would like to clarify that there exists a server component that performs bulk of the business logic (see this architecture diagram). The client simply sends its commands and queries to the server using JSON based services. In this respect, the client is really light-weight and only focused on user interaction and presentation.

So what I am really after is:

a) guidance on what frameworks to use for approaches 1 and 2 to achieve clean modular designs

b) Opinions on why one approach would work better than the other

For example, I would lean towards #1 provided that a combination of JavaScript frameworks will suffice to create a robust presentation-tier easily. In other words, if I am going to invest in a JavaScript heavy client, why introduce additional dependencies on a server-side framework - does that really make my job any easier? (assuming that there is a learning curve involved either way)

GWT is client side. It can replace jQuery if you use it with gwtQuery.

The choice of technology really depends on many factors (which you did not mention here), but mostly on what you already know. Personally I'd go with:

1. GWT and gwtQuery client side, mostly because I know them. Client would be pure-ajax, where all business logic is done on server.

2. REST server, performing business logic and serving (presentation) data to client. There are many REST technologies, personally I know Resteasy, so I'd use that.

Update:

On 1. versus 2. approach: approach 1. is mainly used in complex web apps (aka gmail), where web page is not reloaded and all interaction is done via DOM manipulation and AJAX calls. It gives you better responsiveness (page is not reloaded) and better load times (since almost no HTML is transferred, just JSON data). If you want to have rich UI experience, you will need to use some JS on client side anyhow, so you will never entirely escape this part.

The downside is that you need to know JS. Also JS code tends to have maintainability problems when code base grows. HOWEVER, all this can be mitigated if you use GWT: java is static-typed, compiles to minimum-size JS and abstracts the browser quirks away (provides abstracted DOM access). Also it has great IDE support (Eclipse and IDEA), GUI builder (if you want it), modularization (MVP), great docs, tons of libraries and, my favorite, gwtQuery (a clone of jQuery).

So, my personal choice would still be approach 1. with GWT as technology primarily because I already know the technology.

It depends on how much computing has to be done. As this is a trading application which promises 0-seconds execution, you can't really depend on the clients browser doing all scripts without hanging or freezing. Of course is that not the only concern, since that can happen with a hybrid solution as well, but it's much less code to be executed client-side, which lets you keep an eye on the resources needed.

On the topic of maintaining: A client-side executed JS is probably never as easily maintainable as a MVC application. It's merely a question of personal or team-discipline to keep the code well readable and maintainable.

If architectural principles are a big concern for your decision, I'd go for the hybrid solution every time.

Update due to updated question:

In the case of already processed logic, where the client only has to do the updates and DOM Manipulation, i'd probably decide based on the server-side architecture or personal preference. It depends on the long-term goal. If you want to stick to one Architecture, you could for example use ASP.NET, which offers a variety of AJAX enabled controls/objects.

Personally i'd use jQuery's AJAX functions simply because I do know it works so far flawlessly for me with JSON Objects (On our Intranet we're using it with an Asp.NET backend) and because jQuery is pretty lightweight on the client. A minified version doesn't weigh that much in Bytes and is already optimized for performance and cross-browser incompatibilities. With asp, you would still have to look out for cross-browser deal breakers yourself, instead of focussing on the task at hand, the client itself