• Post Reply Bookmark Topic Watch Topic
  • New Topic

Is JSF still a reasonable choice for new web applications ?

 
Claude Moore
Ranch Hand
Posts: 832
7
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I know that I've been recently quite bothering members of coderanch with similar questions, but I really need to clarify my ideas.
So, I'm evaluating different approaches and frameworks to start developing a quite big web project, and at the moment the only clear thing is that i've got a big mess in my mind.

First I evaluated Javascript-based framework like AngularJS, Ember.JS, Handlebars, found them amazing, but I would be reluctant to adopt them in complex applications with tons of pages, forms and so on. I'm sorry, but I still think that they're toys you can play with to build just something simple and limited in complexity.
I'm evaluating GWT and, more specifically, I had a look at Vaadin. They both sound good; but again I'm afraid of adopting something which is not under Java EE umbrella.

So I thought about JSF. Until now, I avoided JSF, most because of the nightmares I had when playing with it at 1.0 version; just recently I gave it another try and found that it became really interesting, expecially PrimeFaces implementation (I found it full of great components).
But I'd love to hear your experiences. How about use JSF in complex applications ? Is still a viable choice ?

Thanks in advance.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Claude Moore wrote:First I evaluated Javascript-based framework like AngularJS, Ember.JS, Handlebars, found them amazing, but I would be reluctant to adopt them in complex applications with tons of pages, forms and so on. I'm sorry, but I still think that they're toys you can play with to build just something simple and limited in complexity.

You would be very very incorrect in this regard. I've worked on a number of complex applications as SPAs and I can assure you that they are far from "toys".

I'm evaluating GWT and, more specifically, I had a look at Vaadin. They both sound good; but again I'm afraid of adopting something which is not under Java EE umbrella.

I've worked with both. Unwillingly. And cannot recommend either except under very niche circumstances. (Need something quick, don't care too much about quality or appearance, have only Java developers who are unwilling or incapable of learning anything new.)

So I thought about JSF. Until now, I avoided JSF, most because of the nightmares I had when playing with it at 1.0 version; just recently I gave it another try and found that it became really interesting, expecially PrimeFaces implementation (I found it full of great components).
But I'd love to hear your experiences. How about use JSF in complex applications ? Is still a viable choice ?

That depends on a lot as well. In my experience, in the industry it's not well regarded, and thought of as a dinosaur. Still lumbering around, but the whole genre of creating UI on the server to send to the client is considered rather passé. But, like lots of other established but older technology, is likely to limp along on for some time. Your call.
 
Claude Moore
Ranch Hand
Posts: 832
7
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:
You would be very very incorrect in this regard. I've worked on a number of complex applications as SPAs and I can assure you that they are far from "toys".


Of course it was not my intention to belittle something I'm not expert of or to offend anyone, Bear... sorry if I gave this impression.
My main concern with JS frameworks is that they spread everywhere like mushrooms, gain a lot of momentum for a while, and then seem to fade out. It's hard to make a decision in adopting any of them.


 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
True, and that is a very good point -- there is a lot more momentum and churn in the client-side JavaScript world than we were used to in the Java world. It makes my head spin sometimes.

AngularJS currently has the mindshare in the SPA world, but that could, and likely will, change. AngularJS 2, in fact, will be largely incompatible with version 1.

And that is an important factor to consider in any choice. But the notion that JavaScript frameworks aren't suitable for large or complex systems is not a valid factor.
 
Tim Holloway
Bartender
Posts: 18415
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a different point of view from Bear. Not surprising, since I'm moderator here. I use JSF regularly and enjoy it. There are things I'd like to see done bettter, and I always reserve the right to mix in alternative technologies when they're more suited, but for a lot of the stuff I do, JSF works quite well, and since it's part of the JEE standard, it's well-supported and well-documented. Also because it's supported by Oracle/Sun it mostly adheres to the concept of controlled obsolescence (deprecation) instead of the case where you wake up one morning and everything's been broken with no at-leisure migration path. Well, except for RichFaces

I myself got burned very badly when using dojo at a time when its popularity had ebbed. I also learned that between client variations in JavaScript implementations (when IE8 support goes out, I know of a major app breakage coming up), and the fact that "clever" people can overload core JS functions (which seriously broke dojo) that JavaScript, in particular has certain risks that server-side code does not. Client-side code is also inherently more hackable, thus harder to keep secure. You not only have possibly-critical functions and data "outside the wall", you have the source code for those functions outside the wall as well, and that's just begging for trouble.

Yes, client-side scripting languages are very popular right now. They allow you to get pretty web pages out in a hurry. But one thing I learned about programming long ago is that the total length of time that it takes to produce an industrial-grade system depends very little on the programming language or framework. Mostly all that a given language/framework does is change which part of the development process requires more time and trouble. Java requires a lot of up-front time before you can get those pretty pages out, but you don't have to do as much work to secure the final product and it's less likely to blow up because of mis-matched dynamic data typing.

Still, I'm not totally against scripting or even client-side scripting. I'm actually quite a fan of jQuery, which not only plays well with JSF, but itself is often employed internally by JSF extensions to do stuff like the grunt work for AJAX.

Incidentally, one thing I've also learned about client-side scripting is that it's a LOT easier to keep a server-side data model in sync with itself if you minimize the amount of fiddling with data on the client side. Translation: I've been burned by attempting to roll my own JavaScript to do certain types of data element synchronization and validation to the point where I generally prefer to use AJAX and put the functions on the server. It's not only more reliable, but the overall code is cleaner. At the expense of more server traffic, but nothing is free.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One point of disagreement:
Tim Holloway wrote:You not only have possibly-critical functions and data "outside the wall", you have the source code for those functions outside the wall as well, and that's just begging for trouble.


Only in poorly architected systems. Anyone who places hackable or critical sections in the client-side code shouldn't be developing web sites. Just because SPAs put the view and control logic on the client isn't a license to move everything there. Critical and secure code should still be on the server with proper authentication and authorization.
 
Tim Holloway
Bartender
Posts: 18415
58
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:One point of disagreement:
Tim Holloway wrote:You not only have possibly-critical functions and data "outside the wall", you have the source code for those functions outside the wall as well, and that's just begging for trouble.


Only in poorly architected systems. Anyone who places hackable or critical sections in the client-side code shouldn't be developing web sites. Just because SPAs put the view and control logic on the client isn't a license to move everything there. Critical and secure code should still be on the server with proper authentication and authorization.


Unfortunately, poorly architected systems are pretty much the demand - and the expectation - these days. You not only are more likely to be commanded to bang out stuff fast and cheap with little thought for performance and less for security, you're actually likely to get dinged for not doing it that way. Or at least I have been. In exactly those words. At a very large financial institution. "We would rather you spent less time on quality and more on getting stuff "done" fast." "Done" was a big watchword there. Rebooting production servers every other day to clear out memory leaks? Fine, no problem. Just as long as there are dancing flowers and singing fairies on that web page! And it's in production tomorrow.

The public at large has gone from hearing "Computers don't make mistakes" (circa 1960) to "Have you tried turning it off and back on again?" People now expect software to crash, to leak vital data to unscrupulous persons and otherwise have all the structural integrity of tinfoil. It's what they're paying for, after all. Lower Prices Everyday.

It's just one more area in life where what "should" be and what is aren't the same thing.

It's because I am obsessed with quality that I continue working with Java, even though it's considered stodgy and old-fashioned. The "Git 'R Dun!" frameworks get it "Done!" in large part not by accelerating quality software development but by hoping it won't break until after you've departed/been terminated. Java's design parameters were rooted back in older mentality that not everything is about how fast you can get something to market.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:Unfortunately, poorly architected systems are pretty much the demand - and the expectation - these days. You not only are more likely to be commanded to bang out stuff fast and cheap with little thought for performance and less for security, you're actually likely to get dinged for not doing it that way. Or at least I have been.

You're working for the wrong companies (half a ). This is a failure at the company level and has nothing at all to do with any particular technology.

Sure, such an attitude makes me as angry as it does you, but it is not a function of any chosen technology. I would trust the server-side code of any company not dedicated to quality and security no more and no less than their client-side code. My last couple of years creating SPAs for companies that do not have such a poor focus on quality and security tells me that it's just as easy to create a secure application as an SPA as it is to create one using traditional MVC. And vice versa: it's just as easy to create insecure server-side code as it to create insecure client-side code ; easier, in fact.

To castigate a technology because some companies use it poorly isn't appropriate.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And I know you know this based upon how quickly you (rightly) pounce on those trying to roll their own security systems without any understanding of security measures. It's not about the choice of programming language or ecosystem, it's all about dedication to quality, which as we know, is sadly lacking in a large portion of our industry.
 
Claude Moore
Ranch Hand
Posts: 832
7
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:
Yes, client-side scripting languages are very popular right now. They allow you to get pretty web pages out in a hurry.

Ok Tim, you can achieve very fast prototyping with Javascript. The same is true for server-side scripting languages like python. What happens when you have to mantain large systems ? I remember how much Visual Basic 6 was blamed and pointed as an example of a bad designed language (despite its popularity) due to its weak type system, its extreme flexibility which may turn into a badly organized and messy code.
I wonder if JavaScript doesn't suffer for the very same pitfalls that were ascribed to VB: no type checking, weak type system (or fuzzy type system, like 'duck typing' seems to me) and so on. Despite the fact that it is the language for web programming.

By the way, I'm not against web programming. I just wonder why instead having a proliferation of frameworks that, more or less, try to do the very same thing (help you not to write messy code, help you to be rigorous), and, with only a few exceptions, are doomed to be forgotten in a couple of years, programmers' community (and browser vendors, too) doesn't feel the need to join effords to develop a common web gui language, beyond HTML and Javascript.
Google tried with Dart, I don't know if has dumped it or not. Then Go language arose. For the gui, here is Polymer. Then AngularJS UI. Ehi, don't forget JQuery UI. Don't forget Dojo. And so on....
Gosh, practically every season something new, spectacular, saviour-of-the-world framework rise from the web. That's not "freedom of choice". It's simply confusion.... or I am totally wrong in saying this ?
That's way I'm in search of some fixed point to move from. And JSF seems to be a good starting point, not for itself, but mostly because it's part of a large and stable ecosystem that Java is.

And of course, thanks for your discussion, i found it very interesting and instructive.

 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 65530
105
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Claude Moore wrote:I just wonder why instead having a proliferation of frameworks that, more or less, try to do the very same thing (help you not to write messy code, help you to be rigorous), and, with only a few exceptions, are doomed to be forgotten in a couple of years, programmers' community (and browser vendors, too) doesn't feel the need to join effords to develop a common web gui language, beyond HTML and Javascript.


This explains it much better than I could:



Google tried with Dart, I don't know if has dumped it or not. Then Go language arose. For the gui, here is Polymer. Then AngularJS UI. Ehi, don't forget JQuery UI. Don't forget Dojo. And so on....

You are conflating languages with libraries and frameworks. Not the same thing.

(And Go was never intended as a web language.)

And JSF seems to be a good starting point, not for itself, but mostly because it's part of a large and stable ecosystem that Java is.

Then that may be the right path for you.
 
Claude Moore
Ranch Hand
Posts: 832
7
IBM DB2 Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That image is really fantastic... And terribly true!!
 
Tim Holloway
Bartender
Posts: 18415
58
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
XCKD - something for every occasion!

I started to harp on my user-defined login hobbyhorse, but figured it was overkill. Besides, user-defined security systems are usually not handled quite as sloppy as the main app code, it's more a case of designing security systems being a specialized technology of its own that shouldn't be left in the hands of little Jimmy because anyonecanprogramAllYouHaveToDoIs...

As for employer standards, unfortunately, I live in a city - indeed a state - where Wal-Mart is considered upscale, but I like the geography even if the professional opportunities reek like 3-day fish. So I whinge a lot an hope that eventually someone will take the hint. Or that I'll pick up work from an out-of-state employer enlightened enough to allow remote employees who aren't located in Asia.

There are many problems where use of late-binding and/or interpretive languages are the way to go, but the Law of Computer Karma says that if you get something, you have to pay for it. My general opinion of using such frameworks on Internet-facing apps is much the same as it is on using Windows for Internet-facing servers. Yes, you can certainly do it, but is it really wise to risk it? A failing app in-house is a nuisance, but a security hole on the Internet is potentially a way for an invader to worm in and suck all the goodness out of a company. And I wouldn't put too much faith in firewalls and DMZ's in any company whose front-line software is allowed to be that weak.

OK. I think I've ranted enough for now.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!