You’ve likely heard that the Lightning Component Framework is cool, and easy, and fun. But if you’ve been working with JavaScript User Interface (UI) frameworks such as jQuery, Knockout, or even AngularJS, you might be wondering what all the fuss is about and whether it’s worth your while to learn yet another JavaScript UI framework. I’ll try to provide you with the information you need to make that decision. I’ll show how you can quickly understand what Lightning Components are all about, and I’ll highlight what makes the framework different from other frameworks that can be used to build mobile web apps for Salesforce1.
Creating Lightning Components is a short, 60+ minute video course from Salesforce University where we demonstrate how to create and use simple Lightning Components. The course begins with a short module providing an overview of what Lightning Components are, how they can be used, and how they offer a new architectural approach for developing responsive and sophisticated custom web and mobile applications on the Salesforce1 platform. Subsequent modules dissect components to expose their internal resources, show how to build out their presentation with markup and style, explore how they process both client-side JavaScript and server-side Apex logic, how they message other components using a publish and subscribe eventing model, and more. For the next few weeks, I’ll be posting here some additional insight around the topics covered in each of the six modules.
Single Page Applications
What might not be obvious (and is not covered in the video course on Lightning Components) is that Salesforce1 is essentially what is known as a Single Page App or SPA. If you’re unfamiliar with the term, it refers to a web application that runs inside a single HTML page residing in the browser with all supporting content such as markup, style, and JavaScript retrieved during the initial page load.
In an SPA, page content is manipulated behind the scenes using client-side JavaScript, creating the appearance of separate pages. Applications that are expected to run on a variety of mobile devices will most benefit from this web-based development approach, because they require alternate display behavior for inconsistent form factors and page transitions that are gesture-based. This approach lies at the heart of Salesforce1 technology.
The heavy adoption of AJAX technology and the growing desire for browser-based applications providing a sophisticated user experience has led to the rapid evolution of SPAs. However, building SPAs is not easy, and requires expert knowledge of HTML, CSS, JavaScript, mobile UI design patterns, security, data serialization, and service oriented architecture (SOA) technologies and best practices. The beauty of the Salesforce1 SPA architecture is that implementation is kept well-hidden, with complexities abstracted away behind a metadata layer. This allows administrators to easily configure their mobile page layouts, navigation, actions, and security to configure the standard Salesforce1 app for their users.
Complexity Made Easy
However, a significant challenge arises for customers needing to build a custom Salesforce1 user experience. Developers have to be able to rapidly build pages and apps that mirror the behavior and “look and feel” of Salesforce1. Developers who have used Visualforce for rapid development of custom Salesforce pages running in a desktop browser are now being tasked with rapidly delivering SPAs, and integrating them into the Salesforce1 app using HTML, CSS, and JavaScript.
Javascript is a flexible, powerful, and complex programming language that allows developers to structure their SPA UI and data transport architecture in a wide variety of ways. Since 2006, a preponderance of JavaScript-based UI frameworks and libraries have evolved, such as jQuery, Backbone, Knockout, AngularJS, ExtJs, and Sencha Touch. These toolsets provide developers with structured frameworks and libraries for organizing their JavaScript front-end logic, each in its own manner. This code runs in a browser, on devices that have limited memory, that lack powerful processors, and that connect to the web over wireless channels typically with constrained bandwidth.
At first glance, it appears that Lightning Components are merely another contribution to this collection of frameworks. So we’re back to the question, “Why do we need yet another framework, and why should I learn it? Why not just keep building using <YOUR FAVORITE UI FRAMEWORK HERE> hosted in Visualforce?”
After all, Salesforce developers have been building SPAs hosted in Visualforce pages for years. Even before the advent of the mobile web, early SPA frameworks such as ExtJs allowed construction of custom pages providing a superior user experience for high-volume or complex data entry screens. Then, with the advent of the mobile web and HTML5, but before the release of Salesforce Touch (an early version of Salesforce1), tools like jQuery and Sencha Touch allowed pioneering Force.com developers to begin mobilizing Salesforce users by building mobile SPAs hosted in Visualforce pages.
Visualforce is Suboptimal for SPAs
It may be true that these SPA’s hosted in Visualforce can be “surfaced” in Salesforce1, but it is not an optimal approach for the following reasons:
1. The very nature of Visualforce requires the use of an iframe HTML component, adding performance overhead.
2. Core frameworks and libraries must be linked to the host Visualforce page, either with an external link, or a link to a file uploaded as a Static Resource.
3. Each framework provides its own particular architectural approach that developers must follow, and while some do promote a more manageable component-based approach well suited for scalable enterprise development, others provide little if any guidance around organizing or scaffolding code modules.
4. Developers must somehow choose which framework or approach is best suited to their purpose, learn how to use it, organize it, and maintain a consistent set of practices so that as their app’s complexity grows, the maintenance burden is kept in check, and a robust and organized codebase maintained.
Even the “best of the best” of these frameworks provide such challenges when building custom SPAs hosted in Visualforce.
Lightning is an SPA Framework
Lightning Components, on the other hand, gracefully solve all of these issues and more:
1. An easy-to-use scaffolding pattern is provided for building, organizing, and maintaining the encapsulated HTML, CSS, and JavaScript component resources, all managed using cloud- based Salesforce developer tools.
2. Components are stored as metadata inside a Salesforce org in the cloud, and are also accessible through the Tooling API.
3. Patterns for inheritance and interface implementation are provided, along with a decoupled event messaging model.
4. Components extend the capabilities of the core Salesforce1 framework, and dozens (soon to be hundreds) of pre-built components allow developers to assemble their application from modular building blocks that can be nested into other components, or further extended.
5. Components in Lightning are “peers” of each other, rather than being isolated within iframes, which are not used in the framework. This makes integration easy and maintenance rapid by allowing developers to piece together components (both those they have created and those obtained from outside sources), without the need to reinvent the entire transaction model.
6. No additional external libraries or frameworks are required, although they may be used with Lightning Components if desired.
7. No Visualforce page is required to host Lightning Components. Lightning Components are built on top of Aura, the same open-source JavaScript UI framework used by Salesforce1. The framework was designed to serve up a mobile Salesforce user experience using an underlying component-based architecture. This is the same framework with which developers build their own components.
8. Lightning Components can be deployed into any Salesforce org, added into Salesforce1 mobile navigation, assembled into custom Lightning Pages with a drag-and-drop Application Builder, and surfaced a number of ways in Salesforce1. They may also be used to build completely standalone apps, independent of the Salesforce1 app.
9. Best of all, components built by Salesforce, other ISV partners, or any developer can be reused and extended by any other developer, providing enormous ability to reuse existing functionality as building blocks for rapid application development.
Let’s Dig In
So now that you have a sense of why you might want to see what Lightning Components are all about, go ahead and dig into Creating Lightning Components, it’s only about an hour of your time. And if you want to dig down even further, check out the Salesforce1 Lightning page on the Developer Portal and the recently released Lightning Component Trailhead Module. Try it, I think you’ll like it!