We Keep Coding

Seam with JSF v. Seam with GWT

Would anyone be able to compare and contrast the two solutions? I don't know much about Seam or JSF, though I am familiar with the way GWT works and very much like the theory of it.
Primary concerns:
Scalability / performance
Cross-browser compatibility
Learning curve
Productivity
WYSIWYG UI building
Capacity to code as much as possible in Java (I can touch JS/HTML/CSS if possible, but preferably not)

Concerning the server-side implementation of your app you have to take the following point into account (pro/con is subjective, so you should decide) when using GWT instead of JSF.
As mention by #z00bs, using GWT you'll have a desktop like app. So you won't use/need page-navigation or page-action feature of Seam.
All requests from GWT to the server are short-running. That means, most of your components will be of ScopeType.EVENT or ScopeType.STATELESS and you don't need/use the conversation scope.
Using GWT instead of JSF reduces the load on the server because you hold most of the state in the client.
You cannot use the JSF/Seam-lifecycle with GWT. For instance, you lose the model validation part in the lifecycle. Model validation will only be triggered by using the entity manager or manually
All other feature, such as security, mailing, or EL, are still working when using Seam with GWT.
Since Seam is well-known for its JSF support, you should consider another framework, such as Spring roo which is strongly related to GWT, too.

Concerning the client-side development of your app we had the same decision to make.
We decided to go for GWT for the following reasons:
Most of the development can be done in java. Since we have a strong background in java development this will save us a lot of time.
We could use all the well known and beloved tools for implementing since all is done in java.
Our app was going to be a desktop like, single page web application without complete page refreshes. At this point GWT seemed to fit best for that need (and it still does).
Pushing most of the state to the client and let him do most of the time consuming processing appealed to us. This way the server can handle lots of simultaneous request and connections to the server are only needed to sync the state on the client.
The support for Unit Testing GWT code is good, in conjunction with the MVP pattern even better.
Since the introduction of UiBinder creating and styling complex UIs has gotten a lot easier and faster.
To your main concerns:
Cross-browser compatibility is mainly taken care of by GWT itself.
WYSIWYG is possible with GWT Designer (I must say I've never used it; I like building the UI myself...)
GWT is really fast because the rendering is all done on the client-side.
Productivity is high when you're used to java.
The learning curve depends mainly on the architecture you use (MVP is complex at first).
Your application will scale since the server is freed of much costly processing.
Hope that helps.
(Some considerations concerning the choice of Seam are coming soon from #kraftan).

The conversation scope offered by Seam can readily be replaced in GWT by storing long lasting transactions (like shopping carts) in memory on the client side.

Neither! dont use seam (or jsf for that matter) if you absolutely dont have to! There are so many better web techs on java.

Wicket vs Vaadin

I am torn between Wicket and Vaadin. I am starting a micro-isv and need to make a choice of web framework. I have narrowed down my choices to Wicket and Vaadin. I have used both frameworks and I love them both. however I need to make a choice.
If If I choose Vaadin:
I wont have to worry much about the look and feel. It comes with nice themes.
I will do all my programming in Java which am very good at and wont have to spend time hacking CSS which am not very good at.
And most of the components that I will need for a business applications are there OUT OF THE BOX including, desktop like layout, tooltips, Keyboard shortcuts, tables with draggable and collapsible columns to name a few.
However, if I go the Vaadin way:
I will loose the ability to create UI declaratively.
I wont have the fallback feature if the browser doesn't support JavaScript - e.g most non Webkit mobile browsers.
Vaadin company is selling some components - e.g the JPAContainer so am not sure the company will be committed to offering full open-source framework. Business interests will always come first.
Vaadin applications will be mostly for the intranet. They are not very suitable for the internet with a web look and feel.
If I go the Wicket way:
I will have to style my applications and I can hardly give them a desktop look and feel.
Any advice? Anyone with experience on either framework kindly tell me the cons and pros and how you made your decision.

I think I've invested some time for both frameworks. I really like both because they bring the Swing-alike coding to web development. And I don't know easier ones for me (although there is click but I don't like the velocity templating thing)
And yes, there are differences.
I wont have to worry much about the look and feel.It comes with nice themes
true, but every serious company will style its app differently (unless you are prototyping)
I will do all my programming in java which am very good at and wont have to spend time hacking css which am not very good at
Then Vaadin would be 'better'.
i will loose the ability to create UI declaratively.
What are the advantages of that? (BTW: you could code declarative in groovy ;-))
But ok. I know what you mean: if you can afford a few separate designers then wicket is 'better'.
i can hardly give them a desktop look and feel.
Why not? Or what do you mean here? Wicket supports ajax and there are components which supports nice 'desktop-alike' things (ajaxlink, lazycomponent, autocompletion, progressbar, see wicket stuff + extensions). ok, for any more complex component you'll have to code in javascript BUT BTW did you know that you could even use GWT within wicket
Some minor experiences:
Vaadin is surely faster while coding (no css, html stuff). But if you go production keep in mind that the ease of programming can come to the cost of performance on the client side: e.g. if you use the 'wrong' layouts such as Horizontal/VerticalLayout, ... the massive use of javascript could slow down old browser.
But Vaadin is not slow! Use appropriate layouts such as CssLayout or FastLayout and also old browser can serve it. (Although if you would use CssLayout your coding-style is really wicket-alike.)
One issue with Vaadin is that it is a bit harder to profile, because you don't see easily where the client needs all the CPU and the nested divs gets cryptic id-names.
One great thing about Wicket is its warp persist integration
(Guice can be integrated in Vaadin and Wicket)
Testing the UI should be easy with Vaadin (although I didn't found unit testing stuff) and is very easy with wicket.
Last but not least creating lists/tables is VERY easy in Vaadin compared to wicket.

I've worked extensively with Wicket but I've not had any experience with Vaadin so this might be (a little) biased.
I'd recommend Wicket for obvious reasons, but what's probably of interest to you is Wickets openness. As Gweebz rightly pointed out, Wicket uses basic HTML markup as its foundation, so any structural or cosmetic changes are often trivial to implement.
Personally one of the things I really enjoy about out wicket work is the flow between front end presentation and the data backend, we've implemented Spring & JPA/Hibernate which means that any changes in the front end can be translated back into the data base with a single line of code thanks to Wickets model based architecture.
Again I can't say much for Vaadin having never worked with it, but if you're looking for architectures to start off with, I'd also recommend you have a look at GWT.

(continued from the comment in the first Wicket-related answer)
The major difference between Vaadin and Wicket is with how UI composition and client side code is written. With Vaadin you usually compose your UI without any templates or HTML at all and you get a sleek, fully Ajax'ed UI out of the box. However, if you prefer the templating approach just use CustomLayout which does exactly that.
Client side coding is rarely needed, but when it is you do it with the Java-based GWT which is IMO a lot more nicer than writing Javascript by hand. Besides, with GWT you automatically get cross-browser compliant solution instead of having to deal with those issues yourself.
When comparing frameworks you also should take a look at community activity and documentation. With Vaadin both of those are excellent. Also note the Vaadin Directory which currently contains 100+ very useful UI components and other addons.

I have a limited amount of experience with each but I prefer Vaadin. It allowed a richer experience with the web application I was developing. The main benefit that sold us though was how easy it was to write unit tests around our UI classes, ensuring the components functioned correctly when interacted with in the expected ways. This is also possible with Wicket however it was more difficult in my experience.
I will also mention that either framework will require some styling. Wicket starts off as plain old HTML and Vaadin starts off with a MacOSX-like theme by default but almost any web-app you write will require at least SOME customization. With this in mind, customizing the CSS of a Wicket app is SIGNIFICANTLY easier than Vaadin for the simple reason that you control the markup. Vaadin hides the markup from you and generates elements with weird IDs and structures so it is harder to customize the look. Just remember this when making your decision.

I am currently working with Wicket and I have worked in the pass with Vaadin. I wil be short in my observations:
Vaadin is entitled to be free but IMO, is not so beautiful like that. If you need support, help, documentation for that painful and tricky problems that you encounter, then you are screwed because you do not have so good documentation/community when compared with Apache Wicket. Vaadin have guys to help you, but you have to pay for it.;
To program in wicket you need to be a strong programmer. Vaadin also requires good Java knowledge but you can easily do some spaghetti code if you want (just saying, not doing..);
Apache Wicket really separate the web technologies (Javascript, HTML, etc.) from the framework technology (Java). Vaadin also try to do it, but IMO is not so elegant and transparent on that.
Appart from that, we are talking about two different types of frameworks, two different approach, which have pros and cons that I advice you to search and compare and see what really fits your needs.
Edit: Oh, and about the look and feel, for instance you always have Wicket Bootstrap

Also do notice that even though Vaadin base framework is free, for some additional functionality you might need to buy extensions.
Ex - If you need to integrate a good charting solution such as Highcharts, you'd have to pay and buy the vaadin charts extension (even though highcharts is available free for FOSS apps, the vaadin charts plugin built on that is not given free for FOSS apps).

Thank you for your question.
The answer is short and simple
Vaadin is a great tool for java developers who needs to develop web apps, but it is a powerful WAR Machine if you have moderate javascript knowledge, and some basic css skils.
Vaadin is not slow, it is even faster than React and Angular.
If your app is slow, it's because you designed it wrong, and that's true to any framework you use.
Keep in mind this, Vaadin uses web components, so most of the UI is built on the client, no heavy rendering on the server
In your case you said you don't have css knowledge, two options:
Use Vaadin, or hire frontend developer.
I am a web developer for more than 10 years, and I have started as a php developer and a javascript developer.
I can tell you that once I've got into Vaadin, I can not develop another way.

What to choose depends primarily on the business requirements (see points 2 and 4 of your question)
However, if I go the Vaadin way:
I will loose the ability to create UI declaratively.
You can try using the ZK framework - similar to Vaadin with a declarative user interface in XML

How to manage content on a Java based web site?

I am in the process of writing a Java based web site. I am trying to figure out how to manage some of the content that will appear on different pages. Obviously I don't want to hard code the content; but on the other hand I also don't feel like using a full blown CMS like Alfresco or OpenCMS since I think that it is complete overkill for my needs.
So my question to the experts out there is what is a good way to separate content from the code and maintain it independently without resorting to a large scale CMS? There has to be some sort of middle ground that allows me to change content without having to redeploy the code or go through the other extreme with some large CMS. I don't need all that workflow or versioning stuff etc. Maybe there is an open source library or API that allows you to manage content in a simple way. So what are the opinions out there?
Cheers,
Luis

Beside Tomislav interesting advivce,
You can rely upon template engine (like freemarker or velocity or stringtemplate) to have on one side your page content and on the other your page rendering. This is, in a more evolved fashion, what good old JSPs used to do. But with a twist : using these template engine, your pages can be easily loaded from XML, as an example (I know, for having used recently freemarker on a personnal project that is is quite straightforward).

Alfresco is not designed to build web sites on (although yes, you can). You could try with Daisy ("a comprehensive content management application framework") or one of the other similar solutions from the open source CMS in java directory.
In the end, you might fall back on a relational database and the web interface technology you are most familiar with. Having said that, I would expect Grails or Rails might offer the best value-for-money if you're aiming for a moderately complex web site (authentication, separate back and front end etc.).

Pros and cons of writing complete view logic of a web application in a javascript library (ExtJS)?

I am a newbie in web development using javascript libraries. But I recently saw a J2EE web application that uses ExtJS extensively (say 90%) for rendering the web pages. The web pages in question are either simple forms or grids (tabular reports). The JSPs are fairly threadbare and simply delegate to the ExtJS framework (using onReady function) which then makes AJAX calls to the server and renders the pages. There is a separate .js file for each web page that encapsulates all rendering logic within ExtJS functions.
This is the first time I am seeing an application coded this way. I would like to know if this is a common approach to use these days or is this an extreme use of a javascript library. What are some pros and cons of this design ?

Pro:
The system looks and behaves much better than with regular plain HTML
Con:
The system is hard to debug and modify if is not coded by developers with good experience on the framework.
You can mitigate that cons by using a server side library such as GWT that even can be used with Ext: GWT-Ext

Cons:
Pages won't work at all if the user
has JavaScript disabled.
The user
has to wait for the script to be
downloaded, parsed, and executed
before any content appears. Depending
on the design, the user may also have
to wait on some AJAX requests after
that.
Accessiblity is harder to implement.

My company develops RIAs like you describe as its main focus. These applications (some are in Flex, some in ExtJS) are designed to be highly functional applications for a relatively small set of people.
For ExtJS applications, our main approach is to have static HTML and JavaScript files that then build the UI on the client side (for users, they generally experience sub-second load times as everything is cached and JavaScript runtimes in newer browsers are amazingly fast). Whether it is an all-in-one 'HTML' page, or spread across multiple HTML pages depends on the app (or segment of an app).
All data is then served via AJAX requests through web services (mostly ESTful APIs). The ExtJS grid for example can be served with data with such a trivial server side component it's almost embarrassing.
All complex server side components that we write end up being complex business logic that is not suitable for the client side (or is a duplication of client side functionality for security or checking purposes).
All-in-all I am a big fan of this approach, for the right situation. I would not suggest it for public web sites - but it has a really nice niche in the business application space for example.

One advantage of a Rich Internet Application is that you free up your server(s) from the rendering responsibility, and delegate this to the clients (the browsers).
In a 3-tier architecture, you would literally take the whole presentation layer away from your hardware. You would just need to serve the static files (XHTML, CSS, JavaScript and images).

Pros and cons of Java Portlets?

I have a project in which my client is asking me to use portlets 1.0 spec and Websphere Portal Server 6.0. I haven't worked with portlets before but what I've heard of them always have been bad critiques. What are the reasons besides the obvious of using them? If not reasons, what arguments could I use to avoid them?

As someone who has had several jobs (including my current one) developing Java portlets, I'd say don't use them.
Here's the problem:
If you just wanted to use the pre-existing functionality of the portal you are choosing, then use a portal.
If your use of portlets is just to construct a small, light, primarily read-only web-based dashboard where you can quickly look at disparate information, then that's fine.
But if you (or more likely someone higher up on the org chart) thinks of portlets as a way to put a bunch of different web apps on a page and have it all "just work", then you are headed for a world of hurt. Portlets are highly-restricted, self-contained islands of functionality, not web apps in tiny squares on a page.
Every one of my portlet-based jobs has made this mistake, and there's no light at the end of the tunnel. As a portlet developer, here's a small list of things you're used to doing in regular web apps, that you can't reliably do in portlets:
Generate URLs to other pages. You'll need a vendor-specific way to do that, since the Portlet API only allows you to generate URLs that target the portlet that generated them.
Read and set HTTP headers or set the HTTP response code (so no redirects or HTTP caching, since you don't own the page your portlet will be placed on)
Having to namespace all identifiers in the generated page. This means HTML id attributes and JavaScript function names. Since the namespace has to be determined at runtime to ensure uniqueness, you can't have these Javascript functions reside in a separate browser-cachable file they have to be in the response body for your portlet.
Portlets feel as if they were designed for the state of web development as it was in the mid to late 90s (pre-AJAX). But they are ill-suited for today's web development environments (AJAX, single-page rich web apps, etc.) that assume you have complete control of the request/response cycle.

The problems I have with portlets remind me of the same problems as EJBs-
portlets require you to write special code that can only be hosted and run in a special server;
every portlet server vendor has custom extensions/configurations/additional abilities so it's not trivial to change server vendors;
portlets seem to be overly complex to cover functionality that 90% of people wanting to use it don't need
I'd suggest something like Google Gadgets as the Hibernate to portlet's EJB -
Javascript framework - server-side pieces can be written in any language, hosted on any server.
simpler to use
lots of portal servers support it, and it's more portable across vendors because it's not as complex, and it's not a spec for vendors to implement (and extend)

Portlets are attractive to a business because of the promise of flexibility, you an allow customers to tweak and rearrange components on the page, and if you are primarily serving content then they are an effective means of doing that.
In my opinion portals are well suited to aggregating portlets that are either pure content, functionally independent or simply related (e.g when you pick an item from a list in one portlet, you update another to show the details).
Portlets can also enable reuse, because you can configure them into multiple pages/locations fairly simply.
Where the problems can start is when you are trying to decompose complex business functions with multiple steps and interactions. In this scenario determining the granularity of the portlets is more of an art than a science, and careful consideration needs to be given to the interactions between the portlets.
You also need to consider the flexibility of the UI. If you have a set of portlet building blocks your business need to be clear that they can rearrange those blocks, but moving items between portlets involves a rewrite. For example moving the submit button from one portlet to the bottom of the page is not trivial.
So in summary, I guess it depends on what you are trying to do and how much reuse you anticipate of the components. It may be simpler to manage the reuse by creating technical components that IT build into servlets, or it may be that portlets are perfect for your business. There's no right answer, you just need to carefully consider what you are trying to achieve. If you do decide on portlets, you need to embrace the full lifecycle, and avoid any temptation to work around them, you can quickly find yourself in a bad place with all the overheads and restrictions of portlets, without being able to realise the advantages.