Hi I am trying to compare the performance of zk and gwt.
In my comparision I cant write any javascript by myself if the framework itself converts some code into js its ok(like gwt) but I cant write js by myself
On writing code in the above way for almost anything done on browser a request is sent to the server in ZK.
Hence eventually if you compare the no of request sent by zk to server is too high as compared to gwt.
i would like to ask the following.
whose performance is better zk or gwt while ignoring the above.
if we dont ignore the above then is my conclusion that gwts performance is better than zk right ?
I know that there might be other parameters when comparing performance... but if the difference between requests are so high i cant really see zk beating gwt which some people have said on some forums
pls help
thanks
GWT and ZK are very different architecturally. GWT is client-centric so it sends less requests to the server. With GWT you can basically control everything by yourself. This on the otherhand means, the developer is responsible for handling server requests and asynchornouse data transfer between server and client. If you are an experienced web developer then the result could be great. If you are not then it could be pretty challenging and complex as there are some network and security issues you need to take care.
On the other hand, ZK is server-centric, it handles these server-client async communication for you. With ZK developers can focus more on the business logic without taking care of client-server issues. As the framework takes care of client-server talk, there are more requests by default. If you wish to minimize the request, you can probably follow their developer's guide to do some tuning.
IMO ZK and GWT are both matured framework. You can probably think about your project requirements and your experiences in Web development then choose the solution.
The previous posts are basiclly, but there are some features in zk that,I think, must be talked about.
Remember, every request is a zk-event, cos zk is completely event-based.
Client-Side Event-Handling
Zk allows you to implement client-side event-handling just as well as server-side,
which includes preventing zk from firing an event to the server.
You can simple manipulate the client objects in js as you can do it in Java on the
server-side or just do some post processing and and then...
Use Client-Side Event-Firing
Zk got that usefull js method zAu.send(zk.Event,int) that let's you send custom
or standart events to the server.
Deferrable Event-Listeners
Deferrable-events are queued at client-side, so you can minimize the number of
requests.
Stubonly
Stubonly is a way to make a component client-side only. But by now this is only
available for zk EE.
So, you can see, if you like, you can limit the requests to maybe the same amount of requests of GWT.
If it make sense or not depandce on you/your applycation. But I think you can say that zk is more powerfull than GWT.
You maybe interested in iZUML and defer rendering too.
ZK is server side focused, since GWT is all in the browser, so ZK needs much more ajax hits to the server to get js fragments, screen portions, etc. whereas GWT just hit the server at the beginning to download the js app (which will be cached in the client for ever) and whenever the app needs some data from the backend.
Said that, IMHO GWT should perform better since you dont need any sort of view logic being executed in the server (lighter servers), and there are less requests in the wire.
GWT and ZK are kind of different.
I've done some ZK projects and also some GWT projects. I didn't have performance issues in either cases,but I feel I need to write more code when I use GWT.
My experience from real world projects with two teams, one writing using the zk framework and the second using GWT. Identical UI projects having data served from the same data service layer. The zk team completed the project in one third of the time the GWT team consumed. Both projects deployed in production. Users were happy using either app. Finally we kept the zk version in production. Why? Simply because the maintenance of the zk app was so much faster and simple compared to GWT! Sorry GWT... Nice technology backed up by a giant but we will keep going with zk.
Related
Let's say I wanted to create a collaborative web application where users can simultaneously work on e.g. a diagram. I have my interactive web site (HTML/CSS/JavaScript) on the client side, and let's say a Java application synchronizing a centralized model on the server side. How would client and server exchange messages? To get a better idea of how the system is supposed to work like, here are some details and a small illustration:
Requirements
The underlaying technology should support authorized communication to show/hide sensitive information.
The model of the diagram should only exist on the server (centralized model, no copies), whereby changes should be broadcasted to other users (other browsers who are currently editing the same document).
After receiving changes to the model, the server shall perform computationally higher demanding tasks such as consistency checks and inform the user if e.g. an action is invalid.
Constraints
The system must not poll or set flags (it should be a direct communication).
The website must not be reloaded during use.
Software running on the client must be restricted to JavaScript.
Technology I've found
Here are some of the solutions I've looked at, ranked from (imho) most suitable to least, whereby I'm not sure if the list is even complete and all my assumptions are correct.
Java Web Service using javax.jws - The service would offer an API described by WSDL and be capable of responding with SOAP messages using the HTTP protocol, but can JavaScript process these messages?
Servlets & Java Server Pages (JSPs) - Would, as far as I know, require a page reload to fetch new content (isn't this pretty much the same as PHP? Both are executed on the server to generate HTML pages..)
I've already found this question which, however, does not provide concrete technologies in the answer. Thank you for any hints and clarification, I dearly appreciate it!
As you have already found out, there are many approaches to this common problem.
SOAP (sometimes called "Web Services" or "WS*") is a standard that was developed for application to application communication. It's strengths are precise specifications (and therefore many good libraries), interface sharing for client and server (through WSDL), and discoverability.
However, SOAP has very limited -if any- support in Browsers.
The most common modern approach is probably RESTful web services based on XML or JSON. When used in a browser as client, JSON is preferred, as the unmarshalling is trivial in JavaScript. Many frameworks and libraries like Angular and jQuery take on the tedious cross-browser AJAX request crafting. Some boilerplate is required to wrap the data in HTML, however. This downside can also be an upside if you consider the cleaner architecture and maintainability.
Since you're using Java on your server, you might also want to look into JSFs AJAX capabilities. It doesn't really use REST (no well-defined resources), but loads server-side rendered chunks of your HTML page asynchronously (read: AJAX) and re-renders them in the DOM. This can be seen as a compromise between real REST and full page reloading. The good side of it is you don't have to define any resources but your backing beans. The downsides are: possible overhead, since you're downloading HTML instead of pure data; and bad testability since you cannot access the rendered chunks outside the JSF context.
Wholly different issues are 1. the synchronization of concurrent requests and 2. communication with clients from server. For the latter you can either look into Web Sockets (the next big thing) or the good-old polling.
If concurrent edits of the same data are a concern to you, you'll have to implement a sort of strategy to tell whether edits can be merged or whether one has to be declined. The client will need to handle such situations and offer the user reviewing, overriding or reverting etc.
EDIT: more on Java servlets and JSP
Servlets are nothing but Java classes that handle specific HTTP requests, usually bound to certain URL paths. They're comparable to PHP pages: In PHP the web server gets a request and searches for a corresponding PHP file. Then it parses the PHP script and returns the response. Servlets do the same, only the syntax is very different. JSP is mostly a try at bringing more PHP-ish syntax to Java. Behind the curtains, they're rendered to pure Java servlets.
Java servlets have a long history which is older than AJAX, but many frameworks have taken on the challenge of implementing flexible resource handling on the server. Most notably Jersey and RESTEasy, which are implementations of the Java EE standard JAX-RS; and Spring, which is a request-based framework that competes well against Java EE standards. Then there is also JSF, which is sometimes called a successor of JSP. To the user it's little different than JSP, but the syntax is nicer and IMHO it is more feature-rich than JSP. Especially considering extensions like PrimeFaces. In contrast to JSP, JSF embraces AJAX and many built-in components are capable of communicating with the server using AJAX, including calling Java functions and re-rendering parts of the page.
I would recommend you try websockets since connections will be persistent between clients and server and any of them can send a message at any time.
You could implement a websocket server in Java on the server and use Javascript's built in websockets functionallity on the clients.
Take a look at https://www.websocket.org/ to learn more about websockets.
I am redesigning a web application which previously has been rendered server side to a Single Page Application and started to read about websockets . The web application will be using sockets to have new records and/or messages pushed to the client. I have been wondering why most pages which make use of sockets don't handle all their communication over the socket. Most of the times there is RESTful backend in addition to the websocket. Would it be a bad idea to have the client query for new resources over the socket? If so why - other than that a RESTful api might be easier to use with other devices?
I can imagine that using websockets would probably not be the best idea in case the network connection is kind of bad like on mobile devices, but that probably should work quite well with a reasonable connection to the web.
I found this related question, however it is from 2011 and seems a little outdated:
websocket api to replace rest api?
No, it won´t be a bad idea. Actually I work in an application that uses a WebSocket connection for all what is data interaction, the web server only handles requests for resources, views under different languages, dimensions .. etc..
The problem may be the lack of frameworks/tools based on a persistent connection. For many years most of frameworks, front and back end, have been designed and built around the request/response model. The approach shift may be no so easy to accept.
Coming back to this question a few years later, I would like to point out a few aspects to illustrate that having all your communication through websockets does have its drawbacks:
there is no common support for compression. You can easily configure your webserver to compress http requests and browsers have been known to happily accept compressed responses for years, however for web sockets it is still not that easy (even though the situation has improved)
client frameworks often are build upon commonly used standards like rest. The further away you move from frameworks expectations, the less addons or features will be available.
caching in the browser is not as easy. By now this goes a long way, reaching into the realm of offline availability and PWAs.
when using technology, that is only used by a subset of users, it is more likely to find new bugs, or bugs might take longer to fix. And if it's not bugs, there might be an edge case somewhere around the corner. This isn't an issue per se - but something to be aware of. If one runs into those things, they often easily take up quite some time to fix or work around.
I'm working on the design of a web app which will be using AJAX to communicate with a server on an embedded device. But for one feature, the client will need to get very frequent updates (>10 per second), as close to real time as possible, for an extended period of time. Meanwhile typical AJAX requests will need to be handled from time to time.
Some considerations unique to this project:
This data will be very small, probably no more than a single numeric value.
There will only be 1 client connected to the server at a time, so scaling is not an issue.
The client and server will reside on the same local network, so the connection will be fast and reliable.
The app will be designed for Android devices, so we can take advantage of any platform-specific browser features.
The backend will most likely be implemented in Python using WSGI on Apache or lighttpd, but that is still open for discussion.
I'm looking into Comet techniques including XHL long polling and hidden iframe but I'm pretty new to web development and I don't know what kind of performance we can expect. The server shouldn't have any problem preparing the data, it's just a matter of pushing it out to the client as quickly as possible. Is 10 updates per second an unreasonable expectation for any of the Comet techniques, or even regular AJAX polling? Or is there another method you would suggest?
I realize this is ultimately going to take some prototyping, but if someone can give me a ball-park estimate or better yet specific technologies (client and server side) that would provide the best performance in this case, that would be a great help.
You may want to consider WebSockets. That way you wouldn't have to poll, you would receive data directly from your server. I'm not sure what server implementations are available at this point since it's still a pretty new technology, but I found a blog post about a library for WebSockets on Android:
http://anismiles.wordpress.com/2011/02/03/websocket-support-in-android%E2%80%99s-phonegap-apps/
For a Python back end, you might want to look into Twisted. I would also recommend the WebSocket approach, but failing that, and since you seem to be focused on a browser client, I would default to HTTP Streaming rather than polling or long-polls. This jQuery Plugin implements an http streaming Ajax client and claims specifically to support Twisted.
I am not sure if this would be helpful at all but you may want to try Comet style ajax
http://ajaxian.com/archives/comet-a-new-approach-to-ajax-applications
I'm relatively new to the whole AJAX way of doing things so please excuse me if I'll mix two different things (although I'd appreciate it greatly if you could comment me on that).
My question is this:
I have many web clients (lets say around 1500) whom I want when starting up to "subscribe" to the web server with some sort of Id and then I want the web server (APACHE) to send them a relevant url (build dynamically doesn't really matter for this purpose) to display (sort of redirect).
Now my problem is basically that I've spent the last few days reading a lot of articles and howto's on how this should be done and I think I have too many buzz-words.
I think that in order to solve my problem I need some sort of implementation of COMET with something called "continuations" (to support that many clients). Is that correct?
Am I going down the right path?
Does GWT have any connection with this?
Thank you all very much in advance
EDIT: After reading some more I think that basically the Java Servlet 3.0 Asynchronous support is exactly what I need on the server side (correct me if I'm wrong) and I'm still debating on the client side? Maybe GWT after all?
Thanks
OK, so I indeed was making a bit of a mess earlier and I'm putting it out there so my nonsense doesn't confuse anyone.
What I was looking for was asynchronous request support both on the server side, regarding the thread handling to allow many users and scalability, and on the client side for ease of use of the Comet patter.
I've found that Jetty, Tomcat and Grizzly all offer a solution for this (just search the specific server with Comet and see what they offer) but I've decided to use the Servlets 3.0 spec as supported in Glassfish even though it will only be released with Java EE 6 as to not be tied down to a specific server.
On the client side I will probably go with GWT for many other reasons not related to Comet and because it has sufficient support for Comet.
Thanks
You may want to try StreamHub Push Server and the accompanying GWT Comet Adapter. This will give you a scalable Comet server and a GWT Client-side.
I want to build an Ajax gui, that is notified on any state changes happening in my ejb application. To achieve this, I thought I build an stateful ejb (3.0) that implements the Observable interface to which the Ajax client is added as an observer.
First, is this possible with Ajax. If yes, is this a good design idea or is there a more propriate way to do this?
Thanks in advance!
Cheers,
Andreas
It sounds like you are interested in 'Reverse-Ajax', where the client is notified when an event happens server side. This is different than standard Ajax, where an asynchronous event is sent to the server based on some client action. Reverse Ajax is possible, and one framework that does a very good job of allowing this is and simplifying the underlying complexity is DWR.
http://directwebremoting.org/dwr/reverse-ajax
You'll want to read up on the performance implications of the various ways to implement based on your expected load, webapp container, etc. regardless of which framework you use.
As for whether or not it is good practice, that really depends on your application. If it is important to get near-real time data pushed back to the client and you don't want to use something like Flex or other heavier frameworks, then I'd say you are on the right track. If the data does not need to be real time, or if your load is extremely high, then perhaps a more simple approach like a scheduled page refresh will save you some complexity and help with performance.
Now, some time later there is a new possible answer to your question: Usage of Websockets
From the previously linked website by Pete: "The web was not designed to allow web servers to make connections to web browsers..." That is changing now with html5.
http://en.wikipedia.org/wiki/WebSockets