Is JSF really ready to deliver high performance web applications?

Question

I have heard a lot of good about JSF but as far as I know people also had lots of serious complains with this technology in the past, not aware of how much the situation has improved. We are considering JSF as a probable technology for a social network project. But we are not aware of the performance scores of JSF neither we could really come across any existing high performance website that had been using JSF. People complain about its performance scalability issues.

We are still not very sure if we are doing the right thing by choosing jsf, and thus would like to hear from you all about this and take your inputs into consideration.

Is it possible to configure JSF to satisfy the high performance needs of social networking service ? Also till what extent is it possible to survive with the current problems in JSF. What exactly are its problems ?

I am not worried about the development complexities with JSF what others usually complain about because as per my personal experience I believe that's not at all true, but I am more concerned about what performance and scalability issues. And please don't just abuse it on its old issues linked to previous versions. I just care about the present state whatever had been its past.

https://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/ I know that there has been a response by the JSF chief architect who justifies every decision, but to me, someone who knows some web technologies and who suffered, even with JSF 2.0, Facelets and SEAM, this is mockery. Even James Gosling sais: "I hate JSF with a passion." I'd use Wicket or Tapestry and avoid JSF and its problems altogether. — Falcon, Nov 20 '11 at 16:39
@Falcon you could just say you don't like JSF and leave it at that... — , Nov 20 '11 at 20:46
@ThorbjørnRavnAndersen I disagree with you gently. I think it is better to provide more explanation than just saying: "I hate JSF" — Chiron, Nov 20 '11 at 21:09
@chiron, well, if you dislike or even hate it, could you actually provide any insight that the OP needs? — , Nov 20 '11 at 21:57
@ThorbjørnRavnAndersen I understand your point but I really encourage people to provide more info. For example, a down vote without a comment always annoys me. — Chiron, Nov 20 '11 at 22:01
@Chiron, the question is not whether JSF is usable or not, but if JSF can be made to perform. People who start by putting the framework down, can most likely not answer the actual question. Maintaining a JSF application myself, I'd like to know too. — , Nov 21 '11 at 07:14
@Falcon, notice how the ptrthomas link is all about JSF 1.x. Despite being challenged to come up with criticism for JSF 2.x, nobody seems to be able to come up with anything concrete. JSF 2.x has addressed pretty much each and every complaint uttered in the impressive collection of links peter collected. It's therefor an excellent testimony against using JSF 1.x, but says nothing about JSF 2.x. — Arjan Tijms, Feb 18 '12 at 09:49
> Even James Gosling sais: "I hate JSF with a passion." - It's well known this was a mistake, as he meant to say JSP. Listen carefully to the fragment in question. It's about what was created in response to classic ASP, and that was JSP, not JSF. — Arjan Tijms, Feb 18 '12 at 09:50
@Arjan Tijms: I have used JSF 2.0 with Seam and Facelets and I don't care what you say to defend JSF. It's still crap. — Falcon, Feb 18 '12 at 09:51
@Falcon, anything more specific than a kind of argument like "Android rulez, iPhone sucks"? — Arjan Tijms, Feb 18 '12 at 10:33
@Arjan Tijms: Boy, have you ever written a custom user control in JSF? Go ahead ... try it. If you like it, you simply just don't know the better technologies out there. — Falcon, Feb 18 '12 at 12:13
@Falcon, it's called a *custom component* in JSF. And yes, I've written plenty. Ever since JSF 2.0 it's incredibly easy. Composite components are the easiest ones (put a simply .xhtml file with markup in the /resources folder and it's fully useable). But Java based ones are really simple too. See http://jdevelopment.nl/simple-java-based-jsf-custom-component and http://jdevelopment.nl/jsf-22/#594 It's a Java class that inherits from `UIComponentBase`, nothing more. I've got a strong feeling you only know JSF 1.x, in which creating custom components was indeed tedious. — Arjan Tijms, Feb 18 '12 at 12:21
@Arjan Tijms: Sure it's easy as long as your component is as simple as that. What about JavaScript integration, and the fact that IDs are automatically created with a ":". Having generic actions in composite facelets controls is still a major pain. JSF looks good on paper and in examples. In real world applications it just causes a lot of little headaches that pile up to a big mountain of crap. And I told you: I've worked with JSF 2.0, Facelets and JBoss Seam and won't ever again. Also JSF, is just complex. It's fine if you like it, the majority of users doesn't. — Falcon, Feb 18 '12 at 12:28
>What about JavaScript integration - What about it? It's no problem at all. A Java component can declare a dependency on a script and JSF will automatically make it available. The JSF JS API is readily available for user programs and you can easily get the client ID of components for interaction with them in your own scripts. — Arjan Tijms, Feb 18 '12 at 12:41
@Falcon >and the fact that IDs are automatically created with a ":" - if the colon it self is your beef, you can replace it with any other character, e.g. an underscore. If the automatic creation is your beef then you can assign explicit IDs. If the fact that you don't know the ID for usage in your client-side scripts then there is API available to obtain this ID. — Arjan Tijms, Feb 18 '12 at 12:45
@Falcon >Having generic actions in composite facelets controls - do you mean passing action methods? That's fully supported by default. Facelets tags were problematic indeed, but that's another thing and there are workaround for that. — Arjan Tijms, Feb 18 '12 at 12:47
@Falcon >It's fine if you like it, the majority of users doesn't. - actually, JSF scores pretty well in many surveys and statistics. See e.g. http://henk53.wordpress.com/2011/10/12/reply-to-comparing-java-web-frameworks You seem to be advocating Wicket in some of your posts, but that one seems to be less popular overall. — Arjan Tijms, Feb 18 '12 at 12:49
@Arjan Tijms: I don't care if JSF is popular. Those statistics don't show what developers actually think about it. Most of them use it because they have to or because they think it's the standard. JSF is a major PITA. — Falcon, Feb 18 '12 at 13:02
@Falcon >Most of them use it because they have to - that's the exact same card Bruno Borges tried to play at http://zeroturnaround.com/java-ee-productivity-report-2011, but http://it-republik.de/jaxenter/news/Und-das-populaerste-Webframework-ist...-060497.html actually asked what developers LIKE, not what they USE. And surprise, JSF still scores very high. There are also tons of open source projects for JSF. Those are started voluntarily by individual developers. There's nothing forcing them. — Arjan Tijms, Feb 18 '12 at 13:20
Comments are not suitable for extended discussions, if you want to continue this one please move it to chat. Feel free to post a single comment with a link to the transcript, to keep the discussion connected with the question. — yannis, Feb 18 '12 at 13:52
I don't use JSF on highly loaded servers, but for light usage it's VERY fast, even when handling a lot of data. I've done a few custom apps for manufacturing in it and was impressed to the point where it's my primary web tool now. — Brian Knoblauch, May 01 '13 at 15:45
"I am not worried about the development complexities with JSF what others usually complain about because as per my personal experience I believe that's not at all true..." You sir are an idiot. I can say that with complete confidence, having used JSF extensively. — Andrew, Mar 08 '19 at 18:41

score 24 · Answer 1 · answered Feb 18 '12 at 10:29

JSF is most definitely capable of delivering high performance web applications. The app I'm currently working on is completely in JSF and from the log stats I can see that many non-DB intensive pages have minimum execution times of 0ms and average times of less than 10ms.

Some of the Wicket guys have been saying things about JSF' performance, but according to this elaborate benchmark JSF actually performs better than Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/

Notice that as long as the server isn't saturated, JSF also performs better than GWT. The GWT/JSF benchmark comparison is difficult though, since it's really important that the server for GWT also does the conversion and validation of data in the postback that JSF does. This is something you simply can't leave out in practice (never trust the client). Also, for the GWT vs JSF/Wicket graphs, it should be taken into account that the browser's rendering step is trivial for JSF/Wicket (since they mostly serve ready-to-render HTML), but the GWT client still has some work to do after receiving the server response.

One of the major performance/scalability issues that old JSF versions (prior to 2.0) had, was abusing state saving by putting way too much data in it. Things that absolutely should not have been there where put into it (like constants such as 'foo' as in <my:tag attribute="foo"/>).

JSF 2.0 introduced the partial state saving mechanism, which means only delta state is being saved. In practice this can be very little and reductions of two orders of magnitude compared to JSF 1.x are not uncommon.

After years of using JSF, I can say that except for saving too much state in JSF 1.x, I've never run into any performance issue that I could attribute to JSF. Any performance problems we ever had were always rooted in the DB and/or how we set up back-end services, wrote our queries, etc.

@gbjbaanb I don't think so, these came from statistics that were quite professionally set up. Do note that I'm talking about the *minimum* time and about *non-DB intensive* pages. Pages executing in such time obviously did not have 1000 components on them spread over 100 includes. We're talking about relatively simple pages here, maybe 10 components, 1 master template, maybe 1 include, on a server that has been running for a while so everything is hot and in memory. Average time is higher (10ms as I mentioned) and 90% higher too. Max can be anything. — Arjan Tijms, Oct 01 '13 at 07:02
The situation is that this world criticizes only those things that are capable of solving all the problems. But that solving all the problems always come at a price and requires a great zeal and an enthusiasm. What I have seen in teams is they start developing without even understanding the life-cycle. It involves a steep learning curve but it's beautiful as well as remarkable. — Farhan stands with Palestine, Nov 02 '15 at 19:13
The bottleneck is more likely to be in the database/IO and bandwidth (mobile ...) than the server itself. Java is really fast when used well. — Christophe Roussy, Oct 19 '17 at 09:42

score 8 · Answer 2 · answered Nov 22 '11 at 21:29

All the theoretical in the world can say JSF is wonderful, but just take a look at what your pages look like. It produces massive piles of javascript and other crap that are going to severely handicap your ability to add in modules like jQuery or clean use of CSS. Not saying it can't be done, but at what cost.

Personal experience with a relatively small project and medium complexity. A disaster. It was a mess dealing with all the callbacks and you can't mix in other technologies easily. We had a huge bug that turned out to be caused when using JSTL mixed in with JSF. We never were able to use all the jQuery stuff due to the fact that EVERY link is a javascript callback.

Run away and run away fast.

Also when you say scale, what kind of scale are you talking about. Number of pages, number of users, number of requests per second, number of features. The answers to these may help you. Also when someone tells you it needs to scale ask them to what degree and how fast. The answer will help you tremendously. If you are talking google scale in a week or are you talking about 1000 users and 10000 page views per day in a year.

Almost any framework, short of you typing in responses real time in the background, will scale to meet 99.999% of the use cases.

-1 for any framework scales. That's like saying "don't care about performance." — Raynos, Nov 22 '11 at 23:14
In and of themselves any published web framework will scale including JSF. They all say they do, it would be a pretty crappy framework if it didn't. That said, many people do stupid things with it and that is usually where the scaling problems arise. — Bill Leeper, Nov 23 '11 at 14:53
true, but some frameworks encourage you to do things with hinder scaling, either because the framework encourages or the community encourages it. I would argue those frameworks don't scale. — Raynos, Nov 23 '11 at 14:59
The "how do you measure scaling" bit should perhaps be a comment to the question? — , Dec 06 '11 at 23:19

score 4 · Answer 3 · answered Mar 02 '13 at 00:52

4

Disclaimer: I like JSF. Anyway, even with the latest RI (Mojarra 2.2.x) or MyFaces, even with the long awaited stateless implementation performance is very poor. This is because of the JSF lifecycle and the fact that each View is (expensively) built for every request.

To get a clue, this is a simple benchmark against a plain java servlet vs a JSF page, both just printing "hello world"

Servlet

glassfish-3.1.2.2$ ab -n 10000 -c 100 http://localhost:8080/mavenproject-web/NewServlet

Server Software:        GlassFish
Server Hostname:        localhost
Server Port:            8080

Document Path:          /mavenproject-web/NewServlet
Document Length:        128 bytes

Concurrency Level:      100
Time taken for tests:   0.970 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      4300000 bytes
HTML transferred:       1280000 bytes
Requests per second:    10307.02 [#/sec] (mean)
Time per request:       9.702 [ms] (mean)
Time per request:       0.097 [ms] (mean, across all concurrent requests)
Transfer rate:          4328.14 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.0      1       5
Processing:     1    9   4.6      8      51
Waiting:        1    8   4.4      7      40
Total:          4   10   4.1      8      51

Percentage of the requests served within a certain time (ms)
  50%      8
  66%     10
  75%     11
  80%     11
  90%     12
  95%     14
  98%     29
  99%     33
 100%     51 (longest request)

JSF

glassfish-3.1.2.2$ ab -n 10000 -c 100 http://localhost:8080/mavenproject-web/xhtml/test/jsf.xhtml

Server Software:        GlassFish
Server Hostname:        localhost
Server Port:            8080

Document Path:          /mavenproject-web/xhtml/test/jsfxhtml
Document Length:        100 bytes

Concurrency Level:      100
Time taken for tests:   4.676 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      4250000 bytes
HTML transferred:       1000000 bytes
Requests per second:    2138.60 [#/sec] (mean)
Time per request:       46.759 [ms] (mean)
Time per request:       0.468 [ms] (mean, across all concurrent requests)
Transfer rate:          887.60 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       6
Processing:     5   46   6.0     46      73
Waiting:        2   45   5.5     45      72
Total:          8   47   5.8     46      73

Percentage of the requests served within a certain time (ms)
  50%     46
  66%     48
  75%     50
  80%     51
  90%     54
  95%     56
  98%     60
  99%     62
 100%     73 (longest request)

answered Mar 02 '13 at 00:52

gpilotino

140
4

1

I don't think a simple helloworld page can be representative or meaningful. A serious comparison must provide necessary information like version numbers, configuration used and so on. Please read the comparison between JSF and Wicket in a previous answer. – lu4242 Apr 02 '13 at 17:16
Let me disagree. I find really meaningful that in the simplest stateless context jsf is 5 times slower than jsp. It's trivial to verify that in more complex scenarios jsf performance get worst. Or i can provide more benchmarks for the laziest :-) jsf implementation is mojarra 2.2 as stated above, with glassfish 3 – gpilotino Apr 02 '13 at 22:36
"... jsf is 5 times slower than jsp ..." I think the mistake here is do not take into account the throughput, and the underlying behavior of jsp vs jsf. It is too complex to explain, but in this case, the response time is obviously slower because jsf has a concurrency effect that jsp do not have. But at the end it is more accurate to compare the cycles per second. Also, Mojarra is not the same as MyFaces, so both implementations has different numbers from performance perspective. Note the concurrency effect in this case is exagerated. – lu4242 Apr 03 '13 at 01:41
In fact, it is completely absurd to compare a plain servlet vs JSF. The only comparison that has sense is an "application" made using JSP/servlets vs another "application" that do exactly the same using JSF. Why? because JSF provide built-in solutions for rendering/ajax/navigation/validation, things that needs to be done from scratch or by hand in JSP. Even if the comparison is interesting from performance perspective (no framework will be faster than servlet/jsp), JSP is no match for JSF, because it doesn't do even a tiny part that what JSF does for you. – lu4242 Apr 03 '13 at 02:00
"it is completely absurd to compare a plain servlet vs JSF". no, it's not. both technologies are supposed to deliver content. this is why i'm taking into account stateless contexts, where validation and other things just doesn't count. "the response time is obviously slower because jsf has a concurrency effect that jsp do not have" isn't this a scalability issue itself ? about myfaces, afaik mojarra it's the fastest implementation around (i'll investigate this) – gpilotino Apr 03 '13 at 07:59
JSF and servlet/JSP are two completely different "animals". It is too simplistic to compare things in that way, and then try to get a conclusion. That is not convincing, no one will believe that. The concurrency effect is not a scalability issue, because response time is not the same as throughput. Please read the document [comparing JSF and Wicket](http://lu4242.blogspot.com/2012/05/understandingjsf-2-and-wicket.html), and you'll see a comparison between MyFaces and Mojarra too. – lu4242 Apr 03 '13 at 16:01
Note that comparison is old, and was done using old versions of the libraries. Also, those guys does not provide a way to verify its results. It also does not consider the inherent differences between different frameworks. My point is if you are going to do a comparison, do it on the "same level". Don't compare how much time it takes to render something, compare a full use case done in xxx against yyy, keeping the same business model and the database. Performance is not the only consideration for web framework, people wants to make apps without effort, at a reasonable perf cost. – lu4242 Apr 04 '13 at 15:51
sorry i've deleted the comment as i felt it was somewhat rude (even if i think you're, at best, "passionately biased" :), here's the link again http://www.devoxx.com/display/DV11/WWW++World+Wide+Wait++A+Performance+Comparison+of+Java+Web+Frameworks that said, i agree when you say performance is not everything, but the question is about it. for other jsf cons (like the necessity of using an external library, pretty-faces, to do simple url mapping) i'm open for discussion somewhere else:) – gpilotino Apr 04 '13 at 21:01
The truth is I'm working in extend the comparison done between JSF and Wicket for other frameworks, including this case too. I hope to include a detailed analysis and clarify the different concepts, but that will still take some time. I know this topic is interesting and controversial, but I'll update this site when the work is complete. – lu4242 Apr 05 '13 at 03:22

score 3 · Answer 4 · edited Dec 25 '12 at 19:15

An article that might help a little (although not really conclusive) is Server Centric Java Frameworks: Performance Comparison at DZone Javalobby:

...This article reviews how much effective most of the SPI Java web frameworks are on partial changes provided by the server. We are not interested in events with no server communication, that is, events with no (possible) server control.

How they are going to be measured

We are going to measure the amount of code that is sent to client regarding to the visual change performed in client.

For instance for a minor visual change (some new data) in a component we expect not much code from server, that is, the new markup needed as plain HTML, or embedded in JavaScript, or some high level instructions containing the new data to be visualized. Otherwise something seems wrong for instance the complete component or page zone is rebuilt, wasting bandwidth and client power (and maybe server power).

Because we will use public demos, we are not going to get a definitive and fine grain benchmark. But you will see very strong differences between frameworks.

The testing technique is very easy and everybody can do it with no special infrastructure, we just need FireFox and FireBug. In this test FireFox 3.6.8 and FireBug 1.5.4 are used.

The FireBug Console when "Show XMLHttpRequests" is enabled logs any AJAX request showing the server response...

Frameworks tested

RichFaces, IceFaces, MyFaces/Trinidad, OpenFaces, PrimeFaces, Vaadin, ZK, ItsNat

...apparently the only JSF implementation free of serious performance penalties is PrimeFaces...

I haven't been able to find a proper comparison (for performance), if anyone finds one I'd love to see it!

score 3 · Answer 5 · answered May 21 '12 at 18:48

If you want to understand more clearly how JSF performs (both Mojarra 2.1.7 and MyFaces 2.1.7) and compare it against a similar framework like Apache Wicket(both 1.4.20 and 1.5.5), take a look to this in-deep comparison (MAY 2012):

Understanding JSF 2 and Wicket: Performance Comparison

The good part is everything is available (code, experimental data, instructions about how to reproduce the test, a detailed exhaustive report). It will solve all your questions about JSF performance, and you'll see what Apache MyFaces is able to do.

score 2 · Answer 6 · answered Nov 21 '11 at 07:11

There is a problem with Facelets in general which IMHO is a pretty inconvenient thing to use. It is four times more wordy than indeed necessary and need too much manual work once you make one step off something primitive. HybridJava would be a good replacement for Facelets as presentation engine within JSF - it does the same job (and even much more, in particular - it makes all the "bindings" and ids for you) with much fewer keystrokes.

Jonathan S. Fisher · Answer 7 · 2013-05-01T15:40:58.277

So I wanted to throw a similar benchmark in. I took a twitter bootstrap example page and converted it into xhtml strict. After that, I setup exactly one ApplicationScoped CDI bean that returned Hello, World. I put the EL expression on the page. For the JSF version, I used the JSF resource handler, for the JSPX version, I used HTML style css and js includes.

I used apache bench to test the main page load time. The test was performed on an un-optimized TomEE+ v1.5.2 server. I ran each benchmark 5x, then ran a full GC before taking a measurement. Bost tests were done in the same JVM instance without restarting the JVM. I have the APR available on the libpath, but I'm not sure that affects this test.

JSF is slower, but not by a whole lot, since we're dealing with very small quantities. What is not demonstrated is as the pages get more complex, does JSF/JSPX scale linearly or exponentially.

One thing I noticed is that JSPX is produces very little garbage compared to JSF. Running the benchmark on the JSPX page caused the used heap to jump from 184mb to 237mb. Running the benchmark in the same JVM on the JSF page causes the used heap to jump from 108mb to at least 404mb, but an automatic garbage collection kicked in at that point. It would seem tuning your garbage collector for JSF is an absolute necessity.

JSF

jonfisher@peanut:~$ /usr/local/bin/ab -n 10000 -c 100 http://localhost:8080/cdi-jsp/index.jsf
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /cdi-jsp/index.jsf
Document Length:        2904 bytes

Concurrency Level:      100
Time taken for tests:   2.138 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      32160000 bytes
HTML transferred:       29040000 bytes
Requests per second:    4677.27 [#/sec] (mean)
Time per request:       21.380 [ms] (mean)
Time per request:       0.214 [ms] (mean, across all concurrent requests)
Transfer rate:          14689.55 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.3      1      21
Processing:     1   20   9.0     18      63
Waiting:        1   19   8.8     17      62
Total:          2   21   8.8     20      64

Percentage of the requests served within a certain time (ms)
  50%     20
  66%     23
  75%     25
  80%     27
  90%     32
  95%     39
  98%     46
  99%     50
 100%     64 (longest request)

JSPX

jonfisher@peanut:~$ /usr/local/bin/ab -n 10000 -c 100 http://localhost:8080/cdi-jsp/page2.jspx
This is ApacheBench, Version 2.3 <$Revision: 1373084 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost
Server Port:            8080

Document Path:          /cdi-jsp/page2.jspx
Document Length:        2440 bytes

Concurrency Level:      100
Time taken for tests:   1.273 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      26290000 bytes
HTML transferred:       24400000 bytes
Requests per second:    7856.63 [#/sec] (mean)
Time per request:       12.728 [ms] (mean)
Time per request:       0.127 [ms] (mean, across all concurrent requests)
Transfer rate:          20170.98 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    5   2.3      6      20
Processing:     1    8   4.6      6      40
Waiting:        1    8   4.3      6      40
Total:          2   13   3.8     12      41

Percentage of the requests served within a certain time (ms)
  50%     12
  66%     12
  75%     13
  80%     13
  90%     17
  95%     20
  98%     24
  99%     28
 100%     41 (longest request)

score -3 · Answer 8 · answered Dec 25 '12 at 18:53

-3

GWT converts your java code into java script. so it runs as a java script on your client side. And also, you can integrate css into your gwt applications. In general, gwt is light weight and can run across all browsers without any problem. I dont know much about JSF. But I think dt, JSF is not that flexible like GWT.

answered Dec 25 '12 at 18:53

Joenan

1

1

It doesn't answer the question, which is about JSF performance and not framework recommendation. Anyway, GWT is usually liked by people that don't know JavaScript ^^ – Danubian Sailor Nov 26 '13 at 15:04

Is JSF really ready to deliver high performance web applications?

8 Answers8

How they are going to be measured

Frameworks tested

JSF

JSPX

Linked