20

I'm debating whether to use Seam, Wicket, JSF or GWT as the foundation for my presentation layer in a Java project.

I narrowed my selection of Java web frameworks down to this subset based on job market considerations, newness of the technology and recommendations from other S.O. users.

What factors should I take into consideration in deciding among these?

Jonas
  • 121,568
  • 97
  • 310
  • 388
karl
  • 393
  • 3
  • 7
  • 14

11 Answers11

34

I've used GWT since version 1.4 and JSF since the 2.0 spec came out.

GWT is a client-side framework, it generates JavaScript from Java. Your architecture would be a pure client-server, which means:

  • Best to use coarse-grained services
  • All objects that travel to the client side should be fully serializable (it means there's no lazy load, or OpenSessionInView pattern)
  • Since GWT 2.0 you can design your gui using xhtml, which is much easier in regards to styling & structuring HTML
  • GWT tends to favour good architecture, if you mess it up it will be bad to refactor
  • Perfect History (browser back button, bookmarkable urls) support is hard, you probably have to roll your own, although it's easy to hack something right up front

JSF is a component-based framework, with a view-first design (code-behind if you like):

  • It's easier to do some type of webapps (stateful, like shopping cart)
  • JSF+Seam have suport for conversations (think wizard-like pages that maintain state across several pages)
  • You can implement OpenSessionInView, depending on your stack. It's probably not recommended if you use EJB for service/business layer
  • JSF2 has superb support for AJAX, and with a component suite like RichFaces you can build nice webapps
    • But if you want exquisite javascript behaviour, you'll have to write some javascript
  • JSF tracks the current UI state in client or server-side. This is a tradeoff between network traffic or server memory.

Resume:

  • GWT is more adequate for web applications (think gmail) that require the best client-side performance. It's easy to write custom components (you write Java) and since your server-side is just a service layer you can be fully stateless on the server side.
  • JSF is more adequate for mostly CRUD applications that are better suited for component-oriented stuff: think a hotel/flight reservation system, an online store with a shopping cart, etc
Miguel Ping
  • 18,082
  • 23
  • 88
  • 136
  • You forgot to advice him to never use GWT or any other client side framework for Java since these frameworks tend to be very painful for the developers, I greatly choose to use my own HTML/CSS/Javascript instead of building my html page with Java code and then compiling everything into Html/Js. – Yassir Khaldi Sep 25 '19 at 15:03
18

The only one of those I've used is JSF, so I won't be able to give you feedback on the others, but here's my take on JSF. In my experience, the minute we converted from JSF in JSP to JSF in facelets, life got MUCH easier, so I'll focus around facelets. Also, It looks like Seam and JSF are not mutually exclusive.

Pros:

  • Creating facelets xhtml components is simple, which promotes re-use.
  • Decent templating abilities using built in tags like ui:insert, ui:include, and ui:decorate
  • Simple access to Spring beans through faces-config
  • XHTML based so web developers unfamiliar with java can still be effective
  • Good widget library available in tomahawk/trinidad

Cons:

  • Post requests only. This can make bookmarking difficult.
  • Not as built-in ajax-y as GWT, but this may be fixed if used with Seam

I'm by no means an expert in JSF/Facelets, so I'm sure there are others I've missed. Hopefully someone else will also elaborate.

Update for JSF 2.0:

digitaljoel
  • 26,265
  • 15
  • 89
  • 115
  • tomahawk/trinidad - good tip. Thanks. – karl Apr 13 '09 at 21:48
  • 1
    Seam makes it easy to use GET requests and have bookmarkable URLs with JSF. – Peter Hilton Apr 16 '09 at 09:48
  • Thanks Peter, I'll have to look into it. – digitaljoel Apr 16 '09 at 15:26
  • 1
    If you search for 'wicket' in stackoverflow, you will find many discussions on these web frameworks which may help you. Particularly http://stackoverflow.com/questions/24596/what-web-application-framework-for-java-is-recommended and http://stackoverflow.com/questions/538550/pros-and-cons-of-various-java-web-presentation-layer-technologies – digitaljoel Apr 20 '09 at 19:22
  • Adding on to this question of frameworks, which would be preferred if seo is important? – Nick Aug 26 '09 at 19:28
  • 1
    I don't know much about seo (I'm assuming you mean search engine optomization), but I'm guessing ajax/javascript can interfere with it. It's all about how you disseminate the content though, so I suspect you could successfully use any of these depending on how you structure you app and presentation. In my limited experience, I would think a full blown GWT app might be the most difficult for SEO. – digitaljoel Aug 26 '09 at 20:21
  • @digitaljoel JSF2 includes the support for GET requests in a manner similar to how JSF1.2 + Seam 2 supports GET requests. The idea of using Seam 2 *without* JSF is a bit strange (I've been using Seam since it came out). IMO, Seam patches up most of the important holes in JSF 1.x. JSF2/CDI has most of that addressed already, as I'm sure you know. – Joshua Davis Sep 12 '13 at 15:17
  • @JoshuaDavis Note that in my edit 3 years ago I mention that JSF 2 supports GET requests. I'm not sure using JSF without Seam was that strange back in 2009 when I answered the question, but maybe we were just doing it wrong. In any case I would strongly suggest looking at anything other than JSF for new web UI work. – digitaljoel Sep 13 '13 at 16:20
  • Yep, using JSF 1.x without Seam is pretty painful. I've been using JSF2/CDI for some newer things and I've found it easy to work with. – Joshua Davis Sep 15 '13 at 14:11
16

Thanks wicket guys for remaining sober and keeping over this discussion. I am a wicket user and i love it. My main reasons are :

  1. Its a component framework. I love working with components as opposed to full pages.

  2. I can let the designers work on the templates and pages as i work on the java parts

  3. There is nothing new to learn. Its "just java and just HTML"

  4. I like its ajax Fallback mechanism. Where there is not javascript support on a browser especially on mobile devices, it falls back to plain html and everything works.
  5. Its lack of xml configuration is a plus
  6. It supports everything i would want in a web application. e.g validation, internationalization, back button support and restful URLs among others

My previous experience is GWT and JSF 1.0

Chris Seymour
  • 83,387
  • 30
  • 160
  • 202
joshua
  • 4,118
  • 3
  • 40
  • 53
10

Seam is an application framework, not really a presentation layer. It was originally developed to make JSF less painful, but has evolved into a more general purpose dependency injection framework.

I believe that you can use Seam with JSF, Wicket and GWT. JSF support is primary and excellent; I'm not sure how well the other two are supported.

Since the focus of your criteria seem to be the marketability of your skills, I would suggest trying out Seam and JSF via Facelets. JSF is a well accepted standard and is actually enjoyable to use if you are using Facelets. You can have slick AJAX functionality via Richfaces and Ajax4jsf. Seam is being more or less standardized via the JCP.

recampbell
  • 1,247
  • 8
  • 14
  • Interesting. Does Richfaces tie you into JBoss? You also recommend the Facelets route - I don't see any job postings that mention it - is this because it's relatively new or because job postings are more likely to just mention JSF? – karl Apr 13 '09 at 21:53
  • JSF was first used in JSP, and then in facelets, but I believe the JSF group favors facelets. This is evident in the JSF 2.0 spec which has a table showing the advantages of facelets over JSP. – digitaljoel Apr 13 '09 at 22:15
  • 1
    Karl - Richfaces should be usable in any container that supports JSF, there are no JBoss dependencies that I am aware of. As for job postings, I would personally avoid any job that requires JSP; facelets are the way to go. ;-) – recampbell Apr 14 '09 at 18:52
  • 1
    Forget JSP. Facelets is the default view technology in Seam (and JSF 2.0) so Seam usually implies Facelets, although there is some Wicket support. – Peter Hilton Apr 16 '09 at 09:47
  • I've not been enjoying using richfaces. If I could take XCSS without any of the built in "basic" XCSS used in the control suite then its would be great, otherwise its origins in an educational establishment are clear as day. It gets in the way and prevents you from freely utilising your existing expertise in HTML and CSS. Otherwise +1 for a good answer. Seam Remoting "just works" and is recommended for AJAX. – Simon Gibbs Apr 29 '09 at 12:22
7

My experience is, in chronological order:

Raw servlets - (yeah, lot's of hard work but the it was early days and we were eager beavers!)

JSP - I thought it was the beez neez at the time it came out (if we only knew ;) )

Echo - Awesome framework but not for pages that need to be search engine friendly (same problem with GWT)

Wicket - Awesome framework - the developers fully understand the concept of OO (unlike JSP and many others) and have applied all the usual OO niceties to this framework. If you appreciate 'reusability', if you appreciate encapsulation, if you appreciate separation of concerns and if you like to bind your model to the UI code without having to worry about object marshalling and other such ugliness then this is the framework for you!

Volksman
  • 1,969
  • 23
  • 18
  • 2
    I never went the plain servlet route (not for html rendering) so I can 't commend on that. But I have some experience in building Wicket applications and are now (must now) use JSF. Heck, how i wish to go back to Wicket. For some people it might be easier to use JSF, but i much prefer the clean and simple principles behind Wicket. Easy things are easy to do and more complex task are not difficult either, as the API provides hooks to override default behaviour.. – bert Feb 11 '11 at 06:27
3

In a long term scenario I'd recommend using technologies backed by a Sun specification. This has so far proven to give multiple implementations resulting in choice (frequently also open source implementations), plus behaviour tends to be very well defined.

That will help you in a maintainance scenario, which - hopefully - your code will end up too in time. Well-written code lives forever :)

In this particular scenario I would suggest JSF. I have only tried the Apache implementation of 1.1, but it hurt to be on top of JSP. We are to revise it soon - I expect to look into having JSF on facelets.

Thorbjørn Ravn Andersen
  • 73,784
  • 33
  • 194
  • 347
  • 4
    I would argue that choosing a Sun specification is not that important as many defacto standards (Struts, Hibernate, Spring, Log4j, etc.) were Sun specs and yet were widely adopted due to their power and utility. If anything, these successful projects later drove the creation of standards once proven which is decidedly not the case with JSF. – Brian Laframboise Aug 18 '09 at 14:58
  • Edit: ...were *NOT* Sun specs... – Brian Laframboise Aug 18 '09 at 15:05
  • I was talking long-term. Which of the frameworks you mention do you expect to be supported in 10 or 20 years time? Code tend to live forever. – Thorbjørn Ravn Andersen Aug 18 '09 at 18:16
  • A downvote? For saying that long term maintenance is important? And JSF made it in JEE 6... Oh well. – Thorbjørn Ravn Andersen Sep 08 '10 at 06:29
  • Upvote from me. I went with Seam 2/JSF 1.x because I believed that eventually Seam would result in a change to JSF. This came to pass with JSF2/CDI. – Joshua Davis Sep 12 '13 at 15:19
  • You would recommend restricting yourself to using technologies backed by a Sun spec? - Don't get me wrong I loved Sun (when it was around) but I'm assuming your policy meant you marched over the cliff with all the other lemmings with Sun released (unleashed) the most ridiculous technology ever seen in the Java world: EJBs - EJBs are the reason you should question everything and assume nothing regardless of who produces it. – Volksman Oct 12 '16 at 11:13
  • @Volksman it is a poor craftsman that blames the tool. The problem with Java EE is that it was originally designed to be able to run relatively transparent on multiple JVM's. Unfortunately for Java EE this is not the typical use case. – Thorbjørn Ravn Andersen Oct 12 '16 at 12:09
  • @ThorbjørnRavnAndersen I'm speechless after your uniformed insult... well not quite: Obviously you're a person who makes massive assumptions without engaging your brain first - I love Java EE - spent the last 20 years building systems that have earned clients millions of $ with it. Read over what I said carefully: I'm making a point about taking your advice of blindly using everything that is backed by a Sun spec using EJB 1 as an example of possibly the worst Java technology EVER. You didn't need to be a poor craftsman to hate EJB - you just needed to not have a frontal lobotomy to hate it. – Volksman Oct 13 '16 at 14:45
  • @Volksman Let's first revisit the actual wording of my answer because it appears you may not have understood it before commenting: "_In a long term scenario_ I'd recommend...". In other words when you are dealing with projects expected to have a long lifetime. My guess would be that you could still find a vendor _TODAY_ selling and supporting a Java EE container which could be used for your EJB1 solutions. For some that is very important. That said, calling others for lemmings straight out of the blue is not very polite in the first place :-/ – Thorbjørn Ravn Andersen Oct 14 '16 at 10:03
  • @ThorbjørnRavnAndersen honestly, do you really think anyone but a lemming would choose to use EJB1? Lots of people had no choice but that's not their fault - decision makers who understood that technology (though I fear that often the decision makers are technologically clueless) and then still chose it for their organization just because it had some 'official' approval - lemmings! :) – Volksman Oct 14 '16 at 11:29
  • @Volksman You still do not get the point. Even if a given technology is absolutely fantastic an architect may choose something else much less fantastic, because the concerns are broader than what a single narrow minded developer fancies in his little world. But, I'll bite, what would you recommend for a scenario where the desired lifespan of a solution is decades? What would you have recommended 10 years ago? 20? – Thorbjørn Ravn Andersen Oct 14 '16 at 13:35
1

I know it's a bit late but there is already lot of comparison on Framewrok, espcially this one, wich occured durinf Devox 2010 conf :

http://www.devoxx.com/display/Devoxx2K10/Comparing+JVM+Web+Frameworks

This should help you to choose :)

Jean-Rémy Revy
  • 5,607
  • 3
  • 39
  • 65
1

I started with JSF (1.1 and 1.2) and it was so painful that I decided to change in next projects. I researched a bit and I decided to try Wicket, and it was so a pleasure. Also I've tried JSF 2 but is still the same thing.

Both of them are component frameworks, but things with Wicket are easy while with JSF are a complete mess.

Wicket over JSF:

  • In Wicket HTML are HTML. JSF has its own mark-up tags. The h:dataTable (for tables) is nonsense. Believe me, Sun Engineers had to be drunk when designed it.
  • In Wicket things like security,
  • With JSF the navigation bar shows the previous URL. Really odd.
  • JSF seems to me very heavy, and with libraries like Rich or Prime even more.
  • Sometimes, it seems impossible to know which is happening. You always end up yelling at your computer because you don't know why JSF is doing.

JSF over Wicket:

  • In Wicket you're going to write more Java (the binding with HTML). At least, your IDE will provide refactoring and validation support.
  • Resources management in Wicket is a bit tricky.
  • There are much more documentation and support for JSF

One common flaw is that session size is are problem (because graphical components are stored in there).

All in all, if you have to decide only between Wicket and JSF there not doubt for me, Wicket.

polypiel
  • 2,321
  • 1
  • 19
  • 27
  • HTML == HTML in wicket? Yeah, but don't forget you need to mirror the entire component tree in Java and make sure this is kept synchronized. This is a major price to pay and thus a highly misleading benefit. In JSF you define the tree once and only once on the view template. Facelets also has an HTML mode (see wikipedia page on Facelets) and JSF 2.2 has "passthrough elements". – Mike Braun Nov 03 '12 at 11:51
  • Navigation bar shows previously URL?! That's only if you use navigation rules without redirect. But 1. You don't have to use navigation rules and 2. You should use PRG pattern (post redirect get) or plain get based links. Your experience seems to be based on an ancient JSF version here. – Mike Braun Nov 03 '12 at 11:54
  • JSF heavyweight compared to Wicket??? Yeah right... JSF uses less resources (less CPU and less memory) than Wicket does. Check benchmarks like "world wide wait". Again, your experience seems to be with ancient JSF versions that did not had partial state saving yet. – Mike Braun Nov 03 '12 at 12:04
  • @MikeBraun I have never found mirroring the component tree in Java a major burden for Wicket. There is a ComponentResolver interface that can be overridden. We use this to allow the markup to virtually drive the assembly of components. We provide a list of all the available components and then markup can be changed at will and the relevant components are added as directed by the markup so providing a Java component graph that matches the markup is totally automatic. Also Wicket 7 now adds Component Queuing which makes managing the Java side easy. – Volksman Oct 13 '16 at 14:53
1

I've used Wicket and GWT pretty heavily. Never really learned to love Wicket.

My ego blogged about it http://salk31.blogspot.com/2009/07/wicket-ajax.html

Looking at GWT 2.0 uiBinder today reminded me how annoying it was in Wicket to have to match the XML component tree with the one created in Java. The GWT spin on this looks vastly better to me.

I've not used Wicket for over a year so maybe they have fixed a lot of this but given modern browser and JS support I can't see the point of doing all this on the server (I know, I know data locality).

salk31
  • 44
  • 3
  • It depends how much you value your IP. With Wicket your code/IP all remains safe and secure server side. If you don't value your IP that much, then sure, write most of your UI code in JS make it available for your competitors to rip off by sending it all out to the browser in non compiled, easily reverse engineered JavaScript. Don't get me wrong, Wicket makes ample use of JS to make highly efficient and responsive interactive UIs but in a way that doesn't expose your domain models or algorithms. – Volksman Oct 12 '16 at 11:16
1

If you consider only job market , you should choose JSF. But, I belive that the future of RIA belongs to GWT and gwt like client side technologies.

I think that the most obvious upside of GWT, it is better scaleable than server side presentation layer technologies such as JSF, wicket. Because , server does not need to store client state and the client cpu power also are also used.. It is a huge benefit, you dont need to serialize client state between server computers to achive fault tolerant system.

Gursel Koca
  • 20,940
  • 2
  • 24
  • 34
  • It's now 6+ years later, do you still think GWT owned that future? – Mike Braun Nov 26 '16 at 13:34
  • No , I dont.. JavaScript has dominated the market.. But the part of my foresight was true; the client side technologies has dominated the market.. The complexities of GWT has frightened most of the developer. – Gursel Koca Dec 06 '16 at 15:44
-10

JSF is deprecated (JSF is not even listed as a framework to compare when evangelists compare or talk about web frameworks in 2010).

Now full fledge large scale applications are created using GWT, YUI, JQuery etc.

Read some articles over google and above will be obvious.

(ALL JOBS on JSF are to support legacy applications).

daud
  • 7
  • 1