Questions about the future of JSF (comparing with GWT, JavaFX)

[Abdullah Dokuyucu]

I am wondering what might the future hold for JSF; emergence of GWT as a superior alternative and new JavaFX 2.0 for RIA makes me wonder how and why will we ever use JSF? Now JSF is a web application framework based on Servlet technology, and so is GWT and it's so much superior... As much as I like working with Facelets, the framework behind it is looking weak in the presence of GWT. These are my thoughts.

What do you think of the roadmap for JavaFX and Java in general? http://www.infoq.com/news/2010/09/javaone-monday-keynote-javafx

Will JSF survive GWT and JavaFX; how or why?

[Yogesh Gnanapraksam]

The same question has been in my mind for some time now. We started our project using ADF (JSF framework provided by oracle ) but later we shifted to
an mvc framework based on javascript (javascriptmvc.com) which is based on jquery ui and ajax and for webservices we used RESTful.

The architects certainly don't see a need to use JSF or any other frameworks like that.

Request other members to share their views/opinions.

Thanks
Yogi

[Tim Holloway]

Maneesh Godbole - one of my fellow bartenders - is a big fan of GWT. It would be interesting to hear his opinion.

I'm sticking with JSF for the moment. With RichFaces + PrettyFaces, it gives me good AJAX and REST support. However, some of the alternative frameworks may be more lightweight. A JSF/RichFaces/Hibernate app can get pretty fat.

I'm not a big fan of client-side scripting. Over the years I've worked with many languages and platforms, and the one thing that seems to be pretty invariant is the amount of time and effort that a project will require, regardless of what you write it in. Scripting languages are in vogue because they give instant visual gratification, but their dark side is that they can be absolutely crawling with bugs that lurk for long periods of time and only jump out and bite at critical moments in production. So you've pushed a lot of the project time into areas where you can publicly embarrass yourself. Strongly-typed languages such as Java catch more of those problems at the front end, but by doing so, they push back the date of the visual gratification and that annoys the Pointy-Haired Boss who says "What's taking so long? All You Have To Do...". Google's DART initiative is an attempt to split the difference by being both interpreted client-side AND strongly-typed, but whether it will catch on remains to be seen.

I will say one thing, however. I've become very fond of jQuery. It smooths over a lot of the warts in JavaScript - especially the browser-dependent ones.

As for what architects see a need for... call me a cynic, but a lot of "needs" are really just needs to cash in on fads.

[Yogesh Gnanapraksam]

Yes,Jquery has greatly simplified the way we do client side scripting.
Also came across this blog http://www.artima.com/weblogs/viewpost.jsp?thread=335549 by Bruce Eckel where talks about building a webapp with
jQuery, CoffeeScript, Ajax, Web.py & Heroku.

I agree with Tim's point on the quick visual gratification we experience in client side scripting but I do not completely understand why that should create problems in the future.With proper testing we should be able to avoid any surprises.
I am of the view that these languages will start dominating web application development from now on.

One thing I like most about the html5 based technologies is that of component development.

Creating a JSF custom component is not that developer friendly.

Thanks
Yogi

[Tim Holloway]

Yogesh Gnanapraksam wrote:... I do not completely understand why that should create problems in the future.With proper testing we should be able to avoid any surprises.

What I was doing was observing that different systems have different ratios of design time/code time/debug time/test time. However, the total time remains about the same, no matter which system you employ. Interpreted, loosely-typed systems shorten the front-end times at the expense of requiring more backend time.

I'm a big fan of test suites, but I know that tests are "unimportant" when crunch time comes, so it's common that the tests will get written "someday" as soon as this other big project gets done and that keeping tests up to date is just slightly more diligently done than keeping comments up to date. Tests can rot when you "know" that everything's OK, but don't have time to update the test, so you just switch off the failing parts "until there's time to fix them".

My own personal preference is that I'd rather be yelled at by my computer than by my boss or users, so I like systems where the compiler can catch as many screw-ups as possible instead of having them blow up in front of an audience. Some prefer the instant gratification route, instead. And some - dare I say it? - simply want to take the money and run. They won't be there when it all hits the fan, they'll be off doing yet another instant system.

Regular visitors to this forum know that I don't recommend building JSF custom controls at the binary level right now. Fortunately, it's pretty easy to build custom controls using facelets XHTML components.