Ist JSF wirklich bereit, leistungsstarke Webanwendungen bereitzustellen? [geschlossen]

16

Ich habe viel Gutes über JSF gehört, aber meines Wissens hatten die Leute in der Vergangenheit auch viele ernsthafte Beschwerden über diese Technologie, ohne zu wissen, wie sehr sich die Situation verbessert hat. Wir betrachten JSF als wahrscheinliche Technologie für ein soziales Netzwerkprojekt. Wir sind uns jedoch der Performance-Scores von JSF nicht bewusst und konnten auch keine existierende Hochleistungs-Website finden, die JSF verwendet hatte. Die Leute beschweren sich über Probleme mit der Leistungsskalierbarkeit.

Wir sind uns immer noch nicht sicher, ob wir mit jsf das Richtige tun, und möchten daher von Ihnen alles darüber erfahren und Ihre Beiträge berücksichtigen.

Ist es möglich, JSF so zu konfigurieren, dass es die hohen Leistungsanforderungen von Social Networking-Diensten erfüllt? Auch inwieweit ist es möglich, mit den aktuellen Problemen in JSF zu überleben. Was genau sind ihre Probleme?


Ich mache mir keine Sorgen über die Komplexität der Entwicklung bei JSF, über die sich andere normalerweise beschweren, weil ich meiner persönlichen Erfahrung nach der Meinung bin, dass dies überhaupt nicht zutrifft, aber ich mache mir mehr Sorgen darüber, welche Leistungs- und Skalierbarkeitsprobleme auftreten. Und bitte missbrauchen Sie es nicht nur wegen seiner alten Probleme, die mit früheren Versionen verknüpft sind. Ich kümmere mich nur um den gegenwärtigen Zustand, was auch immer seine Vergangenheit gewesen war.

aklin81
quelle
7
ptrthomas.wordpress.com/2009/05/15/jsf-sucks Ich weiß, dass der Chefarchitekt von JSF eine Antwort gegeben hat, die jede Entscheidung rechtfertigt, aber für mich, jemanden, der einige Webtechnologien kennt und der selbst mit JSF gelitten hat 2.0, Facelets und SEAM, das ist Hohn. Sogar James Gosling sagt: "Ich hasse JSF aus Leidenschaft." Ich würde Wicket oder Tapestry verwenden und JSF und seine Probleme insgesamt vermeiden.
Falcon
12
@ ThorbjørnRavnAndersen Ich bin nicht einverstanden mit Ihnen sanft. Ich denke, es ist besser, mehr zu erklären als nur zu sagen: "Ich hasse JSF"
Chiron
6
@ ThorbjørnRavnAndersen Ich verstehe Ihren Punkt, aber ich ermutige die Leute wirklich, mehr Informationen bereitzustellen. Zum Beispiel ärgert mich eine Abwahl ohne Kommentar immer.
Chiron
3
@Chiron, die Frage ist nicht, ob JSF verwendbar ist oder nicht, sondern ob JSF ausgeführt werden kann. Menschen, die mit dem Ablegen des Frameworks beginnen, können die eigentliche Frage höchstwahrscheinlich nicht beantworten. Ich möchte auch wissen, ob ich eine JSF-Anwendung selbst pflege.
3
> Sogar James Gosling sagt: "Ich hasse JSF aus Leidenschaft." - Es ist bekannt, dass dies ein Fehler war, da er JSP sagen wollte. Hören Sie sich das fragliche Fragment genau an. Es geht darum, was als Reaktion auf klassisches ASP erstellt wurde, und das war JSP, nicht JSF.
Arjan Tijms

Antworten:

24

JSF ist definitiv in der Lage, leistungsstarke Webanwendungen bereitzustellen. Die App, an der ich gerade arbeite, ist vollständig in JSF und aus den Protokollstatistiken kann ich ersehen, dass viele nicht-DB-intensive Seiten minimale Ausführungszeiten von 0 ms und durchschnittliche Zeiten von weniger als 10 ms haben.

Einige der Wicket-Leute haben sich über die Leistung von JSF geäußert, aber nach diesem aufwändigen Benchmark schneidet JSF tatsächlich besser ab als Wicket: http://prezi.com/dr3on1qcajzw/www-world-wide-wait-devoxx-edition/

Beachten Sie, dass JSF auch eine bessere Leistung als GWT erbringt, solange der Server nicht ausgelastet ist. Der GWT / JSF-Benchmarkvergleich ist jedoch schwierig, da es sehr wichtig ist, dass der Server für GWT auch die Konvertierung und Validierung von Daten im Postback durchführt, das JSF durchführt. Dies können Sie in der Praxis einfach nicht auslassen (vertrauen Sie niemals dem Kunden). Bei den GWT- und JSF / Wicket-Diagrammen sollte berücksichtigt werden, dass der Rendering-Schritt des Browsers für JSF / Wicket trivial ist (da sie meistens renderbereites HTML bereitstellen), der GWT-Client jedoch noch einige Aufgaben hat Tun Sie dies, nachdem Sie die Serverantwort erhalten haben.

Eines der Hauptprobleme in Bezug auf Leistung und Skalierbarkeit bei alten JSF-Versionen (vor 2.0) war die missbräuchliche Speicherung des Status, indem zu viele Daten darin abgelegt wurden. Dinge, die auf keinen Fall hätte da sein dürfen (wie Konstanten wie 'foo' wie in <my:tag attribute="foo"/>).

JSF 2.0 führte den partial state savingMechanismus ein, was bedeutet, dass nur der Delta-Status gespeichert wird. In der Praxis kann dies sehr gering sein, und Verringerungen um zwei Größenordnungen im Vergleich zu JSF 1.x sind keine Seltenheit.

Nachdem ich JSF jahrelang verwendet habe, kann ich sagen, dass ich mit Ausnahme des Speicherns von zu viel Status in JSF 1.x nie auf ein Leistungsproblem gestoßen bin, das ich JSF zuschreiben könnte. Jegliche Performance-Probleme, die wir jemals hatten, waren immer auf die Datenbank und / oder die Art und Weise zurückzuführen, wie wir Back-End-Services eingerichtet, unsere Abfragen geschrieben usw.

Arjan Tijms
quelle
1
0 ms ... Ich denke, Ihr Messmittel muss angeschaut werden.
gbjbaanb
2
@gbjbaanb Ich glaube nicht, diese stammten aus Statistiken, die ziemlich professionell erstellt wurden. Beachten Sie, dass ich über die minimale Zeit und über nicht DB-intensive Seiten spreche . Seiten, die in einer solchen Zeit ausgeführt wurden, enthielten offensichtlich nicht 1000 Komponenten, die über 100 Includes verteilt waren. Wir sprechen hier von relativ einfachen Seiten, vielleicht 10 Komponenten, 1 Master-Template, vielleicht 1 Include, auf einem Server, der schon eine Weile läuft, also ist alles heiß und im Speicher. Die durchschnittliche Zeit ist höher (10 ms, wie ich bereits erwähnte) und auch um 90% höher. Max kann alles sein.
Arjan Tijms
Die Situation ist, dass diese Welt nur die Dinge kritisiert, die in der Lage sind, alle Probleme zu lösen. Aber das Lösen aller Probleme hat immer einen Preis und erfordert viel Eifer und Begeisterung. Was ich in Teams gesehen habe, ist, dass sie anfangen, sich zu entwickeln, ohne den Lebenszyklus überhaupt zu verstehen. Es beinhaltet eine steile Lernkurve, aber es ist sowohl schön als auch bemerkenswert.
Shirgill Farhan
Es ist wahrscheinlicher, dass der Engpass in der Datenbank / E / A und der Bandbreite (mobil ...) liegt als auf dem Server. Java ist sehr schnell, wenn es gut benutzt wird.
Christophe Roussy
8

Alle Theoretiker der Welt können sagen, dass JSF wunderbar ist, aber sehen Sie sich nur an, wie Ihre Seiten aussehen. Es produziert riesige Mengen von Javascript und anderem Mist, die Ihre Fähigkeit, Module wie jQuery oder die saubere Verwendung von CSS hinzuzufügen, erheblich beeinträchtigen werden. Ich sage nicht, dass es nicht geht, aber zu welchem ​​Preis.

Persönliche Erfahrung mit einem relativ kleinen Projekt und mittlerer Komplexität. Ein Disaster. Es war ein Durcheinander, mit all den Rückrufen umzugehen, und man kann andere Technologien nicht einfach einmischen. Wir hatten einen großen Fehler, der bei der Verwendung von JSTL und JSF verursacht wurde. Wir konnten das gesamte jQuery-Material nie verwenden, da es sich bei JEDEM Link um einen JavaScript-Rückruf handelt.

Lauf weg und lauf schnell weg.

Auch wenn Sie Skala sagen, welche Art von Skala sprechen Sie. Anzahl der Seiten, Anzahl der Benutzer, Anzahl der Anfragen pro Sekunde, Anzahl der Funktionen. Die Antworten auf diese Fragen können Ihnen helfen. Auch wenn Ihnen jemand sagt, dass es skaliert werden muss, fragen Sie ihn, zu welchem ​​Grad und wie schnell. Die Antwort wird Ihnen enorm helfen. Wenn Sie in einer Woche über Google Scale sprechen oder wenn Sie über 1000 Benutzer und 10000 Seitenaufrufe pro Tag in einem Jahr sprechen.

Nahezu jedes Framework, in dem Sie Antworten nicht in Echtzeit im Hintergrund eingeben, wird so skaliert, dass es 99,999% der Anwendungsfälle erfüllt.

Bill Leeper
quelle
3
-1 für beliebige Framework-Skalen. Das ist so, als würde man sagen "Leistung ist mir egal."
Raynos
3
An und für sich wird jedes veröffentlichte Webframework einschließlich JSF skaliert. Sie alle sagen, es wäre ein ziemlich beschissener Rahmen, wenn es nicht so wäre. Das heißt, viele Leute machen dumme Sachen damit und dort entstehen normalerweise die Skalierungsprobleme.
Bill Leeper
1
stimmt, aber einige Frameworks ermutigen Sie, Dinge mit Behinderung der Skalierung zu tun, entweder weil das Framework es ermutigt oder die Community es ermutigt. Ich würde argumentieren, dass diese Frameworks nicht skalieren.
Raynos
Das Bit "Wie messen Sie die Skalierung?" Sollte möglicherweise ein Kommentar zur Frage sein.
4

Haftungsausschluss: Ich mag JSF. Trotzdem ist die Leistung der Implementierung ohne Status trotz des neuesten RI (Mojarra 2.2.x) oder MyFaces sehr schlecht. Dies liegt am JSF-Lebenszyklus und an der Tatsache, dass jede Ansicht (teuer) für jede Anforderung erstellt wird.

Um einen Hinweis zu erhalten, ist dies ein einfacher Vergleich zwischen einem einfachen Java-Servlet und einer JSF-Seite. Beide geben nur "Hallo Welt" aus.

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)
gpilotino
quelle
1
Ich glaube nicht, dass eine einfache helloworld-Seite repräsentativ oder aussagekräftig sein kann. Ein seriöser Vergleich muss die erforderlichen Informationen wie Versionsnummern, verwendete Konfiguration usw. enthalten. Bitte lesen Sie den Vergleich zwischen JSF und Wicket in einer vorherigen Antwort.
Lu4242
Lass mich nicht zustimmen. Ich finde es wirklich sinnvoll, dass jsf im einfachsten zustandslosen Kontext fünfmal langsamer ist als jsp. Es ist trivial zu überprüfen, ob in komplexeren Szenarien die Leistung von jsf am schlechtesten ist. Oder ich kann mehr Benchmarks für die Faulsten bereitstellen :-) Die Implementierung von jsf ist mojarra 2.2, wie oben angegeben, mit
glassfish
"... jsf ist 5 mal langsamer als jsf ..." Ich denke, der Fehler hier ist, den Durchsatz und das zugrunde liegende Verhalten von jsf vs jsp nicht zu berücksichtigen. Es ist zu komplex, um es zu erklären, aber in diesem Fall ist die Antwortzeit offensichtlich langsamer, da jsf einen Nebenläufigkeitseffekt hat, den jsp nicht hat. Am Ende ist es jedoch genauer, die Zyklen pro Sekunde zu vergleichen. Außerdem ist Mojarra nicht mit MyFaces identisch, sodass beide Implementierungen aus Sicht der Leistung unterschiedliche Zahlen aufweisen. Beachten Sie, dass der Nebenläufigkeitseffekt in diesem Fall übertrieben ist.
Lu4242
Tatsächlich ist es völlig absurd, ein einfaches Servlet mit JSF zu vergleichen. Der einzige sinnvolle Vergleich ist eine "Anwendung", die mit JSP / Servlets erstellt wurde, mit einer anderen "Anwendung", die mit JSF genau dasselbe tut. Warum? Da JSF integrierte Lösungen für Rendering / Ajax / Navigation / Validierung bietet, müssen diese in JSP von Grund auf oder von Hand ausgeführt werden. Auch wenn der Vergleich unter Performance-Gesichtspunkten interessant ist (kein Framework ist schneller als Servlet / JSP), ist JSP für JSF nicht geeignet, da es nicht einmal einen winzigen Teil dessen ausmacht, was JSF für Sie tut.
Lu4242
"Es ist völlig absurd, ein einfaches Servlet mit JSF zu vergleichen". Nein, ist es nicht. Beide Technologien sollen Inhalte liefern. aus diesem grund berücksichtige ich staatenlose kontexte, in denen validierung und andere dinge einfach nicht zählen. "die antwortzeit ist offensichtlich langsamer, weil jsf einen nebenläufigen effekt hat, den jsp nicht hat" ist das nicht ein problem der skalierbarkeit selbst? Über MyFaces, Afaik Mojarra Es ist die schnellste Implementierung um (ich werde dies untersuchen)
gpilotino
3

Wenn Sie die Leistung von JSF (Mojarra 2.1.7 und MyFaces 2.1.7) besser verstehen und mit einem ähnlichen Framework wie Apache Wicket (1.4.20 und 1.5.5) vergleichen möchten, sehen Sie sich dieses Handbuch an. tiefer Vergleich (MAI 2012):

Grundlegendes zu JSF 2 und Wicket: Leistungsvergleich

Der gute Teil ist, dass alles verfügbar ist (Code, experimentelle Daten, Anweisungen zum Reproduzieren des Tests, ein ausführlicher ausführlicher Bericht). Es werden alle Ihre Fragen zur JSF-Leistung beantwortet und Sie werden sehen, was Apache MyFaces kann.

lu4242
quelle
3

Ein Artikel, der ein wenig helfen könnte (obwohl nicht wirklich schlüssig), ist Server Centric Java Frameworks: Leistungsvergleich bei DZone Javalobby:

... Dieser Artikel beschreibt, wie effektiv die meisten SPI Java-Webframeworks bei Teiländerungen sind, die vom Server bereitgestellt werden. Wir sind nicht an Ereignissen ohne Serverkommunikation interessiert, dh an Ereignissen ohne (mögliche) Serversteuerung.

Wie werden sie gemessen?

Wir werden die Menge des an den Client gesendeten Codes in Bezug auf die im Client vorgenommene visuelle Änderung messen .

Beispielsweise erwarten wir für eine geringfügige visuelle Änderung (einige neue Daten) in einer Komponente nicht viel Code vom Server, dh das neue Markup, das als einfaches HTML oder eingebettet in JavaScript benötigt wird, oder einige Anweisungen auf hoher Ebene, die die neuen Daten enthalten visualisiert. Andernfalls scheint etwas nicht zu stimmen, z. B. wird die gesamte Komponenten- oder Seitenzone neu erstellt, wodurch Bandbreite und Clientleistung (und möglicherweise Serverleistung) verschwendet werden.

Da wir öffentliche Demos verwenden werden, werden wir keinen endgültigen und präzisen Benchmark erhalten . Sie werden jedoch sehr starke Unterschiede zwischen den Frameworks feststellen.

Die Testtechnik ist sehr einfach und jeder kann es ohne spezielle Infrastruktur machen, wir brauchen nur FireFox und FireBug. In diesem Test werden FireFox 3.6.8 und FireBug 1.5.4 verwendet.

Die FireBug-Konsole protokolliert bei aktivierter Option "Show XMLHttpRequests" alle AJAX-Anforderungen mit der Serverantwort ...

Frameworks getestet

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

... anscheinend ist PrimeFaces die einzige JSF-Implementierung, die frei von schwerwiegenden Performance-Einbußen ist ...

Ich konnte keinen richtigen Vergleich (für die Leistung) finden, wenn jemand einen findet, würde ich ihn gerne sehen!

Martijn Verburg
quelle
2

Es gibt ein Problem mit Facelets im Allgemeinen, dessen Verwendung IMHO ziemlich unpraktisch ist. Es ist viermal wortreicher als nötig und erfordert zu viel manuelle Arbeit, wenn Sie einen Schritt von etwas Primitivem ablassen. HybridJava ist ein guter Ersatz für Facelets als Präsentations-Engine in JSF - es erledigt die gleiche Aufgabe (und noch viel mehr - es erledigt alle "Bindungen" und IDs für Sie) mit viel weniger Tastenanschlägen.

Dima
quelle
1

Also wollte ich einen ähnlichen Benchmark einbauen . Ich habe eine Twitter-Bootstrap-Beispielseite genommen und sie in xhtml strict konvertiert. Danach habe ich genau eine ApplicationScoped CDI-Bean eingerichtet, die Hello, World zurückgegeben hat. Ich habe den EL-Ausdruck auf die Seite gesetzt. Für die JSF-Version habe ich den JSF-Ressourcenhandler verwendet, für die JSPX-Version habe ich CSS und JS Includes im HTML-Stil verwendet.

Ich habe Apache Bench verwendet, um die Ladezeit der Hauptseite zu testen. Der Test wurde auf einem nicht optimierten TomEE + v1.5.2-Server durchgeführt. Ich führte jeden Benchmark 5x durch und führte dann einen vollständigen GC durch, bevor ich eine Messung durchführte. Bost-Tests wurden in derselben JVM-Instanz durchgeführt, ohne die JVM neu zu starten. Ich habe den APR im libpath verfügbar, bin mir aber nicht sicher, ob dieser Test davon betroffen ist.

JSF ist langsamer, aber nicht viel, da es sich um sehr kleine Mengen handelt. Was nicht gezeigt wird, ist, dass die Seiten komplexer werden und JSF / JSPX linear oder exponentiell skaliert.

Eine Sache, die mir aufgefallen ist, ist, dass JSPX im Vergleich zu JSF sehr wenig Müll produziert. Wenn der Benchmark auf der JSPX-Seite ausgeführt wurde, sprang der verwendete Heap von 184 MB auf 237 MB. Wenn Sie den Benchmark in derselben JVM auf der JSF-Seite ausführen, springt der verwendete Heap von 108 MB auf mindestens 404 MB. Zu diesem Zeitpunkt wurde jedoch eine automatische Garbage Collection gestartet. Es scheint eine absolute Notwendigkeit zu sein, Ihren Garbage Collector auf JSF abzustimmen .

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)
Jonathan S. Fisher
quelle
-3

GWT konvertiert Ihren Java-Code in ein Java-Skript. so läuft es als Java-Skript auf Ihrer Client-Seite. Außerdem können Sie CSS in Ihre GWT-Anwendungen integrieren. Im Allgemeinen ist gwt leicht und kann problemlos in allen Browsern ausgeführt werden. Ich weiß nicht viel über JSF. Aber ich denke, JSF ist nicht so flexibel wie GWT.

Joenan
quelle
1
Die Frage, die sich auf die JSF-Leistung und nicht auf die Framework-Empfehlung bezieht, wird nicht beantwortet. Wie auch immer, GWT wird normalerweise von Leuten gemocht, die JavaScript nicht kennen ^^
Danubian Sailor