[SalesForce] Will Lightning Web Components have retrocompatibility

First off: "Lightning" is a larger (marketing) effort to rebrand existing and new Salesforce1 platform services under one shiny new umbrella. "Salesforce1 Lightning" consists of the following pieces, among others:

• Lightning Schema Builder (rebrand of Schema Builder)
• Lightning Process Builder (rebrand of Visual Workflow)
• Lightning Components (new - port of open source Aura Framework onto Salesforce1 platform)
• Lightning App Builder (new - drag and drop assembly of Lightning Components into a page)
• Lightning Connect (rebrand of "External Data Objects", which allows you to interact with external data sources that implement the OData spec as if they were regular Salesforce SObjects )

What you're asking about, though, is really Lightning Components (LC) and the Lightning App Builder (LAB).

As you've surmised, Lightning Components are essentially a rebranding of "Aura on the Platform" (AOTP), an initiative that's been going on within Salesforce for several years. Aura began as an internal initiative at Salesforce to build a scalable, component-based user interface framework, and earlier this year, Salesforce open-sourced the Aura Framework (available at http://documentation.auraframework.org/auradocs# and https://github.com/forcedotcom/aura). But as you mentioned, Salesforce1 is built using Aura Components, as are many newer components in various parts of the Salesforce UI (e.g. the Chatter Feed -- just Inspect Element on a page with the Chatter Feed or in the Service Cloud Console and you'll see Aura script libraries pulled in and attributes on elements).

Lightning Components are Aura Components --- if you go to create a new "Lightning Component", the actual markup you use is <aura:component>, and a lot of the core XML tags available from Aura, e.g. <aura:iteration>, <aura:if>, etc. are prefixed with aura and will remain that way.

Re #1) The goal of the Lightning App Builder, long term, yes, is to provide an admin-friendly way to construct apps by assembling and configuring Lightning Components.

Re #3) Lightning/Aura Components and Apps can currently be exposed in more places than just Salesforce1 --- and going forward (from what we've heard) more and more places where you can currently use Visualforce to "override" will be places you can use Lightning Components and Apps as well.

Lightning Applications are intended to be top-level, standalone entry points to distinct "apps". For example, Salesforce1 is a Lightning Application. Its Namespace Prefix is "one", and the App is called "one", thus it is available at /one/one.app , but Lightning Apps that you create can be accessed via the syntax /MY_NAMESPACE/MY_APP_NAME.app, e.g. in one of our orgs, our "Product Catalog" app is accessible via /sk_aura/ProductCatalogApp.app , and it looks something like this:

In general, Lightning Components are intended to be used to:

• extend / override portions of Salesforce's mobile (and eventually desktop) UI
• construct other Lightning Components

As of right now (Winter 15), Lightning Components can be used in the following specific ways:

• Create Tabs within Desktop or Mobile Apps. To do this, a LC must implement the force:appHostable interface. Once an LC implements this interface, it can be chosen as the content of a "Lightning Component Tab", must like Visualforce Pages can be chosen as the content of Visualforce Tabs. Then, you can add Lightning Component Tabs, like any other Tabs, to custom/standard Apps / Consoles, as well as to Salesforce1 via the "Mobile Navigation" setup.

• Override / extend portions of the Salesforce1 standard UI, via the "UI Plugins" framework. The UI Plugins framework exposes "Extension Points" where Lightning Components can be plugged-in to the standard UI. For instance, if your LC implements the force:recordTab interface, it can be added as an additional Tab / Slide within the SF1 record detail view by creating a new UiPlugin record from the Developer Console. It could look something like this:

I face similar issues in my current project. I'm trying to create a datatable implementation with columns defined by inner column components in a following matter:

    <c:datatable items="[...]" var="item">

        <c:column>

            <aura:set attribute="header">
                Column Header
            </aura:set>

           Column Body:{!item}
        </c:column>

   </c:datatable>

Now what I've discovered is that you can use Aura.componentdefref[] attribute type to define iteration template and then set this template like any other facet, using attribute:set. Please find an example below:

<aura:component>
    <aura:attribute name="template" type="Aura.componentdefref[]"></aura:attribute>
    <aura:attribute name="var" type="String" ></aura:attribute>
    <aura:attribute name="items" type="Object[]" ></aura:attribute>

    <aura:iteration items="{!v.items}" var="{!v.var}" template="{!v.template}" >
    <!-- Content doesnt matter but it cannot be empty -->
        i 
    </aura:iteration>

</aura:component>

Then you can use component like this:

<c:list var="item" items="[1,2,3,4]">
    <aura:set attribute="template">
        Test template {!item}
    </aura:set>
</c:list>

Output:

Test template 1 Test template 2 Test template 3 Test template 4

There might be way to transform component's body into a template, but I had no luck so far. I hope this information can be of any use to you. It's really hard to find any information on this matter.