Lies, damned lies, and statistics :-)

You're right about how EJB 2 was popular at one time. There are a few differences here, though. First, JSF is gaining market share from an entrenched alternative (i.e. Struts). There was no such thing in the EJB world (unless you count CORBA or DCOM...which I wouldn't.) This implies that it's better than an existing framework, and although we all complain about Struts now, I would argue that it's better than EJB 2.x. It follows, then, that JSF is certainly better than EJB 2.x (especially if you use 1.2). Second, JSF is extremely extensible, and this extensibility has allowed the development of extensions that fill in gaps in the spec. That wasn't possible with EJB 2.x. Third, we on the expert group are very aware of what's happening in the ecosystem, and are rolling existing innovation into the spec. This is similar to what happened with EJB 3, except that we're doing this before an alternative (like Spring) has already eroded market share. So, while EJB 3 has had a tough time because of the bad taste of EJB 2 and the success of Spring, I don't think we'll have such resistance with JSF 2.

Yeah there was a time when EJB 2.X job stats looked like JSF today. Don't you remember the days when "life cycle of an EJB" was the stock J2EE interview question? *shudder* Lies, damned lies, and statistics. Indeed :)

I guess time will tell, and it will be interesting to watch. I'll respond to a couple of your points: >> First, JSF is gaining market share from an entrenched alternative (i.e. Struts). You are drawing this conclusion from the second chart posted - but I don't really see much of a decrease in market share for Struts here, do you? You can also see things like Flex / Rails gaining more market share than JSF. Another observation is that you have not included Spring MVC in the second chart. I would argue that Spring MVC is far more "entrenched" than Struts 2. And running a search would be difficult, for e.g. most of the hits that say "Spring" would probably use Spring MVC too. By the way the first chart has the Y-axis in the range of 0.01 percentage points, hardly what I would call a strong basis to draw any conclusions. >> There was no such thing in the EJB world (unless you count CORBA or DCOM...which I wouldn't.) Well why not? You freely add Flex / Rails / ASP.NET today to the comparison. Look at this old, old, link from The ServerSide: http://www.theserverside.com/tt/articles/article.tss?l=EJB-ComPlus

>> Second, JSF is extremely extensible, and this extensibility has allowed the development of extensions that fill in gaps in the spec. That wasn't possible with EJB 2.x I don't agree. I have been involved in a few EJB 2.X app-server porting projects. In theory this should have been Write Once - Deploy Anywhere. But no, each app-server vendor encouraged use of proprietary extensions that went beyond what the core spec had to offer.

where's JSP in these stats?

>> You are drawing this conclusion from the second chart posted - but I don't really see much of a decrease in market share for Struts here, do you? You can also see things like Flex / Rails gaining more market share than JSF. I think the Struts downward trend is pretty obvious. There's definitely no growth there. You're right about the growth curve for Flex and Rails being steeper, but I'm not convinced it's that dramatic of a difference. >> Another observation is that you have not included Spring MVC in the second chart. I would argue that Spring MVC is far more "entrenched" than Struts 2. And running a search would be difficult, for e.g. most of the hits that say "Spring" would probably use Spring MVC too. True. >> By the way the first chart has the Y-axis in the range of 0.01 percentage points, hardly what I would call a strong basis to draw any conclusions. Those numbers are based on the whole set of job postings, so the numbers are useful for inclusions. Indeed's own examples are in that range. >> I don't agree. I have been involved in a few EJB 2.X app-server porting projects. In theory this should have been Write Once - Deploy Anywhere. But no, each app-server vendor encouraged use of proprietary extensions that went beyond what the core spec had to offer. It's a completely different scenario. With JSF, the implementations aren't really providing a lot of extensions -- component libraries and other utilities are. So they tend to work in either of the major two implementations. The only major area of incompatibility is with Ajax-enabled components on the JavaScript side of things. This is because JSF came out before Ajax took off, and JSF 1.2's mandate was to fix issues with JSP. This is something we're fixing in JSF 2.

>> where's JSP in these stats? Here I was searching specifically for web frameworks...