What is the difference between ltng:require and aura:clientLibrary?
What are the best practices with regard to their usage?
What are the technical concerns that should be taken into account when choosing either of them.
I see that combine on aura:clientLibrary allows to can improve performance by reducing the number of requests
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:
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:
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:
In addition to what everyone else has said...
The helper is designed to have shared code in it. So, you could have code shared by your renderer and your controller or by multiple controller functions. That should go in the helper JS file.
I think that a good practice is to let the controller respond to events, possibly perform some amount of control flow, and delegate business logic to the helper as a separation of concerns. It also sets you up to be able to reuse your business logic in other parts of the component in the future.
Helper code can be shared among components when they are related through inheritance. If one component extends another it inherits its super component's helper and can override it.
Sub components can call super component controller methods, but that may be deprecated in the future according to the documentation in the Lightning Components Developer's Guide.
Components can communicate with each other via events to "share" code. For example, if you have a component that handles writing business logic errors in a uniform way in your app, and handles some sort of error related event, you could fire an event to trigger it to handle an error.
Best Answer
ltng:requireis used to refer javascripts and CSS only from static resource and we can decide sequence in which javascript should be loaded.Whereas
aura:clientLibraryallows external Javascript even from URL as well as CSS files.