Summary
In a recent article, TheServerSide.com editor Joseph Ottinger asks whether the problems with JSF are technical, or are based mostly on developer perception, and suggests a few ways in which the JSF ecosystem can develop.
Advertisement
When JSF debuted as part of the Java EE 5 stack, a lot of hope was pinned on having at last a unified client-side component model for Java. JSF tools and component libraries have since sprung up, part of a nascent JSF ecosystem. According to Joseph Ottinger, editor of TheServerSide.com, that ecosystem is still not strong enough to help developers deliver real-life solutions fast, a key promise of JSF's reusable component architecture.
JSF—JavaServer Faces, JCP's component framework for the presentation layer—has had a long and fairly controversial road so far. There's still a lot of dislike floating around for it, as you can see on various TheServerSide threads that deal with it head on... The problem isn't JSF—not for the most part, at least. The real problem is the perception of JSF, as well as how it's being shown and taught.
Ottinger goes on to say that
The real problem is that JSF, for a component framework, has so few components. What kind of component would be useful? Well, consider your standard web application and how a user interacts with it: the user logs on, looks for something, reads it, possibly creates something new, then logs out.
So... where are the login box components? Where are the search box components? Where are the data input components? Where's the ability to manage "pretty URLs?" ("Pretty URLs" are also known as bookmarkable URLs, or search-engine-friendly URLs.) Where is the data flow? Where's the conversational state?
To be fair, Ottinger notes the numerous proprietary and open-source JSF component libraries that provide exactly those types of components. He also points out that the way JSF is used today in an enterprise application forces certain changes in how developers work with their code:
People have budgets and timelines to deal with. Learning a new XML configuration and component lifecycle... these aren't compelling reasons to use JSF, they're compelling reasons to use what you already know.
Considering the material that's already out there... even the simple components used are a problem...
The real problem is that the existing standard components are simply too basic to offer any real benefit to users, and creating new components is too much of a jump from using basic JSF features. The curve there isn't impossible, but it's steep enough that people resist it...
The real problem is that with such basic components in the reference implementation, JSF really has no true benefit until users investigate and invest in better components. Users won't find better component sets until they see the potential in using JSF in the first place, and the documentation doesn't make this point up front, in clear and emphatic language, enough such that users "stick it out" until they learn JSF to the point that it yields the real benefits of its component model.
Do you agree with Ottinger that lack of sophisticated and standard components is the biggest problem for JSF at this time? What are your JSF pain points?
Sure JSF seems over-complex but that's not the issue either. JSF's problem is that it isn't Ruby on Rails. Anyone who has written a non-trivial web application in Java (be it with JSF, Struts, JSPs, servlets, ...) and then done the same in Rails will be reluctant to return to the pain that is Java on the web
JSF doesn't seem to get any easier for the experts. We went a recent round of recruiting and resume reading, and every engineer who had implemented a project recently with JSF described the horrors- everything from the awkwardness of it's development model, thorugh deployment to production scaling issues.
JSP is so natural and can abstract so much functionality away quickly and easily. I don't even use JSP classes anymore, I deploy only the .tag files - which to me is a very clean example of convention over configuration "It just goes in this directory and ends with .tag and then you can import it like this.
About 2-3 minutes of work and I have a gorgeous web 2.0 component based on Prototype/YUI/Ext etc and nicely encapsulating with a name-spaced jsp tag... Why would I learn anything else, especially when Javascript frameworks have an intimate/natural knowledge of the web's nature. I don't get the same impression of the JSF.
> I think the problem is simpler than he suggests. > > Sure JSF seems over-complex but that's not the issue > either. > JSF's problem is that it isn't Ruby on Rails. Anyone who > has written a non-trivial web application in Java (be it > with JSF, Struts, JSPs, servlets, ...) and then done the > same in Rails will be reluctant to return to the pain that > is Java on the web
Exactly. And then just try to explain this... It's actually very very hard to explain why JSF sucks, not because it doesn't suck, but because in order to properly explain it, you have to WATCH YOURSELF LIKE A HAWK, while you suffer with JSF, and as soon as the pain hits, you have to document it right away, before you forget. It's actually pretty hard, at least for me. I did just that for a few days and got a list of some 5 to 7 items of why I didn't like JSF, but that list doesn't capture everything by far. And I'm not going to become a Buddhist monk meditating on the pain of JSF just so I can accurately report why it sucks. No way. It's not for me.
I am not sure that feedback helps that much anyway. I think it helps some, but there is a point where feedback is now what will help the most, but rather, if the original developer could go back to a dark room, calm down, and really think things through, from 5 different perspectives, then forget it, then sleep, have a beer, then think about it again, then do this for 1 month, and then finally an enlightened viewpoint will emerge. It's not exactly like that, but I mean, a real quantum leap in improvement cannot come from blind knee-jerk response to feedback. Feedback has to be digested and integrated and then response has to well up from the very depth of one's own mind.
Because that's how I think, I am motivated to point out some flaws, but not really motivated to justify every single thing I say. It's too difficult and ultimately, not necessary.
> JSP is so natural and can abstract so much functionality > away quickly and easily. I don't even use JSP classes > anymore, I deploy only the .tag files - which to me is a > very clean example of convention over configuration "It > just goes in this directory and ends with .tag and then > you can import it like this.
Normally I detest JSP. But maybe using .tag extensively makes it fun? I don't know. I'll keep it in mind. Thanks for sharing.
What I don't like about JSF is that page components are assembled via tag files (XML and HTML). If you find yourself doing similar things in various pages, the only way to abstract out common presentation logic is by building new JSF components -- but component development in JSF is quite difficult and tedious.
The JSF approach is to reduce the difficulty of using components at the expense of making it _more_ difficult to build components. That strategy simply redistributes the difficulty. It's a strategy that may work for M$'s business model -- in which all users buy from a single toolsmith that benefits from economies of scale -- but the Java business model requires a system in which powerful components are easy to _build_.
I suggest that JSF be scrapped and replaced with a system that is built around Wicket.
I don't like the way JSF development works. On one hand you have the spec guys who take no responsibility for the quality of implementations. On the other hand, you have implementation guys who can do some finger pointing of their own to the spec guys. At the end of the day, you have way too many cooks for this soup. Everyone has a finger in the pot. No one can unify the vision. No one is 100% responsible for anything. It's a design-by-committee nightmare.
This is why frameworks that don't have an accompanying standard are actually better. Because if it sucks, you have to admit it sucks, and you cannot point finger elsewhere. And if you want to improve something, you don't need approval of some large committee to do so.
I think standards are wonderful when the data needs to be exchanged. Standardization process just doesn't belong in some areas. Plus, having the framework in question be free software/open source totally obviates the need for standardization anyway. Standards are necessary only when you want some closed source vendors to play nice together. If your software is mostly open source, then standards just slow things down in many areas.
I think standards are good for network protocols and document exchange, and so on. But web frameworks? Not so much.
I'm still coding pages in JSP. It's agile. Everytime I've tried any kind of framework (I never tried using JSF - I recoiled from it after reading a tutorial), it's got in the way. As long as I encapsulate all of the data (including SQL), and main application logic in Java classes, the JSP itself can stay focused on the page generation, and stay surprisingly neat and readible.
The problem with all the server-side web framework approaches to creating web applications is that in the transition to a web 2.0 universe, they are now obsolete.
So JSF, Tapestry, Wicket, Struts, Rails, Grails - all these solution approaches are essentially in the same camp - they involve generating/formatting UI web pages on the server-side (the distinction of whether uses component objects or templating engines is not material here). Sure, folks are tacking AJAX on to this approach, but it's not a naturally intrinsic addition nor in anyway turns them into web 2.0. (Web 2.0 is also about how the web app is devised, the programming model, and most definitely the distributed application architecture.)
Now the true RIA (coupled to SOA middle-tier) approaches of web 2.0 are different. Executions cycles and complex state are being shifted to run in the client where are using client machine CPU cycles. Deployment, though, for RIA web apps is still completely from the web server - just as with the "web 1.0" frameworks.
The RIA solutions are:
* Adobe Flex 2 * Google GWT * Microsoft Silverlight * Sun JavaFX
Server-side execution systems like Echo2 don't qualify as a Web 2.0 RIA because execution is spread between client and server - making such apps vulnerable to intermittent network i/o. (UI behavior that relies on network reliability at any given time is bogus distributed app architecture and hence fails as a web 2.0 technology.)
In summary the web frameworks are now only of interest to those captive to legacy systems arising of the web 1.0 era.
> And I'm not going to become a Buddhist > monk meditating on the pain of JSF just so I can > accurately report why it sucks. No way. It's not for > me.
You don't have to. Matt Raible (for example) did it twice:
> > The RIA solutions are: > > > > * Adobe Flex 2 > > * Google GWT > > * Microsoft Silverlight > > * Sun JavaFX > > This is nonsense. > > "solutions" lol...
Good point. Of the RIAs only Adobe Flex 2 and Google GWT qualify as actual solutions at this point in time - Adobe Flex definitely being the most mature.
Also, the point about Echo2 failed to adequately point out that the fault of that architecture is that it relies on synchronous i/o interactions between the client and the middle-tier in order to process UI events (an absolutely brain dead strategy for implementing UI behavior). So Echo2 looks very pretty but it doesn't have an architecture that is truly industrial strength realistic.
I think a tool like this should be created in two layers. The lower layer which is built fundamentally sound, is loosely coupled, and allows you to do the vast majority of everything you might ever want to do. And the upper layer which allows you to do the things you do most often and in, say, one line of code. Tight coupling would be allowed, and the exposed interface would appeal to novice programmers.
It should be left up to the developer to be able to choose which layer to use based upon the context of their application. Use of the higher layer might cause developers trouble when they attempt to scale or do more complex things in that they'll have to back out of certain features and explore features in the lower layer but it seems that with some smart choices up front, developers would be able to both create things quick and dirty when they need to or spend the time learning to use the more complex functionality when they have to.
I do think that when these tools are created there is not enough focus on ease of development especially for the novice developer. Unfortunately, Microsoft has capitalized on that fact with it's half a?sed wizards, VB, etc. They're too eager to please the novice and SUN is not eager enough.
These RIA 'solutions' are great but not for everything. Things like bookmarkability, searchability and security are easier to achieve with a server-side frameworks (at least with one like Wicket), and these frameworks can have the advantage of locality.
Look Roger, why can't we just settle for picking the right tool for the right job? For my current project, we are using Wicket as the main technology but we also have parts implemented as Flex. And that works great. And if we'd decide we would like to use a GWT component, we could just embed it, no problem. Wicket would still be the best option for us to handle the overall application (bookmarkability, applying a consistent look and feel, etc), but the other technologies are at times a nice addition. And if you can get by using just those RIA tech, that's fine, but please let's not promote them as the next silver bullet shall we?
Flat View: This topic has 19 replies
on 2 pages
[
12
|
»
]
Previous Topic
