I have a client that's running an application based on JBoss 4.0.5, Seam 1.2 and RichFaces 3.0.1. Their system is having performance problems due to the fact that a lot of data is coming back from the server to be displayed on screen and it seems like the rendering of that data is taking forever. The data brought back is displayed in a tabbed interface, but the tabs aren't currently being loaded individually, but all at once.
I'm trying to build up a case to present to the client on the benefits of upgrading to never version of RichFaces, which, as I understand it, has added a great number of features related to tabbed panels and being able to use ajax to page the data and load the chunks you actually need to display at the moment, and not the rest that's in other tabs.
The move to a newer version of RichFaces will also result in never versions of Jboss and Seam, as the current production build of RichFaces 3.2.1 requires JSF 1.2.
IF anyone has some suggestions or experience on performance of current versions RichFaces, paging, etc, I would really appreciate some feedback.
I haven't noticed much of a performance improvement by upgrading through various Richfaces versions. You're better off optimizing the code that is involved in the rendering - for example checking whether code is called mutliple times (as is the case when logic is placed in a getter).
I've found the bean-timing interceptor (#MeasureCalls) that Tobias Hill outlines in the Seam forum to be absolutely fantastic - more so than a profiler for specific problems (probably less so if you don't know where to start looking). It lets me track down those methods that are called more often than required and allows me to streamline my beans.
The forum link is : http://www.seamframework.org/Community/SeamPerformanceProblemRewardingWorkaround
One warning... I recently upgraded to JBoss 5.1.0GA, JSF 1.2, etc... so that our software stays current, but there is a drawback. JBoss 5 uses -significantly- more memory than JBoss 4, and takes longer to start. It would be wise for you to test our your new configuration on one machine before attempting to switch system-wide.
Use a profiler and do it for yourself. Only you have the application. Only you know which combination of components are "slow". I think you can measure it for yourself very fast.
p.s. show us the results ,-)
I find the Apache implementation of JSF1.2 much better the the Apache implementation of JSF1.0. I use a little RichFace 3.2 and it seems fine, still a bit too much information being sent on the ajax requests from the client so RichFaces Ajax executes much slower then a hand crafted AJAX solution, but code very much faster in RichFaces.
Related
I am currently working with a Banking firm, we have a requirement to develop a fairly complex but Rich UI application. We are using EXTJS 4.2 and Spring MVC.
The first release of the app went into Production about a month back.
Now while modelling the new phase, we have come across a major hurdle. The application load up time is fairly high at this point of time. This is happening because the application has followed a single Page web 2.0 model and multiple JS files which when minified -> all-classes.js is 3 MB.
Now there is a lot of work to be done going ahead in order to build additional functionality.
Since all code is getting loaded at once during startup it would take a lot of time for this.
I figured out a design but I am not sure if that would help.. If we divide our application into multiple pages each have a different --> all-classes.js , will it help improve the performance ?
I need some advice on this.
You can refer to this links which I found : http://docs.sencha.com/extjs/4.2.0/#!/guide/command_app_multi
http://www.sencha.com/forum/showthread.php?130449-Large-Single-Page-Architecture-in-ExtJS-4.0/page2
Well, there are a number of answers to this, the best of which is "it depends".
Splitting into multiple pages is obviously going to produce some performance improvements. After all, you'll (presumably) have smaller files to initially load, fewer controllers to instantiate, etc.
The question is how much? I'm not sure I can answer that very well, without knowing more about the app and how it's structured.
I do know this, however. I have an app whose all-classes.js is around 2 MB. While there is obviously the initial hit loading it, subsequent visits use a cached version of it. And even the initial load of the 2MB file is pretty fast on most decent connections.
I have been developing a plain JSP/Servlet web application, which focuses mainly in collecting large sets of data through JSPs, processing them and finally commiting them to a MySQL database. Imagine something like a declaration of assets for a pretty big number of people.
While it works pretty good now, the code is really jumbled up and since I now have the time, I am thinking of completely redesigning the whole application in a more sophisticated and reusable way. My main problem is that forms are built mainly through jQuery (my form_build.js and form_validate.js files span over 600 lines each at the moment), and the back-end java code is jumbled up since there is massive use of name[counter] input fields.
I.e. The user can add 5 assets in the form, where he has to submit something like 30 fields of information on each one. The form sends them in the form of attribute[asset_counter].
If I managed to make myself clear, I have been looking into the Google web toolkit - which I had no idea of before - and from what I gather mastering it will take some time for me. Is it worth the trouble, or is it aimed at something completely different? And is there a framework or technique that can handle efficiently what I need?
Frankly, I am a senior java developer and I used a lot of jsp/jsf web applications accompanied by EJB, webservice, simple spring web apps, and I recently came up to use GWT.
It's a very nice platform, it has the following advantages:
All the code is compiled to html/JS which is better in terms speed
and browser understanding agilty
It uses built in JSON xml transer (nice approach)
It use built in AJAX (nice approach)
It use it's own cleint server platform (no need to use other
libraries for each one)
It will adopt to any browser (strong competetor)
drowbacks:
Sometimes it takes time to load in the browser (specially when using
FlexTables)
I advise you to use it!
GWT is a very powerful toolkit, and from what I understand it might help you to better organize you client side code. But you also have to consider some high-level JS framework like backbone.js+require.js or Google Closure. Time spent to learn this frameworks this bascially the same as for GWT, the choice basically depends on what your team prefer, JS or Java. In most cases when logic on client side gets very complicated, I will choose GWT.
Just got back reading a question from 2 years ago here.
From there and several other places on the internet i concluded that developing with Ext-GWT was sucky.
My question is, with the release of GXT 3, whether it is still the condition now?
I have several GXT applications, one of which is ~35K lines. Have not found any of the problems other people mention.
I was doing straight ExtJs/JavaScript, then moved to GWT with the advent of GWT-EXT and later moved to Ext-GWT (GXT). I would still be doing ExtJs/JavaScript today if it were not for those two toolkits.
Performance issues: non issue on modern browsers. on IE6/7, you want to use common sense, displaying 1000 rows in a grid is not the best idea, from a performance and usability standpoint.
GXT is still crappy. We've been using it and although it provides some nice widgets it takes forever to write any business code. Most of our time is spent trying to get GXT to do the things we want. For example, using RPC is painfull because you have to keep converting from JPA entity beans to ModelData object (or some other object that can be serialized over RPC), Also there are inconsistances such as if you want to use the FormBinding object (which automatically maps between form elements and ModelData), then you can't use FieldSets which are really useful. FormBinding will only work with FormPanels and not FieldSets.
Also if you want to use the FileUploadField object you can't test it in Dev mode because of the post URL.
Basically, if you want to add 40% more time to your development fine. But otherwise go with a normal JavaScript framework.
We have been using GXT 2.x in the last one year while we built 3 projects with GXT.
Other than the lack of a WYSIWYG UI designer which makes the UI designing relatively slow compared to other frameworks, it is still IMO the best widgets library built on top of GWT.
So far we have not encountered any major issues with GXT.
A good performance comparision can be found here: http://gxtvsgwt.appspot.com/
In our current project we have been using Ext-GWT 2 for about a year without any major complaint. It's sometimes a bit buggy but generally works.
We used GXT 2.1.x for a year without any major problems. recently, we updated to GXT 2.2.4 and just needed minor changes in our code, but they weren't because of GXT, but due to the upgrade to GWT 2.3.0
Personally, i like coding with GXT. I can't see why someone would say GXT development is sucky, except for the already mentioned performance issues and the lack of a UI Designer.
I don't know any other GWT-based framework with so much features.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
From the following list of frameworks, which one would you use to develop a rich web application and why would you choose it over the others?
Sproutcore
GWT
ExtJS
GXT
SmartGWT
Dojo / Dijit
Flex
Capuccino
Grails
I'm personally tired of browser inconsistencies. If someone else has solved the problem, I'd rather not do it again. That's why I'm getting more interested in front ends like cappuccino and qooxdoo. They are a zero-HTML zero-CSS solution.
These are based on my personal experiences using the frameworks you have mentioned. So yes, it is a bit biased. So as others have said over and over again, define your requirements and which one do you think fits your requirement based on what people have suggested here.
GWT is too verbose eventhough I found many Java developers love GWT because you can unit test it and it's all in Java. But I personally don't like it because it is far from being simple. There are times when I feel I can tweak a little bit with Javascript, but with GWT I am enforced to do it with several lines of Java code.
GXT is too far from GWT these days and you will find it difficult to do things as GXT has its own way of doing things which is way too different from GWT. When complex requirement come up, in the end you are going to go back doing plain GWT. And oh, their technical support is not that good either as I had several bad experiences when asking few questions to them.
Ext-JS is good for simple stuff and the look and feel is really slick. But when things gets more complex, you are going to fight you're way through. Eventhough I have dealt with the GXT tech support, I haven't dealt with the ExtJS tech support since they have different people eventhough it's in one company, so I can't say much.
Flex is nice, really nice. But again it is good for simple stuff. Once things gets more complicated you are going to write lots of actionscript, which is less enjoyable. There are many things that is available out of the box which may be to difficult if you have to code it in Javascript, like multimedia support. And oh, if you are writing for a public website you must consider that not too many user has flash plugin on their browser.
Grails, I'm not sure how you would implement RIA apps with Grails since Grails is just another MVC framework which you need to add your own RIA framework on top of it such as the ones that you have mentioned.
This is strictly a matter of opinion. You will not get any definitive answers from anyone, since anyone that answers will have one or another that they personally prefer.
Try each one for long enough to decide which one is best for your (or your team's) purposes.
That being said, I prefer GWT. Others will invariably disagree with me.
Reasons that I like GWT:
You can share (some) client- and server-side code (as long as your server is written in Java)
GWT makes a lot of advanced performance features really easy (e.g., deferred JS loading, image spriting, CSS obfuscation)
A focus on one-page apps, with third-party support for Places (using the gwt-presenter library)
It's just as easy to add GWT to an existing web page as it is to create a full one-page GWT app
UiBinder allows you to write your UI using a declarative HTML-like syntax; you're not stuck writing Swing-like UI if you don't want to
Browser incompatibilities are (mostly) taken care of by GWT -- you just write Java code, and GWT compiles it to work on every browser
Things that may make GWT not right for you:
If your server is already written in something besides Java, you will still be able to write your UI in GWT, but you'll lose out on some nice features
Compilation time using GWT is a non-trivial cost -- Development Mode mitigates this a lot, but it's still an issue sometimes
As others have mentioned, GWT can be considered "verbose" compared to simple JavaScript libraries like jQuery or ExtJS
Ext GWT has worked well for my project. The premium support has been good.
However the project is for internal use which has allowed deployment to be restricted to one browser on one OS, and no effort has been made to change the default appearance or behaviour of Ext GWT.
Developing entirely within Java is a key benefit as it helps to keep the project manageable as features are added.
I am currently working on a grail/flex hybrid app that is working a lot better than I expected. I have looked at GWT but there were not a lot of books about it at the time and it seemed to stress the leveraging of Swing-like programming techniques which I have never liked. I agree with the comment about trying them all out. Run hello app they all have and measure how hard or easy it is to modify. Also tool (IDEs, Maven, CI...etc) support can be a big factor as well in terms of being immediately productive.
We are using Grails+ExtJS here. Since we try to make an idiomatic ExtJS application, Grails is not fully utilized, though it still makes sense to use Grails instead of, say, JSP, for the server-side part.
Why ExtJS: Because it's a very rich toolkit for GUI-like web applications. Our job is to replace an old Motif GUI, so this is exactly what we need.
Why Grails: Because it gets the job done easily and quickly. For the communication with the ExtJS part, we need a lot of JSON, and in Grails it's like that:
import foo.bar.FooBar
class FooBarController {
def viewFooBars = {
def list = FooBar.getList(session.userId, params.foo, params.bar)
def result = [resultset: list] as JSON
response.setHeader('Content-disposition', 'filename="json"')
response.contentType = "text/json";
render result
}
}
And that's even two or three lines more than necessary...
Unfortunately the answer will be opinionated, GWT in it's purest form is not an eye-candy. That being said, ExtJs GXT is super hunky dory. One of the major issues I face with evolving frameworks is that they are not absolutely defect free, If I remember correctly, GWT 2.0 was shipped out with missing CSS styles for some of the new layouts. I am trying to trouble shoot an issue in ExtJs/GXT since last 5 days :(, frameworks obfuscate a lot of things. I will go with any framework that is absolutely robust and gives appropriate error messages. I haven't worked with others though.
I'd recommend Dojo.
In addition to the massive infrastructure it provides, Dojo 1.6 is also the first (and only) popular JavaScript Library that can be successfully used with the Closure Compiler's Advanced mode, with all the size, performance and obfuscation benefits attached to it -- other than Google's own Closure Library, that is.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
In other words, a program using Dojo can be 100% obfuscated -- even the library itself.
Compiled code has exactly the same behavior as plain-text code, except that it is much smaller (average 25% over minifiers), runs much faster (especially on mobile devices), and almost impossible to reverse-engineer, even after passing through a beautifier, because the entire code base (including the library) is obfuscated.
Code that is only "minified" (e.g. YUI compressor, Uglify) can be easily reverse-engineered after passing through a beautifier.
ExtJs is great for creating complex web applications. The API provides anything you can imagine in a webapp and its really easy to extend any component after some time.
You can plug it to any backend (we use django or php) and reuse or extend any component in several different applications.
You'll need severals months to feel comfortable with it. IMHO.
That said, the lib is sometimes a bit too slow for simples uis like a website (then you can use ExtCore). But when it comes to webapps this is not an issue.
Im not a java guy so GWT was not an option for me :/
hope this helps
I'm starting work on a smartGWT project in a few days and I'd like to know what kind of experiences you had. To avoid making this a bashing of smartGWT or GWT or a freestyle discussion, I'm going to provide some pointers for the discussion:
Do you feel that the provided widgets are integrated well? Is there any widget you miss in particular?
Have you encountered any problems when designing your application that were caused by the framework?
Is the datasource integration as usefull as the smartClient team claims?
What methods do you use to make your smartGWT application persistent? e.g. How well do Hibernate and smartGWT play with each other?
Feel free to add anything you feel is worth pointing out.
I guess you already have your answers, but I would like to add a few more comments that may affect your decision:
Pros:
SmartGWT is the most compreensive LGPL GWT-based widgetery library you can find. So if you care for GPL pain, this is your thing
Comprehensive Showcase.
Really good performance (just check the Showcase).
Very active community in the forums.
SmartGWT extensions is another important project. For example, it has support for GWT-RPC based communication, which is not possible only with SmartGWT (unless you implement your own integration).
Rapid pace of development from the SmartGWT guys. Just count the number of releases since the SmartGWT project appeared.
Cons:
Besides the Showcase, I sometimes feel the only way to figure out how something works is by asking in the forums. This leads to a spread knowledge base. A community based wiki would be preferable.
Large amount of static files you have to use with your application (the famous 'sc' directory) which might lead to problems if your back-end is in GAE (because of the 1000 files limit).
We used SmartGWT in our last project (duration: 6 months). The following is my personal opinion:
The widgets are really great! The documentation and API is verbose. We would use client-side again.
The server-side integration works, but did not save any development time. Instead we had a lot of problems where we had to find workarounds. Also, because of the new API, no other developer can maintain the project within investing a lot of time to learn the SmartGWT API.
Some Cons:
You have to learn a totally new API instead of using Hibernate and GWT-RPC or REST.
The data integration is done automatically, that is true. But if you need some (also little) changes, you have to write XML mapping files as with Hibernate or JDO. So the benefit is gone.
The forum support is bad: You get an answer to almost every posted question. But that answer often does not help. They ask you things such as “why do you want to do that”. Or they say: “use our tool and do XYZ with it” three times, although again and again I told them this suggestion does not work. After a few answers to a question the final answer is: “you need training, buy our support”.
The commercial support is way to expensive (costs approximately as much as the SmartGWT license).
We will probably not use the server-side integration of SmartGWT again.
You can read all my "lessons learned" with Pros and Cons at my blog:
http://www.kai-waehner.de/blog/2010/12/11/lessons-learned-smartgwt-2-3-component-library-for-google-web-toolkit-gwt/
Best regards,
Kai Wähner
Do you feel that the provided widgets
are integrated well? Is there any
widget you miss in particular?
You could create any missed widgets, there is no single framework that can provide everything you want. The widgets are pretty extendable.
Is the datasource integration as usefull as the smartClient team claims?
The data (JSON/XML) can be provided by servlet services, and they are understood by the
widgets.
What methods do you use to make your smartGWT application persistent? e.g. How well do
Hibernate and smartGWT play with each other?
In the backend servlet services of GWT, you can persist your data in the store by using any persistent layer in Java. Hibernate can be just used as same as normal java app.
Do you feel that the provided widgets are integrated well? Is there any widget you miss in particular?
Yes. The widgets have a consistent API and work well together.
Is the datasource integration as usefull as the smartClient team claims?
This IMO is one of their strongest feature. Once you start using their Datasource API you realize how little code is required to get a fully functional CRUD screen
What methods do you use to make your smartGWT application persistent? e.g. How well do Hibernate and smartGWT play with each other?
Hibernate works out of the box with the SmartGWT EE version. With the LGPL version using Glead works wells
I think SmartGWT has a ton of great widgets, but but but there is a HUGE price.
Create a simple SmartGWT based project and watch how many files get loaded by your page.
That, I think, is totally against the ideals of something like GWT. While SmartGWT may be a pretty good option for people on a deadline, if you want raw performance, stay away from it.
The number of HTTP requests will simply kill your application.
Have you encountered any problems when designing your application that were caused by the framework?
Yes. When I combined Google Eclipse plugin, SmartGWT, GWT 1.6.4, and Wicket the gwt compiler would emit bad javascript. By bad javascript, I mean javascrip that would not work in webkit, or firefox. I was not able to get good javascript until I removed it completely from the Eclipse project and restarted Eclipse. So, this combination would not work and I ended up building the SmartGWT piece separately in another project. The other issue is that the Smart client seems to want control of the whole page in a css sense. So, the integrated SmartGWT module was all messed up, because styles were not isolated properly. Your mileage may vary.
Personally if you use SmartGWT only and for everything then all will most likely be fine, but if you try and mix it, well my results were disastrous. So, I no longer use it.
Just as a counterpoint to the poster above who mentioned troubles with Wicket, the SmartClient forums (forums.smartclient.com) have reports of success integrating SmartGWT with a wide variety of other technologies. This poster's problems sound like 1) a GWT bug causing bad JavaScript and 2) CSS naming conflicts between SmartGWT and Wicket, probably neither framework's fault. All of SmartGWT's style names can be renamed via the skinning system to resolve any such conflict.