This week's book giveaway is in the Server-Side JavaScript and NodeJS forum.
We're giving away four copies of Modern JavaScript for the Impatient and have Cay Horstmann on-line!
See this thread for details.
Win a copy of Modern JavaScript for the Impatient this week in the Server-Side JavaScript and NodeJS forum!

Alexander Kolesnikov

author
+ Follow
since Feb 26, 2005
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alexander Kolesnikov


This is why I always urge people to get a good handle on Servlet and JSP technology before diving off into a framework. That way, they have the skills they need to decide which, if any, framework suits their own needs.



Yeah, that's true. You can pick up a frameork very quickly, but you won't go far if you don't understand how it works inside. And (almost?) all Java web frameworks are based on Servlet API.

I do agree with most of what you are writing, Bear! And where I do not agree... Well it really depends on what exactly you are doing.
[ March 05, 2008: Message edited by: Alexander Kolesnikov ]
Okay, Gregg, let's decrease the temperature. Yes, all the frameworks are good, and comparing them is an extremely difficult task. By a reasonably complex application I mean something that can keep you busy for at least a month of full-time work. I've seen just too many of "framework comparisons" made on the basis of 'hello world' applications - that doesn't make sense at all.

Also when choosing a framework, one needs to consider which kind of application is being built. You can do things with GWT or Flex that will be difficult or impossible to repeat with some other frameworks, but each tool has its limitations.
Well, Charles, obviously I cannot guarantee that Howard's ideas will not jump ahead for another decade. And definitely, if compatibility of versions is very important for your company, Tapestry is not for you.

Personally, I cannot understand, why this compatibility is so crucial, but maybe I just don't know something. Say, we have created two huge applications with Tapestry 4.1. Now, Tapestry 5 appeared at the scene. If everything goes well, I will try T5 for a small project and see how it works. I will have to support two 4.1 apps, but why should I rewrite them if they work well? They say in Russian, "the better is the enemy of the good".

Why can't I consider T4.1 as a different framework? It continues to evolve, led by Jesse Kuhnert. The good thing is that it is conceptually close to T5 and there should be no problem for me - and for everyone in the team - to support both versions. It will be probably much easier than supporting two totally different frameworks.

I just can't understand how limited compatibility of versions can overshadow the benefits of Tapestry...
Hi Paras,

Action-driven and component-based frameworks cannot be mixed together. You can integrate Tapestry with the IoC feature of Spring, not with its MVC.
Gregg, this is a difficult task. It will be extremely interesting to do such a comparison, but hardly possible. The reason is our life is too short and there are probably very few people in the world who are equally proficient in at least two of the listed frameworks.

I would understand someone writing a work and trying to find an approach towards comparing frameworks, as I did myself a few years ago. That is a kind of work that can add to our combined knowledge.

But trying to prove which framework is better at the forums, like here, is not productive. Every master thinks that his tool is the best and is ready to passionately defend it.

If the framework works for you and you are happy about it - you definitely do not need anything else, stick to it.

My aim when writing the book and when initiating this promotion was actually to increase the awareness of Tapestry. So many people for whom it would be a perfect choice cannot find it simply because it is not fashionable enough at the moment. But fashion isn't always fair or clever.

To summarize: I propose not to compare frameworks here, but to share our knowledge of them, so that everyone could choose what better suits them. From now on, I will try to write not like "Tapestry is better than X because of ..." but the most important features of Tapestry are a, b, c.

And if someone wants to compare frameworks and choose one of them, the best, or perhaps the only reasonable approach, is to try them in real work and see which one suits you best.
Yeah, thats true. Open Laszlo and Flex are fabulous, but they have their limitations too...
Well, I've read an article proving that creating JSF components is easy. To declare that it is easy is one thing, to prove that is another, and having experience of creating Tapestry components I wouldn't say that that article showed anything that was easy.

I believe that as JSF goes to next version, it will adopt more ideas from Tapestry, and Facelets is an example of how standard technology (JSF) can get rid of its standard predecessors (JSP). Look at what happened with EJB specification. I think something similar will happen with JSF - it will adopt the best solutions from open source projects, Tapestry in the first place.

JSF is less efficient because it recreates components tree each time the page is requested. Tapestry uses pooled preconfigured page classes instead, which is much better in terms of efficiency.
No, you cannot use JSF components with Tapestry, but Tapestry 5 already has quite a few third-party libraries of Ajax-like components of its own. Have a look at this page, under the 'Third Party Libraries' header. And there is also an excellent Tacos project whose version for Tapestry 5 is now being developed.

Also, Tapestry has some core Ajax-enabled components, and there will be definitely more of them.
[ March 05, 2008: Message edited by: Alexander Kolesnikov ]
Hivemind is used in Tapestry 4. Tapestry 5 comes with its own powerful IoC subsystem, but if you prefer not to use it, Tapestry can be integrated with Spring very easily and efficiently. It is easier to use Spring beans in Tapestry than in Spring itself.

To find out more, have a look here.
[ March 05, 2008: Message edited by: Alexander Kolesnikov ]
Yes, Greg, this is exactly the book that might be helpful for you. You've got an experience of JSP and you know what it takes to build a reasonably complex application using just JSP.

If you read this book (and it is not thick, only 250, and is easy to read), I am sure you will appreciate what Tapestry can do to make your work more productive and rewarding.
This discussion can be endless. Indeed, different people have different preferences, very often based on different history of experiences. I am far from thinking that I can convince an experienced Struts developer that Tapestry is superior - no way. Some years ago I had a colleague who was programming exclusively in assembler, and he was very proud of himself.

The only real test would be to build a reasonably complex application using one framework, than another, but this is not practical or even possible.

My message is to those who haven't yet chosen their framework - be aware of Tapestry, it might be exactly what you need. It is very easy to learn and a pleasure to work with.

I would also suggest to those who understand the limitations of action-based frameworks that JavaServer Faces is not the only alternative. Tapestry is a much healthier and easier solution.

I am going to my office in an hour or so and I am planning to create a couple of pretty complex and functionally rich Tapestry 4 components and put them to work in the new project. I am pretty sure I will be able to complete this work in one day, and probably will even have time left to play with new ideas. This is Tapestry. Once you worked with it, there will be no way back to any other framework, however popular it is.
[ March 05, 2008: Message edited by: Alexander Kolesnikov ]
Well, of course frameworks are not *required*. You can write absolutely any piece of software using assembler. It is all about productivity. If you are building complex webapps and denying frameworks, then I guess you are either putting together a private framework de-facto of your own, or you just have unlimited time and very few projects.

Originally posted by Gregg Bolinger:



That said I find it hard to believe that anyone doing serious web application development spends time looking at their pages outside of the app server's container.



Agreed, but still it is much simpler to convert an HTML mock up that you used to inspire your customers into a Tapestry template than into a JSP page. Plus, in Tapestry there is simply no way to mix presentation and code.

But these are details. I would say that if the application is simple, there is no difference which framework you choose. But the more complex the application is and the more applications you create, the better the benefits of Tapestry will be seen as you will have to write much less code and you can easily package repeating functionality into your own libraries of custom components.
Well, Gregg, everything I write is only my opinion and not the law, of course

I am speaking about complex highly dynamic web applications with sophisticated user interface, and I think there will be many more of them with time. If the application is blog-like, it doesn't really matter that much what you use to build it.
That's right, web frameworks are a different world from desktop applications. Totally different.