Joel,
Just thought it would be interesting to echo Freddy's points from a
different perspective.
We are currently developing a social networking site that will span 8
countries and 2 languages and are inviting 500K users for starters. We
are leveraging Stripes, Stripersist, JPA 2.0, Hibernate, Lucene, Spring,
Memcached,... within a 3/4 tier architecture - RP (web servers), UI / WS
(app servers), DB and are even incorporating custom DB Sharding.
When we did our analysis to try to find the right UI framework I was
initially drawn away from JSF OR Struts because I had used both in the
past (and though Struts 2 appears a whole lot better and JSF 2 is a
whole lot better it just wasn't very appealing) and was drawn towards
Spring MVC because of yes *perception*... it is part of an established
and extremely well respected and well known framework - *Spring*. I
then started looking at presentations that compared frameworks and was
more convinced than ever that Spring MVC was the way to go and all was
well... . I had a lot of experience developing with Spring and
Hibernate in the past and already had the tomb sized Pro book on Spring
and others on Hibernate. I also have a subscription to Safari Online
and pretty much found all the resources that I thought I needed.
Then I walked into a book store and saw *by accident* this rather slim
book - yes 1-inch thick is *really* slim - on a framework I had never
heard about and started reading it and found it to be quite
interesting. In developing with Java since the early 1.1.8 days and
JBuilder Enterprisse 2 (which allowed one to build an actual Enterprise
/ usable Java app) and having been a Java Applications Architect (as
well as many other things for well over a decade working with companies
public and private including Fortune 100/500) I started to really
appreciate and salivate at the thought that I could actually build a
Java app that didn't get in my way, that didn't force so much boiler
plate down my throat that I would spend more time refactoring and
keeping things aligned than I would on actual features.
Then I had a *perception* let down. I was amazed to hear that Stripes
development team didn't really care to see the latest and greatest 1.5.3
in Maven Central Repo (there are JIRA tickets still open on this) and
then the *reality* that the community is much smaller and less active
and yes that may be a testament to Stripes being solid but it is a
*risk* when an architect has the opportunity to pick any UI framework
they want.
After lot's of thought, some indecision, and having bought Freddy's book
regardless, I started asking questions on this list and I have to admit
I don't *technically* regret that decision. At times I feel like I
might but that is due to the *perception* factor that even now affects
me when I am happily using Stripes and a convert and was the match that
started this fiery thread. I too didn't know that "Tim" had departed.
So what does Stripes offer - well I have to say Freddy's book is worth
every dime especially for the 1 DAO BaseModel superclass leveraging
Stripersist and JPA 2.0 and that's it... Hibernate is transparently
under the covers... on top of action beans, localization and all sorts
of other great stuff allowed me to spend literally *MOST* of my time
developing a sharding layer, constructing POJO model, building web
services and constructing the UI layout, forms, etc... Yes, all the
things a developer should only need concern themselves with and the
things that draw appeal towards other frameworks are actually right here
and inherent in Stripes.
<aside>
In fact just a month *BEFORE* discovering Stripes I had actually bought
a subscription to MyEclipseIDE which includes all manner of scaffolding
and tools for Spring and Hibernate and do you know what I use from
MyEclipseIDE today... the JSP editor (which isn't that great),
subeclipse, testng, maven and some other Eclipse plugin-ins. That is
it!!!! All the wonderful scaffolding and tools are not necessary when
using Stripes. I pretty much could have gone with downloading vanilla
Eclipse and installing a handful of plug-ins... . A true testament to
the product i.e. a few years ago RAD tools were all the craze -
synchronize your POJO's to Hibernate and back - guess what that takes a
lot of time when developing and I simply don't care - I simply re-run my
app and my database is reconstructed based on my model POJO's... . Sure
once the product releases you need to deal with Schema files and update
them / migrate data but that is going to happen regardless... .
... the point is tools only need to be great and books need to be tomb
like when something is overly complex and over engineered... .
</aside>
Someone on the main thread said Stripes is *dying*... I disagree... what
Stripes is hurting from is *perception*.
Lastly, I was literally 99% convinced I was going with Spring MVC and am
glad I didn't because I know I would still be in the early stages of
development. Fighting with Tools or struggling with the Framework.
Of course - YMMV and I hope your decision will be the best for you
whatever you decide ;-)
HTH,
--Nikolaos
Freddy Daoud wrote:
Hi Joel,
We are 99% sure we are going to go with Spring MVC. We are still implementing
the JPA/Spring based back end, so right now the UI is simply hello world, but it
was pretty simple to get at least something put together.
The other consideration was JSF 2. I've been using JSF at my full time job
for about 3 years now and seen some successes and some difficulties with it.
While JSF 2 is much, much better than JSF 1.x, for this project the whole
component model felt way too heavy, which is why Stripes was such a draw.
I'm anxiously looking forward to your thoughts on the subject, Freddy.
Well, if I was not allowed to use Stripes for whatever reason, I would
definitely prefer Spring MVC over JSF 2. JSF 1.x is awful, and JSF 2,
although not as bad, is still unnecessarily complicated.
I looked at Spring 3 briefly and liked what I saw. I didn't dig deep, so
I can't form a real opinion (there is more to a real web app than a
hello world form), but at least the "Spring requires too much configuration"
argument is no longer valid. Spring 3 does its part in using convention
over configuration, and using annotations instead of XML.
Cheers,
Freddy
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
