I was under the assumption that the apps built in both the Lightning app builder and the Developer Console are the same except that one is visual drag & drop and the other one is via hands on coding..

but seems they are way different.. not even closer..

here's the differences I've noticed so far..

  1. what we build in App builder is called a Lightning Page (Flexi Page) or an App page and the one built via Developer console is called a Standalone Lightning App

  2. the one's built in Lightning App builder are branded under "flexipage:" namespace instead of the regular lightning namespaces "aura:" or "ui:" or "force:"..

  3. The Metadata component for Apps (Pages) built in lightning app builder is FlexiPage and for the apps built using developer console is AuraDefinitionBundle

  4. The Standard Components showing up in App builder cannot be used in the Lightning App aura bundle. believe some of them have an equivalent one under UI namespace..

  5. Adding Community Builder to the mix, the Pages built in Community Builder is not showing up under both AuraDefinitionBundle or FlexiPage. So not sure what's happening here

having listed this, now my question is why do we have these totally different approaches( frameworks /tools /components ) for a similar output [ i.e to produce a UI (either standalone or replace existing) that can be included in S1 or LEX desktop or Communities ]

3 Answers 3


I'll try to answer this question in part by adding some historical context and also by framing it in terms of User context and an evolving Lightning framework. The answer to your question isn't a simple answer that only involves a single context.

First, as we all are hopefully aware, the Lightning framework itself is still evolving and isn't completely defined. We'll be seeing more of it further defined and more changes to come with the SP16 Release. With that release there will be new functionalities and I wouldn't be surprised to see some things deprecated as we saw with the release of W16. In essence, the platform is incomplete and, for all practical purposes, is in what many would consider a "public beta".

Next, to develop Lightning components, the only tool available from the start has been the Developer Console. Components can be bundled into a single page "App" for use in Salesforce 1 mobile. When that happens, the "wrapper" they're put in is called a "Lightning app". Off-hand, I believe those apps can be used as mobile pages or as components in the App Builder as part of a Flexipage. Why it was done that way, is somewhat beyond me. It's unfortunate that this terminology got intermixed and creates such confusion.

Now we come to the Lightning App Builder. This UI was originally created for developers and admins so they could take standard and custom components, then drag and drop them on a page layout, while designing page mark-ups from which they could create applications to run in Salesforce Mobile as Lightning Pages/Applications. It's a multi-page size WYSIWYG type of GUI that helps avoid some of the coding that would otherwise be necessary if all the work were done in the Developer Console. It uses the Lightning Design System where Grids change the CSS that's applied to accommodate different page sizes. Thus, the reason it creates what are called flexipages.

Community Builder is there for a reason. If you're building a community, you're creating pages for a specific namespace: the one that your Community resides in. You can create components from the Developer Console that are enabled for Communities using aura:component implements="forceCommunity:availableForAllPageTypes" See Make Your Lightning Components Available For Communities from the W16 Release notes for more on this.

Further down on the aforementioned page, you'll see "Add a Design Resource to Your Component Bundle". You can mark your resource with access="global" to make the resource usable outside of your own org if you want it to be in an installed package or used either by a Lightning App Builder user or a Community Builder user in another org simply by adding a Design Resource to Your Component Bundle. A design resource describes the design-time behavior of Lightning component—information that visual tools need to allow adding the component to a page or app. A design resource supports only attributes of type int, string, or boolean. Design resources must be named componentName.design. Of most importance to your question, an attribute marked as required in the component definition automatically appears for users in the Community Builder, unless it has a default value assigned to it.

If you're building a Community, it's essential to have the ability to set attributes on Lightning Components you might use in those pages. You certainly don't want to be going into the Developer Console to try and edit them; something a page designer can't possibly do if the components are from a managed package.

As you can readily see, there's a rhyme and a reason for Salesforce to have all of these tools available. They each have a purpose and a use. It's also important that users with different skill sets or needs have tools available to them that suit their use cases. To make an analogy, not everyone needs Photoshop, yet graphic artists would be very limited in what they can do if they were limited to only having the default Windows Paint program available to them. Another analogy would be Notepad or Wordpad vs a full featured Editor like MS Office Word, Corel Wordperfect or LibreOffice. There are those of us who use Eclipse with the Force.com IDE or Sublime Text with MavensMate instead of the Developer Console. We all use tools that suit our needs and purposes. All the tools you've mentioned have a different purpose and serve a different audience.

  • thx for the detailed answer. i kind of get that, but its jus making things complicated like i can't even use some of the current standard components across these 3 containers, and to make a custom lightning component available for all 3 containers, i hv to implement multiple interfaces. :-( Dec 28, 2015 at 22:08
  • I hear your pain Vamsi, I really do! Until SF finalizes the Lightning platform, this is going to be an ongoing headache for Devs and will cause a great deal of confusion for many different people. To me, it's in part a "branding" issue and also a haphazard planning issue as different aspects of the "Lightning Experience" have been developed. If they'd drop some of the branding aspects that only add to the confusion, I think that would help tremendously.
    – crmprogdev
    Dec 29, 2015 at 0:05

You can implement multiple intefaces for your lightning component and that should allow you to use Single component built everywhere (except for lightning out which requires another app to declare dependencies ).

Here is what I have been doing to use components across everything .

<aura:component implements="force:appHostable,flexipage:availableForAllPageTypes,forceCommunity:availableForAllPageTypes,flexipage:availableForRecordHome,force:hasRecordId,force:hasSObjectName" controller="SalesLeaderBoardController">

force:appHostable will allow you to implement components for SF1 and lightning experience

flexipage:availableForAllPageTypes will allow your component to use in app builder

forceCommunity:availableForAllPageTypes will allow your component to use in community builder

flexipage:availableForRecordHome Configure component for record home page in Lightning experience

The key Idea of components is build once and use everywhere .

  • ye, i got that.. but what i don't like / understand is why do we hv different containers within a single platform (and remember this is time they are revamping / unifying things).. wat if they merge all of them to single interface one day.. wat if another container comes up (say wen they revamp site.com studio or service console or something else to include components) and we need to go back and add something to our existing component to support that.. :-( Feb 11, 2016 at 22:42

As mentioned in the other answer, there are different marker interfaces your component must implement for the component to be available in different places of the platform. Some of them are:

  • force:appHostable for the component to be used as a Lightning Component Tab in Salesforce1
  • flexipage:availableForAllPageTypes for the component to be available on Lightning Pages (and in App Builder)
  • forceCommunity:availableForAllPageTypes to use the component on pages in Community Builder

These are marker interfaces to allow component developers to control where their components show up. For example the builders/design time tools have additional requirements/capabilities to allow components to provide additional design time metadata like labels, icon and which of the component attributes should be configurable in the builder.

Agree it is confusing how the term app is used and have different meaning depending on context. Some historical context around the different containers:

  • Lightning Page/FlexiPage (since API version 29.0) is a metadata model describing the structure of a page. This was built specifically for declarative drag and drop tools like the Lightning App Builder.
  • AuraDefinitionBundle (since API version 32.0) allows you to programmatically write Aura code to be deployed on the platform (both .app and .cmp).
  • Community Builder is built on top of the old site.com technology. These pages are usually intended to be public facing which have a different set of requirements when it comes to things like SEO, CDN/caching etc.

The standard components that are available in the App Builder are a little different than the other programmatically exposed components. They are usually more coarse grained components that require additional design time metadata like labels and icons. Some of them should probably be exposed for programmatic use as well but that requires additional work to test and maintain. The programmatic components are generally more fine grained like ui:button, ui:inputText that does not necessarily make sense in the builders.

I think you should focus on building reusable components that can be used independent of the container technology they are put in.

  • thx Kristian, I m not concerted abt developing components for different containers.. it's just that I m not comfortable or clear on the needs for multiple containers in one platform which demands changes to the components and creates uncertainty / incompatibility sometimes.. Jan 3, 2016 at 2:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .