Comments on: The _Real_ problem with JSF http://www.spenceruresk.com/2007/05/26/the-_real_-problem-with-jsf/ Random posts about Java, software development, politics, and economics Sat, 22 Nov 2008 09:23:38 +0000 http://wordpress.org/?v=2.0.1 by: Marc http://www.spenceruresk.com/2007/05/26/the-_real_-problem-with-jsf/#comment-20336 Thu, 26 Jun 2008 15:37:43 +0000 http://www.spenceruresk.com/2007/05/26/the-_real_-problem-with-jsf/#comment-20336 When hundreds of people say “IT SUCKS”, there’s always someone who sais “no, really it doesn’t. you just don’t understand”. While I have no concrete experience in JSF and to me it just “seems to suck”, I think more effort should be going into what developer’s really need in stead of defending something that many people obviously dislike. Let’s not forget: JSF was a vendor/tool-centric attempt to answer the age old problem that Java simply didn’t have any good UI/web tools. What we should be looking for is developer centric UI productivity tools. Get things done quickly, without a lot of setup/hassles/drawing-board-proved-fail-in-basic-everyday-use functionality. For example, I’m currently desperately trying to find a solution that answers the simple question: “if you use JPA, it should be possible to generate a UI and customize it from there”. Looking around there seem to be preciously little solutions out there (e.g. jpa2web) that answer this question, and those that do seem to be very immature. Why are we “building” so much stuff when most of it can be generated? When hundreds of people say “IT SUCKS”, there’s always someone who sais “no, really it doesn’t. you just don’t understand”. While I have no concrete experience in JSF and to me it just “seems to suck”, I think more effort should be going into what developer’s really need in stead of defending something that many people obviously dislike. Let’s not forget: JSF was a vendor/tool-centric attempt to answer the age old problem that Java simply didn’t have any good UI/web tools. What we should be looking for is developer centric UI productivity tools. Get things done quickly, without a lot of setup/hassles/drawing-board-proved-fail-in-basic-everyday-use functionality. For example, I’m currently desperately trying to find a solution that answers the simple question: “if you use JPA, it should be possible to generate a UI and customize it from there”. Looking around there seem to be preciously little solutions out there (e.g. jpa2web) that answer this question, and those that do seem to be very immature. Why are we “building” so much stuff when most of it can be generated?

]]> by: Tyler http://www.spenceruresk.com/2007/05/26/the-_real_-problem-with-jsf/#comment-7655 Thu, 09 Aug 2007 18:28:51 +0000 http://www.spenceruresk.com/2007/05/26/the-_real_-problem-with-jsf/#comment-7655 You have an interesting hypothesis there. In short, the only reason JSF "sucks" is that people think it "sucks". Frankly, I don't buy it. The majority of people who hate JSF hate it because of the headaches they've had to go through to get some seemingly simple functionality to work correctly. I know I hate JSF for just that reason. I've had nothing but endless headaches trying to build a JSF based interface for a Java system. There are so very many things that just don't work, there's little to no feedback on why things aren't working, and the actual process that goes on behinds the scenes is intentionally opaque. If anything does go wrong, debugging it is sheer hell. When you do get an error message that indicates an actual problem, rather than the wrong error message entirely, there is a total lack of helpful supporting information to help determine what, exactly is wrong. The _Real_ problem with JSF is that it is immature, buggy, and dysfunctional. It might still be better than Struts, but that's a case of proving how bad Struts is, not how good JSF is. You have an interesting hypothesis there. In short, the only reason JSF “sucks” is that people think it “sucks”. Frankly, I don’t buy it. The majority of people who hate JSF hate it because of the headaches they’ve had to go through to get some seemingly simple functionality to work correctly.

I know I hate JSF for just that reason. I’ve had nothing but endless headaches trying to build a JSF based interface for a Java system. There are so very many things that just don’t work, there’s little to no feedback on why things aren’t working, and the actual process that goes on behinds the scenes is intentionally opaque. If anything does go wrong, debugging it is sheer hell. When you do get an error message that indicates an actual problem, rather than the wrong error message entirely, there is a total lack of helpful supporting information to help determine what, exactly is wrong.

The _Real_ problem with JSF is that it is immature, buggy, and dysfunctional. It might still be better than Struts, but that’s a case of proving how bad Struts is, not how good JSF is.

]]> by: suresk http://www.spenceruresk.com/2007/05/26/the-_real_-problem-with-jsf/#comment-4040 Tue, 29 May 2007 02:43:52 +0000 http://www.spenceruresk.com/2007/05/26/the-_real_-problem-with-jsf/#comment-4040 I do agree that some things in JSF are unnecessarily complex, and there are things that could be improved. Show me a framework that doesn't have that issue. Ruby on Rails is hailed as the best web framework around right now, and doing some simple things with select boxes (that would take a few minutes to do in JSF) have taken me hours and been totally frustrating. While I agree frameworks should always strive to make complex things easier and leave easy things easy, I hate to see frameworks judged on a few cases. It is easy for you to look at a handful of situations like that and say, "yeah, this was really hard, so JSF sucks". On the other hand, how many things has JSF made easier? Compare development time of a particular screen in JSF vs Struts. JSF is almost always faster to develop with. Compare the amount of code you have to write for each - JSF wins by a long shot there. And, it is easy to forget how many things are unnecessarily complex in Struts also. XML hell - can't really agree there though. How much XML do you have to use when building pages with JSF? I don't take issue with people saying JSF 'sucks', I take issue with how people mis-represent it, argue based on problems that no longer exist, or simply are wrong about things. I certainly think other frameworks do a better job than JSF does for certain things. I'd hope the JSF EG would implement the things in other frameworks that are better (and judging by Ed Burns' draft for JSF 2.0, they are). Perhaps Struts 2 would be better in certain situations, but neither of us have actually implemented anything with it, so I don't think it is fair to compare the two at this point. You are also ignoring the fact that JSF is a spec that is backed by Sun and a lot of other groups, and has good integration with a lot of new frameworks such as Seam. How would you implement a conversation context with Struts2? I definitely do think the component model is good for web development. Look at the reuse we achieve with JSF that we couldn't do with Struts. Look at the amount of code that we do away with. I honestly don't see how you could look at a page done in Struts and say "Yeah, this is so much better than JSF". I do agree that some things in JSF are unnecessarily complex, and there are things that could be improved. Show me a framework that doesn’t have that issue. Ruby on Rails is hailed as the best web framework around right now, and doing some simple things with select boxes (that would take a few minutes to do in JSF) have taken me hours and been totally frustrating.

While I agree frameworks should always strive to make complex things easier and leave easy things easy, I hate to see frameworks judged on a few cases. It is easy for you to look at a handful of situations like that and say, “yeah, this was really hard, so JSF sucks”. On the other hand, how many things has JSF made easier? Compare development time of a particular screen in JSF vs Struts. JSF is almost always faster to develop with. Compare the amount of code you have to write for each - JSF wins by a long shot there. And, it is easy to forget how many things are unnecessarily complex in Struts also.

XML hell - can’t really agree there though. How much XML do you have to use when building pages with JSF?

I don’t take issue with people saying JSF ’sucks’, I take issue with how people mis-represent it, argue based on problems that no longer exist, or simply are wrong about things. I certainly think other frameworks do a better job than JSF does for certain things. I’d hope the JSF EG would implement the things in other frameworks that are better (and judging by Ed Burns’ draft for JSF 2.0, they are).

Perhaps Struts 2 would be better in certain situations, but neither of us have actually implemented anything with it, so I don’t think it is fair to compare the two at this point. You are also ignoring the fact that JSF is a spec that is backed by Sun and a lot of other groups, and has good integration with a lot of new frameworks such as Seam. How would you implement a conversation context with Struts2?

I definitely do think the component model is good for web development. Look at the reuse we achieve with JSF that we couldn’t do with Struts. Look at the amount of code that we do away with. I honestly don’t see how you could look at a page done in Struts and say “Yeah, this is so much better than JSF”.

]]> by: maxpower http://www.spenceruresk.com/2007/05/26/the-_real_-problem-with-jsf/#comment-4037 Tue, 29 May 2007 01:12:32 +0000 http://www.spenceruresk.com/2007/05/26/the-_real_-problem-with-jsf/#comment-4037 I don't like the complexity (I spent a number of hours with a JSF committer to get simple functionality to work) or vebosity (xml hell) of JSF. Where are the tools promised us to make the use of the framework as simple as drag and drop? The tools for facelets are pathetic. Could it be that those who quote JSF as "sucking" do so only because they are using a framework that better suits them? Does the component model and the web really fit? Note that Struts2 seems to have unified the component and request based frameworks. Struts2, based on the WebWork2 code, has built in support for JSF, using an approach that smoothly combines both frameworks into one configuration file, one framework. This is pretty amazing since we no longer have to choose between component-based or not. Furthermore, it seems to be the most often used framework in famous software products like jira and web sites like infoq and javablogs. There's also a plugin for Eclipse that can aid in development. Definitely something to test. I don’t like the complexity (I spent a number of hours with a JSF committer to get simple functionality to work) or vebosity (xml hell) of JSF. Where are the tools promised us to make the use of the framework as simple as drag and drop?

The tools for facelets are pathetic.

Could it be that those who quote JSF as “sucking” do so only because they are using a framework that better suits them?

Does the component model and the web really fit?

Note that Struts2 seems to have unified the component and request based frameworks. Struts2, based on the WebWork2 code, has built in support for JSF, using an approach that smoothly combines both frameworks into one configuration file, one framework. This is pretty amazing since we no longer have to choose between component-based or not. Furthermore, it seems to be the most often used framework in famous software products like jira and web sites like infoq and javablogs. There’s also a plugin for Eclipse that can aid in development. Definitely something to test.

]]>