Develop Reference

I want to make a "Web 2.0" application without using JavaScript directly

I'm a full time Java developer of around 4 years, professionally. I'm a GWT fanatic. I love Java. Here's the problem: In my free time I often fall victim to the verbosity of my favorite tools for doing "heavy" development. I also often fall into the trap of obsessively engineering my software. I'll end up with the most beautiful unfinished implementation, ever.
So, here's what I normally work with.
GWT - I use this for dynamic UI and web layout. I love the ease of re-use and it has taught me to absolutely hate javascript. I really can't even bring myself to do much HTML/JS anymore.
Hibernate - POJO to Database, easy-peasy. What i really need from this other than the mapping is that it allows me to have an application that works across multiple databases.
Spring - Mostly security. I've written my own custom LDAP bits for a project.
XML - I've used dom4j and other implementations, including xstreamer. I'd like to use JiBX for XML transport. The problem with this is that I need XML messages that conform to a specific standard rather than being autogenerated. Object->XML->Object are also common enough that it can be a performance bottleneck with large messages (250KB+).
I tried Lombok for a little while and liked it but had occasional issues with it and then I blew up a partition and lost all that work. I don't really feel like doing the same thing again (half the fun was in learning how to do it, now that I know... meh). This taught me why other people want to reduce the explicit code and replace it with an implicit system.
I've been looking into Grails but that runs me into the JavaScript problem (you know, that I don't like it) pretty quickly. I could use GWT with Grails on the back end but I get back into the problem of getting deep in the weeds with GWT. It has also occurred to me that there might be a way to have Grails tags in GSP that are made up of GWT widgets. I'm not really sure how I feel about that.
Another problem I have with Grails is that validation logic before form submission is separated from validation constraints after submission. I don't see how they can be unified (yet) to produce "pretty" front-end validation. I went out of my way to start a JSR-303 compliant validation project for GWT to help solve some of this problem for GWT and really liked the results. It isn't finished but I still find it useful.
So, help me find a better way!
TL;DR - I want to have a Database (and Database-Independent) to GUI solution that allows for dynamic web programming all in one language. Failing that, as close to one language as possible.
TL;DR is TL;DR - I hate JavaScript now, help.
EDIT: I know that it is techincally impossible to do "Web 2.0" development without JavaScript. I'm just trying to not be the guy who has to write it. (Getting a tool such as GWT to do it for me from a language I do like, for example.)

Just learn JavaScript.
Resistance is Futile
...and you will be assimilated.
PD: I'm an ex JavaScript enemy. Now it's my favourite language.

You can certainly develop an entire Web 2.0 project without coding Javascript using GWT (we have), but at the end of the day you still have to know HTML/CSS & Javascript.
This might sound like a stupid statement, but it's not once you consider that GWT is not a perfect abstraction, nor is it designed to be. It wasn't written in Java so that you didn't have to ever code in Javascript again, instead they did it because Java has better IDE's, is statically typed and makes maintenance a hell of a lot easier.
So yes, by all means go with GWT (and check out the new OOPHM, because it's AWESOME) but don't forget that you'll always need an understanding of the underlying frameworks of the web, if you want to develop for the web.

Have you heard of Echo?
It doesn't provide the database part of the problem, but it would work well with any database that you can work well with.
Echo is a platform for building
web-based applications that approach
the capabilities of rich clients. The
applications are developed using a
component-oriented and event-driven
API, eliminating the need to deal with
the "page-based" nature of browsers.
To the developer, Echo works just like
a user interface toolkit.
The latest iteration, Echo3, features
the ability to write applications in
either server-side Java or client-side
JavaScript. Server-side applications
run in any Java Servlet Container and
do not require developer knowledge of
HTML, HTTP, or JavaScript.

You might want to take a look at some of the AJAX powered JSF libraries. IceFaces and RichFaces are both solid.

Been there, done that. I was a GWT developer for 3 years... I started using it in v1.1! GWT is fantastic, and works really well for small applications. But the development comes to a crawl once you it a moderate application size, even if you divide your application in sub-modules.
It is also quite ironic that a UI framework has such limited UI creation tools. :)
Personally I bit the bullet and learned javascript. It isn't as bad as I thought. Especially with jQuery. :)
Obviously there is no perfect framework. But just the fact that GWT has been out for 3.5 years now, and it still largerly ignored in the Java world should tell you something. Since you're doing this on your free time, I would recommend learning the most popular framework: Struts. You'll see its limitation, and also why it is so popular. Of course, you'll need jQuery for that 2.0 functionalities. :)

Take a look at JRapid, a rapid development platform for Java developers. It generates very powerful Ajax enabled UI without the need of coding.

Not sure if you would like this , but have you heard about Haxe?
You might not like it but its AIO (all in one) solution (sort of).

I can understand your dislike of JavaScript and it certainly has its problems but I think your fighting nature at this point.
Web 2.0 is strongly based on JavaScript for a good reason as it provides the ability to perform tasks on the client machine without requiring page loads.
I'm sure there are alternatives but if you want the look and feel of Web 2.0, you will end up doing a lot more work with little reward. JavaScript is the accepted and functional tool for the job.

I'd say stick with GWT and just drink more of the Koolaid. It's a completely awesome development model that seems to be lost on those who haven't tried it.
If you want to improve your GWT experience, jump to the bleeding edge (I work off trunk, it's quite stable) and use the other Google originated projects like GIN, gwt-incubator and Guice. Especially watch Ray Ryan's GWT best-practices Google I/O talk: http://www.youtube.com/watch?v=PDuhR18-EdM
As for the "framework" part: forget 'em. Just use normal servlets and let GWT take care of the RPC for you. Servlets are a pain when you have to deal with JSP and you're own AJAX calls, but when they're only implementing asynchronous app logic, it's not that bad at all. Guice Servlet makes it all quite easy. You can still use a JVM hosted language to write your servlets if you want.
GWT has an incredible advantage over other JavaScript frameworks in that the layer of abstraction it provides allows for major future advances without any changes to your code. If the GWT compiler and browser detection scripts can take advantage of new browser features then you benefit from a simple recompile.
The big annoyance I see in your requirements in XML... hopefully that's just for integration with a 3rd party service and your client-server communication can just be GWT-RPC.

I don't use javascript or ajax, in medium-large application they create a lot of problem with compatibility, because moving some part of code inside client, create security breaches and problem with different browser.
I use only HTML(5) and CSS2/CSS3, and I have a lot successes.
I use this 2 ways:
using "puzzle-techinque". Write a lot of small and simple template (or tiles) to create the big page. I use only JSTL and Spring tag, with Rich/Prime/Ice-faces I encountered a lot of problem with rendering, page building and flow controller, so I discarded them.
using my custom library to parse HTML pages. I create template with my custom grammar, put inside the parser and write on output stream. This is the best way.
If you say me your preferred language and context, I can help you to perform JS-free.

Making life better by not using Java web frameworks? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm so tired of having to learn yet another Java web framework every other day.
JSP, Struts, Wicket, JSF, JBoss Seam, Spring MVC to name just a few - all this countless frameworks out there try to address the same issues. However, none of them really solves the fundamental problems - that's why there are still coming up more and more new ones all the time.
Most do look very bright and shiny on the first impression because they simplify doing simple things.
But as soon as it comes to the implementation of a real world use case one is running into problems.
Often the frameworks don't provide any help but are hindering one and limiting the options by forcing things to be implemented according to the frameworks own logic and environment.
In short, I see the following disadvantages when using a framework:
There mostly is a steep learning curve and you first need to understand sometimes quite academic concepts and know meaning and location of a bunch of configuration files before you can get started.
The documentation usually is more or less awful, either missing a public accessible online reference, is helpless outdated, confuses different incompatible versions or all of this together and often doesn't provide any helpful examples.
The framework consist of zillions of classes which makes it practically impossible to understand the intended use only by browsing the sources.
Therefore you need to buy some "XYZ in action for dummies in 21 days" kind of books which have a bad user interface because they are missing a full text search and are heavy to carry around.
To really use one of this frameworks you need to learn by heart how things can be done the way the framework requires it by remembering the adequate classes and method names until your head is full of stupid and useless information you can't use for anything else.
There is a big overhead, slowing down your applications performance and making your brain feeling numb when try to understand what really is going on.
In the real world there is usually no time to get well familiar with something new because of the pressure of being productive. As a consequence of this learning by doing approach one always looks only for the fastest way to get the next task done rather than really understanding the new tool and it's possibilities.
The argument that following a standard would allow people who are new to a project to quickly get started is not valid in my view because every project uses a different framework even within the same company (at least in my case).
It seems to me that the following quote from Albert Einstein fits here very well:
“We can't solve problems by using the same kind of thinking we used when we created them.”
Back in my good old PHP coding days when coding still was fun and productive, I used to write my own frameworks for most things and just copy-pasted and adopted them from one project to the next.
This approach paid out very well, resulting in fast development, no overhead at all and a framework which actually was mightier than most Java frameworks out there but with only a few hundred lines of code in a single file plus some simple mod_rewrite rules.
This certainly wasn't solving all problems of web development, but it was simple, fast and straight to the point.
While perfectly adjusted to the requirements of the current project, it also was easy expandable and had a very high performance due to zero overhead.
So why all that hassle with using this frameworks, why not throwing them all away and going back to the roots?
What should I say to my boss when we're starting tomorrow the next project with a new framework again?
Or are there maybe frameworks which really make a difference?
Or some hidden advantages I have ignored?

Back in my good old PHP coding days
when coding still was fun and
productive, I used to write my own
frameworks for most things and just
copy-pasted and adopted them from one
project to the next. This approach
paid out very well, resulting in fast
development, no overhead at all and a
framework which actually was mightier
than most Java frameworks out there
Forgive me for believing that not one second.
but with only a few hundred lines of
code in a single file plus some simple
mod_rewrite rules. This certainly
wasn't solving all problems of web
development, but it was simple, fast
and straight to the point.
So basically you developed your own framework over the course of months or years, tailored to your own needs, and could work very fast with it because you knew it intimately.
And yet you can't understand why others do the same and then try to turn the result into something useable by everyone?
Where's this great framework you developed? If it's so powerful and easy to use, where are the dedicated communities, thousands of users and hundreds of sites developed with it?
every project uses a different
framework even within the same company
(at least in my case)
Well, that's your problem right there. Why would you throw away the expertise gained with each framework after each project?
The idea is to choose one framework and stick with it over multiple projects so that you get proficient in it. You have to invest some time to learn the framework, and then it saves you time by allowing you to work on a higher level.

The problem with coming up with your own framework is that you will make all of the same mistakes that all of the established frameworks have already stumbled on and addressed. This is true particularly when it comes to security.
Just ask Jeff and the guys about what they had to consider when implementing the WMD in stack overflow. I'd rather use what they have produced in a project rather than implement it from scratch. That is just one example.

Here is a quote from Kev from the thread What’s your most controversial programming opinion? which fit's in here really well:
I think that the whole "Enterprise" frameworks thing is smoke and mirrors. J2EE, .NET, the majority of the Apache frameworks and most abstractions to manage such things create far more complexity than they solve.
Take any regular Java or .NET OMR, or any supposedly modern MVC framework for either which does "magic" to solve tedious, simple tasks. You end up writing huge amounts of ugly XML boilerplate that is difficult to validate and write quickly. You have massive APIs where half of those are just to integrate the work of the other APIs, interfaces that are impossible to recycle, and abstract classes that are needed only to overcome the inflexibility of Java and C#. We simply don't need most of that.
How about all the different application servers with their own darned descriptor syntax, the overly complex database and groupware products?
The point of this is not that complexity==bad, it's that unnecessary complexity==bad. I've worked in massive enterprise installations where some of it was necessary, but even in most cases a few home-grown scripts and a simple web frontend is all that's needed to solve most use cases.
I'd try to replace all of these enterprisey apps with simple web frameworks, open source DBs, and trivial programming constructs.

The problem is of course not just with Java frameworks. I've lost count of the number of C++ MFC projects I've seen floundering around trying to shoe-horn their requirements into the Document/View model (which really only workks for text and graphic editors - database applications are particularly difficult to shoehorn).
The secret of succesful framework use is to change your application to match the framework, not the other way around. If you can't do that, don't even think of using the framework - it will end up being more work than if you had written the app from scratch with the help of some good, reliable and well-documented utility libraries.

So are you saying we should deal in sockets and HTTP every time we want to build a web application!
The servlet container itself can be considered a framework, since it handles all these messy details, and leaves you to write much simpler Servlets/Filters/Listeners (ie: 'extensions' of the framework specific to your application).
All any framework tries to do is separate mundane, repeatable, error-prone, legwork code from the fun application-specific code.
However, for a small application, you can get away with simply having a Model 2 MVC approach which uses only JSPs and Servlets.
Example:
class MyController extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ... {
MyBean model = // do something
request.setAttribute("model", model);
request.getRequestDispatcher("/view.jsp").forward(request, response);
}
}
Then as your app becomes more sophisticated, you could look at using Spring MVC to provide looser coupling (and hence more flexible) of controllers, view resolvers etc..

I share your pain when confronted with yet another framework that doesn't do the trick.
Having survived ten years of jsp, struts, EJB, EJB2, struts2, jsf and now more recently all the new web services framworks, the xslt horrors and wsdl-first nightmares, I am definitely fed up.
There is a number of problems with frameworks. They leak so you have to learn more -not less, inhouse frameworks have huge costs, using external frameworks costs too (but much less), as they seldom deliver, and then you end up writing enourmus chunks of xml-configuration and spend days correcting case and spelling errors that you had seen immediately in your favorite content helping code editor.
Maybe the answer is to find less pompous toolkits that tries to solve a problem but not redefine the world, but that is hard too as the fundamental application model (html over http) is awkward - at best.
Add the fact that there seems to be a lot of complicators around, people that seems to be obsessed of trading boring simple problems to complex (but hard) interresting problems ( maybe a variant of Eric Sink’s Axiom of Software Development mentioned above.)
Add the hubris of developers that knows it all and do not hesitate to write a new framework to solve all the hard problems for you, Only that they can't, leaving 10% left, only much harder to fix now.
I have no .NET experience, but the .NET world seems to be less crowded with theorists and complicators, and maybe the lingering stink of VB is scaring them off, but everytime I hear someone telling me that they have spent 1500 hours on their maven config (hello?), I am seriously considering deleting "java" from my resume.
...what was the question again? Are there any frameworks that make a difference?
EDIT - added Stripes and QueryDSL.
I would try Stripes or GWT with QueryDSL + Hibernate or OpenJPA (with annotations) just for the fact that you actually develop in Java, and try to limit the use of wsdl-first web-services, xml-centric frameworks, EJB and ESBs (not the beer) as much as possible.

I once had to work on a project trying to implement it in JSF. It was a nightmare.
Most of the working time was spent to just making things compile. The fact that no less than half of what was compiled didn't work was another story. Almost no tutorials. Documentation is basically an automated source code export with no human comments. How can one be expected to work like this?
Of several frameworks we'd seen only Sun's was able to create a new project that is compilable at all! The other could only produce bunch of stuff it took many days to ring to a compilable state.
The web was almost silent. To any search there we no more than 20 pages of search results, with useful first 1-3. In that relevant what was found, a half of people was crying for help, the other half declared they had cried for help, noone came, they lost time and interest and dropped that technology.
So we spent times and only made something simple that could have been done in a few weeks with ASP.NET for example.
Then we looked at alternative JSF frameworks. To our surprise we found them all quite incompatible.
With not surprise at all, we joined the ranks of those who dropped JSF as well.

Consider the counter point. I am working at a shop right now that doesn't use any frameworks beyond the JSP standard. Everyone has a different way of doing things and we are very lax about concepts like de-coupling and security concerns like validation.
While I don't think use of frameworks automatically makes you a better coder, I do think by using a standard design pattern implemented by most frameworks and by having easy access to utility functions like validation, I think the chances are you are going to be forced to code up to a certain standard.
In web application design you aren't inventing the wheel every time, so you either end up rolling your own solution to common tasks, or using a framework. I make the assumption that by using a commonly used framework rather then roll your own, you are going to get underlying code that is well tested and flexible.
There is nothing wrong with rolling your own solution as an academic pursuit but I accept that there are people out there putting a lot more time into a robust solution then I may be able to spend. Take log4j for example, pretty easy to roll your logger, but log4j is well tested and maintained and they have taken the time to improve on flexibility and performance to a degree that most roll your own loggers can't touch. The end result is a framework that is robust but also simple enough to use in even the most basic applications.

What worked for me is: you shouldn't just learn any web framework you hear about, take a look at it, see if it makes you code comfortably, ask around stackoverflow or forums to see its advantages and disadvantages, then learn it and learn it good and just stick with it until you feel its broken or plain outdated. Any of the webframeworks you wrote about is good by itself and a fun to work with if you "REALLY" know what it does. if you don't you are just wandering in a desert with no compass! I've also found the 21 days book is a sure way for you NOT to master a framework or a technology. Docs is surely something to consider while adopting a f/w it also helps if you look around the code yourself (actually this is what helps me the best when I faced with some behavior that I find wierd.
1-So why all that hassle with using this frameworks, why not throwing them all away and going back to the roots?
if you go back to the roots you rewrite code that does the same thing again and again + most of these f/ws being open source means they are probably better off with maintenance than you would do alone to your own f/w.
2-What should I say to my boss when we're starting tomorrow the next project with a new framework again?
this is my first time working with this f/w I don't see why should we use this f/w I already know X and I am really good at it. bare in mind the cost of me learning this f/w, the cost of rework that has to be done due to my ignorance of such a f/w. I think we are better off using X, if this is a specific requirement we should fight for it and only do it if we really have to stating the previous notes.
Or are there maybe frameworks which really make a difference?
only those who address the way you think not the way you write code (think struts at its golden age enforcing the MVC pattern).
Or some hidden advantages I have ignored?
can't think of any tbh.

You have the same problem in PHP: more frameworks than you have fingers to count them on, each being the best and greatest (although you have some hints: pure PHP5 design vs. PHP4 compatibility, Rails philosophy (inflexible folder hierarchy, auto-generated code) vs. library approach...) and you spend more time searching and exploring the possibilities than writing your code!
But in PHP it allows to pre-solve common problems, like I18N support, integration of plugins, management of sessions and authentication, database abstraction, templates, Ajax support, etc. Avoiding to re-invent the wheel on each project, and to fall in common traps for newbies.
Of course, there are some hints for Java frameworks too: big or small? well documented or not? widely used or confidential? for XML fans or not? Etc.
I suppose most frameworks aim at large projects, where learning time isn't a big problem, scalability and ease of deployment are important, etc. They are probably overkill for small projects.
There is also a trend in such frameworks to aim at doing a consistent set of loosely coupled libraries rather a monolithic framework. That's the case, in the PHP world, for the Zend framework (some even deny the usage of word 'framework'...).
So it solves the issue of "resolving common problems" without getting in the way.

So you think it's better if we all invent the wheel in every project?
You might see an excess of frameworks as a problem, and it does make it harder to choose your own set. But on the other hand, you don't have to try each one; and even if you do, you'll end up preferring some of them. You will have a favorite framework for ORM, another for web development, IoC, etc.
It does help to read up on some forums to learn which are the most popular ones; they must be popular for a reason, and even if it's not the right reason (like being technically superior, maybe it's popular just among managers because of the buzzword overload or whatever), knowledge of said framework will be helpful because you will be able to participate in several projects that use it.
Plus, using a framework instead of writing your own will save you a lot of problems. Bugs are not always found and solved by the authors; that's often done by users of the framework. You said you ended up with your own private framework in PHP; I bet it wasn't bug-free, but maybe you didn't know it since you were the only user and the only coder.

However I disagree on some points that you have mentioned but I agree with you regarding the boring work.
Yes all web applications are about pages displaying forms, collecting data, making validation, sending the data for storage in Database, and filtering the stored data by search forms and displaying the result in tables and selecting one or more records for manipulation (CRUD, or business actions that all about changing status in database).
however I'm working for just 4 years plus of course my 4 years academic study.
I feel this type of development is boring as you are not inventing algorithms, off course you got happy when you discover new framework and will be happier if you integrated one of the AI engines into your application, but at the end I feel that this work is dummy works, or lets say machine work, so why we don't automate all of this stuff.
yes another framework ;)
MDA Model Driven Architecture, in brief is about transforming from PIM (Platform Independent Model) to PSM (Platform Specific Model), i.e for example from UML to Code.
And this may solves your problem of learning curve and technology changes as you will only need to be good at modeling, as there are some frameworks that implements the MDA specs such as AndroMDA as it have cartridges that take the Class Diagrams, Use cases, Sequence Diagrams, and Activity Diagrams and generate Database creation script, POJOs, hibernate mapping, Spring/EJB, JSF/Struts, .NET code.
Off course such frameworks will not generate 100% of the code but will generate a big percent, and off course you will ask whither this framework will solve complex and tricky scenarios of requirements? today I will say no, tomorrow yes.
so why you and I don't invest in the development of this great framework.

Pros and Cons of Various Java Web Presentation Layer Technologies

I'm currently working on a web app that makes heavy use of JSF and IceFaces. We've had some discussions of moving to another presentation layer, and I thought I'd take the discussion out into SO and see what the experts think.
I'm curious if anyone could weigh in on the pros and cons of the various Java presentation layer technologies. If you've only worked with one, say why you love it or hate it. If you've worked with several, give your impressions of how they stack up against each other.
Our technologies under consideration are:
IceFaces
JSF (without IceFaces)
GWT (Google Web Toolkit)
Wicket
Tapestry
And if I'm missing anything from my list, let me know.
Thanks!

My opinions are quite heavily biased towards Wicket because I've been using it for a while after tripping over JSP mines far too many times.
Wicket PROs:
True separation of layout and code.
Component based which means high reusability of site elements; For example you can create prettified form with automatic labeling and CSS styles and everything and just by changing it's DAO object in the component's constructor it's completely reusable in another project.
Excellent support for things like Ajax, Portlets and various frameworks in general directly out-of-the-box AND more importantly it doesn't rely on anything else than slf4j/log4j to work, everything's optional!
Wicket CONs:
Development has some confusion about things in general and Wicket generics are a bit of a mess right now although they've been cleaned a lot in 1.4
Some components (like Form.onSubmit()) require extensive subclassing or anonymous method overriding for injecting behaviour easily. This is partly due to Wicket's powerful event-based design but unfortunately it also means it's easy to make a code mess with Wicket.
Random CONs: (that is, I haven't used but these are my opionions and/or things I've heard)
GWT is JavaScript based which sounds stupid to me. Main issue is that it reminds me too much of JSP:s and its autogenerated classes which are horrible.
Tapestry doesn't separate markup and code properly in a manner which could be easily validated between the two which will cause problems in the future.

I've used GWT for a couple small projects. Here are some things I like about it:
It's ajax by default, so I didn't have to make it do ajax, it just came along with using GWT.
It's got good separation of client versus server-side code.
I can unit-test my client code using junit
It lets you built crisp, snappy apps, largely because it's ajax.
Things I don't like:
Some things don't work as expected. For example, I've seen cases where click events didn't fire as expected, so I had to do a workaround.
Auto-deploy to tomcat running in eclipse sometimes just stops working, and I could never figure out why.

The biggest question I'd ask is why are you changing presentation layer? That's a very expensive cost and I can see the benefits of one technology outweighing the others by as much as the cost to change...

In short:
= JSF =
PROS:
component architecture;
many libraries & tools;
somewhat good IDE support
CONS:
heavy weight, both in CPU/memory and learning curve;
when something doesn't work as expected, it's difficult to debug
= WICKET =
PROS:
lightweight;
sensible templating system;
good tutorials;
CONS:
reference documentation is not so well organized and deep as are the tutorials;
development team had some serious difficulties, especially when becoming and incubated project. This lead to confusion on important aspects of the framework, at that time I had to switch to another framework because of this...

What about Stripes?

My pick would be Wicket. Have used it and is gives excellent re-usability. It has one of the most vibrant forum/mailing list. As a question and its gonna be answered in minutes. It has excellent support for AJAX. One of the usual cons attributed to Wicket is the steep learning curve. Well those were one of the old age cons which hold no value anymore now.
JSF: Better stay away from it. Another team which developed a project on JSF is now thinking to shift to Wicket after our success with it.
#Megadix: Like you said the documentation was poor in the beginning, but not any more. There is an excellent book called Wicket in Action written by the developers of Wicket. The sample code provided on the site is also a good place to start and learn

I'd wonder if you a have a service layer that's distinct from the web client, something that the web controllers simply invoke to get their work done.
If you do, the choice of web UI technology can be decoupled from the back end. If it's exposed as a contract first web service, you can have different apps share it. As long as your clients can send and receive XML they can interact with your services. Want to switch to Flex? No worries - point it at the service and render the XML response.

See my comparison of Wicket and Tapestry 5: Difference between Apache Tapestry and Apache Wicket.

Are Java web frameworks really worth the hassle?

I'm relatively new to Java programming (About 2 years) but not to web development. I started out with HTML and ASP (pre .NET), and have recently started messing with J2EE. I feel like I have a good grasp of JSP/Servlets (I find them to be similar to ASP) and have recently begun working with JSF and Facelets. Although I can see why people would like JSF, I find it to be a huge burden and it's actually slowing my development times down. I imagine this is due to the learning curve, but I often find myself thinking that I would be finished with a page/task if I were just using JSP/Servlets.
Is this common to those of you who have taken the time to learn a framework? Have you ever invested time into learning a framework and once you were proficient in it, just decided to go back to a method that wasn't as sophisticated but you felt comfortable with?
I'm also questioning whether I've chosen the right framework. I was really hoping to find something that didn't interfere with adding AJAX capabilities.

JSF can be tricky to get started with, and is harder to learn than many Java web frameworks. You might find it easier to use JSF with Seam, which simplifies much of how you work with JSF, and replaces JSP with Facelets, which is a great improvement.
Alternatively, you could try SpringMVC, which lots of people find easier to use.

I've been using facelets for a little over a year. One of the main advantages I see in Java web frameworks is that it helps to keep the code clean and promotes re-use. For instance, in facelets, you don't get any scriptlets in your pages like you do in JSP. I've seen ASP files in production that are over 3000 lines long. There's nothing inherently wrong with ASP or JSP, but it does make it quite easy to lump some business logic in the page. No harm, right? Until someone else has to maintain it.
Most frameworks try to 'help' you keep a more strict separation of MVC or whatever model they favor, which in turn leads to cleaner templates ( jsp, facelets, whatever ) and business and domain code that is automatically unit testable. Using many of the frameworks can take a bit more time up front, but save you many times that when it comes to maintenance and refactoring.

I think the easy answer is - how will you test it and verify it works when you make changes?
This is where the easy solutions breaks down, and you end up in maintainance hell. Unfortunately :(

I think this depends on whether the framework genuinely solves a "difficult problem" for you, and solves it easily. People always find this a terribly controversial thing to say for some reason, but most of the frameworks I've considered using I've ending up ditching halfway through because it's just easier to Write Some Code to do exactly what I want.
Later, when I have a problem in my code, I can just go to where the problem is and add a line of code to fix it, rather than wading through pages of documentation to find the magic configuration parameter. If I have a problem with (insert favourite framework), I generally find I'm p*ssing around for ages when the underlying problem that the framework is supposed to be solving was never that complicated in the first place.
My favourite useless frameworks are ones that require lots of configuration and clumsy boilerplate code to do basic tasks such as sending some bytes down a socket or stuffing some parameters into a prepared statement and firing it off to a database. Another of my favourites are the whole raft of "XML technologies", especially ones that are "pluggable" or "configurable". (Why do I want a "pluggable parser framework" rather than just one parser that always works...?) Call me Victor Meldrew, but it's amazing how people can turn a 10-minute regular expression problem into a 2-day how-do-you-make-this-framework-with-X-in-the-title-do-it problem.
Now that said, there are people who absolutely thrive on Spring, Hibernate, JSF, MVCJammer, Joomajamaventilate, things with 'X' in them etc etc. So clearly for some people in some situations, they're a miracle, and I'm just missing out in life.
Possibly it depends on whether you or your organisation primarily have "configuration" and "plugging things together" expertese or "programming" expertese? I suppose I have more of the latter.

My advice: get comfortable with lots of different frameworks, and know how to get your hands dirty and write it yourself, too. You'll develop some favorite ways to work, but you'll get a good understanding for what the tools can do, and what they can't. And you'll also develop an eye for when is the right time to use a framework, and when is the right time not to.
I've found that JSF and Facelets are definitely worth the hassle, if you can survive the learning curve. It's pretty steep, but when you figure it out, it's very easy to work with. They make managing session and application scope objects much easier to deal with than just raw JSP and servlets, and I've found that I can write cleaner Java when I don't have to think about the web in the business logic. In general, I find that the frameworks help me to organize my thoughts (and by extension, my code) in a consistent, easy to understand way.
Facelets, in particular, is my favorite web template engine. I love the fact that my pages are valid XML, and that I don't have scriptlets all over the place. It makes the code much cleaner and easier to follow if you know the framework. There's that learning curve again.
By the way, adding AJAX to Facelets is easy if you use something like RichFaces or IceFaces. They have pre-built ajax components that you can easily add to your application.
That said, it's not the best for all projects, YMMV, and so on. At the end of the day, using any framework is a judgment call. If it's not helping you solve your problem, then it's not worth it. Don't fight with your tools, use them correctly. If the tool is in your way, use a different tool. JSF and facelets are really not very good choices on a very small application. They don't really come into their own until you have a fairly complex domain model and complex business logic. Basically, you need the project to be complicated enough to overcome the amount of boilerplate code you need to write to get going.

I second SpringMVC. It's very easy to comprehend, and the code is very semantic if you use annotations. Like those Budweiser commercials...Servlets is too light...Struts is too heavy.
I wish Java had Scaffolding. It can with Grails, but that's another framework to embed within a framework.

SpringMVC is worth the hassle. J2EE is not.

How can I port a legacy Java/J2EE website to a modern scripting language (PHP,Python/Django, etc)?

I want to move a legacy Java web application (J2EE) to a scripting language - any scripting language - in order to improve programming efficiency.
What is the easiest way to do this? Are there any automated tools that can convert the bulk of the business logic?

Here's what you have to do.
First, be sure you can walk before you run. Build something simple, possibly tangentially related to your main project.
DO NOT build a piece of the final project and hope it will "evolve" into the final project. This never works out well. Why? You'll make dumb mistakes. But you can't delete or rework them because you're supposed to evolve that mistake into the final project.
Next, pick a a framework. What? Second? Yes. Second. Until you actually do something with some scripting languages and frameworks, you have no real useful concept of what you're doing. Once you've built something, you now have an informed opinion.
"Wait," you say. "To do step 1 I had to pick a framework." True. Step 1, however, contains decisions you're allowed to revoke. Pick the wrong framework for step 1 has no long-term bad effects. It was just learning.
Third, with your strategic framework, and some experience, break down your existing site into pieces you can build with your new framework. Prioritize those pieces from most important to least important.
DO NOT plan the entire conversion as one massive project. It never works. It makes a big job more complex than necessary.
We'll use Django as the example framework. You'll have templates, view functions, model definitions, URL mapping and other details.
For each build, do the following:
Convert your existing model to a Django model. This won't ever fit your legacy SQL. You'll have to rethink your model, fix old mistakes, correct old bugs that you've always wanted to correct.
Write unit tests.
Build a conversion utility to export old data and import into the new model.
Build Django admin pages to touch and feel the new data.
Pick representative pages and rework them into the appropriate templates. You might make use of some legacy JSP pages. However, don't waste too much time with this. Use the HTML to create Django templates.
Plan your URL's and view functions. Sometimes, these view functions will leverage legacy action classes. Don't "convert". Rewrite from scratch. Use your new language and framework.
The only thing that's worth preserving is the data and the operational concept. Don't try to preserve or convert the code. It's misleading. You might convert unittests from JUnit to Python unittest.
I gave this advice a few months ago. I had to do some coaching and review during the processing. The revised site is up and running. No conversion from the old technology; they did the suggested rewrite from scratch. Developer happy. Site works well.

If you already have a large amount of business logic implemented in Java, then I see two possibilities for you.
The first is to use a high level language that runs within the JVM and has a web framework, such as Groovy/Grails or JRuby and Rails. This allows you to directly leverage all of the business logic you've implemented in Java without having to re-architect the entire site. You should be able to take advantage of the framework's improved productivity with respect to the web development and still leverage your existing business logic.
An alternative approach is to turn your business logic layer into a set of services available over a standard RPC mechanisim - REST, SOAP, XML-RPC or some other simple XML (YAML or JSON) over HTTP protocol (see also DWR) so that the front end can make these RPC calls to your business logic.
The first approach, using a high level language on the JVM is probably less re-architecture than the second.
If your goal is a complete migration off of Java, then either of these approaches allow you to do so in smaller steps - you may find that this kind of hybrid is better than whole sale deprecation - the JVM has a lot of libraries and integrates well into a lot of other systems.

Using an automated tool to "port" the web application will almost certainly guarantee that future programming efficiency will be minimised -- not improved.
A good scripting language can help programming efficiency when used by good programmers who understand good coding practices in that language. Automated tools are usually not designed to output code that is elegent or well-written, only code that works.
You'll only get an improvement in programming efficiency after you've put in the effort to re-implement the web app -- which, due to the time required for the reimplementation, may or may not result in an improvement overall.

A lot of the recommendations being given here are assuming you -- and just you -- are doing a full rewrite of the application. This is probably not the case, and it changes the answer quite a bit
If you've already got J2EE kicking around, the correct answer is Grails. It simply is: you probably already have Hibernate and Spring kicking around, and you're going to want the ability to flip back and forth between your old code and your new with a minimum amount of pain. That's exactly Groovy's forte, and it is even smoother than JRuby in this regards.
Also, if you've already got a J2EE app kicking around, you've already got Java developers kicking around. In that case, learning Groovy is like falling off a ladder -- literally. With the exception of anonymous inner classes, Groovy is a pure superset of Java, which means that you can write Java code, call it Groovy, and be done with it. As you become increasingly comfortable with the nicities of Groovy, you can integrate them into your Java-ish Groovy code. Before too long, you'll be writing very Groovy code, and not even really have realized the transition.