Related
I am new to development and would like to develop an android application. I have previously built an application with Adobe Flash Builder 4.6 with Flex Mobile Project. I just recently noticed in 4.7 there is an option for Action Script Mobile Project.
Can someone please explain to me the difference between the two and the pros and cons to utilizing either or?
Pros:
Creating a Flex mobile project is easier (use Flex 4.6 with design mode to rapidly prototype, 4.7 to develop) and visually let's you drag and drop
You can use data binding and other convieniant built in tools
Like anything else, there's good and bad about using the Flex mobile project as oppose to a complete ActionScript based solution. Mainly, it's a lot easier to customize your preloadeder, your splash screen and other features similar to tht like customizing how your application handles screen. Below is a couple pros and cons of using the Flex mobile version instead of ActionScript.
Cons:
Slower performance
Can't use Adobe Scout, it's an awesome tool for real time benchmarking and profiling. Using the built in one is ok but it doesn't give you theamazing information that Scout provides.
My advice: if you're savvy enough to do everything in ActionScript, then definitely create an ActionScript project, your users will love you for it. Plus, it's not that much harder and it lets you have a myriad of additional control over your components. Also, you don't have to deal with the overhead that comes with data binding ( it generates event listeners, get and set methods and you can create much more efficient ones on your own). There are a number of other things that benefit you by creating an ActionScript version like refactoring and better subversion but those are more of incentives than anything else.
If you plan on making use of the declarative mark-up, built in UI components, and data binding which the Flex framework provides then you should probably start with a Flex Mobile Project. The downside to this approach is that the additional scaffolding of the Flex framework will incur a slight performance hit and will increase the over-all file size of your project.
On the other hand, if performance is critical and you don't need the declarative markup, built in UI components, or data binding provided by the Flex framework, then you should start with a pure ActionScript mobile project. Really simple applications, games, or applications with highly customised UIs would be examples of projects for which a pure ActionScript approach might be more suitable.
FYI, you can use Adobe Scout on Flex apps. Apache Flex now supports advanced Telemetry.
You can also add advanced telemetry to any SWF with the SWF Scout Enabler.
I had selected sproutcore as a framework right before Ember forked from sproutcore. I am left uncertain of which way to go and a bit frustrated in the apparent dilution of efforts caused by the fragmentation - as rarely does that lead to better things. The efforts of Sproutcore 2.0 (now Ember) seemed to be going in the right direction of modularization and reuse of other javasript components (jQuery), however it is really unclear from an outside view why the two efforts had to split... couldn't we have modular code, and a widget library module too?
The main questions are:
What are the effective differences between the two efforts?
What is history of the split?
What is sproutcore future, where is it going now?
Is Ember going develop to be a complete replacement for sproutcore?
As someone who has both a Sproutcore app and an Ember app close to a production launch, I'll take a stab at your questions (re-ordered for clarity). All of the below is what I've observed with no inside knowledge. A bit of it is speculation, so I've enabled wiki mode on this answer, so that more informed people can correct details.
What is history of the split?
Here is what I've pieced together:
SproutCore was created by Charles Jolley's company Sproutit as the basis of their Mailroom product in 2007. Jolley later joined Apple and Sproutcore was used to build the original web apps for Mobile Me. The mandate was to recreate the experience of Mac apps like Mail and iCal, and that effort continues on Sproutcore today with iCloud.
Jolley left Apple and formed a company called Strobe in San Francisco with a vision in part to leverage Sproutcore. The team at Strobe decided that Sproutcore didn't fit many Web 2.0 use cases well enough, and was too much of an all-or-nothing proposition for developers, so they initiated an effort toward Sproutcore 2. The goals of Sproutcore 2 were modularity, and a more HTML-aware approach that would be more accessible to web developers everywhere. Backbone's early traction was part of this analysis.
After struggling to move the Sproutcore codebase toward this vision, the Strobe team decided to start fresh with Sproutcore 2 (internal codename Amber). Charles wrote the core Run Loop and key-value observer code. Yehuda Katz and Tom Dale were the lead Strobe developers on the project. The vision at the time was that Strobe and the community would eventually port over most features and functionality from Sproutcore 1.x to Sproutcore 2.
Strobe business efforts were not yielding hoped-for results, and the company weighed its options, eventually deciding on a acquisition of Strobe talent by Facebook. Before this happened, a number of Strobe employees, including Katz and Dale, split off to form a new company called Tilde.
Tilde decided to continue to develop Sproutcore 2, but change the name (to Amber.js and then Ember.js) and goals of the project. They dropped long-term goals of backward compatibility with Sproutcore. They dropped support for any kind of view widget library and focused on the HTML/CSS use case with tight integration of data binding with the Handlebars templating language.
Since the dissolution of Strobe, stewardship of Sproutcore 1.x has passed from Jolley to Tyler Keating, and the community has re-focused on cleaning up Sproutcore 1.x, which was in an uncomfortable place for a while when the idea of Sproutcore 2 was looming.
What are the effective differences between the two efforts?
The similarities in the projects are that they feature very similar object models. They have similar property, observer and binding systems, too.
Sproutcore includes a library of view widgets like toolbars, list views, grid views, buttons, and theming system, and a focus on defining the view layer via Javascript and absolute positioning managed by the library. It is very powerful for creating desktop-style apps on the web.
Ember has a smaller footprint. It features tight integration with Handlebars. It is an alternative to Backbone for many projects. It aims to provide a standard application architecture for client-side apps and eliminate boilerplate code.
Those differences will likely lead to the frameworks diverging, although there has been some consideration of adopting the same core. In that scenario, Sproutcore would use Ember's "metal" library and perhaps other core libs).
What is Sproutcore's future, where is it going now?
This thread has minutes from the a recent contributor's meetup.
https://groups.google.com/group/sproutcore/browse_thread/thread/aacf00a6047a866e#
The short-term roadmap is to focus on solidifying the marketing materials, demos, and codebase. The team recently released the Sproutcore Showcase. There is general consensus about replacing abbot, the Ruby build tools for Sproutcore, with a Javascript(node.js)-based solution, which is now under active development. There is also a desire for fewer "large" merges of code from companies like Apple and more frequent releases. Sproutcore 1.8 was recently released.
Is Ember going develop to be a complete replacement for sproutcore?
Not likely. The Ember core team has been clear that they have no intention of personally developing those missing features. It is possible that community members may develop those as separate projects -- flame.js is the most ambitious attempt so far. Ember's design choices make it easier to integrate with projects like jQuery UI, so a full replacement may or may not be necessary.
1) The official line is Sproutcore is intended for RIAs and Ember.js is intended for "web-styled" applications. So when you look at iCloud think Sproutcore and when you look at Twitter think Ember.js.
From the technical standpoint, Ember.js is focused on more modularized code and so called "semantic-templates" for views. Sproutcore is more monolithic.
2) I'm not sure anyone really knows. If you look at the timeline, Charles Jolley left Apple to form a company called Strobe, which developed a full-stack platform for application development. Strobe hired Yehuda Katz and others, who began working on slimming down SC so it would run better on mobile devices. After about a year, Yehuda left to form the company Tilde, and a month after that Facebook bought Strobe in what is widely regarded as a talent acquisition.
So interpret that as you will.
3) This is an excellent question. Recently there was a meetup and several things were discussed. Key points discussed were:
SC is still alive and kicking
Improve documentation (we have been hearing that for a while).
Keep the good parts the code that was introduced post 1.4.5 in development of SC2 and get rid of or move to optional modules other stuff (like Templates)
new javascript-based build tools
completely new canvas based view layer, called Blossom.
Some sort of foundation/corporate backing for SC
There are probably others that I missed
4) Definitely not a replacement, although you can use any framework to build any app (it's all javascript, after all).
I am starting out a new project that involves the use of JSF 2.0.
From my initial reading, the Mojarra and Apache Implementation of the
project covers the basic components that you will need.
But I know that user's would seek gui with better presentation such as
panel tab, accordion, slider etc... Currently, there are other implementation that I am seeing, the Primefaces, RichFaces and Icefaces.
But I cant find a good article that discusses which among the three are the best.
I have used Spring MVC before but I use JqueryUI for those widget.
Now that I am into component based framework, I would like to use the best JSF Implementation.
I would like to know metrics such as performance/interoperability/ease of use/support.
Sorry if my question might be vague but I would like to hear comments before I select my JSF Vendor Implementation.
Thanks.
I happily use Primefaces as it is by far the most rich set of open source JSF2 controls out there, but they can be infuriatingly buggy at times. It is best to operate under the assumption that component X will not work correctly in a dialog without heavy tinkering.
I would avoid Primefaces if you operate in a development environment with strict UI design requirements as getting everything exactly the way you would like it to look and operate may not be a possibility.
Further I would avoid Primefaces if you are not comfortable with JSF, HTML, JQuery, JavaScript and CSS as you will need a good bit of JQuery trickery to work around the bugs that crop up.
But on that note, I haven't run into a problem yet that a couple lines of custom Javascript haven't fixed for me, and I have one of the most feature rich applications I have ever wrote in the shortest amount of time.
The speed of development is very fast in this area, and any article gets outdated quickly. I used Primefaces for a new project almost a year ago, because at that time it was the only one that was fully compatible with JSF 2 (both Icefacves and Richfaces have had JSF 2 compatible releases in the meantime).
Primefaces has a lot of powerful components that automatically use AJAX, and even more were added in version 3. Unfortunately this focus on new features led to a lot of bugs, but the developers said they would focus on bugfixing after release 3; I can't say anything about the current status since I left the project after 3 months.
There is one thing against Icefaces: a lot of components and functionality are only available in the Enterprise version, which is commercial, not free (but that might as well be a good thing since you get support etc. if your project can afford it).
Why not play with all three libs for a short time, build a simple project and see how you are getting along with either of them. My personal taste prefers Primefaces, but I haven't tried Richfaces since it turned JSF 2 ready.
I have successfully used JBoss RichFaces on a large online B2B store. RichFaces is a quite good framework for building webapps Web 2.0 style, and have easy to use tags that help you develop features faster.
I do not have any metrics regarding performance between RichFaces and IceFaces/Primefaces, but the ease of development should be approximately the same. All three frameworks have similar components, and they are all working towards more and more logic on the client via JavaScript.
At the current state of the JSF libraries, I am fairly sure that you will be happy with whichever framework your choose. IMO RichFaces and IceFaces are the two frameworks that have been around the longest, and i would put my bet on one of these two. IIRC both frameworks have key developers in the JSF design group as well.
As a general rule of thumb, these framework should work interoperably, but I wouldn't mix and match between them. The frameworks are really ment to be used on their own.
Yesterday I saw a presentation on Java Server Faces 2.0 which looked truly impressive, even though I am currently a happy ASP.NET MVC / jQuery developer. What I liked most about JSF was the huge amount of AJAX-Enabled UI components which seem to make development much faster than with ASP.NET MVC, especially on AJAX-heavy sites. Integration testing looked very nice too.
Since the presentation only emphasized the advantages of JSF, I'd like to hear about the other side as well.
So my questions are:
What are the main disadvantages of Java Server Faces 2.0?
What might make a JSF developer consider using ASP.NET MVC instead of JSF?
JSF 2.0 disadvantages? Honestly, apart from the relative steep learning curve when you don't have a solid background knowledge about basic Web Development (HTML/CSS/JS, server side versus client side, etc) and the basic Java Servlet API (request/response/session, forwarding/redirecting, etc), no serious disadvantages comes to mind. JSF in its current release still needs to get rid of the negative image it gained during the early ages, during which there were several serious disadvantages.
JSF 1.0 (March 2004)
This was the initial release. It was cluttered with bugs in both the core and performance areas you don't want to know about. Your webapplication didn't always work as you'd intuitively expect. You as developer would run hard away crying.
JSF 1.1 (May 2004)
This was the bugfix release. The performance was still not much improved. There was also one major disadvantage: you can't inline HTML in the JSF page flawlessly. All plain vanilla HTML get rendered before the JSF component tree. You need to wrap all plain vanilla in <f:verbatim> tags so that they get included in the JSF component tree. Although this was as per the specification, this has received a lot of criticism. See also a.o. JSF/Facelets: why is it not a good idea to mix JSF/Facelets with HTML tags?
JSF 1.2 (May 2006)
This was the first release of the new JSF development team lead by Ryan Lubke. The new team did a lot of great work. There were also changes in the spec. The major change was the improvement of the view handling. This not only fully detached JSF from JSP, so one could use a different view technology than JSP, but it also allowed developers to inline plain vanilla HTML in the JSF page without hassling with <f:verbatim> tags. Another major focus of the new team was improving the performance. During the lifetime of the Sun JSF Reference Implementation 1.2 (which was codenamed Mojarra since build 1.2_08, around 2008), practically every build got shipped with (major) performance improvements next to the usual (minor) bugfixes.
The only serious disadvantage of JSF 1.x (including 1.2) is the lack of a scope in between the request and session scope, the so-called conversation scope. This forced developers to hassle with hidden input elements, unnecessary DB queries and/or abusing the session scope whenever one want to retain the initial model data in the subsequent request in order to successfully process validations, conversions, model changes and action invocations in the more complex webapplications. The pain could be softened by adopting a 3rd party library which retains the necessary data in the subsequent request like MyFaces Tomahawk <t:saveState> component, JBoss Seam conversation scope and MyFaces Orchestra conversation framework.
Another disadvantage for HTML/CSS purists is that JSF uses the colon : as ID separator character to ensure uniqueness of the HTML element id in the generated HTML output, especially when a component is reused more than once in the view (templating, iterating components, etc). Because this is an illegal character in CSS identifiers, you would need to use the \ to escape the colon in CSS selectors, resulting in ugly and odd-looking selectors like #formId\:fieldId {} or even #formId\3A fieldId {}. See also How to use JSF generated HTML element ID with colon ":" in CSS selectors? However, if you're not a purist, read also By default, JSF generates unusable ids, which are incompatible with css part of web standards.
Also, JSF 1.x didn't ship with Ajax facilities out of the box. Not really a technical disadvantage, but due to the Web 2.0 hype during that period, it became a functional disadvantage. Exadel was early to introduce Ajax4jsf, which was thoroughly developed during the years and became the core part of JBoss RichFaces component library. Another component libraries were shipped with builtin Ajax powers as well, the well known one being ICEfaces.
About halfway the JSF 1.2 lifetime, a new XML based view technology was introduced: Facelets. This offered enormous advantages above JSP, especially in the area of templating.
JSF 2.0 (June 2009)
This was the second major release, with Ajax as buzzword. There were a lot of technical and functional changes. JSP is replaced by Facelets as the default view technology and Facelets was expanded with capabilities to create custom components using pure XML (the so-called composite components). See also Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?
Ajax powers were introduced in flavor of the <f:ajax> component which has much similarities with Ajax4jsf. Annotations and convention-over-configuration enhancements were introduced to kill the verbose faces-config.xml file as much as possible. Also, the default naming container ID separator character : became configurable, so HTML/CSS purists could breathe relieved. All you need to do is to define it as init-param in web.xml with the name javax.faces.SEPARATOR_CHAR and ensuring that you aren't using the character yourself anywhere in client ID's, such as -.
Last but not least, a new scope was introduced, the view scope. It eliminated another major JSF 1.x disadvantage as described before. You just declare the bean #ViewScoped to enable the conversation scope without hassling all ways to retain the data in subsequent (conversational) requests. A #ViewScoped bean will live as long as you're subsequently submitting and navigating to the same view (independently of the opened browser tab/window!), either synchronously or asynchronously (Ajax). See also Difference between View and Request scope in managed beans and How to choose the right bean scope?
Although practically all disadvantages of JSF 1.x were eliminated, there are JSF 2.0 specific bugs which might become a showstopper. The #ViewScoped fails in tag handlers due to a chicken-egg issue in partial state saving. This is fixed in JSF 2.2 and backported in Mojarra 2.1.18. Also passing custom attributes like the HTML5 data-xxx is not supported. This is fixed in JSF 2.2 by new passthrough elements/attributes feature. Further the JSF implementation Mojarra has its own set of issues. Relatively a lot of them are related to the sometimes unintuitive behaviour of <ui:repeat>, the new partial state saving implementation and the poorly implemented flash scope. Most of them are fixed in a Mojarra 2.2.x version.
Around the JSF 2.0 time, PrimeFaces was introduced, based on jQuery and jQuery UI. It became the most popular JSF component library.
JSF 2.2 (May 2013)
With the introduction of JSF 2.2, HTML5 was used as buzzword even though this was technically just supported in all older JSF versions. See also JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used. Most important new JSF 2.2 feature is the support for custom component attributes, hereby opening a world of possibilities, such as custom tableless radio button groups.
Apart from implementation specific bugs and some "annoying little things" such as inability to inject an EJB in a validator/converter (already fixed in JSF 2.3), there are not really major disadvantages in the JSF 2.2 specification.
Component based MVC vs Request based MVC
Some may opt that the major disadvantage of JSF is that it allows very little fine-grained control over the generated HTML/CSS/JS. That's not JSF's own, that's just because it's a component based MVC framework, not a request (action) based MVC framework. If a high degree of controlling the HTML/CSS/JS is your major requirement when considering a MVC framework, then you should already not be looking at a component based MVC framework, but at a request based MVC framework like Spring MVC. You only need to take into account that you'll have to write all that HTML/CSS/JS boilerplate yourself. See also Difference between Request MVC and Component MVC.
See also:
What is the difference between JSF, Servlet and JSP? (just to understand the basics)
Using JSF to develop tableless CSS layouts (another myth about JSF)
JSF vs plain HTML/CSS/JS/jQuery (when JSF is the wrong choice)
Design patterns in web applications (illustrates the ideology behind MVC)
After 5 years of working with JSF, I think that I can add my 2 cents.
Two major JSF drawbacks:
Big learning curve. JSF is complex, that's just true.
Its component nature. Component-based framework tries to hide the true nature of the Web, which comes with a huge amount of complications and disasters (like not supporting GET in JSF within almost 5 years).
IMHO hiding HTTP Request/Response from the developer is an enormous mistake. From my experience, every component-based framework adds abstraction to the Web development, and that abstraction results in unnecessary overhead and higher complexity.
And minor drawbacks that come to my mind:
By default ID of the object is composed of its parents' ids, for example form1:button1.
No easy way to comment-out incorrect page's fragment. Tag <ui:remove> needs syntactically correct content which is parsed anyway.
Low quality 3rd party components which e.g. don't check isRendered() inside processXxx() method before continuing.
Incorporating LESS & Sencha is hard.
Doesn't play well with REST.
Not so easy for UX designers, because ready-to-use components have their own CSS styles, that need to be overwritten.
Don't get me wrong. As a component framework JSF in version 2 is really good, but it's still component-based, and always will be...
Please take a look at the low popularity of Tapestry, Wicket and low enthusiasm of experienced JSF developers (what is even more meaningful).
And for contrast, take a look at the success of Rails, Grails, Django, Play! Framework - they all are action-based and don't try to hide from the programmer true request/response and stateless nature of the web.
For me it's major JSF disadvantage. IMHO JSF can suits some type of applications (intranet, forms-intensive), but for real-life web application it's not a good way to go.
Hope it helps somebody with his/her choices that regards to front-end.
A few drawbacks that pop to mind:
JSF is a component-based framework.
This has inherent restrictions that
have to do with obeying the
component-model.
AFAIK JSF supports only POST, so if you want a GET somewhere you have
to do a plain servlet/JSP.
Most components try to provide abstractions over domains like
relational databases and front-end
JavaScript, and many time these
abstractions are "leaky" and very hard to debug.
These abstractions might be a good starting point for a junior developer or someone not comfortable with a particular domain (e.g. front-end JavaScript), but are very hard to optimise for performance, since there are several layers involved, and most people that use them have little understanding of what is going on under the hood.
The templating mechanisms that are usually used with JSF have nothing to do with how web desigers work. The WYSIWYG editors for JSF are primitive and in any case, your designer will give you HTML/CSS that you'll have to spend ages converting.
Things like EL expressions are not statically checked and both the compiler and IDEs are not doing a good job at finding errors, so you'll end up with errors that you'll have to catch at run-time. This might be fine for dynamically typed language like Ruby or PHP, but if I have to withstand the sheer bloat of the Java ecosystem, I demand typing for my templates.
To sum up: The time you will save with JSF, from avoiding to write the JSP/servlet/bean boilerplate code, you'll spent it x10 to make it scale and do exactly what you want it to do.
To me the biggest disadvantage of JSF 2.0 is the learning curve not only of JSF, but the component libraries that you have to use in order to get it to do useful work. Consider the staggering number of specifications and standards you have deal with to really be proficient:
HTML in the various incarnations. Don't pretend you don't need to know it.
HTTP -- when you can't figure out what is going on you have to open Firebug and see. For that you need to know this.
CSS -- Like it or not. It isn't so bad really and there are some nice tools out there at least.
XML -- JSF will probably the first place you use namespaces to this degree.
Servlet Specification. Sooner or later you will get into calling methods in this package. Aside from that you have to know how your Facelets gets turned into XHTML or whatever.
JSP (mostly so you know why you don't need it in JSF)
JSTL (again, mostly to cope with legacy framework)
Expression Language (EL) in its various forms.
ECMAScript, JavaScript, or whatever else you want to call it.
JSON -- you should know this even if you don't use it.
AJAX. I would say JSF 2.0 does a decent job of hiding this from you but you still need to know what is going on.
The DOM. And how a browser uses it. See ECMAScript.
DOM Events -- a topic all by itself.
Java Persistence Architecture (JPA) that is if you want your app to have any back end data base.
Java itself.
JSEE while you are at it.
The Context Dependency Injection specification (CDI) and how it clashes with and is used with JSF 2.0
JQuery -- I would like to see you get along without it.
Now, once you are done with that you can get on with the proprietary specifications, namely the component libraries and provider libraries you will pick up along the way:
PrimeFaces (my component library of choice)
RichFaces
MyFaces
ICEFaces
EclipseLink (my JPA Provider)
Hibernate
Weld
And don't forget the container! And all those configuration files:
GlassFish (2, 3, etc)
JBoss
Tomcat
So -- THIS IS MAKING IT EASY? Sure, JSF 2.0 is "easy" as long as all you want to do is the most basic web pages with the simplest interactions.
Simply put, JSF 2.0 is the most complicated and cumbersome mishmash of glued together technologies as exists in the software universe today. And I can't think of anything I would rather use.
Inexperienced developers usually will create applications that are painfully slow and code will be really ugly and hard to maintain. Its deceptively simple to start, but actually requires some investment in learning if you want to write good programs.
At least at the start you will often "stuck" on some problem and will spend more time reading balusc posts on internet than actually working :) After a while it will be less and less of that, but it still can be annoying.
Even more annoying when you find out that the problem is not due to you lack of knowledge/mistake but actually a bug. Mojarra was(is?) quite buggy, and another layer of components adds even more problems. Richfaces was biggest piece of crap software ever written :) Don't know how it is now on version 4. We have Primefaces which is better, but still you will run into bugs or lack of features especially with more exotic components. And now you will need to pay for Primefaces updates. So I would say its buggy but its getting better especially after 2.2 version fixed some problems with spec. Framework getting more mature but still far from perfect (maybe myfaces better?).
I don't find it especially flexible. Often if you need something very very customized and there are no components that does that - it will be a bit painful. Again I'm talking from average developer perspective - the one with deadlines, quick reading tutorials, and searching stackoverflow when getting stuck because no time to learn how it really works :) Often some components seems to have "almost" what you need, but not exactly and sometimes you might spend too much time to make it do something you want :) Need to be careful in evaluating if its better to create your own or torture existing component. Actually if you are creating something really unique I would not recommend JSF.
So in short my drawbacks would be: Complexity, Not very smooth development progress, buggy, inflexible.
Of course there are advantages too, but that's not what you asked. Anyway that's my experience with framework others might have different opinions, so best way is to just try it for a while to see if its for you (just something more complex - not naive examples - JSF really shines there:) IMHO best use case for JSF is business applications, like CRMs etc...
"JSF will output View-layer HTML and JavaScript that you cannot control or change without going into Controller code."
Actually JSF gives you the flexibility, you can either use standard/third-party components or create your own which you have full control over what is rendered. It is just one xhtml you need to create your custom components with JSF 2.0.
We developed a sample project with JSF (It was a three week research so we may have lose some things!)
We try to use core jsf, if a component is needed we used PrimeFaces.
The project was a web site with navigation. Each page should be loaded via ajax when the menu is clicked.
The site has two usecases:
A page with a grid. The grid is loaded via ajax and should support sort and paging
A three step wizard page. Each page has client side validation (for simple validations) and server side ajax base validation (for complex validations). Any server exception ( from service layer) should be displayed on the same page of wizard without navigating to next page.
We found that:
You need to use some hacks from omniFaces to make the JSF view state fixed. The JSF state will be corrupted when you include pages via ajax in each other. This seems a bug in JSF and may be fixed on next releases (not in 2.3).
The JSF Flow is not working correctly with ajax (or we could not make it work!) We try to use primeface wizard component instead but the client validation seems not supported and mean while it was not standard JSF flow standard.
When using some jQuery components like jqGird, and you need to load JSON results, then you are advised to use pure servlet, The JSF will do nothing for you. So if you use these kind of components, your design will not fit in JSF.
We try to do some client scripts when ajax complete by ajaxComplete and we found that the PF 4 has implemented its own ajax events. We had some jQuery components and we need to change their code.
If you change the above sample to a non Ajax project ( or at least less ajax project) you will not face lots of above issues.
We summarize our research as:
JSF is not working well in an fully ajax base website.
Of course we find lots of nice features in JSF which may be very helpful in some projects, so consider your project needs.
Please refer to JSF technical documents to review JSF advantages, and in my opinion the biggest advantage of JSF, is the COMPLETE AND HUGE support from #BalusC ;-)
I'm not a Java Server Faces expert at all. But IMHO the main disadvantage is that it's server side. I'm tired of learning and using server side web presentation layer frameworks like ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, php frameworks and ruby on rails frameworks. I said goodbye to all of them, and I said hello to Angularjs and TypeScript. My presentation layer runs on the browser. I doesn't matter if it is served by Windows IIS running php or ASP.NET, or if it is served by an Apache web server running on Linux. I just need to learn just one framework that works everywhere.
Just my two cents.
For me the biggest shortcoming of JSF is poor support for programmatically (dynamically) generated pages.
If you want to construct your page (create page component model) dynamically from java code. For example if you are working on WYSIWYG web page constructor. Adequate documentation of this use case in not generally available. There are many points where you have to experiment and development is quiet slow. Many things just don't work how you would expect. But generally its possible hack it somehow.
Good thing is that it's not problem in philosophy or architecture of JSF. It's simply not elaborated enough (as far as I know).
JSF 2 brought Composite Components which should make component development easy, but their support for dynamic (programmatic) construction is very poor. If you overcome quiet complicated and almost undocumented process of dynamic Composite Component construction, you will find out that If you nest few Composite components little deeper, they stop working, throwing some exceptions.
But It seems that JSF community is aware of this shortcomings. They are working on this as you can see from these two bugs
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599
Situation should be better with JSF 2.2 at least if we are talking about specification.
Commenting on my last few months of Primefaces/JSF experience:
If you can use components "off the shelf", I guess it's not terrible.
However, it doesn't play well as soon as you step outside and need custom UIs. - For example, we needed to use Twitter's bootstrap for our project. (Not primefaces bootstrap).
Now our pages work as follows:
Page loads.
User interacts with a Primefaces that has ajax functionality
Bootstrap's javascript bindings break
We run extra javascript to rebind everything
The promise of JSF to avoid writing javascript turned into writing more javascript than we would have if not using Primefaces--and that javascript to is fix what Primefaces breaks.
It's a time sink--unless you again use "off the shelf" stuff. Also really ugly (Primefaces) when having to work with Selenium. It can all be done--but again--there's only so much time.
Definitely avoid this if you're working with a UX/design team and need to rapidly iterate on the UI--you can save time by learning jquery/writing straight HTML--or looking at react/angular.
JSF has many advantages, question being on disadvantage let me add couple of points on it.
On a practical scenario of implementing a web project with in a time frame you need to keep an eye on the following factors.
Do you have enough senior members in your team who can suggest best
controls suitable for each scenario?
Do you have the bandwidth to accommodate the initial learning curve?
Do you have enough expertise in your team who can review the JSF
stuff produces by the developers?
If your answer is 'No' for the questions, you may end up in a non-maintainable codebase.
JSF has only one disadvantage: before starting "JSF" development you should clearly understand web development, core java and front-end architecture.
Nowadays "new" JavaScript frameworks just try to copy/paste "JSF" component-based model.
Among all the "mainstream" frameworks such as Spring MVC, Wicket, Tapestry, etc., the JSF of Java EE with its composite components is the most elaborated presentation-layer and component-oriented technology provided. It is a bit cumbersome and incomplete compared to solutions provided by HybridJava.
Vaadin and Apache Click seem to be equally good, which one should I choose for developing my web application. Or rather, what are the Pros and Cons of each framework.
I'm a committer of Apache Click but hopefully you will find my opinion objective.
I don't know Vaadin at all, just had a cursory look at their website and examples and mission statement.
Apache Click and Vaadin are meant for different problem spaces. Apache Click is targeted at traditional enterprise web applications while Vaadin targets the Rich Internet Application (RIA) space.
Apache Click is a traditional share nothing, stateless framework. Unlike traditional action based web frameworks Click provides a slightly higher level of abstraction by using Pages and Components. At the of the day Click isn't a revolution. Its just one of many approaches of doing web application development. In my opinion its a very good approach, both from a developer and maintainer point of view. (In enterprise environments the developer and maintainer are often not the same individual, so I differentiate between the two roles).
However developers sometimes have requirements that cannot be satisfied by traditional web applications, which is where RIA comes in. They provide a richer user experience (think desktop) but this does not come for free. RIA comes at a cost in terms of complexity, productivity and time-to-market. It makes sense though, if the requirements are for a richer experience, you need to do more in order to deliver that experience.
My advice here is: think carefully about your requirements. Don't simply assume that RIA is better, there is a price to pay, so make sure you get return for your investment.
Lastly, if your requirement is for RIA, then you should compare Vaadin with Flex. If your requirement is for a more traditional web application then compare Click with Struts, Stripes, Wicket, Tapestry etc.
Kind regards
Bob
I use both ;-)
Click is the best for classic web applications (pure html with no/ small/ handmade javascript).
It is very lightweight (small size and stateless), less verbose (you can do your html in html with velocity/freemarker power ;-).
A real php-killer.
Vaadin is the best for desktop like enterprise applications.
It is statefull, heavyweight, verbose, but amazing.
Grails, Play!, Spring MVC is a real step back after Click/Vaadin.
So my advice: use both!
For most of your pages you will use Click, for complicated tasks - Vaadin.
I've been using Click since 2006. I've built various web applications with it in the last 4 years. All apps (B2B) are still going strong and continue to be maintained/added to now. The best things about Click IMO include:
Very little magic and almost no plumbing. It's all just plain java (and jsp/velocity/freemarker take your pick; or alternatively use all 3 if you so choose; I have for some scenarios because it's so easy to).
It's super fast (It doesn't mean your app won't be slow, it just means Click will never be the reason why your app is slow)
It is so easy to integrate your favourite java lib eg. Ibatis SQLMAP, Spring, displaytag, DWR etc.etc.
You don't need to buy a book to understand/use it (although you may need books for all the other 3rd part libs you plan to use).
Most of my code written 4 years ago still works with the current release. That is just awesome.
Click fits in your head. The whole framework that is. It is so simple you don't have too many questions even as a beginner.
The guys that maintain Click are super responsive and very noob friendly.
It's simplicity helps my apps adapt to new/old tech. i.e I can easily do AJAXy stuff if I want or not.
The form features make handling html forms very easy/fast.
The table features make displaying data super easy/fast
Click's features help me write apps very quickly. Makes the need for scaffolding unnecessary imo.
If you want a light weight, fast, easy to understand framework which helps you build applications as fast as you or your team are personally able to, check out click, it will be worth your while.
Before making your choice you should evaluate all options by taking them out on a test drive.
I'm not familiar with Click, and someone should correct me if I'm wrong, but I understand Click basically a technique to link your server side code to web pages. The UI is page-based and you define the UI with components corresponding to HTML elements. Ajax is not (yet) supported, I gather.
Vaadin operates at a higher level of abstraction. With Vaadin you get to concentrate on your business logic, and build your UI naturally with views, layouts and other components (check out the Sampler). You don't need to care about RPC, page transitions, HTML or templates. Vaadin gives you a fully cross-browser compliant Ajax UI that looks and works great out of the box. It's very easy to get started, and the forum is very active (>700 messages last month compared to 96 on the Click mailing list).
Disclaimer: I'm a member of the Vaadin team and have not used Click.
I would choose, and I already did in a few projects Click (over all other frameworks).
The main selling point for me was that I was able to learn Click and be quite productive in one week-end (Vaadin - but other frameworks too took me much more).
The free and available documentation for Click is much better - you can compare the sites yourself (even if the Vaadin site looks cooler, the Click site is simply more useful - at least it was for me).
The live examples are much better - I always look at them as a snippet repository, and just copy what I need from there (since I'm a lazy programmer :) ) - there's a "Page Java" and "Page HTML" link for every example that shows the source code for every available example.
Regarding the message traffic, I don't think that should be a criteria, since having so good free online docs, and the framework being so much simpler, the users simply don't need to ask that much.
Disclaimer: I'm just a simple user that have used both frameworks.
Is Apache wicket an option as well ?
My experience is with jboss/ejb/jquery, but looking at technologies for starting a new project. I've done a quick bit of research myself abd Vaadin seems to be very well regarded.
Surely Apache Wicket is something you can not ignore if you are comparing UI frameworks. ( I am doing same.) I dropped Vaadin because of poor documentation ( maybe I am not a good Googler.)
Currently comparing Wicket, Click, and ZK.
Click and Wicket are ahead so far for the following reasons:
Generates pure HTML instead of rendering UI using JavaScript which happens in GWT, Vaadin, and ZK. You can use HTML5 features then.
Even with native HTML, server-side binding of UI forms is possible.
You don't need to worry about communication with the server. ZK also does this but with their own language ZUML.
I have found server-side memory footprint higher in ZK in the case of components like the ZK Grid. (Memory footprint for Click is not known to me yet.)