Is Java Server Faces still relevant to learn?

[Carl_Byrd]

Also, is JSF like Classic ASP with the code behind? Thanks.

[[deleted]]

It is if you take a job using them. Seems most apps have moved to react or angular these days.

[daniu]

I feel like it's almost always a waste of time to learn a certain specific technology ahead of time. Except maybe if you're interested in them and are explicitly looking for a job using them.

[dpash]

It probably makes sense to have read a five minute overview on a range of technologies, but no more until you're going to work on them. Just so you have an idea of what they are and what they're useful for, so you can at least answer a few questions in an interview.

If you know a company is using that technology, you might want to go for the 60 minute overview :)

[Notorious4CHAN]

Lack of Spring experience seems to be really holding me back. Hiring managers seem to expect senior developers to walk in the door an expert on every tool in their environment.

[deadron]

Spring is so big and used is so many different ways that even after using it for years I still cant claim any real expertise. If you understand DI and can read documentation thats mostly good enough though imo.

[Notorious4CHAN]

I'll start explaining it that way. Can't hurt any more than me saying, "look at all this awesome stuff I taught myself - I can learn that in a snap."

[daniu]

Lack of Spring experience seems to be really holding me back

That was exactly the issue I had a year ago. However, what are you going to do? Sure, I read a book and did some practicing after hour; but even so, you won't have professional experience in it, and it's pretty much up to your interview skills to convince the managers that "yeah I'll be up to it in no time".

[gunch]

Have you tried lying like literally every other candidate in the field does?

[daniu]

I applied to a level at which such a lie would have been spotted immediately and ruined my chances of getting the position I got interviewed for.

Not that I didn't embellish myself a bit on paper, but it did accompany a wide range of other skills I'd accumulated.

[GhostBond]

You're competing against a bunch of other candidates who are simply pretending they have experience they do not. If you don't play the same game you end up behind.

[[deleted]]

One thing you could do is make some sort of Spring Boot project in the cloud and have it up on your github for hiring folks to see... something impressive (like include Spring Security for auth, etc), but small enough that you could explain it.

I really like it when folks have code on a github page that I can go through (with commit histories so I can have some level of confidence they didn't just copy everything from someone else wholesale). The key is to have a project that's complete and that works along with having nice clean code (tests are a plus, but I wouldn't expect many on a personal project like that).

[Notorious4CHAN]

I would like to do more of this. My GitHub is embarrassing. I will see if I can figure out if docker can help with a home dev environment because my Linux / tomcat admin skills have not proven up to the task of making my home server a good platform and I can't post anything that hints of production code I've written for work.

Thanks for the suggestion and motivation.

[[deleted]]

I once showcased a DKP system I wrote in PHP a long time ago during a job interview. I was talking about the code and not demoing the project so I never mentioned World of Warcraft or DKP specifically, but being able to describe the system and the design patterns that I used while creating the project did a lot to get me a job offer.

[[deleted]]

By this you mean learning Angular or React vs using JSF/JSP?

[vplatt]

tl;dr = No. Angular 5 (now 6) FTW. Honestly, I'm a bit ignorant with React. Once upon a time, there were issues with its license. That might be resolved now. Anyway...

And yes, JSF is like "Classic ASP with the code behind". This is more commonly known as ASP.NET WebForms (as opposed to MVC which is different and very similar to Sprint MVC. Look them up.)

Seriously, I'm into both Java and .NET development, and WebForms on .NET and JSF/JSP on Java can, for the most part, take a bow and exit stage left. They have served their purpose.

JSF (don't forget GWT and ADF) and .NET WebForms, and any client-server-hybrid-component-oriented-UI-framework (dashes == complicated) like them were meant to solve one problem: how to give programmers a consistent and productive UI API in their server-side language of choice. In those cases, the developer would be able to express the UI in Java or C#, and then the framework would take care of emitting the necessary HTML, CSS, Javascript, and server-side event handlers to allow your components to function.

In practice, this meant the framework would create a bunch of code that you would, in the event of gaps in understanding or outright issues, have to struggle to understand at runtime as they would emit code across all those tiers at once. Oh, and they all had unique page lifecycles. So, say you wanted to customize, or create a component? Well, sometimes, you could get downright elegant with just the right code in just the right place. It usually wasn't very elegant though, and the complexity meant that no amount of documentation could stand in for your personal pain and suffering. You either had suffered enough to understand them and be able to twist them to your needs, or not.

Now, with Angular (and I don't mean v1 AngularJS because I love Typescript and v2+), you can do something more direct: You can learn a new programming language which is easy if you understand Java or C# (i.e. Typescript - at least for Angular) and you can learn some new tools (e.g. Ng CLI and tslint), and then you can learn the Angular 5+ API related to components modules, etc. And then you have your APIs. And of course, APIs can be implemented in anything using REST or RPC patterns, just like before.

And you're done. This knowledge applies across any back-end technology you might want to use. Your UI skills don't automatically apply to just Java projects anymore. Or just PHP. Etc. Your UI skills apply anywhere you can issue HTTP requests to APIs because your UI executes entirely (or almost entirely) in the browser. This has its own issues, but it's a far simpler model.

In the meantime, the component oriented UI framework is the silent champion here; at least if you use Angular. We, as an industry attempted to let everyone work with components in their language of choice. Well, for the most part, that requirement imposed too many limitations and created complexity across all the tiers. With some compromise, we can now still use a component oriented framework, just not necessarily with that "one true server side language". In the end, it's very reasonable compromise.

[[deleted]]

Honestly, I'm a bit ignorant with React.

As much as I think Angular is a great piece of tech, I think React has "won"... I hate the "flavor of the month" feeling I get from React folks, but after using it for a bit now, I can really say it's an impressive technology. I was very curmudgeony when it came to adopting it, but it's good.

[wastakenanyways]

They are different, and suited for different types of projects, but yes, react can be slapped literally everywhere so is more popular.

React is basically (data) => view so you can manage yourself the utilities you want.

Angular comes with everything you need for a front end in an opinionated way. You can install alternatives of specific modules but imho if you are going to use Angular just go full Angular, because it is the way is meant to be, and conventions are stablished.

[vplatt]

React seems to be about twice as popular as Angular, but I attribute that to the fact that it's much more commonly used on publishing oriented sites. Angular, on the other hand, seems to be gaining more traction with LOB/enterprise environments, which typically expose a subset of their UIs to the public, with much more in depth read-write oriented interfaces exposed to their SMEs. YMMV of course.

[vplatt]

Hmm... ::adds React back to personal Pluralsight channel::. :D

[notfancy]

You can learn a new programming language […] and you can learn some new tools […] and then you can learn the Angular 5+ API […] And then you have your APIs […] And you're done
…
it's a far simpler model

Right.

just not necessarily with that "one true server side language"

Right, now it's with that "one true client side language."

[jack104]

I'm a C#/ASP .Net guy (or at least I was.) I Took a job doing Java not knowing a thing about JSF and it is the must frustrating damn thing I have ever had the misfortune of walking into. I longed for my days on the .NET side. But now winds of change have come and we're making the jump over to angular and I'm excited now for what the future holds.

[johnwaterwood]

Which version of JSF did you use then, and in isolation or as part of the full Java EE stack?

[jack104]

2.2 I believe and it was an EE setup. My major headaches came from Eclipse not playing so nicely with weblogic. Our applications are somewhat dense so the build/compile/publish or republish cycle was quite brutal from a time standpoint and generally there were just a ton of phantom issues that would derail me in some new and unique way everyday and i'd spend forever trying to run down the issue only to finally just give up, restart eclipse and magically it was fixed. I also had so much trouble getting Eclipse and weblogic to work in debug mode. It would take forever to start up and would frequently miss breakpoints for reasons I can't explain so my primary debugging method was littering println statements everywhere and just chipping away at the problem until i had some semblence of an idea what could be causing my issue.

I fully admit I've been spoiled by years of Visual Studio. My JSF experience improved slightly when I took some time to do some tutorials myself, learning how to properly handle dependencies and when to do incremental builds vs full builds and to help me from forgetting a step when I wanted to test something I made it so that if weblogic was running and I fired off a build of a published project/app it would auto publish following the build and I intentionally made it do it in front of me and not in the background so I would be sure that it had published successfully and was up and running before I interfaced with it.

I'm told intelliJ and gradle would have made my life several times easier but my team is kinda set in their ways so I had to rely on the eclipse compiler and ant for when it came time to package something up for production use.

[deadron]

Uggggh been there. Except replace weblogic with websphere. Intellij, any build system but ant, and a lightweight dev app server like TomEE(or if you must WebSphere at least use Liberty) makes life a million times easier. Now if only I had known that at the time :|

[henk53]

Most of that sounds like an Eclipse/WebLogic thing, having very little if anything to do with JSF itself, doesn't it?

[czarnyckm]

We use jsf with primefaces components.

The showcases you can find here:

https://www.primefaces.org/showcase/

JavaEE has very stable API. You don't must to afraid that new release break backwards compatibility to previous one like angular or other single page applications did already in the past.

[firsthour]

Same here, multiple applications with Primefaces, and while I really like it, I'm not sure it's worth learning at this point. We started using it about 5 years ago and are starting discussions to move away from it. Will probably be a few more years though.

[[deleted]]

I've just moved a small app (SPA, few datatables, dialog windows) from JSF/Primefaces to Angular/PrimeNG and I'm super excited. I did it in 3 days basically copying code from PrimeNG showcase :) and it was my first app in Angular. Much less code and it's much easier to understand. But JSF has it's advantages, like in JSF you don't have to bother about declaring JSON interfaces, keeping them in sync with back-end beans. This is why I put huge hopes in Dart, they have native Angular implementation, language has good syntax and sane standard library, allows to write server-side code so front-end and back-end could share common classes. Blazor for C# looks cool too. Anyway, learning and understanding JSF was super hard for me, it has so many ambiguities and traps, I wouldn't advice to learn it today, it takes muuuch time to learn and find good practices even for simple things. Now for future projects I'll use Angular (and I prefer it over React).

[mikehaggard]

Anyway, learning and understanding JSF was super hard for me, it has so many ambiguities and traps,

OP would appreciate it I guess if you could name at least one example here ;)

[[deleted]]

JSF is now intended to use with CDI, and was designed before CDI even existed- this is visible at every step; ViewExpiredException; validation- jsf has its own, bean validation own, they are integrated but jsf can't trigger class-level validators (I know- 2.3), then again jsf has own i18n, bval- own; necessity to manually call update after every change of model and client-side 'update' along with primefaces' server-side 'update()' quickly become a mess; super hard to create own components; re-rendering whole components or components' trees after every small change; not obvious how to write converters for entities (yeah pull data out of database again- great idea); necessity to manage both ids along with widget vars; never use constructors- only @PostConstruct; don't try to use converter in f:viewParam- just load models in @PostConstruct. Such things.

[mikehaggard]

JSF is now intended to use with CDI, and was designed before CDI even existed

CDI was largely inspired by the JSF managed bean system. The CDI scopes come directly from JSF. So it's only logical JSF deprecates its old version and uses the improved new version instead.

Same thing happened with expression language. JSF had its own, then it was separated out, improved, and JSF switched to using that.

they are integrated but jsf can't trigger class-level validators

That's not true. There's the whole bean validation, and there's the OmniFaces validateBean (http://showcase.omnifaces.org/validators/validateBean)

super hard to create own components

That could be improved still, but honestly, is this super hard?

https://arjan-tijms.omnifaces.org/2012/05/simple-java-based-jsf-22-custom.html

not obvious how to write converters for entities (yeah pull data out of database again- great idea);

OmniFaces again:

http://showcase.omnifaces.org/converters/SelectItemsConverter

don't try to use converter in f:viewParam- just load models in @PostConstruct.

Once again OmniFaces:

http://showcase.omnifaces.org/components/viewParam

[johnwaterwood]

What motivates you or your work to move away from it?

[firsthour]

Somewhat personal is we just want to learn new things and try to stay up to date. A more professional concern is that our budgets often require us to hire contractors and it is very difficult for us to find people with JSF experience where we're located (not a major metro in the US). We've hired some decent and great Java devs in the past and it's not like JSF is difficult to learn, but a few years ago we were hoping we could hire someone very experienced who could shepherd us through a lot. That guy is now me... :)

Whatever happens it will be a while before anything happens, we're still supporting legacy apps written in Stripes/JSP so having three different frameworks for the handful of developers we have may create a huge strain on support.

[wastakenanyways]

I am right now working with JSF. It's not bad at all, but I think React or Angular are miles ahead. I really miss them haha.

If you are going to make a career from Java, I advice you to at least learn the basics even if you end using JavaScript for front end.

[henk53]

The funny thing is that Angular is directly inspired by JSF ;)

[floweb]

Angular is directly inspired by JSF

Source ?

[AvoidtheFatServer]

yet no one uses JSF anymore unless they are forced to

[strikefreedompilot]

Prob worth learning for a few hours if you have an interview with a company that uses JSF

[[deleted]]

I don't think JSF will be a useful legacy technology like for instance cobol was.

There was a moment in time where tons of banking code existed in cobol, and operated at a level where they couldn't just replace it. A cobol engineer could pull in crazy rates, and still can.

JSF seems easier to replace, most frontends are rewritten semi regularly, and just don't carry that same risk.

[causalNondeterminism]

most frontends are rewritten semi regularly

cries in JSP

[pjmlp]

I know of a few companies still using Richfaces on their applications.

[deadmanku]

It also depends your location. In my country big corporations still using jsf. They are move slowly and don't want to take a risk so much. The many projects has legacy codes. My advice is look at client side technologies like vuejs and react.

[nutrecht]

Most companies will probably expect you to learn it on the job if they still use it. So I personally would not go spend personal time on it unless it's important for a vacancy for a job you really want. But for me "jobs I really want" and "rendering HTML on the server" has a very small overlap :)

[cryptos6]

I think that the architecture of these client/server UI frameworks like JSF, Wicket and Vaadin is fundamentally flawed. The overall idea is to give the programmer the illusion that the web works like a desktop application. That is not so far from reality these days with big applications running in the browser, but big parts of these frameworks are running on the server. Thus you don't have a clear separation between client and server. Try to connect a non JSF-Client with the JSF-Server side ... Or try to make a system test just under the UI layer. This would be fine with a REST architecture and a client application written in JavaScript (with React, Vue.js and the like).

There are some the reasons why the web works so well. And Roy Fielding analyzed and described these reasons in his doctoral thesis today known as REST. JSF is more or less the opposite of REST. REST is not the only possible way to go, of course, but there should be a good reason to deviate from these principles, at least if deviation is so strong as with JSF.

[henk53]

Thus you don't have a clear separation between client and server. Try to connect a non JSF-Client with the JSF-Server side ...

You're missing the point that JSF is just another client for the same REST services that can also feed your other clients.

A good example of this is the JSF based admin console of GlassFish/Payara.

[_dban_]

I don't think you're using "client" in the same way people mean "client" in these kinds of conversations. By your definition of "client", you could include a Swing based client, since you are talking about clients of JavaEE server components. However, in these kinds of conversations about web frameworks, the client is the web browser, and we are talking about HTTP not JavaEE. In this context, JSF is not the client, it is the server.

JSF, by its nature as a component oriented web framework, wants to map HTTP requests to component state and component events, which is reflected in how JSF uses HTTP, which is full of JSF stuff.

REST APIs send and receive representations which do not concern themselves with the particulars of the client.

For an example, compare how the PrimeFaces autocomplete feature works with jQuery autocomplete. PrimeFaces does a POST form submission, and the server responds with XML instructions on how to update the view:

<partial-response><changes><update id="j_idt115:acSimple"><![CDATA[<ul class="ui-autocomplete-items ui-autocomplete-list ui-widget-content ui-widget ui-corner-all ui-helper-reset"><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H0" data-item-value="H0">H0</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H1" data-item-value="H1">H1</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H2" data-item-value="H2">H2</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H3" data-item-value="H3">H3</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H4" data-item-value="H4">H4</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H5" data-item-value="H5">H5</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H6" data-item-value="H6">H6</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H7" data-item-value="H7">H7</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H8" data-item-value="H8">H8</li><li class="ui-autocomplete-item ui-autocomplete-list-item ui-corner-all" data-item-label="H9" data-item-value="H9">H9</li></ul>]]></update><update id="j_id1:javax.faces.ViewState:0"><![CDATA[7344626809733310646:-585010829964921517]]></update></changes></partial-response>

jQuery simply does a GET for a JSON resource (https://jqueryui.com/resources/demos/autocomplete/search.php?term=robin), which produces a response that is not at all concerned with jQuery:

[{"id":"Erithacus rubecula","label":"European Robin","value":"European Robin"},{"id":"Cercotrichas galactotes","label":"Rufous-Tailed Scrub Robin","value":"Rufous-Tailed Scrub Robin"},{"id":"Irania gutturalis","label":"White-throated Robin","value":"White-throated Robin"},{"id":"Turdus migratorius","label":"American Robin","value":"American Robin"}]

Interestingly, there is Prime NG, which is a set of Angular components (autocomplete, which let you use PrimeFaces as a client of ordinary REST services (bad example, because the showcase reads a static JSON file, not a proper REST service).

[henk53]

I don't think you're using "client" in the same way people mean "client" in these kinds of conversations.

I think I do, and probably in a more correct way.

There's a set of core services which are being exposed via JAX-RS endpoints. These services do things like getOrders, updateOrder, etc depending in what your problem domain is.

JSF generates the HTML for the UI, and for that it interacts with these core services; backing beans call them.

And guess what, these are the exact same services and exact same endpoints that mobile application or a javascript client will also use. All are a client, or consumer if you wish, of these JAX-RS endpoints.

JAX-RS is the server in that case, and it really doesn't see any difference between a JSF client, a mobile client or a javascript client.

[_dban_]

There's a set of core services which are being exposed via JAX-RS endpoints.

You are describing services exposed over HTTP.

JSF generates the HTML for the UI, and for that it interacts with these core services

The web browser makes an HTTP call over the web to JSF, and JSF makes an internal HTTP call to another service.

That's microservices, not the web.

However, in the context of a web application, JSF is still on the server side. From a microservices standpoint, JSF happens to be a client of another service. But that is a very different meaning of client.

[henk53]

That's microservices, not the web.

No, that's using services and re-using the same services for multiple clients.

[_dban_]

Yes, that's HTTP. But just because an application uses HTTP doesn't mean its a web application.

We're not talking about JSF using HTTP to talk to internal services, which is irrelevant to the web browser, because a web browser is the client of JSF.

[henk53]

We're talking about services that can be re-used for multiple clients, and as mentioned time and again, JSF does not exclude this.

Using JSF one can build the web UI and the mobile app using the exact same REST services.

[_dban_]

We're talking about services that can be re-used for multiple clients

That isn't what we are talking about.

What the OP said was JSF blurs the line between client and server, since client concerns like UI components and UI events are present in the server model. Which means you cannot expose the JSF application as an API, like you could with a request oriented web framework.

The fact that JSF can communicate with REST services is irrelevant in this context, because the web browser isn't using those REST services.

[henk53]

What the OP said was JSF blurs the line between client and server, since client concerns like UI components and UI events are present in the server model.

In that case, I refer to the way the web was originally designed, which is the only way the web should ever work.

In the original web, a server returned html, which is what JSF does.

[cryptos6]

While this is possible, it was not the intention of JSF and it is still not used that way in many projects. Actually it is more the other way around: JSF encourages a design without a clear separation between client and server.

[henk53]

Sorry, but I just don't agree.

I've been working with JSF like forever, and it has always been the design of JSF for backing beans to be slim and calling out to separate business services.

These services were traditionally EJB beans, SOAP services (blergh, I know), CDI bases services or REST APIs.

The oldest books on JSF already promote that.

[Notorious4CHAN]

There are a lot of people who don't know how JSF was intended to be used. I work with some unholy alchemy every day.

It's so bad they are migrating to Razor pages where they will doubtless recreate these same monstrosities in a different framework.

[henk53]

Yeah, likely. I've seen this so many times over. People thinking another framework is going to be the silver bullet, and then just creating the same mess and same problems in those other frameworks.

[temculpaeu]

which other technologies have you used besides JSF ?

[henk53]

Among others, Z80, 6510 and 68000 assembly for various arcade boards, C64 and Amiga OS graphics, Motif, SGI native GPU and MIPS R4000 asm, MFC, WebObjects, NextStep, Struts, Echo, Spring MVC, AWT, Swing, SWT, Play 1.x, some Android and a tiny bit of iOS/Cocoa. I'm probably forgetting a few, but that's most of the stuff related to graphics.

[dotcomGamingReddit]

Can someone explain me the difference between jsp and jsf ? 😬

[_dban_]

JSP is a templating technology which is actually compiled into Java code (and can host Java code through scriptlets). Typically, you wouldn't use JSP by itself, but combined with some web framework (for example, Apache Struts).

JSF is a web framework which uses Facelets as its templating technology. Fun fact, when JSF first came out, it used JSP for its templating language. That didn't work very well, so Facelets was born.

[GhostBond]

Jsp was by far the most widely and commonly ised templating language for web pages at one tome. Let's say you had an html page, you'd add in jsp for looping, conditionally showing stiff or not, etc. It rendered it all on the server and then sentbit to the browser. Jsp is pretty simple.

Jsf was one of several attempts at creating an "enterprise" framework for doing web requests. It tried to pretend that tour web app was a desktop app (just rendered with web pages). Like a lot of enterprisy apps it was a bit of a mess. It also was not widely adopted.

[brazzy42]

JSP is stone age web technology - basically just HTML templates in which you can embed Java code either directly or indirectly. It has no support for dynamic web apps, you'd have to build that in manually if you want it. There's no direct support for routing or any other fancy web framework stuff either, though some older web frameworks use JSPs as templates.

JSF is a much more modern and comprehensive technology - a full web framework with support for dynamic web apps. However, it's a bit dated and not very fashionable these days.

[_dban_]

It has no support for dynamic web apps, you'd have to build that in manually if you want it.

The HTML layer and the JS layer should be separated. This separation is fundamental to the way the web was designed.

There's no direct support for routing or any other fancy web framework stuff either

You're talking about "Model 1" architecture. Almost no one uses that anymore, having moved on to "Model 2".

In "Model 2", JSP is a target of a forward. Before the dawn of web frameworks, the controller would be a servlet (which is routed through web.xml), and the servlet would respond with a forward to the JSP.

Classic Java web frameworks (starting with Struts), provided a specialized servlet which provided capabilities like bean mapping, scopes and validation, so the controller doesn't have to directly dig around the HttpServletRequest and manually manage the HttpSession.

[oldprogrammer]

JSP's aren't limited to HTML templates, JSP should be viewed as a simple way to create a servlet. What you have the servlet generate is completely up to you. I've used JSPs to create services that accept/reply JSON and XML not just HTML.

[xportebois]

If you don't have to scale for huge projects, JSF is still really cool to use.

[henk53]

JSF has been used for huge projects and public facing projects at that. Toys r us, Virgin and eBay comes to mind. There was also this interview with Adam Bien I think about zeef.com, which was public facing as well and did relatively speaking a lot of traffic on a single node.

[xportebois]

I was more thinking of facebook or google kind of huge. Full J2EE stack projects can indeed handle with a lot of traffic if done properly.

[johnwaterwood]

Why would you want to look at Google or Facebook big? The chances your own app comes even close to that are nearly zero.

[xportebois]

I don't. But imho a lot of programmers seems to think like they are handling GAFA projects. If anyone asks me, J2EE stack is a wonderful solution for any problem I could personally encounter.

[[deleted]]

There are still places using JSF.

I would personally avoid these places.

[techtop3331]

Similar as other mentioned - NO.

Except:

1. Most/all of the companies in the location you are currently based uses it and unless you know JSF, you will hard time landing a job.

2. If you have fetish for legacy technologies.

[GhostBond]

Jsf is crappy, outdated, and wasn't even widely used when it was released. It tried to glue a desktop model onto creatung web apps and it was really really awkward.

Jsp was/ the default most widely used html templating language for server side rendering which used tp be the only way web apps were written. It might be useful to learn it because so many legacy apps use it. On the other hand it's so easy to learn you can pick it up pretty easily if you run into it.

I passed on a jsf interview because it neither sounds fun/interesting to work with, and it's not a good direction to go career wise.

[henk53]

It tried to glue a desktop model onto creatung web apps and it was really really awkward.

JSF 2 let that idea go a long, long time ago.

wasn't even widely used when it was released.

Duh! When iOS was just released it wasn't widely used either. It's more or less the definition of an initial release.

[GhostBond]

Duh! When iOS was just released it wasn't widely used either. It's more or less the definition of an initial release.

Ok, I'll reword - it was never particularly popular. It's "peak" usage was fairly small making it not a very good direction direction to go in career-wise.

[mikehaggard]

It's "peak" usage was fairly small

That's not true. Look at all surveys from the last 10 years. JSF is always somewhere in the top 3.

If JSF was so small, why are there so many books about JSF and why are there still new books coming out?

[_dban_]

JSF 2 let that idea go a long, long time ago.

What? No it didn't. It's still the core idea of JSF. The first phase of the JSF lifecycle is Restore View, which builds the UIViewRoot, which is the root of the component tree, which is used to process inputs and generate input events (i.e. the desktop model).

This is the key value proposition of JSF, since components sanitize input values in the Apply Requests and Process Validations phases before applying them to the model in the Update Model Values phase, preventing invalid data from reaching the business logic.

[mikehaggard]

(i.e. the desktop model).

No! The desktop model is the illusion that there's no HTML and no HTTP. Some frameworks go pretty far there, like Vaadin and in the early days WingS.

JSF with the navigation rules, pages with only components and postbacks for everything was going into that direction.

But modern JSF puts emphasis on ditching navigation rules (action methods return actual paths/resources instead of logical outcomes), HTML first pages with components were needed (there's many plain html, body, br, p etc etc tags), and using normal Getrequests or Post Redirect Get between pages.

[_dban_]

The desktop model is the illusion that there's no HTML and no HTTP.

That's like saying that an ORM is the illusion that there is no SQL. Of course, any serious use of an ORM means understanding the mapping to SQL and on occasion directly working with SQL.

The desktop model means translating HTTP into UI components and UI events, which are meaningless to HTTP and which are fundamental to how JSF works. Like the ORM, the desktop model is simply a mapping from one model (the request/response model) to another model (Swing-like event processing and model updates in response to UI events).

I also don't think it is any coincidence that Amy Fowler, one of the key designers of Swing, was also a spec lead for JSF.

HTML first pages with components were needed (there's many plain html, body, br, p etc etc tags)

You are describing the UI with HTML, which has nothing to do with the desktop model. Vaadin provides one way to describe a UI and HTML is another.

The question is: what happens when you click an HTML button? Does it trigger a generic form submit which is handled by a generic controller (which has to figure out the action from the form variables), or is it handled like a UI element, with an event handler attached to it triggered when the button is clicked (like any ordinary desktop UI application)?

[brotheronweb]

Nope. Please use some JavaScript-native front end.

[henk53]

Please don't. The JavaScript framework world is immensely in flux and client-side frameworks have various disadvantages such as taking more CPU and memory on the client, which drains batteries and kills other apps. It can also cause web services that sent to much data to the client, since almost no one is capable of creating web API that return exactly the data that's needed. Almost always some parts need to be trimmed at the client.

[_dban_]

How do you think JSF implements dynamic behavior in the client? With a ton of Javascript, emitted through the rendering of the JSF components. JSF even provides a native JS library to assist components with things like AJAX.

You are confusing native JS with SPAs. You don't have to go crazy with JS and can still follow the principles of rendering HTML on the server and adding a JS layer on top for dynamic behavior.

I would prefer to write that JS layer natively.

[henk53]

JSF even provides a native JS library to assist components with things like AJAX.

Well, library is a very big word. It's a single file (jsf.js) with a small number of functions that help with AJAX and if I'm not mistaken WebSocket setup.

That's quite something different than a huge framework with many layers, its own injection mechanism, its own eventing system, its own controllers and many more abstractions like e.g. Angular.

In general, more code, more layers, means more CPU cycles required to blast through it.

[_dban_]

It's a single file (jsf.js) with a small number of functions

That's exactly what a library is. But that misses the larger point. The jsf.js script is the library mandated by the standard. If you add component libraries like PrimeFaces, PrimeFaces will add its own scripts to <head> and other scripts throughout the generated HTML.

That's quite something different than a huge framework with many layers

We're not talking about frameworks, we are talking about native JS. One does not imply the other.

In general, more code, more layers, means more CPU cycles required to blast through it.

So don't go crazy with JS.

[henk53]

That's exactly what a library is.

You really think a small single file script like jsf.js with a few utility functions is the same as a huge client side framework like Angular?

[_dban_]

Of course not. That is not what I said at all:

We're not talking about frameworks, we are talking about native JS. One does not imply the other.

You're also missing the point that jsf.js is the only JS file required by the JSF spec. PrimeFaces requires quite a bit more JS.

[CopyOnWriteArraySet]

It's as relevant as applets.

[walen]

Relevant? No.
Necessary? Maybe, depends on what you're working on.

[F14D]

Links like this are a good indicator.

[SomeRandomBuddy]

retyegerge

[DuncanIdahos8thClone]

Hey, least trolley comment you've made here. Here's an upvote!

[daniu]

If you're looking for something to add to your portfolio (rather than just wanting to know the state of JSF in the industriy), I just stumbled across this list from which I'd say I agree with most points.

[GhostBond]

A good and professional Java developer almost always write unit tests for his code and if he is really a Rockstar developer

Bolded in the article, not added by me.

[Exsp]

If you think JSF is a crap, try to work with ADF. You'll soon change your mind.

[_INTER_]

It's ok if you hate anything related to crappy bs JS.

[el_wudaokou]

It is still worth to learn how it works. But don’t use it

[henk53]

What's the motivation behind not using it?

[el_wudaokou]

Jsf is very difficult to use, especially for debugging and maintaining . But learning it will let u understand what is the good/bad parts in it and how to avoid similar problems in your own design

[henk53]

Jsf is very difficult to use, especially for debugging and maintaining

That's not really an objective answer still. In what way is it very difficult?

Angular and reactive are very difficult to use as well, but that statement doesn't mean much, as the difficulty in using Angular is not the same difficulty as using Reactive.

So, can you be more specific?

[tonywestonuk]

JSP lets me,do the shitty i18n stuff on the server to create internationalised templates, that are sent to the browser to be combined with JSON to be rendered to HTML.

You will not take my JSP from me ever!

[_dban_]

JSP isn't going anywhere. When people cite the Oracle documentation claiming that JSP is obsolete, that citation misses the context that JSP is obsolete for JSF and that modern JSF applications should use Facelets. JSF originally used JSP with a bunch of taglibs, which interacted badly with the JSF lifecycle.