Hi Dan, Thank you for your feedback! Please check my inline answers below:
On Wed, Oct 8, 2014 at 5:21 PM, Daniel Klco <dk...@apache.org> wrote: > > 1. Performance: > > I found JSP to be roughly 10x faster in contrived tests than Sightly. I've > uploaded a package which can be run on an AEM6 instance showing the > performance difference between the JSP and Sightly text components here: > https://www.danklco.com/assets/Sightly%20Performance%20Test.zip > The Sightly foundation components from AEM 6.0 use JavaScript Use-API objects evaluated in Rhino. The Sightly JS Use provider shipped with AEM6.0 suffered from a performance hit due to the fact that Rhino seems to be slower when compiling JS objects than when evaluating them directly. In 6.0 SP1 JS Use-API objects are evaluated, which greatly reduced rendering time for components using JS Use-API objects. On my machine, with SP1, the rendering time ratio is 1:5 in favour of JSPs with your test (these rendering ratios should more or less be the same, irrespective of the CPUs we have, right?!). However some performance gains can be obtained if: 1. the Use-API objects are written in Java (and / or) 2. you configure the Use providers so that they're evaluated in the order which will most likely return a success outcome (e.g. if your Use-API objects are in the JCR repo, then it would make sense for the PojoUseProvider to run first) Now, keep in mind that Sightly is designed with the primary goal of simplifying component development. Obviously, this shouldn't come with a severe performance cost. But simplified component development means that components should be easily implemented by web developers, whose knowledge is more geared towards HTML, CSS and JavaScript. That's one of the reasons there's a JS Use-API - consider it as an enablement feature for the typical web developer. After releasing the TCK I will concentrate my efforts in improving several areas which could offer us a performance gain without requiring manual tuning or Use-objects migration. The end-goal is to have a performance ratio >= 1:2. > > > 2. Casting: > > It's somewhat concerning to me that we don't see more examples of how > casting works here. What about Dates? Longs? How would a byte[] be > handled? Additionally, the handling of booleans is very concerning. > Complicated value coersion rules for boolean logic is one of the worst > things in JavaScript in my opinion. At the very least there should be the > equivalent of === > Sightly is not a strongly typed programming language, it's a web templating language. Since JavaScript is the de-facto scripting language for the web we decided to implement its coercion rules when it comes to casting to boolean. I'll add more examples in the casting section. However, the current implementation handles casting to Strings for primitives and collections. For all objects you can call the toString method in your templates. > > 3. Extension: > > Is there an API for adding new statements or options to Sightly? I didn't > see this in the spec. > Currently we don't support adding new block elements through an API. Options could be added in any implementation without breaking the spec. However I don't think the way options are added to expressions should be part of a specification that aims to be independent of the implementation. These are more implementation-specific details. I'll make sure to document these for Sling. > > 4. Sling Integration: > > First, I'd echo the concerns of others that if this is going to be a > general-use language, Sling specific integrations should be part of a > separate integration package. Also, is there an equivalent of the Sling > Resource Access tags in Sightly? What I see this being useful for is basic > display logic where some of the properties may not be on the current > Resource. For example if you have a structure to represent a carousel like > this: > > ... > /carousel > /carousel-item-0 > /carousel-item-1 > /carousel-item-2 > > Would it be possible to loop through the carousel-item child resources and > access their properties? I think the case could be made for creating > separate components or having some external logic be executed, I was just > wondering if this would be possible. > There's no equivalent for Sling Resource Access tags - at the core of a Sightly script is the resource which was accessed. You could iterate over child resources and perform some processing in an Use-object, or, like you suggested, create separate components and include the child resources with data-sly-include. I'm really thankful for your constructive reviews. I think most of the questions will find their answers once we can build a Sling launchpad with Sightly support. Thanks, Radu
