This series introduces you to the Lightning Component Framework through a free online course by Salesforce University combined with a six part blog series written by Don Robins, a Salesforce MVP, Certified Advanced Developer and Certified Salesforce Instructor. Each post provides deeper insight and additional perspective around topics covered by each course module.
Single Page Applications
Complexity Made Easy
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:
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.
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!
Creating Lightning Components: Single Page Applications (1 of 6)
Creating Lightning Components: The Bundle as Scaffolding (2 of 6)
Creating Lightning Components: Action Processing and Binding Data (3 of 6)
Creating Lightning Components: Component Based Architecture (4 of 6)
Creating Lightning Components: Events and Messaging (5 of 6)
Creating Lightning Components: Wrapping It Up (6 of 6)
About the Author
Don Robins is a Force.com MVP, Certified Advanced Developer and award winning Salesforce University Certified Instructor. Since 2010, he’s been delivering the core development curriculum to hundreds of customers in both public and private workshops for Salesforce University in the US and abroad. As an independent Training Delivery Partner through his company Forcementor.com, he leads and mentors a team of certified Salesforce instructors, curriculum developers and technical authors. He found his way onto the platform as a consultant and developer in 2009, after two decades of building custom business applications with a metadata, framework-based approach. Ever since, his primary focus has been to educate developers and the business community on Salesforce1 and to evangelize the platform.