>On Fri, 26 Oct 2012 10:47:35 -0200, trsvax <[hidden email]> wrote: > >> 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. > >That's an Apache module and many people don't use it.
I don't use the Apache module either, but I think the current script combining compression code is more trouble than it's worth because it does not solve any problems very well. For small sites it's easier just to have one file already compressed. For high volume sites I would use a CDN and the framework just gets in the way. In fact these days small sites should probably just use the Google CDN. https://developers.google.com/speed/libraries/devguide > >> 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. > >Nope, I don't think this is going to happen (creating a complete >JavaScript framework). Otherwise, it wouldn't be an abstraction layer. The >Java equivalent would be creating interfaces and have a jQuery >implementation of it, also a Prototype one. I don't think it's going to happen (or should happen) either which is way I don't see any benefit in trying. > >> 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. > >That's the Bob Harner's point. What you said was valid for Prototype years >ago, is valid now, but it may not be valid in the next years. Again, we >would have people complaining that Tapestry uses a JavaScript framework >that isn't the best anymore. I do think this is a valid point but with Prototype there was still an abstraction layer. It was not easy to pickup a Prototype component and just use it. jQuery is different in that respect. It's possible to easily integrate existing widgets with no Javascript and virtually no Java. In fact with some framework support I certain it could be done by just dropping a javascript file into the resources.widgets directory. The question is would it be better to have excellent support for the currently popular framework or mediocre support for none of them. I don't think this is really a backward compatibility issue because as you say the abstraction layer will not be complete enough to really shield you from the underlying Javascript framework anyway. I do think it's true that people will complain no matter what. I know I will :) > >> 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 abstraction layer would be needed for these modules to be written >without rewriting everything in jQuery and in Prototype. I don't see how a Javascript abstraction layer helps you here because I think the correct abstraction point is the Java component. Let's say you want a Calendar component. The jQuery and Prototype calendars are completely different but they can appear the same at the Tapestry component level. What does a Javascript abstraction layer bring to the table? You will still need to create two different components. > >> 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 abstraction layer is intended to be used mostly by Tapestry itself, >probably component libraries too. Your code using jQuery would work >exactly the same. Of course, people could use the abstraction layer too, >but that's up to them. I think you are correct here, the abstraction layer would be used by the framework developers and not so much by the end user. In fact I think it's actually detrimental to the module builder. For example I'm not going to create Prototype equivalents to the jQuery Bootstrap components. It's not worth my time. I suspect I'm not alone in that thinking so my question is how many Javascript frameworks will the base Tapestry framework support? If it's the legacy Prototype one and jQuery then I don't see any benefit to the framework either and I would put this in the premature optimization category. I also don't think it's possible to build an abstraction layer that encompasses some of the existing current possibilities such as GWT. In fact I know other existing frameworks present their own challenges. For example the Facebook API has it's own async script loading mechanism. The current Tapestry abstraction layer does not work with it. Will the proposed one support it? If the proposed abstraction layer cannot support popular existing frameworks it seems unlikely it will support future ones. I'm likely to continue using Tapestry whichever way it goes but I will say if my existing 5.3 site does not work in 5.4 because of Javascript abstraction layer changes it's going to be a lot of work for me to get to 5.4. Given that choice I'd rather just convert to jQuery than a different abstraction layer. > >-- >Thiago H. de Paula Figueiredo Thanks for your comments. They are insightful as always. Barry -- View this message in context: http://tapestry.1045711.n5.nabble.com/Abstract-layer-or-jquery-all-the-way-tp5717250p5717299.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]
