Deciding to Use Lightning or Visualforce
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:
- Object Tabs
- Object Lists
- Record View
- Record Edit
- Record Create
- Record Delete
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.