If you want to recreate the look-and-feel of Lightning Experience or the Salesforce1 mobile application, you will need to apply the Salesforce Lightning Design System (SLDS) external style sheet to your Lightning Components and Applications.
There are a number of ways in which to apply SLDS styling, with some being automatic based on context, and others requiring a reference to the SLDS style sheet in markup.
Although not a technical deep dive, this overview will help you understand the different strategies for applying SLDS to your Components and Applications.
Prior to the Winter ’17 release, the only ways to implement SLDS were to either download the design system as a ZIP file that contained the CSS style sheets and icon library and upload the ZIP as a Static Resource, or download an unmanaged package to your org.
In either case, the burden of keeping the SLDS resources up to date fell on developers and admins, who had to monitor for updates to SLDS and upload new versions to the Static Resource as they became available.
In some cases with early adopters of Lightning, there were multiple versions of SLDS floating around as Static Resources within a Salesforce org, further complicating the maintenance requirements.
With the Winter ’17 release, SLDS is included in all Salesforce orgs and will be updated on a schedule that is more aligned with the three-time per year Salesforce release schedule.
Lightning Experience and Salesforce1
As of Winter ’17, any Lightning Components that are exposed in Lightning Experience or Salesforce1 will automatically have SLDS included in the app.css external style sheet that gets generated at the time the Lightning Component Framework bootstraps.
When you work in Lightning Experience or Salesforce1, the user interface is composed by a special top-level application that we refer to as the one.app container. If you look at the address bar of your browser when you are using Lightning Experience, you will notice the URL looks something like this:
Just like we can create our own custom .app applications and expose them by URL, one.app is a Lightning Application that contains all of the markup, styling and events needed to run the Lightning Experience and Salesforce1 user interfaces.
There are a number of options for exposing your custom Lightning Components through the one.app container, each of which automatically applies SLDS, and we will touch on them here.
Lightning Pages are created using the Lightning App Builder, which is a drag-and-drop interface that allows you to declaratively create new user interfaces from any standard, custom, or third-party Lightning Components that implement a special interface.
Lightning Pages enable developers and admins to create new App Pages, Home Pages, and Record Pages by simply by assembling reusable components on a canvas and assigning component attribute values where required.
When you implement the appropriate interface and expose your custom Lightning Components as Lightning Pages, they will automatically have SLDS available to them.
If you simply want to expose your Lightning Component as a custom tab in Lightning Experience, you can create a new Lightning Component Tab and add it to Apps in the App Launcher. By implementing the interface to expose your Lightning Component in a tab, the component will have SLDS available to it when it is rendered in the one.app container.
With the Winter ’17 release, Salesforce introduced the concept of exposing Lightning Components as Quick Actions. Now you have the option to expose your Lightning Component in a much more granular fashion than exposing it on a Lightning Page or in a Lightning Component Tab, and any Lightning Component that implements the appropriate interface can be exposed as a Quick Action.
Again, since the component is being rendered in the one.app container, SLDS will be available to your component automatically.
Lightning Out and Lightning Components for Visualforce
Whether using Lightning Out to expose Lightning Components to an external website or a Visualforce page, SLDS CSS classes will automatically be included in the app.css stylesheet so you won’t have to worry about manually loading the SLDS stylesheet or other assets.
To apply the look and feel of Lightning Experience and Salesforce1 in custom Lightning Applications (.app resources) that are not rendered in the one.app container, you can extend force:slds in the application definition to implement the SLDS style sheets and design tokens from Lightning Design System.
In some cases you may have a requirement to use a specific version of the Lightning Design System. If you do not want to take advantage of automatic upgrades to SLDS provided by the one.app container or by extending force:slds, you can upload the CSS stylesheets for SLDS as Static Resources and create a dependency on them in your components by using ltng:require.
If you do choose to use a Static Resource to apply SLDS, or if you have components that were developed prior to Winter ’17, keep in mind that you will be responsible for maintaining the stylesheets in your Salesforce org.
In earlier releases of SLDS, the design system was available as an unmanaged package that could be downloaded directly into your Salesforce org. This is no longer an option as the unmanaged package has been deprecated.
To find more detailed technical articles related to styling Lightning Components and Applications, check out the curated library of Lightning content here:
Strategies for Migrating From Visualforce to Lightning
In Part 3 of the Patterns for Migrating from Visualforce to Lightning Components series, I’ve envisioned five possible migration strategies for transitioning from a page-centric Salesforce Classic and Visualforce experience to an app-centric experience using Lightning Components in Lightning Experience.
For each of the five migration strategies, I lay out at a high level what each would look like from an implementation perspective, as well as call out key considerations that have to be made for each.
Scorched Earth Strategy
The Scorched Earth Strategy is the most ambitious of all of the migration strategies. While it may not be necessary to go the route of completely replacing Visualforce – in some cases Visualforce is still the only available option for certain functionality – if your organization has completely bought into Lightning and wants to make the cutover from Visualforce, this may be your ideal route.
Scorched Earth Strategy: Implementation
To go down the path of the Scorched Earth Strategy, you will have to completely rip out and replace all of your existing Visualforce Pages and Components with Lightning Components and Applications.
Since custom Visualforce Components are somewhat analogous to Lightning Components in that they are reusable building blocks of code, I would recommend starting with them in your analysis or pre-design phase as they may provide some “low-hanging fruit” in your migration effort.
Begin by mapping all existing Visualforce Components to the Pages that reference them. This will not only give you an idea of the dependencies that exist between Pages and Components, but it will help you understand both the construct of the Visualforce Page that you will be redesigning as an application and the mental models that your users have developed in using the legacy Visualforce Page.
Since Visualforce employs a page-centric architecture, you will probably find that most of your pages contain a great deal of markup and probably have several areas on the page that perform specific functions. For each of the functions being performed on a page, try and find where the function begins and ends within the Visualforce code.
Once you have your Visualforce page sliced up into the different functions performed, envision each of the functions and the corresponding UI patterns as standalone Lightning Components. What concepts can you keep? What has to be redesigned from the ground up for Lightning?
After you have rebuilt your custom Visualforce Components and abstracted all Visualforce Page logic and markup as individual Lightning Components, reassemble all of the pieces by composing new top level Lightning Components for each of the top level Visualforce pages being replace. The top level Lightning Component should contain no markup – only references to each of the granular components.
To surface the Lightning Components to users in Lightning Experience, you can either create new top level .app Lightning Apps that contain references to the top level Lightning Components, or you can add the top level Lightning Components to a Lightning Page using Lightning App Builder.
Scorched Earth Strategy: Considerations
Some key considerations for implementing the Scorched Earth Strategy:
It will take a huge amount of effort to pull this off.
Your team has to have a deep understanding of developing Lightning Components.
Successfully implementing this requires either a rapid phased cutover or a flash cutover.
The migration could potentially be disruptive to your users.
You may find that you can reuse existing controller logic by abstracting to static methods with the @Auraenabled annotation.
You will get a rare one-time opportunity to wipe technical debt off the books by refactoring and cleaning up old Visualforce code during the migration process.
The Greenfield Strategy presupposes that you are either new to Salesforce, or you are starting over in a new pristine Salesforce org.
Greenfield Strategy: Implementation
The implementation of the Greenfield Strategy is pretty straightforward:
Take a Lighting-first development approach from day one and be free from the constraints of Visualforce.
Build your customizations in a new, pristine Salesforce org.
Greenfield Strategy: Considerations
Some key considerations for implementing the Greenfield Strategy:
This is a good option for new Salesforce customers as you can start and grow with Lightning.
There would be very little migration from Visualforce.
This presents an opportunity to cutover from a cluttered Salesforce org, but cutovers will require a data model redesign and a full data migration.
Starting your Salesforce development roadmap with Lightning enables a sort of “catch-up effect” as developers would not need to learn Visualforce first.
War of Attrition Strategy
The War of Attrition Strategy is probably the most viable for most organization, as it is more of a gradual evolution than a migration.
With the War of Attrition Strategy, you adopt a Lightning-first approach to development, but rather than migrating existing Visualforce Pages and Components to Lightning Components, you leave them behind until they eventually reach the end of their useful lives and can be removed from the org.
War of Attrition Strategy: Implementation
To implement the War of Attrition Strategy, you have to take a number of steps within your development organization:
Shift your team’s development focus from Visualforce to Lightning-first.
Draw a line in the sand and meet new business requirements with Lightning solutions.
For enhancement requests to legacy Visualforce Pages, evaluating the trade-offs of maintaining the Visualforce functionality as opposed to replacing with Lightning.
Sunset existing Visualforce Pages and Components as they become obsolete.
Reuse your existing Apex controller code by refactoring to use @AuraEnabled methods and commenting out Visualforce specific methods after Pages are sunset.
If your organization wants to move to Lightning Component development but isn’t ready to move to Lightning Experience, use Lightning Components for Visualforce to surface new Lightning Components in Salesforce Classic.
War of Attrition Strategy: Considerations
Some key considerations for implementing the War of Attrition Strategy:
This, in my opinion, will be the most likely scenario for existing Salesforce customers.
Rather than throwing your developers into the fire, you can give the development team more time to learn how to build Lightning Components the right way.
This process will inevitably create Visualforce clutter during the transition period
Do not undertake the implementation of this strategy lightly – it requires disciplined management of your Salesforce operations.
The Coexistence Strategy is one where Visualforce and Lightning live in peaceful harmony. The best solution is chosen for each business use case, regardless of having to manage the overhead of multiple development platforms within the Salesforce space.
Coexistence Strategy: Implementation
The Coexistence Strategy is less of a migration path and more of an organizational mindset. You simply choose to evaluate both Visualforce and Lightning for new business requirements that cross your desk, and pick the best option for the use case.
Coexistence Strategy: Considerations
Some key considerations for implementing the Coexistence Strategy:
You will need to have the oversight of a Salesforce Architect to make design decisions and ensure solutions adhere to Salesforce architecture guidelines.
You could have a potentially inconsistent user experience across your Salesforce applications.
This type of strategy would require a larger development team as you would have to have multiple skillsets available.
Having a larger development team enables developer specialization in Apex, Visualforce and Lightning Components, fostering deep focus and expertise
You will still need to migrate Visualforce Pages to Lightning Components if specific Visualforce functionality is ever deprecated.
Parallel Paths Strategy
The Parallel Paths Strategy is more of a thought exercise than a strategy. I don’t see many organizations adopting this as an approach, but it is interesting to think philosophically about how this strategy might enable a shorter learning curve and a deeper understanding of Lightning within your development team.
Parallel Paths Strategy: Implementation
The implementation of the Parallel Paths Strategy is about as straightforward as it gets: When new business requirements come in, design solutions for both Visualforce and Lightning Components.
Parallel Paths Strategy: Considerations
Some key considerations for implementing the Parallel Paths Strategy:
You will be creating double work as you will be building and maintaining Visualforce and Lightning solutions in parallel.
In the end, implementing some form of this strategy could enable a smoother transition to Lightning Components as developers gain confidence with the technology.
Your developers will get to learn Lightning hands in a lower pressure environment.
You allows your users the choice of transitioning to Lightning Experience or sticking with Salesforce Classic.
In Part 2 of the Patterns for Migrating from Visualforce to Lightning Components series, we’ll talk about the roles Visualforce can play in our brave new Lightning world. We’ll also talk about how Lightning can take us far beyond where Visualforce can today.
Once we have this background and understand the roles that each of these technologies play, we’ll talk about visions for our future state Salesforce experience.
Which Should I Use: Lightning or Visualforce?
So which one do you move forward with? Lightning Components or Visualforce?
Since we’re here to talk about migrating from Visualforce to Lightning, we need to pick one…right?
Does it really need to be an either / or decision? Do we really need to pick a winner here?
Lightning + Visualforce
Or can Lightning and Visualforce both have a place at the table?
Can they be like chocolate and peanut butter…you know, two great tastes that taste great together?
Before we get too far into comparing Visualforce to Lightning Components, let’s take a minute to discuss the new Lighting Experience and how it fundamentally changes the way we work in Salesforce.
The UI that we have been using for years is now being branded as the “Salesforce Classic” UI. This is where Visualforce reigned supreme – Salesforce Classic is a page-based architecture where we had long, scrolling pages of data, and Visualforce components were designed to recreate the look and feel of the very same components that we saw in the out-of-the-box UI.
With Lightning Experience we are working with Single Page Applications (SPA) and are shifting to a responsive design model.
How Are Lightning and Visualforce Different?
At a high level, Lightning Component and Visualforce development are fundamentally different.
Client-Side vs. Server-Side UI Generation
App-Centric vs. Page-Centric Model
We have grown accustomed to the long, scrolling page architecture of Salesforce. If we wanted to expose applications to our users, we did so either declaratively by grouping tabs together as “applications” or programmatically by developing page-driven custom applications in Visualforce.
With Lightning, we are moving to a responsive, Single Page Application architecture. Rather than grouping all of the UI elements and business logic into Visualforce Pages, we are developing reusable components that can be assembled into new applications by both developers and admins.
Component Based vs. MVC Framework
Visualforce is the “V” in the Model-View-Controller (MVC) architecture. It was designed to render custom user interfaces by interacting with a Controller – the “C” the MVC architecture – using either a “standard” controller that is exposed on every Salesforce object that can be accessed through the API, or an Apex class that serves as a “custom” controller or controller “extension.” The Controller is responsible for implementing business logic, exposing actions to enable interaction with Salesforce from the Visualforce Page, and to retrieve data from the “M” – or data Model – layer of the MVC architecture.
Lighting Components are radically different in that they are are assembled into self-contained applications that drive entire business processes end-to-end. Interaction with a Lightning Component is event-driven, with events being raised and handled within the context of a component hierarchy.
Individual components within an application are rerendered based on events and conditions rather than requiring full page refreshes or navigating to new pages, which reduces expensive round-trips to the server and improves performance. Data can be sent to and from Salesforce by enqueueing actions in a client-side controller or helper function to make calls to static methods in Apex classes that are annotated with a special keyword.
Visualforce is a proprietary tag-based markup language that is tightly coupled to Salesforce metadata and actions. Visualforce tags are interpreted on the server side at runtime when Visualforce Page requests are received, and the server responds to valid requests with an HTML document to the browser.
Lightning Experience vs. Salesforce Classic
Visualforce has been around a while. Visualforce standard components render HTML and CSS that mimics the look and feel of UI elements in the Salesforce Classic UI. While the Lightning Design System can be applied to many Visualforce components to give them a similar look and feel to Lightning Experience, there is no indication that Salesforce has plans to update standard Visualforce components to natively support Lightning Experience.
Visualforce is also relegated to an iFrame in Lightning Experience, limiting its interaction with the page it is rendered in, which could degrade the functionality of a Visualforce Page if it depends on context that it would normally have access to in Salesforce Classic.
Lightning Components have been designed from the ground up for tight coupling with Lightning Experience and the Salesforce1 native mobile application, and the Lightning Design System provides icons and a CSS stylesheet to enable developers to create responsive applications that render with pixel-perfect recreations of the UI patterns used natively by Lightning Experience and Salesforce1.
Where Can I Use Visualforce In Lightning Experience?
What if our organization wants to dive in and make the switch from Salesforce Classic to Lightning Experience? Does Visualforce even work in the new Lightning Experience?
You bet. Although as mentioned previously, the way Visualforce renders in Lightning Experience (as an iFrame) is much different than the way it renders in the Salesforce Classic UI.
For the sake of time I won’t go into the gory technical details of how iFrames work or the implications on Visualforce in Lightning Experience, but it is important to understand this consideration.
The specific areas in which you can surface Visualforce Pages in Lightning Experience include:
The Lightning Experience Navigation Menu
The Lightning Experience App Launcher
Embedding in a standard page layout
Launching from custom buttons and links
Custom Visualforce Quick Actions on page layouts
Overriding standard buttons and links
The Lightning App Builder Visualforce Component
Lightning Experience Navigation Menu
You can now add a Visualforce page to the Lightning Experience navigation menu.
Lightning Experience App Launcher
You can still access your Visualforce tabs in your custom apps.
Granted, it’s a couple extra clicks now in Lightning Experience, but your Visualforce pages don’t go away.
Lightning Experience Standard Page Layouts
You can drag and drop Visualforce pages onto the detail page layout just like you could in Salesforce Classic.
Lightning Experience Buttons + Links
Just like we could override standard actions such as creating or editing records in Salesforce Classic, we can continue to override standard actions using Visualforce pages in Lightning Experience.
You know how you can create Visualforce pages that use the standard controller for an object along with a controller extension, then create a custom button to launch that page from the standard page layout for that object?
Well, that still works in Lightning Experience. That’s not going away anytime soon.
What Standard Buttons and Links Can I Override?
The following standard buttons and links can be overridden with Visualforce Pages in Lightning Experience:
Lightning Experience Quick Actions?
Have you ever used Quick Actions?
Remember how you had to Chatter-enable an object if you wanted to use Quick Actions because they weren’t supported natively in page layouts in Salesforce classic?
Well, we can continue to use custom Visualforce Quick Actions, and in Lightning Experience Quick Actions become an integral part of the page layout.
Lightning App Builder
With the Lighting App Builder in Lightning Experience, not only can your Awesome Admins create new Lightning Pages using reusable Lightning Components, your Visualforce Pages can be exposed by dragging and dropping the Visualforce component onto the Lighting App Builder canvas.
Why Would I Want to Stick With Visualforce
So why would we want to keep using Visualforce? For starters, there are some technical considerations.
Currently there is no way to expose the functionality provided by Standard Controllers directly to Lightning Components. If you want to use the Standard Controller for an object, you will need to use Visualforce for that.
There are a number of interfaces that are exposed in the Lightning Component Framework that allow you to access much of the same context provided by a Standard Controller, but you will need to explicitly implement these interfaces if you require this functionality.
Standard Component Library
One of the great things about Visualforce is that developers really didn’t need to know all that much about HTML and CSS. Visualforce comes with a robust library of standard components that will automatically render the HTML and CSS for a given component based on the attribute values that you declare in the tag for the component.
Lightning doesn’t have a robust component library yet. There are a number of out-of-the-box UI components available, but at this stage in the game you have to manually recreate many of the UI patterns in Lightning Experience by writing custom HTML and referencing the appropriate CSS classes provided by the Lightning Design System.
One of the great things about Visualforce was its tight coupling with the Force.com platform, which allowed Visualforce components to render themselves based on the context of the implicitly referenced metadata.
For example, if you used an <apex:inputField> component with a field of type Picklist, Visualforce would know to render that field as a picklist along with all of the values defined for that picklist.
Visualforce could also conditionally show or hide input or output components based on the Field Level Security (FLS) for a given field in the database.
When developing Lightning components, developers are responsible for asking the platform for metadata and explicitly taking action based on the context provided by the metadata.
If you currently use Force.com Sites to expose Visualforce pages as public web pages, you are going to have to continue to use Visualforce with Sites because there currently is no equivalent for surfacing Lightning Applications or Components in a public, unauthenticated context.
If you are using Visualforce for custom email templates, keep using them. There is no equivalent in Lightning
Did you know you can use the ‘renderAs’ attribute of the <apex:page> tag to have your Visualforce Page render as a PDF document?
If you want to take advantage of this functionality, you are going to have to stick with Visualforce for now. There currently is no way to render Lightning Applications or Components as PDF documents.
We also have some non-technical considerations…
Lightning is New. Visualforce is Mature.
Visualforce has been around for almost 10 years. Lightning Experience has only been GA since Winter ‘16. Lightning Components were introduced within the past two years.
Limited Lightning UI Component Availability
By contrast, Visualforce has hundreds of standard components.
Granted, those components render HTML that was designed to recreate the look and feel of Salesforce Classic and are of diminishing value moving forward, but the point is that the Lighting Component Framework doesn’t have that robust set of standardized components that you can use to build your own Lightning Components.
As of this moment, there isn’t even the concept of a data grid available as a UI component. You have to build the HTML table yourself, whereas in Visualforce you can use standard components such as <apex:pageBlockTable> or <apex:dataTabel> to automatically generate HTML tables with your Salesforce data.
Lightning Isn’t Done Yet
By Salesforce’s own admission, they rolled out Lightning before it was done. Have you developed Lightning Components yet?
To this point, it’s been a fairly bumpy ride developing Lightning Components.
The ride has gotten a lot smoother with the Spring and Summer ‘16 releases, but there’s still a ways to go before this platform is truly ready for the enterprise.
Lightning Has a Steep Learning Curve
There is no natural learning path to switch from Visualforce to Lightning Component development. Lightning Components are hard to grasp at first.
Visualforce has the advantage of wide adoption and there is a treasure trove of documentation, design patterns, and community discussions to help Visualforce developers figure out how to build solutions
There is even a Visualforce book available from Salesforce Developer Relations. See if you recognize one of the co-authors.
By contrast, Lightning Component development is still a relatively new concept within the Salesforce developer community and there simply are not as many resources available to learn Lightning.
The Trailhead modules are great, you can take one of my DEV601 classes, and you can spend some quality time with Lightning Components to learn them inside and out, but just keep in mind that Lightning is different than anything you’ve ever experienced with Salesforce development.
Be prepared to invest a significant amount of time and brainpower learning this platform.
Why Would I Want to Use Lightning Components
Why would your organization or you as a Salesforce developer want to consider Lightning Component development?
For starters, Lightning is the future of Salesforce development. There is no way around it…Salesforce is betting the company on it.
But even if you ignore that and focus on the value that Lightning can provide, you will find that there are many compelling reasons for making the jump to Lightning.
From one code base, you can create components and applications that will give your users a unified experience across all form factors: Desktop browsers, mobile devices, tablets, wearables, and anything else that comes along in the near future.
You can create components that can be consumed by other Lightning Components and Applications, allowing your component to be reused many times in many different places.
Your admins can also use your components in the Lightning App Builder, allowing them to declaratively create new Lightning Pages with your components. This is where the line between declarative (clicks) an programmatic (code) development starts to blur!
Because Lightning Components render on the client and do not require expensive round trips to a server-side controller to update data and context, you can build components that are…wait for it…lightning fast.
Have you ever used the AJAX components in Visualforce to do something as simple as create a type-ahead function for an input field? There was always a lag between the time an event was handled and the target component was rerendered. With Lightning Components, any change to an attribute value will automatically rerender a component, giving you the ability to create high performing client-side Salesforce applications.
For new developers coming onto the Salesforce platform, Lightning provides an opportunity to quickly apply web application development skills to hit the ground running without having to first learn Apex or Visualforce.
With Visualforce development, we are constrained to a fairly rigid architecture that executes server-side controller actions when explicit user events occur such as clicking a link or a button.
Granted, you can use the <apex:actionSupport> tag in Visualforce or component-specifc event handlers to handle supported events, but this requires a significant amount of hard-coding to server-side controller methods.
With Lightning, you can listen for and handle just about any DOM event or custom component event and determine what action you want to take when that event occurs. An example of a custom component event is the “press” event on the “ui:button” component.
For example, you can handle the “onchange” event when a picklist value is selected and immediately call a function in your client-side controller to take action based on that value changing. You even have the ability to define and raise custom events, and determine how those events should be handled within your component hierarchy.
Encapsulation simply means that we can wall off the inner workings of a Lightning Component and not expose the secret sauce behind it to another component or application that references it. This allows us to update the code within a Lightning Component without breaking any upstream Components or Applications.
Encapsulation enables us to write reusable and efficient code that is easily maintainable.
Where Can I Surface Components in Lightning Experience and Salesforce1?
“Surfacing” a Lightning Component means making it available to your users. Since the Lightning Component Framework was introduced with Lightning Experience and Salesforce1 in mind, surfacing Lightning Components can be handed in a number of ways:
Lightning Apps are a special type of top-level component that are used to assemble Lightning Components in a way that creates a new application that users can reference by URL.
Lightning Component Tabs
Lightning Experience and Salesforce1 allow you to render individual components directly in the UI by surfacing them through a special type of Tab.
Lightning Pages blur the line between the traditional “clicks vs. code” dichotomy that dictated what customizations you could make using out-of-the-box tools in the UI vs. having to write Apex or Visualforce code.
Lightning Pages are created using the Lightning App Builder, which is a drag-and-drop interface that allows Lightning Components and other components to be assembled into fully functioning applications that can be exposed to users.
Because the Lightning App Builder is considered to be a “declarative” development tool, the Lightning Components you create as a developer can be reused by Salesforce admins without them having to know how to write a single line of code.
Lightning Components for Visualforce
If you have a specific use case for continuing to use Visualforce, you can expose Lightning Components directly in a Visualforce Page by implementing a special interface.
Where Can I Surface Components in Salesforce Classic?
If you want to surface a Lightning Component in the Salesforce Classic UI, you have exactly one option: Lightning Components for Visualforce.
As of now, the concepts of Lightning Component Tabs do not exist in Salesforce Classic, you cannot access a Lightning App by URL in Salesforce Classic, nor can you assemble Lightning Pages because Lightning App Builder does not exist in Salesforce Classic. It is doubtful that Salesforce would ever support them given the company’s march towards Lightning Experience.
If your organization wants to leverage the power of the Lightning Component Framework but is not ready to flip the switch and migrate from Salesforce Classic to Lightning Experience, never fear. Lightning Components for Visualforce has you covered.
After having worked with Lightning Components for Visualforce a number of times, I can tell you that it is an elegant solution for surfacing Lightning Components in Salesforce Classic, even if it is your only option.
Introduction and Background on Lightning and Visualforce
This three-part blog series is adapted from a presentation I had the opportunity to give at the Midwest Dreamin’ event in Chicago. I gave the session a fairly provocative name – The Long, Slow Goodbye: Patterns for Migrating from Visualforce to Lightning Components – as I feel there is a growing belief in the Salesforce developer community that Lightning Components will replace Visualforce over time.
Whether or not this ends up being true is yet to be seen, but as a Salesforce architect I wanted to put some thought into possible migration strategies should organizations choose to adopt Lightning component development as a key part of their Salesforce development strategy. This presentation was my attempt to articulate these strategies to and receive feedback from an audience of Salesforce developers and MVPs.
In Part 1 of the Patterns for Migrating from Visualforce to Lightning Components series, I’d like to start out by giving just a little background on Visualforce and Lightning. With Lighting, I want to talk about what it is and what it isn’t.
Then I’d like to compare and contrast the technologies at a high level so that we understand where Visualforce and Lightning fit into the Salesforce architecture.
The Long, Slow Goodbye
Many organizations are envisioning creating a rich, unified Salesforce experience by migrating from Salesforce Classic to Lightning Experience and developing responsive applications using the Lightning Component Framework.
There are many questions that have to be asked before making the transition to Lightning, one of the biggest ones being, “What happens to Visualforce?”
In this session we will clarify what Lightning is (and what it isn’t), highlight the key differences between Lightning Components and Visualforce and where each fit into the Lightning Experience architecture, and envision five possible migration strategies for transitioning from a page-centric Salesforce Classic and Visualforce experience to an app-centric experience using Lightning Components in Lightning Experience.
Mike Topalovich is a freelance Salesforce architect and advisor with a knack for envisioning and designing next generation systems that help organizations do business in new ways. Focused on removing friction from processes and using cloud computing as a force multiplier, Mike works with visionary organizations to design game-changing systems on the Salesforce Platform to enable rapid business growth and cloud-driven business models.
Mike is also the part time CTO of Marketing Lucidity, a Salesforce ISV Partner, and recently built out a Salesforce implementation to manage tens of millions of person accounts for a Super PAC supporting a 2016 presidential campaign.
Based in Chicago, Mike is a regular presenter at Dreamforce and regional Salesforce events, and is a co-author of the book Visualforce in Practice. When he isn’t advising growing organizations or pushing the envelope of Salesforce technology, Mike is a part time instructor for Salesforce University, teaching Apex, Visualforce and Lightning Component programming to Salesforce developers in major cities around North America.
I want to talk about something that’s been on my mind for a while. When I teach the DEV450 class (Apex and Visualforce), we usually move into the Visualforce section of the class after lunch on Thursday. In nearly every class I have taught since Dreamforce 2015, I have gotten the same question during the Visualforce content:
“Why are we learning about Visualforce if it’s being replaced by Lightning?”
At first I didn’t have a good answer to that question. Now that I’ve had enough time working hands on with the technology and teaching it to developers, I have a better answer. And that’s what I’d like to talk about.
For the sake of readability, I have broken the presentation into three separate blog posts:
Part 1: Introduction and Background on Lightning and Visualforce
I’d like to start out by giving just a little background on Visualforce and Lightning. With Lighting, I want to talk about what it is and what it isn’t.
Then I’d like to compare and contrast the technologies at a high level so that we understand where Visualforce and Lightning fit into the Salesforce architecture.
Part 2: Deciding to Use Lightning or Visualforce
We’ll talk about the roles Visualforce can play in our brave new Lightning world. We’ll also talk about how Lightning can take us far beyond where Visualforce can today.
Once we have this background and understand the roles that each of these technologies play, we’ll talk about visions for our future state Salesforce experience.
Part 3: Strategies for Migrating From Visualforce to Lightning
Once we have a vision of where we want to go with Lightning, I’ve mapped out a number of possible migration strategies and the considerations that have to be made for each.
What is Visualforce?
Introduced at Dreamforce ’07, Visualforce is a server-side, tag-based UI language. It was originally designed and optimized to recreate the look and feel of what is now called the Salesforce Classic UI, with the page-centric, scrolling architecture that would display a detail section at the top of the page, followed my any number of related lists.
Visualforce gives you access to hundreds of standard components that will generate HTML and CSS based on attributes that you pass through to them. You write Apex controllers for advanced business logic.
Is Visualforce Going Away?
OK. So back to the question that started me down the path of thinking about the future of Visualforce…is Visualforce going away?
No. Visualforce is not going away. Anytime soon, at least.
I know everything you hear from Salesforce right now is Lightning, Lightning, Lightning…but there are two key factors that are going to keep Visualforce around for a long time to come:
Visualforce has been around for a long time and there is a huge existing footprint.
Visualforce pages get billions of hits every month.
Lightning is an immature technology that will not only take years to reach any level of maturity, but will take years after that to be fully adopted by the Salesforce community
When I do the math, I don’t see the tipping point for Lightning coming for another 2-3 years. And I don’t see Visualforce being sunset anytime within the next 7-8 years…if that happens at all.
What is Lightning?
Here’s the $20,000 question. What is Lightning?
I think before we can answer that question, we first have to ask, “What isn’t Lightning?”
The marketing department at Salesforce loves their brand names. And they seem to particularly love the Lightning brand name. Because they’ve slapped it on literally everything.
Sales Cloud is now…Sales Cloud Lightning.
Service Cloud is now…Service Cloud Lightning.
I just saw “Lightning for Outlook” and “Lightning Sync” the other day…
OK…so there are a lot of products that woke up one day to discover that their names had been augmented with the word “Lightning.” I could probably spend hours talking about products that have had Lightning appended or prepended to their names, but we’re not going to go down that rabbit hole.
We’re going to talk about the two most important Lightning technologies: Lightning Experience and the Lightning Component Framework.
In the grand scheme of things, everything else is just noise. These are the Lightning technologies that matter because they underpin a powerful vision of a unified Salesforce experience across all devices and form factors.
Lightning: It’s All About the Experience
If we think about Lightning as the unified Salesforce experience across all of our devices, it makes our mission today much clearer.
If we think about designing and developing responsive, reusable components for this new unified experience, Lightning makes a lot more sense.
Traditionally, Salesforce UI design came down to two questions:
Do I want to recreate the look-and-feel of Salesforce with custom Visualforce pages?
Lighting Experience and the Lightning Component Framework solve a problem that has long been a barrier to a truly unified experience for all Salesforce users: Providing a single, integrated framework for developers that enabled the creation of rich, responsive applications that could be seamlessly “plugged in” virtually anywhere in the UI rather than having to stand alone in a separate container.
Whether Visualforce has a place at the table in this vision of a unified experience, and what the options are for moving forward from the page-centric world that Visualforce dominates to an app-centric world where the future is a story that is still being written.
Even though the framework itself will accept single quotes or double quotes for most operations, as an instructor and advisor I want to ensure that we teach good programming practices. In response, I have come up with some guidelines and recommendations for the use of quotes in Lightning Component code.