• Post Reply Bookmark Topic Watch Topic
  • New Topic

JSF - Is it modern enough to compete?  RSS feed

 
Rob McBryde
Greenhorn
Posts: 17
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jasper,

Congratulations on curating the JSF course.

I have previously worked on Java web applications that made use of JSPs and then Apache Wicket. It's been a few years since I have been working with Java web apps and most organisations I have since worked at tend to use Java as backend server technology, preferring the front end clients to be written in modern Javascript frameworks such as Angular or React.

Is JSF modern enough to offer reactive UI for the user, similar to features offered by other modern Javascript frameworks. Has JSF it progressed from the traditional request/response model where web forms where prominent?

I am keen to learn about modern Java web app front ends but this fear has been holding me back, what's your thoughts?

Thanks

Rob
 
Tim Holloway
Saloon Keeper
Posts: 18800
74
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JSF is a web form environment. That's all it's intended to be.

JSF2 added native AJAX support (prior to that you had to do it yourself or use a third-party tag library).

But for non-form activities, JSF is not a "greedy" framework, and you can mix it with other frameworks. I've used Apache CXF for ReST services, the Spring Framework and when I need other types of processing, I'll add in an appropriate subsystem for that.

JSF, however, was originally intended to be an abstract form framework. It assumed that the default infrastructure would be HTTP and HTML, but allows for plug-in replacement renderers in the event that some other infrastructure would be convenient. For example, before smartphones, there was a simplified display standard called WML that many of the web-capable but less powerful phones would use.

The Request/Response restriction is because that's how HTTP was originally designed. JSF itself operates in a pretty pure Model/View/Controller mode.

Having said that, I don't think that HTML5 support is yet baked into the JSF standard, and there's no native support for "fractured" HTTP (conversational/long-term connections).
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:Having said that, I don't think that HTML5 support is yet baked into the JSF standard, and there's no native support for "fractured" HTTP (conversational/long-term connections).

One of the new features of JSF 2.2 (which was released in 2013) was support for HTML5, but that mainly has to do with the way you write Facelets pages. JSF 2.2 optionally lets you use HTML5 tags instead of JSF component tags, which is useful if you want to use HTML5-specific features. The pass-through elements and attributes tag libraries are useful for this.

You can, and many JSF components do use JavaScript, and JSF has support for interacting with JavaScript running in the browser. It also supports AJAX, in fact it's very easy to ajaxify a component; most of the time the only thing you need to do is add an <f:ajax/> tag to the component in the Facelets page, and then you get a more interactive page.
 
Tim Holloway
Saloon Keeper
Posts: 18800
74
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. I'm running in maintenance mode these days, so I haven't been keeping track on post 2.0 status.

I should add that JSF and jQuery go together very well. Both the Red Hat JBoss RichFaces and the IceFaces extension tagsets use jQuery internally to do a lot of their javascript-based magic and they support explicit jQuery on JSF View Templates as well.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob McBryde wrote:It's been a few years since I have been working with Java web apps and most organisations I have since worked at tend to use Java as backend server technology, preferring the front end clients to be written in modern Javascript frameworks such as Angular or React.

This is not meant to rain on anyone's parade -- especially not Jesper's promotion week -- but I think you will find that this is prevalent throughout the industry. Most organizations pursuing modern web development will view "creating UI on the server" as hopelessly antiquated and passé.

I got laid off last October, and if all I had had to offer was my extensive experience with server-side UI technologies, and not also an extensive portfolio of front-end experience, I'd likely still be looking for a job.

There will likely always be some organizations using JEE technologies, but in my experience that's not where the focus of modern web development is, and is certainly not where it's going.
 
Tim Holloway
Saloon Keeper
Posts: 18800
74
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Although I'm very pro-JSF, having moderated this forum for a long time, I'm afraid I'm going to have to agree with Bear.

The current managerial mindset is all about "get it done quick and get it done cheap". Virtually nothing in Enterprise Java is either quick or cheap.

The darling frameworks of the day are all about presentation - getting something visible where the management and users can See Something Soon. They're mostly appearance-oriented, mixed with scripting languages that allow fast coding. Largely because they don't have strong type checking. Languages such as Java won't even let you compile until you've got the details in agreement. Scripting languages allow bad scripts to get all the way into production (quickly), where they lay in wait like serpents in the grass ready to strike at the worst moment.

A truly industrial-grade application is more than just a pretty face. People won't remember how fast you got the demo site up when the daily news is all about how your entire customer database ended up in Bulgaria. Or got shredded when the holiday rush began. A well-crafted app requires both good looks and good functionality. And it's a rare individual who's both artistically talented and also can make the gears grind finely.

Unfortunately, looks are all that really get judged and the "less is more" mindset so prevalent these days means that both the visual and functional parts of the app are usually handed to the same person. And, if they're lucky, they'll also get to be the sysadmin, network administrator and DBA.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Frameworks that are more oriented towards the client side and JavaScript, especially Angular, are indeed becoming increasingly popular. That doesn't mean, in my opinion, that web app frameworks that are more oriented towards the server side are completely dead or are going away anytime soon. I come across many clients that are using Apache Wicket or JSF or Spring Web MVC.

There are pros and cons to each. With frameworks like Angular you can make great, modern, responsive applications, but it requires a different skill set than what back-end Java developers are used to - you need to know JavaScript or TypeScript and the whole suite of build tools that comes with that. For Java back-end developers it's probably easier to build web applications with a server side framework.

I am myself more a back-end specialist than a front-end specialist.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:The current managerial mindset is all about "get it done quick and get it done cheap". Virtually nothing in Enterprise Java is either quick or cheap.

The darling frameworks of the day are all about presentation - getting something visible where the management and users can See Something Soon. They're mostly appearance-oriented, mixed with scripting languages that allow fast coding.


This seems to imply that those of us working in modern front-end development are all doing so in a slipshod manner. Far from it. Front-end development is just as hard, perhaps even more so, as backend development. Sure, either can be done in either a slipshod manner, or in a well-engineered manner. The choice of frameworks and tools is irrelevant to the care and level of engineering brought to a project.

 
Tim Holloway
Saloon Keeper
Posts: 18800
74
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not at all. But in my town, the "Git 'R Dun!" mentality pervades management. The pressure is on the developers to produce something as fast as possible.

The advantage of scripting platforms is that you can produce "something" quickly. Where something is defined as visible results. Strongly-typed languages will refuse to let you see anything until you have satisfied the type constraints enough to get clean compiles. Which, among other things weeds out bad assignments of incompatible data types. Weakly-typed languages often allow you the ability to throw random text into a file because until that file is actually invoked in the app, nothing is parsed (depending on the implementation). So you can end up with files with "Fill me in later", appalling fresher mistakes (and I've seen some appalling fresher mistakes come from people with 10 years experience - in mainframe assembly language!), or, like I said, random trash/filesystem corruption.

A dedicated quality-oriented programmer, of course, is going to push back, but when everyone's working in constant fear of "rightsizing", most can only push so much, and locally people privately complain about what they're being forced to do.

I observed quite a few years ago that a professional-quality software system is going to take about the same amount of time and work, regardless of what what language and platform you use. But professional system development falls into stages: design, coding, debugging, testing. Strongly-typed languages load the time spent into the design and coding phases. scripting languages permit you to spend less time on rigorous design and coding, but if you do, you'll pay for it in increased debugging time. Testing has always been shortchanged around here, alas.

I'm not against scripted languages per se. Not everything demands the full infrastructure. I've done my share of PHP and I'm doing a lot of Python these days. But I do get offended when I'm accused of "not being productive" because I'm trying to produce quality and I'm working with a platform that won't show pretty pictures until fairly late in the cycle.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!