JBossDeveloper

Joshua Davis wrote on Apr 16, 2009 18:58:

Luke Simon wrote on Apr 16, 2009 08:38:


After 1 year of Seam...IMHO I don't feel to recommend it to you.
The facts are many, little community, almost 0 tutorials, anyone blogs about it, ...

Read this topic and do your considerations:
http://www.seamframework.org/Community/SeamInProfessionalUse

Maybe I'm a little weird, but:

Community?  It's been sufficient for my needs.  A large community usually means the quality of the community forums, etc goes down, not up.  This is based on my personal experience with the Hibernate community.

Tutorials?  1) Look at the examples!   I learned almost everything from the examples in the Seam distribution.  2) Get a book, man!  Java Persistence with Hibernate has a section on Seam, and JBoss Seam (Yuan, Heute) covers lots of things.   Also, you can use Seam Gen and look at the source code it generates.

Blogs? Most are full of disinformation. I didn't need any blogs to figure out Seam.

In production use?  Seam is relatively new, so of course it's not going to be everywhere.   We have a production system that handles over one million web requests per day for over a year now.   Pretty good for a relatively new thing.

So, I don't think these are legitimate reasons for not learning Seam.   I have experienced Seam to be a very good fit for developers that already have experience with other Java frameworks and/or Java Enterprise.  

Developers that have little or no Java Enterprise experience will have a higher learning curve (mostly Java Enterprise itself), so Seam may not be the way to go for them, at least initially.  PHP, for example, might be good enough.

Oh' common...Seam is almost anywhere if compared to Spring or others reality. The best way to write better code is to share and read others code. With a book you can learn seam, but how you use is different. it's the 'best practice'.

You love seam? share with others some code/trick/best practice...it's this so strange?

I believe both technologies (JSF and ASP.NET) are already in their way to obsolescence. The future is something client side, like ExtJS, Capucchino, Dojo, jQuery, etc.

Why? Just download something like Fiddler and compare bandwith use between:

1. Richfaces Tree (JSF). Around 100K for less than 10 nodes


2. IceFaces Tree (JSF). Around 20K for less than 10 nodes


3. ExtJS Tree (Client Side). Around 2K for more than 10 nodes


4. Flex Tree. Around 1K for more than 10 nodes

This is the moment, either JSF and ASP.NET truly renovate, or they both die. Microsoft is already preparing for the future Web with Silverlight. ASP.NET shares the same design flaws of JSF: Trying to provide a server side component model for a client side ui.

Maybe the guys from  AribaWeb will demonstrate that I am wrong and there is a way to provide a server side component model for a client side ui, but I belive there are some inherent limitations in the server side component model approach that just make it impossible

And this, seems to be, a systemic problem the tree is not the only component with an excessive use of bandwidth and gratuitously excessive HTML complexity.

There seems to be a plan to fix this in Richfaces 4.0, but I really wonder... isn't it too late? hasn't JSF showed that it is a technology with with a tendency for inneficient implementations? is there really a way to overcome the inherent limitations of a server side component model (that is an AribaWeb example, but the problem described is also unsolvable/very hard to solve in JSF but really easy to solve in plain Javascript)?

I guess the future of Seam is in something like Flamingo, but integrated with something Flashless (some people just do not like Flash, I have just noticed it now integrates with JavaFX, I guess what is missing now is something truly just javascript, like ExtJs or Capucchino)