Matt Raible lists his picks of the top web frameworks for deploying on the JVM
:
- GWT-Ext
- Wicket
- Grails
- Flex/OpenLaszlo
- Seam
- Struts 2
What I think is most interesting about this list is simply how /different/ each of these frameworks is from each other. A couple of years ago, any list of the top web frameworks would have featured a bunch of metoo-ish action-style-MVC frameworks, with maybe one or two component-style-MVC frameworks thrown in. I /could/ summarize this list by saying that the balance seems to be shifting in favor of component-oriented approaches, but I don't actually think that this is the real story here.
You see, the component frameworks listed actually have much more that is /different/ about them than they have in common. And the same is true of the two action-style frameworks.
So the real story is that there has been a whole lot of creative thinking going on in the web framework space in the last couple of years (if I recall correct, four of these six frameworks did not even exist three years ago).
For the record, I believe that /any/ of these frameworks is a good foundation for web development, and a big improvement upon what people were using a few years ago.
Now, what I'm really interested to see is what happens next. Will certain projects (for example, Seam and Grails) decide to focus their energies on problems like orchestration, state management, data access and integration, while supporting /multiple view technologies/, and leaving other projects (for example, Wicket, JSF, GWT and Flex) to focus their energy upon the view? Or will each of these projects need to grow independently into a full stack solution?
Clearly, the example of Rails shows that a single project can deliver a full stack solution and that this is attractive to many users. However, it's not clear to me that this approach is as natural in the Java world, where we are more comfortable with choice and with heterogeneous technology environments, and where we are somewhat less inclined toward hero-worship.
The strategy we want to follow with Seam is to support multiple view technologies. We don't yet have a definitive list, but the ones I'm thinking of are JSF, GWT, Flex and potentially Wicket. But we're not kidding ourselves that this is a simple task. Developing and maintaining the level of /deep integration/ that Seam has for JSF is extremely expensive.
Well said, Gavin.
Personally, I feel that the component-based + a sprinkle of action-based is the best solution. All action-based is just too much work, and all component-based just don't fit in this RESTful world. But you already knew that.
In a panel discussion, I brought up the point that the view syntax is way behind when compared to server-side components. JSF components are a great idea, and Facelets helps out a lot, but I hope sometime soon we can stop writing angled brackets to make UIs.
I would be thrilled if Seam supported another view technology, but I also don't want to be like AppFuse where we support every blade of grass in the yard (no offense Matt, I'm just saying). The seamless (or deep) integration is the motivating factor for using Seam.
I think GWT is needing a serious support in the server side, and Seam is the only application framework with chances to solving this problem. I think Seam would be the best option to implement Comet applications, because seam remoting allows JMS Messaging to send asynchronuos server messages to the browser (polling process in current implementation would be changed by Comet in a future release).
Two things: I've proposed a design for JSF 2.0 Components such that JRuby, Groovy, and other UI DSLs can co-exist within a single app. This is a step towards simplifying the concept of JSF into a pure-composite MVC solution. Secondly, I agree with Andres that while RIAs have made UIs more accessible, the data is not. RPC solutions and the archaic focus of the REST JSR is silly-- it's too limiting in facilitating RIAs. M$ has been taking steps with a 'sync' framework and Astoria-- and here the JCP is sitting on simple crap like '/customer/456' as the next big step in data communications for client/consumer applications.
Nice one. The ground was ready for a very good shake up of the Web UI frameworks. About Seam supporting multi UI: Seam developers will have to support Flex on their own. IMHO: JSF, GWT and Wicket should be separate projects with developers outside the Seam team.
Grails already supports orchestration, state management, data access and integration.
Gavin, did you know or tried ZK Framework (www.zkoss.org)?
Any comments from yours?
ZK had been well integrated with your Seam.
ZK for sophisticated applications, you could apply MVC or others. The choice is yours, not framework.
I have migrated from JSF SUN Implementation to ZK, to build Intranet Application at our banking (second largest in Mozambique).
I still building application with ZK, but now I am evaluate Wicket
I still building application with ZK, but now I am evaluating Wicket plus Seam plus Grails.
Thanks in advance,
Marcos de Sousa
Um, yes, I'm well aware of that. Which is exactly why I suggested that the Grails project might decide to focus upon these concerns. Of course, I'm sure the Grails folks have their own ideas :-)
No, I've not looked at ZK. I did not realize they had developed Seam integration. Interesting.
I think they was the to integrate Seam after be opened.
In Aug. 2, 2007, Dennis Chen, Engineer, Potix Corporation, write : www dot zkoss dot org slash smalltalks slash zkseam slash zkseam.dsp
At the forum, many people is using ZK with Seam.
Regards,
Marcos de Sousa
Server side View-Controller frameworks are becoming a thing of the past fast. I have been involved into 2 large enterprise projects within the last year and we have used for presentation YUI / EXT
Server side View-Controller frameworks are becoming a thing of the past fast. I have been involved into 2 large enterprise projects within the last year and we have used for presentation YUI, EXT, DWR completely with just a couple of standard JSPs. The apps look lean and mean and we didn't feel the slightest need to use a server-side ui framework.
I'm /deeply/ skeptical of this claim. Certainly some people are exploring other options and having some success. But, for now, server-side view technologies still rule the enterprise.
And there are excellent reasons why this architecture still has legs.
First, no-one seems to have yet succeeded in bringing a declarative programming model to the client side (though, if I understand correct, the GWT folks are working on it).
Second, it seems to me that the problem of rendering object data to a presentation format is a whole lot easier to solve on the server side. (And more efficient.)
Trying to do rendering on the client side results in a double-rendering process: first we render to XML or json or something (on the server side), and then parse that and re-render it to HTML on the client side. Why not cut out the middleman?
Certainly, the Ajax fad gave a shot in the arm to client-side view technology, but the server-side technology is catching up fast and it's now possible to create highly dynamic user interfaces without resort to client-side scripting. (At least, the developer is not exposed to the scripting language.)
What happened to Spring MVC? Spring MVC is an extremely capable web framework.
Hi Gavin,
You have to transmit something either way. HTML has to be parsed and rendered too. DWR transmits pure javascript statements and it is very fast and elegant.
This is an argument that pops up often. From my personal experience, programming UI in javascript with a good toolkit (like the excellent ExtJS) and Firebug has been a pleasure! I am looking forward to try GWT also. A good developer has nothing to fear from Javascript. In our team we had people that never programmed in JS before but managed fine.
Client side frameworks will not replace server side frameworks. You are missing the search engines. GWT applications are not enabled to support Google spiders. In the other hand, frameworks like JSF are more appropiate than GWT or ExtJS to build CRUD applications. And what about page size? What if the application is very very big? Do you think the client must download 10MB of JavaScript code?
I think Spring MVC happens to be among the old-skool action-based frameworks mentioned in the post..
Dimitris:
I think if we can work at a higher level of abstraction we will be more productive.
Gavin:
Coding business logic should take most of our time. If there is an environment ready, /completed/, integrated, a full stack one, where I can start to program business classes immediately and NOT spend time assembling frameworks and libraries, configuring everything to work together, I think it would be of great productivity. A full stack solution, if I understand it correctly, doesn't necessarily prevent swapping modules, technologies if desired, so choice would still be available.
/Disclaimer: I'm pretty new to Java EE and web dev in general./
Andres,
I am not sure what you mean that JSF is more appropriate to build a CRUD application than GWT or ExtJS. In fact, I would say just the opposite. The programming complexity on the server side is about the same for both. The view side is pretty easy with client side frameworks. I have not used Seam, but I would bet that doing a grid with paging and sorting is probably pretty easy in both JSF and client side JS.
As far as page size goes, I am working on a fairly complex ExtJS application and page size is not an issue at all once you concat and minify the page. You do not have to preload all of your Javascript for the application on the first request as some do. Remember, the browser caches Javascript links -- unlike JSF and JSP with all its whitespace glory. :)
None of the other developers on my current team had used a client side framework before, but they are now loving it.
Eric, storing DB data in JSF tables is trivial with frameworks like Seam in the backend. There is no need to know how the data is retrieved from the server. There is no need to point the table definition to explicit services. JSF has a declarative nature wich is the best option to define statical UIs, and is more IDE friendly than procedural alternatives. I think options like Ext are good for very interactive applications.
I think the statement is only true for big projects.
For small to midsize projects, rendering some JSON on the serverside and passing the URL to it to e.g. a Ext or Dojo Widget is perfectly fine.
I have been using Grails for a few weeks in my current project and the ease-of-use is just insane. Ant on top of that you can have he typical libraries like Lucene/Compass, Acegi, Quartz, Rome FeedBuilder, ... all just working.
It is so much easier to have a high test coverage, so few code to maintain, it has been a blessing to use it.
If you combine that productivity and some native JS widgets from Ext or Dojo, you can solve 90 % of the problems of a typical web project with ease.
There's nothing much to supporting Wicket as you can see in this test. It's still waiting for you to look at Gavin :-)
Which framework for which end? Which language for which end?
IMHO, the best is that I am Accustomed. Which is the better text editor? Is that you are accustomed, isn't it?!
The comparation of an framework can't be made by simple opinion from me or others, it is more complex. Must be examined step by step: in general, performance, fundamental features, limits, etc and this comparation must involve different view points students, ITs, etc, must englobe all web framework as possible.
The is to be presented in an hour, so it is not possible to be made as described here. And that presentation has an assertion from author point view.
Marcos de Sousa
Are you kidding? Sorry, you can't get off that easily.
Javascript is not to be trusted for the same reason that client-side validation alone can never be trusted. If you are putting code in front of John Q. Public, you'd better have the fear of anyone that knows how to use Firebug and Greasemonkey, keeping that thought in mind whenever you find yourself writing /any/ Javascript.
A good developer is concerned with things like security, maintainability, reliability, performance. How do you address any of these concerns adequately in a web environment without robust server-side code?