Link Details

Link 904093 thumbnail
User 236075 avatar

By henk
via blog.brunoborges.com.br
Published: Jan 11 2013 / 10:03

In December 2010, I wrote a blog post entitled "Top 10 reasons why I don't like JSF", and I would guess that 50% agreed with me, the other 50% did not. No surprise, it's like religion. Now let's get to the real thing: Java Server Faces 2.2. The version that is leading me to readaption.
  • 12
  • 4
  • 1702
  • 1589

Comments

Add your comment
User 161039 avatar

mheath replied ago:

0 votes Vote down Vote up Reply

In my opinion, if you're going forward with server side templates, you're doing it wrong.

User 236075 avatar

henk replied ago:

1 votes Vote down Vote up Reply

Why? Because all the hipsters are riding on the wave that client-side Javascript is so cool? Wasn't twitter already going back to server side templates?

User 161039 avatar

mheath replied ago:

0 votes Vote down Vote up Reply

Because of the hipsters? No. We're pushing templating to the client because it's a better architecture and frankly, it gives our users a better experience. Are you really advocating that reloading the same HTML over and over again because part of the UI changed is a good architecture?

User 166389 avatar

dxxvi replied ago:

2 votes Vote down Vote up Reply

I don't know if I understand you correctly but going with JSF doesn't mean "reloading the same HTML over and over again because part of the UI changed". I have the feeling that the author wants to use some JSF component library to take care of the fancy UI. Before I liked JSF because of some great JSF component libraries like PrimeFaces, RichFaces ... and because I knew very little about javascript then, but now my javascript knowledge is improved a lot and I think I'll choose REST, jQuery and some javascript framework like knockout or angular.

User 983885 avatar

infovation_Softwares replied ago:

0 votes Vote down Vote up Reply

so no Mobile, no browser independence, and no responsive websites.

User 166389 avatar

dxxvi replied ago:

0 votes Vote down Vote up Reply

If I understand you correctly, did you mean "REST + jQuery + some javascript framework" is "no Mobile, no browser independence and no responsive website"? I think jQuery Mobile is the answer for "no Mobile", jQuery is the answer for "no browser independence". I don't have the answer for "no responsive websites" right now, but I think the difference between using jsf and rest + jQuery + some js framework is that with jsf the 1st time you load the page, html code is generated by your server while the dynamic html code is generated by the client machine with the other case. Then on your jsf page, when you make ajax calls to change the page content, maybe html code is again generated on your server and pushed to the client and then assigned to some element.innerHTML. I think depending on the situation it can be faster or slower than the client machine manipulating the DOM.

User 236075 avatar

henk replied ago:

0 votes Vote down Vote up Reply

Why is pushing templating to the client supposedly a better architecture? Really, are you actually advocating that we send tons of javascript to the client, which has to plow through that to get the most basic thing rendered? Do you really think that having to wait seconds after the response is received is indicative of a good architecture?

User 161039 avatar

mheath replied ago:

0 votes Vote down Vote up Reply

Seconds to get a basic thing rendered? Dude. It's time to upgrade the 386. Seriously, we have tens of thousands of lines of JavaScript that get plowed through in <100ms. And you only have to download the JavaScript once because it's static and can be cached. So, yes, I think that's a MUCH better architecture. Thanks for asking. It also means that we can deploy our front-end code and REST services independently. Because all our front-end code is now a set of static assets, we push it out to a CDN like Akamai so that our users outside of North America can download the front-end code much faster. It also makes it easier for us to break up our services into more discrete packages that can be deployed independently. Ok. You're right. This is a crappy architecture. I guess all the benchmarks we've been collecting over the past couple of years showing how much faster our client-side apps are compared to our JSF apps are broken. I don't know why Google and other big tech companies are moving in that direction with their web apps. What a bunch of morons. Thanks for setting me straight.

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Spring Integration
Written by: Soby Chacko
Featured Refcardz: Top Refcardz:
  1. Search Patterns
  2. Python
  3. C++
  4. Design Patterns
  5. OO JS
  1. PhoneGap
  2. Spring Integration
  3. Regex
  4. Git
  5. Java