Daniel Jomphe's Library tagged web →  View Popular

I would describe the “three pillars” of jQuery this way:




• searching for elements using CSS selectors
• operations implicitly applied to all found elements
• ability to chain operations




Each of those are powerful features, but more importantly, they work beautifully together. They allow jQuery programmers to express complex manipulations of the DOM in very concise ways, without losing clarity.

Having spent a good deal of time learning my way around Prototype, I prefer it for many of the same reasons you mention.

While there are some neat plugins for Prototype out there that add in some cool things, there are definitely things that Prototype is severely lacking that need to be added to the core: Namespacing/Packing (and dependency resolution) and also a first-class unit testing construct… perhaps a thin facade over something like http://ejohn.org/blog/fireunit/

• public AddMemberPage() {  
•         add(new AddMemberForm("addMemberForm", new CompoundPropertyModel( new Member() )));  
•     }  
•   
•     public class AddMemberForm extends Form {  
•     public AddMemberForm(String id, final CompoundPropertyModel model) {  
•             super(id, model);  
•   
•             member = (Member)model.getObject();  
•   
•             add(new TextField("name"));  
•   
•             add(new Button("save"){  
•             public void onSubmit(){  
•                                 logger.info("Member name: {}", member.getName());  
•                     }  
•             });  
•      }  

•         add(new PageLink("homeLink", HomePage.class)  
•              .add(new Label("homeLabel", new ResourceModel("home"))));  
•   
•         add(new BookmarkablePageLink("addMemberLink", AddMemberPage.class)  
•             .add( new Label("addMemberLabel", new ResourceModel( "member.add" ) ) )  
•         );  

* “Shouldn’t these two frameworks merged like Struts and Webwork since both live under the same house (Apache) ?”

Won’t happen :-). Even though both frameworks look somewhat similar on the surface, the basic assumptions are not compatible. The main difference is that Tapestry provides a declarative programming model, while Wicket provides an imperative programming model (stateful programing, just like regular Java programming). Strengths of Tapestry’s declarative model are it makes for shorter code and potentially better optimization. Strengths of Wicket’s model are more control and flexibility (e.g. if you need to work with dynamic component trees).

It’s good to have both alternatives out there for people to choose, and articles like this one hopefully helps people picking out what suits them.

Wicket’s primary advantage would be in terms of dynamic component model which simplifies certain things, including Ajax operations.

Tapestry’s advantages would be scalability (less stored in the HttpSession) and productivity (due to live class reloading and other factors).