I'm glad you asked this question. Here are my thoughts. I was never really a big Javascript fan and I used Tapestry for many years without writing a single line of Javascript. As time passed it became obvious that this Javascript thing was here to stay and the current world used jQuery so I started using the Tapestry5-jQuery library and never looked back. JQuery has documentation, plenty of widgets and since widgets have a common interface the are easily integrated with only a few lines of Java. Lastly Bootstrap is using jQuery.
Many people have pointed out the drawbacks of tying the framework to a particular Javascript framework and the choice of Prototype has made some of these fears come true but there are also benefits to picking one. 1. With things like mod_pagespeed now appearing it's not clear to me the work of optimizing page load times belongs in the framework. Since there is a common solution development time might be better spent elsewhere. 2. Abstraction layers require a lot of work and in most cases never really solve the problem. If developers are going to provide modules that have Javascript enabled components how would they be written? If they only use the abstraction layer then Tapestry will end up creating a complete Javascript framework. 3. If someone wants to include an existing jQuery component they will need the jQuery library anyway and if Tapestry really is going to head down the Bootstrap path the Bootstrap components are jQuery components. I have a large site that is not jQuery and for it backward compatibility is very important. What I would like to see is the Javascript part become a module and you just pick the one you want and go. The two javascript modules I'd like to see are the old legacy Prototype one and a Bootstrap-jQuery one. I don't see any benefit to an abstraction layer on the jQuery side. Many people know jQuery and it's well documented. Why introduce a layer that just makes things more difficult? The other feature I'd like to see is a component-path configuration that would allow all components to be used without a prefix just like the Unix shell path. This would make it easier to override existing components and use multiple component libraries. Creating the Tapestry-Bootstrap module gave me a better appreciation of how good Tapestry is. I was able to plug in a whole new gui front end that was backward compatible with existing Java code. That said there are some rough edges and inconsistencies I'd like to see fixed. I've also used GWT with Tapestry and if you really want to abstract away the Javascript layer it's the way to go. With GWT it's possible to create an entire site using only Java and you can debug both the client and server side in the same debug session. It's a very nice environment but I think a bit too far out there to become mainstream. The reason I bring it up is I think it would make a nice Javascript Module but any Javascript abstraction layer would be useless to it. Lastly from a practical standpoint I think developers are either going to build site using only Tapestry components perhaps with a bit a Javascript or pick their favorite Javascript framework and go from there. I think Tapestry should be able to provide backward compatibility for either of those options. I don't think it can deliver on a promise of being Javascript framework independent and by that I mean you can plug in any Javascript framework and the existing components just magically adapt to it. Finally there is a lot of momentum behind Bootstrap right now but it also looks like Twitter is letting it go. At this point it's difficult to know what will happen. My feeling is Tapestry with jQuery/Bootstrap would easily be the best web development framework out there. It would have a great foundation for building sites fast and provide a vast library of easily integrated Javascript components. Thanks Barry -- View this message in context: http://tapestry.1045711.n5.nabble.com/Abstract-layer-or-jquery-all-the-way-tp5717250p5717285.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
