i have to start a new project, a webapp with lots of forms and screens and i really don't know which technology fit best. The application is an ERP like app, with very few animations and lot of forms. The goal is to reduce at minimum reloads and waiting time, it has to be as close as possible to a normal desktop app (a lot of work to look like a marvelous VB6 app :-)
On the one hand we have client side MVC (backbone). It's cool to have all the code running on client but in my mind this implies repetition of lot of code (for example all models definitions) from server (PHP + Fuel). Sure once loaded all the informations task like paginations or grid work without any delay but it also present some problems of synchronization (other users can change data and i have to manually invalidate data on client).
On the other hand we have pjax. The idea is to make all the templating and so on on server, just implement a logic to return the page without the frame for pjax request or full page on new requests. No code duplication, very simple client side.
I've read the the story from basecamp and from twitter and both the point make sense to me. You can't relay on visitor computer (features, performance ...)
The more i think about it the mode i like pjax over MVC, but maybe i'm missing something. Which are the MVC advantages over pjax or pjax disadvantages over Client side MVC ?
Thanks a lot
Backbone.js is good for heavy, single page web apps that never truly post back, but have lots of ajaxian things going on, interdependent cascading dropdowns, etc. It has a very good API for events and collections. If you have plentiful client side javascript, it can be a helpful way to organize it. It is opinionated in the sense that it expects your server-side architecture to be RESTful by default, and you have to make some effort to use it for non RESTful APIs.
The project I'm working on is an ERP web app as well, with asp.net MVC on the server-side. I've learned that Backbone (with handlebars as the templating system), and .net mvc really don't play together that well. If you go Backbone, you really have to go full-hog (controller methods serve up json, that's it). On pages in this app that are more or less 'normal' web pages with some forms, Backbone is the wrong choice.
I just googled pjax for the first time, so I've basically just read the short description at the top of the page, but I suspect that might be the way to go for your scenario, in keeping with Keep It Simple Silly principles.
Related
I have created Web API.I know the Main advantage of Web API is cross domain application (I can call Web API in all platform). My question is ,Is there any performance issue When I call Web API in ASP.net WebForm???
I would like to know the below scenario
1.I Can use Direct SQL Query in .aspx Page
2.I Can use Web API and generate JSON to DataTable
I would like to know which one is fast and better to use.......
I have tried in JQuery,the performance is fine but I would like to call in ASP.net WEb Form
Where you call the API from or from what type of app makes no difference. Your issues are going to come from how you use it and what you do with the results of the calls.
Yes, you can get JSON data from the API and yes you can convert that to a DataTable, technically no issue there, but the performance will depend on how much data you retrieve in one go and how many transformations you go through to get it to the state you need for your webforms controls.
You're talking about using a dead tech ( webforms ) and trying to fit some things into how that works, which while possible, is not really the way to build anything these days.
SQL in aspx kinda says it all.Assuming you have an old app, that you just do updates to then just do what you can, but I would start looking into modern ways of building web apps. You don't have to keep using webforms controls anymore.
You can't talk about scalability when you still have stuff thrown in aspx pages. You need to start thinking about a proper separation of concerns, think about testing your stuff, retrieving only the data you need etc etc. Just because you add WebApi in the mix, that doesn't mean you'll get all the benefits, if everything else does not catch up to the required standard.
There is no inherent performance issue with using WebAPI, aside from the overhead of an additional network hop.
In real world terms, I think this would be negligible and outweighed by the benefits:
You get the 'cross platform' benefit you mentioned.
Better scalability as your 'service' and 'web' concerns are seperated and can be scaled appropriate to the load they need to serve.
The service layer functionality is re-useable, for example if you wanted to develop an app later.
When I googled about React.js what I got is: React.js is a Framework that is used to create user interfaces. If a particular part of the website is frequently updated that means we can use react. But I am confused that Ajax has been used for this only. We can update a part of site using Ajax without page refresh. For templating we would be using handlebars and mustache. Could somebody explain me in what ways react is different from Ajax and why we should use it.
In short, React uses AJAX. They are not related in the way you're asking.
Keep reading for a crash course in what React is, what AJAX is, and how they are used to make modern web applications.
This is probably a more simple explanation than you're looking for, but for anyone else who may be confused...
AJAX and Airplanes
Think about an Airplane. The most important part of an airplane is that it flies. But an airplane also has wheels. And the wheels serve a very important purpose, because without them the airplane would never fly or land, and despite all the awesome stuff a plane could do in the air, it wouldn't matter without wheels.
This is the same relationship that React has with AJAX. React is the airplane, and AJAX are the wheels. But, ya know, other things have wheels too. Tractors, cars, even some boats have wheels, and they're all very important, and crippled without wheels. So too is AJAX to other web technologies, but when you're talking about airplanes, its wheels are usually the farthest thing from your mind.
So React is to AJAX, what an Airplane is to Wheels.
But let's talk about AJAX. What is it? Why is it so important? How it is used in websites today. Then I'll show how it's used by React. Then show you what React does that's so impressive, it makes you forget about AJAX - Like an Airplane to its wheels.
Remember Websites in the 90's?
When you clicked anything, a new page would have to load to show the effect of your click - even if it was nothing. Here's an awesome example. Go to that page and click around... See how clicks whisk you away to a completely different page? That is the Internet before AJAX.
Now, take a look at this very page: next to each answer is an Up Arrow... Go ahead and click one of them... Notice the page doesn't reload, but you are given feedback: the arrow turns Orange. This may seem insignificant, but it represents big advancements in web technology: AJAX, or more accurately: the AJAX approach to web development.
The AJAX approach allows that to happen! And this is no big deal now; it's so intrinsic to the web experience, it's difficult to imagine the Internet without it.
AJAX and a Clock Face
A good analogy of the AJAX methodology, and how it changed the web is a simple wrist watch, or a wall clock... Imagine the minute, hour and second hands moving around the clock's face to show time. Now, suppose every movement of the second hand caused the entire clock to be destroyed and rebuilt?
All that effort of destroying and rebuilding just to show a tiny change?! Well, that would be an outrageous waste of resources, and that was the Internet of the 90's. Thankfully, we have AJAX now. Just as a clock seamlessly displays the time, AJAX allows web pages to show changes in data immediately, without the page needing to be refreshed; you click an up arrow, and it turns orange. No page reload needed!
Originally, AJAX was just the name given to using existing technologies together to show simple updates to the user, but it has become so intrinsic to the web experience that unless you know what you're doing, you wouldn't even know you're using it. For instance, fetch is the preferred way to accomplish the AJAX approach since 2015. Before that it was XMLHttpRequest - even though JSON was used to transfer data more often because it's less verbose. JQuery is the only web technology that actually says AJAX ($.ajax()) to my knowledge, but you typically wouldn't (and shouldn't unless you really know what you're doing) use JQuery with a react application.
And AJAX works just like webpages:
The user performs an action (like pressing an up arrow)
A client (A Web Browser like Firefox) requests data from a server (like the Stack Overflow (SO) Server).
The server processes the request (updates the database to record the upvote).
The server sends a response back to the client that says if the action was successful or not.
Finally, some of the code already loaded into the web page, decides how to process this new information (in our example, javascript would add a class to the up-arrow and CSS rules would dictate that elements with that class are orange).
The user only sees that the arrow is orange. All the other steps are hidden so it seems like one seamless, responsive action.
Single-Page Applications
Since we're not rebuilding the entire page with every click, you can keep information about the site stored in the browser. This can be used throughout your entire visit and future visits.
The first time you visit Stack Overflow, all of the CSS, JS, and HTML is loaded. These three languages define the style (CSS), behavior (JS), and structure (HTML) of the data sent back and forth from the server. And guess how that data is sent! AJAX.
This is how most of the web works now. Google, Facebook, Amazon, Youtube, Reddit, every site built with WordPress and WIX, even Stack Overflow - they all use this basic paradigm for delivering their sites to users efficiently. The difference comes in how the Single-page application is built and managed...
React.js
React is a javascript library for building and maintaining Single-Page Applications.
But that's not even that big of a deal. The big deal about React is how it allows you to build applications...
Basically, you build things separately, then put them together: Components come together to form an Application. So take a look at this totally plausible but fake code for all the answers on this page:
answerArray.map(a => <Answer answerData={a}></Answer>)
This is one line that shows most of the information on this page. That is a big deal. The developers at Stack Overflow created their own component, called "Answer" and its only job is to show an Answer. You run that in a loop, and bam, all the intricacies of all the answers are abstracted, hidden in the Answer Component, which is completely separate from other components.
Now take a look at this:
<App>
<Header />
<LeftSidebar />
<Question>
{ answerArray.map(a => <Answer answerData={a} /> )}
</Question>
<RightSidebar />
<Footer/>
</App>
This is the whole Stack Overflow site.
Each tag (Header, Question, Answer, etc.) is a component. These components are completely separate and have self-contained code, but here they are used together to build the more complex application.
Composition
An important concept of React is composition, and we just defined it above. "Composition allows you to build more complex functionality by combining small and focused functions" (flaviocopes). Our Application is composed of smaller components.
It's also important to note that each component contains its own functionality. That means if the user clicks a button and a warning appears, the button and the code that makes the warning appear are in the same component.
Functional Programming
Surprise, we already defined this too. Functional programming, for our purposes, means 1. objects; and 2. how they behave; are in the same place. Like the button example above. Click a button, get a warning. And that's all in the same file.
This is different than pre-React development where all the buttons would be in one file, and all effects of the buttons would be in another. And this isn't necessarily a wrong way to do things, but for web development, it is easier to think in terms of self-contained building blocks, rather than widely dispersed tools that don't work by themselves.
Why you shouldn't care about Moustache and Handlebars
These two technologies have been cannibalized by React. Similar to how React uses AJAX but makes it easier, Moustache and Handlebars are already inside React, and you're using them all the time without even knowing it. And to me, that's ok. There are arguments to the contrary, and knowledge is never a bad thing, so investigate further if you want, but this is already long enough, so that's all I'll say about that.
Instead, I will tell you about 3 technologies you should care about.
What you should care about instead...
Node
The main point of Node.js is that it executes JavaScript outside a browser. Big whoop, right? Well, it turns out this is one of the most influential advancements for web developers ever. In fact, downloading Node is often done before downloading React.
Node is important for 2 huge reasons:
It lets you download other stuff
It lets you process JavaScript before sending it to a browser
I could write pages and pages about Node, but your takeaway from this should be "Node is important, I should be on the lookout for more knowledge about Node and how it relates to React and web development."
NPM
NPM does not stand for "Node Package Manager", but it should, because that's exactly what it does. React, SASS, Angular, Vue, pretty much everything mentioned here you will probably use npm to install and keep updated.
Webpack
Webpack is a "module bundler". It takes all your js and css files and writes them to one file so you only have to worry about writing one <script> tag.
Each React component will have at least one js file associated with it. Each component should have its own file too. Keeping track of all those files is very demanding. Webpack does it for you, it just makes life easier, so learn about it early and don't shy away from it.
This is something so inherent to React Apps that most of the time it will just be working and you won't even know it. For instance, create-react-app installs it automatically, and does not require you to do anything - same with Babel...
Babel
Translates all your code to ECMA5 so it can be read by most browsers and most versions of those browsers.
Again, this can be installed with npm, or if you just want to play around with React and not get too bogged down with the minutia like this, you can run create-react-app, and this will just work with automatic settings and will be out of your hair while you learn.
They make stuff easier
NPM, Webpack, Babel, and many other Node packages are only there to make your life easier. Building web apps require a lot of maintenance - or small, non-programming annoyances that typically you don't even need to think about.
Try not to be intimidated by new packages because wielding their power can mean countless hours devoted to more interesting things.
Conclusion
Hopefully, this post has helped you learn the difference between React, AJAX, and the ongoing nature of web application development. React and AJAX are not comparable, but React uses AJAX, or rather you - the developer - use AJAX in React to get data without the page needing to reload.
AJAX and other technologies were monumental to the advancement of web applications, but because of how absolutely essential they were to applications, they were assimilated into new technologies so much so that you don't even have to know about them to reap their benefits.
My goal was to correct some misconceptions on your path of learning; explain the "why" of the current state of web dev; and introduce technologies you didn't mention but should know about: Node, npm, Babel.
If you want to continue learning, I highly recommend doing a tutorial in React. I have done some at platform.ui.dev/, and enjoy their approach to learning and their payment structure (I haven't been paid to say this). Good luck out there, and I hope this was helpful.
Ajax is used to refresh a web page without having to reload it : it sends a request to the server, but typically the response is processed by the javascript that displays dynamically a new element on the browser without having to reload the entire page.
React is a javascript library that dynamically update the page with inferface components. The components are calculated either by javascript interactions or by an ajax request that go through the server. So ReactJS can also use Ajax requests to update the page.
Mustache and Handlebars are a bit different from ReactJS as the main goal is to transform a template in a component that will be displayed in a page. It can also use Ajax to get data (for getting templates or json datas).
Ajax
We are using Ajax to send http requests. And we can't re-render a particular area of the page(DOM) by using Ajax alone. We need jQuery to re-render the page after an ajax call came up with the response. Actually comparing jQuery + HTML and React.js is far better than comparing ajax and React.js.
React.js
The role of the react.js is dividing page(DOM) into small pieces (Components). ex:- Profile image area, Main Navigation, Sidebar, Textfield, Button. etc. from Big pieces to small pieces. Most importantly we can bind functionalities into these components. Example:- Let's assume users need a popup to upload a profile image by clicking on above "Profile image area". We can write a function to open a popup. And also we can write another function to upload profile image to the database. In this way we can use ajax inside the React.js
Please follow this tutorial.
To simply put, React is a JavaScript library built by Facebook. It is commonly looked as a framework because of its many extensions but the official docs label it as a library for building user interfaces. Ajax on the other hand is not a library or a framework or a language at all. Ajax is a technique used by programmers to call web APIs without having the flow of your code be interrupted at all. At the end of that day, your JavaScript code is run synchronously line by line and Ajax is run asynchronously within your synchronous code but in a way in which it will never pause your code from and have it wait for the API call to be sent and received. With Ajax, sending and receiving data is all done in the background so you won't have to worry about the delay that it takes to get that data. You can actually use Ajax in your React code. Ajax uses something called Fetch to actually call an API and you can use a variety of methods to handle the data that you receive from the API such as .then and .catch or Async/Await. You also aren't required to use Fetch at all, there are other third party ways of calling an API with Ajax such as by using Axios. I'd advise you to watch a video on how to use these different tools because when you figure out how they all work, you'll find that React and Ajax can be used together to build a great application. Hope this helped, please vote however way you felt about this answer. I'm pretty new to this website.
If you've scrolled down to this point you probably have this feeling of missing something in these answers which are great though. For me, it was hard to grasp what AJAX is. I had to look it up on Wikipedia. You can find a very good explanation there. I also read Jesse James Garrett archived article from 2005 where he coined this term (AJAX) and described it as a new approach to web applications. To dig deeper you can visit MDN.
Asynchronous requests are so obvious today in web development that it's hard to imagine there were websites without them. That's the key to understanding AJAX. At that time XMLHttpRequest API was something new. Now we have Fetch API in JavaScript or we could use Axios.
Google Maps approach was revolutionary in 2005. You could zoom in, grab a map, and scroll around. This instant response you had without page reloading was a result of the approach called AJAX. It consisted of a set of technologies like XMLHttpRequest, DOM, html & css, javascript.
As you can see AJAX is an old term to describe an approach in web development that makes applications more responsive (more than 20 years ago). Thus no matter what framework you use (Vue, Angular) or a library like React you use AJAX approach whenever your calls to API are asynchronous and they don't stop the user from interacting with your app which is a standard approach today.
BTW React is a library because it doesn't have a built-in state management tool, or routing tool in contrast to Ember.js, Angular, or Vue. We often talk about React stack, a set of separate tools for building react apps (Redux, Zustand, context api, react-router).
Considering the most popular MVC/MVVM client-side patterns (like Knockout.js, Angular.js, Ember.js, and others), I have one great doubt:
Also considering the modeling redundance in both sides, what is the advantages and disvantages to use those client-side patterns with MVC server-side patterns?
I struggled with how to answer this question... hopefully this helps, even if it is in a round-about way.
While some of the pros/cons have already been stated, I think the best rundown is in this answer.
For me, the biggest advantage to using client-side logic is the rich UI aspect.
But the key part of your question seems to be "model redundancy" (I'd call it duplicated logic, or at least having potential for duplicated logic). In my opinion, that is a problem which may exist independently of the pros/cons in the previous link.
So first of all, I think that the decision of whether or not to use a client-side framework should be made based on the well-documented pros and cons. Once that decision is made, the associated problems can be solved.
Lets assume you are using some sort of server-side framework/platform, as well as a client-side framework to provide a little bit of UI interactivity. Now there is a problem with where to put the model logic: on the client, server, or both.
One way to solve the problem is to define your model logic in only the client or the server. Then you have no code duplication, but it affects some of the higher-level pros/cons.
For example, if your model logic is 100% server-side, you lose some of the interactive part of the UI. Or, you are constantly throwing the model to/from the server, which will have a few cons.
If your model logic is 100% client-side, you could suffer performance problems, depending on the size of your view / model. This is one of the reasons Twitter is moving to a server-side processing model.
Then there is "both"... having model logic exist in both the client and the server. I think this is the best solution, as long as no logic is duplicated.
For example, on a shopping cart page, you may recalculate the cost of an order based on the price of a product, and a user-editable quantity box. I think this logic should only exist on the client. Other model properties that do not change once loaded are probably fine hosted on the server.
There's a lot of gray area here... I struggle with putting all the eggs in one basket. For example, choosing a client-side framework, creating a lot of client-side logic, and then [hypothetically] running into problems with performance, browser support, or something like that. Now you may want to tweak a page or two for performance (like move it server-side, a la Twitter). But I think being smart about how you structure your code will help mitigate that issue. If your code is maintainable and clean, moving logic from client to server won't be difficult.
The advantage is that the client side patterns are applicable at the client where the server has no direct reach. If you're building a rich, interactive HTML UI then use client side MVVM. Server side MVC may still be relevant in that case for delivering appropriate content to the client. For example, the ASP.NET WebAPI is a framework for creating HTTP APIs which has a similar controller architecture to the ASP.NET MVC framework. The API implemented with this framework may be called by client side code resulting in MVC on the server side and MVVM on the client side. Normally, when using MVC server side and MVVM client side, the responsibilities of the respective sides are very different and thus there is no redundancy.
The fact you an incorporate a MVVM model into an already implemented MVC framework is also a great thing, we recently added knockout to some new project pages to fit with in an already outdated MVC framework (old pages, not the framework itself).
I think MVVM is fantastic as the above answer states it provides an exceptional user experience with extremely fast response times, you can hide your validation calls in the backround with out slowing them down and its intuitive.
The pain however is that it is VERY hard to unit test and you can get some extremely LARGE javascript files, also the extra coding we've had to do as our legacy systems still run on IE6 is ridiculous.
But MVVM and MVC don't have to be used exclusively on there own, we use both. But having 3 levels of validation is something that still bugs me.
advantages
This can rock.
disvantages
You can screw it.
Seriously. Making use of transporting part of the frontend logic into the browser can boost your application development why you keep more strict data-processing encapsulated on server-side.
This is basically layering. Two layers, the one above talks with the one below and vice-versa:
[client] <--> [server]
You normally exchange value objects in a lightweight serialization format like Json between the two.
This can fairly well map what users expect in a useful structure while domain objects on server-side could not be that detailed.
However, the real power will be if the server-side is not in written in javascript at some certain point because I think you can not create well domain objects there. Consider Scala (or something similar expressive) then if you run into that issue.
Ten months later after this question, I have used the both patterns inside the same application.
The only problem was the need to map the models twice.
MVC (ASP.NET MVC 4 Web API)
The most important resource was the routes.
Models were created to database interactions and as arguments for
controllers' actions.
Controllers were created to manipulate the API
requisitions and to render the views.
Views were not modeled with
server-side models, but all the resources of Partial Views and
Sections.
MVVM (Knockout.js)
Models were created with the same properties as the server-side models.
Views were binded with models' properties, and decreased a lot of the views' size.
View-models were created with the values provided from API methods.
Overall, the MVC combination with MVVM were very useful, but it needed a big expertise and knowledge. Patience is required too, because you need to think about the responsibilites of each application layer.
I used to utilize MVC 3 Razor engine to render pages. Sometimes I had to use AJAX calls to transfer Razor-rendered HTML and inserting it into the page using JQuery. As new project is starting, we do consider to utilize MVC 4 Single Page Application framework which is new to us. I took the first glance at it which left me with mixed feelings:
On the one hand it implies all your data are transferred by JSON and client does all the job to render them and encode some UI-related logic which is great for server and network performance. On the other hand the client (HTML+JavaScript) becomes much more heavy with a bunch of magic strings and hidden relations inside it which seems to be hard to maintain. We got used to VS intellisense, type-safed .NET server code to render pages which we have to exchange for client scripts and Knockout binding statements in case of SPA.
I wonder are any prons and cons of using SPA comparing to Razor, other that this obvious one I've mentioned here? Thanks
Razor is a server based technology where SPA (Single Page Application) is an architecture approach used on the client (web browser). Both can be used together.
From a high level, SPA moves the rendering and data retrieval to the client. The web server becomes a services tier sitting in front of the database. An MVC pattern works best when using SPA. Frameworks like Knockout.js and Backbone.js can be used for this. The net results is a rich responsive desktop like experience.
To achieve this you'll need to be a descent javascript programmer or be willing to learn javascript.
Yes it's moving business requirements from C# into javascript. In Visual Studio there is limited intelli-sense for javascript. To have confidence in your javascript you'll need to lean on unit testing. The up side is the rich user experience (think gmail or google maps).
I think it sounds like you are already fairly well apprised of most of the trade-offs here; you'll have reduced network load with SPA, and will shift a measure of the processing to the client. You will, however, increase the complexity of your code, and make it slightly harder to easily maintain the system (simply because of the increased complexity - not due to any architectural problems inherent in SPA).
Another thing to keep in mind is compatibility. The reason I mentioned a "false choice" in my comment to your question is that to keep the site usable for folks with Javascript disabled, you will still need to provide regular, whole-page views. This is also a good idea to do for the sake of SEO; a crawler will browse your site as a user with JS disabled, and can then index your site. The site should then handle such incoming URLs properly so that those with JS enabled will find themselves in your SPA looking at the same content (as opposed to being dumped in the "no JS" view unnecessarily).
There's something else I'll mention as a possibility that might help with the above, but it breaks the ideals of an SPA; that is, using Ajax-loaded partials in some places, rather than JSON data. For example, say you have a typical "Contact EMail" form on the site; you want that to load within the context of the SPA, but it's probably easier to do so by loading the partial via AJAX. (Though certainly, yes; you could do it with a JSON object describing the fields to display in the e-mail form).
There will also likely be content that is more "content" than "data", which you may still wish to load via partials and Ajax.
An SPA is definitely an interesting project, and I'm about to deploy one myself. I've used a mix of JSON and partials in it, but that may not be your own choice.
My project's domain is of eTendering. And we are planing to use Spring and Hibernate in the architecture and in presentation Spring MVC but we want look and feel like silverlight of .Net or Flex of adobe in short we are planning for Ajax framework in presentaion. So SpringMVC will be worthfull? I have seen wicket and openxava but I am still confused so please suggest correct option in terms of my domain's complexity.
Depends on your needs:
Spring MVC - this option will leave you with writing AJAX on your own (via JQuery for instance) along with HTML and so forth. It might be tedious, but you're controlling everything. It's also up to you what will be the quality of your resulting HTML and how good it will be indexed by SEO.
JSF - this option provides you with a number of components and allows you to create AJAX based forms and handles it out-of-box. But when it comes to writing custom components, it won't that easy as just writing JS/JQuery on your own. Also it generates not that pretty HTML which is not of that good quality and you might be less indexed by SEOs.
GWT - this choice would mean that you don't write JS, instead you write logic in Java and then it transforms to JS. From one hand it will provide you with good-looking AJAX-based app where you don't need to write JS, from the other hand it's a) pretty complicated to write really good-looking apps UI b) it will add another step in your development cycle (it takes pretty much time when you generate that JS) c) it almost won't allow your pages to be indexed. Also, if it comes to such derivatives as SmartGWT, they provide a large set of cool-looking components, but they always require money for support.
Vaadin - this is AJAX based framework that partially generates Java to JS, but it also sends requests go server for logic execution (of course in GWT this happens as well, but not that often, GWT tries to execute logic on client). It takes less time to compile sources to JS and it's also almost impossible to make pages being indexed.
ZK - another AJAX based framework. unlike other frameworks that allow you to work with only one pattern, it can work in MVC, MVP, MVVM modes. It doesn't compile Java sources to JS thus all the requests go to the server (I've heard about internal company's benchmarks that showed it was actually faster than GWT, but I think it depends on your processing logic). SEO won't make it with ZK at all, but it's possible to include ZK components into JSP pages (though this functionality is not free) which makes it possible to kill both birds. It will be not trivial to write your own components with ZK, but it has a wide range of ready-to-use components.
So you should consider several things: SEO, money you can give for the framework, how much AJAX you need and do you want to write it on your own, etc.
Also pay attention to those patterns I mentioned: MVP for instance is suitable for complicated interfaces and is supported by GWT, Vaadin, ZK. MVVM is very cool because of its binding and is supported by JSF and ZK.