Salesforce developed an open-source generic framework called Aura. Aura, in conjunction with the Force namespace, has created many of the new technologies that Salesforce has released under the umbrella of Lightning. The Process Builder, Lightning App Builder, Community Builder, Salesforce1 Mobile, etc. are all built using the Aura framework with the components specifically designed for Salesforce (Force namespace). The Aura framework can easily be compared to Google Polymer or Mozilla Brick in that it is designed to produce modular components. This is very different from how Visualforce is designed, but we will address that later in this Blog. I figured that it was time to address a few questions I’m asked frequently:
What’s the difference between Lightning & Visualforce?
Will Visualforce go away now that Lightning is here?
What’s going to happen to all of my current Visualforce stuff?
Is there a way to convert Visualforce to Lightning?
What’s the difference between Lightning and Visualforce?
Visualforce and Lightning both offer ways to design and create custom interfaces for Salesforce. This has created the extremely common question of “What’s the difference between Visualforce and Lightning?”
Visualforce was designed to follow a Page-Centric model. This means that the intent of Visualforce was to create something that was your full-page interface with Salesforce. When the user needed to perform some kind of operation, like Save a record, it would send that request to the Salesforce servers and then reload the entire page with the new state of the UI. All backend processing is done with Apex Code on the Server-Side. You have the option to inject JavaScript into the mix to handle some of the Client-Side processing, but it isn’t the default interaction methodology. Visualforce was also primarily built for Desktop. When Visualforce was first launched back in 2008 the iPhone had been out for about a year. The concept of designing things “mobile-first” hadn’t yet been realized, this would come a few years later.
Visualforce also uses an HTML-like markup language for designing the pages and Apex code to handle the database operations. Here is a breakdown of what you have with Visualforce pages:
Visualforce Page – HTML-like markup language used to design the layout of the page.
Standard Or Custom Controller – Apex Code to handle Server-Side operations executed from the Visualforce page (EX: CRUD operations).
Optional: CSS Styling – Style your Visualforce page to look a specific way within the header or by file reference.
Optional: JavaScript – Used to handle Client-Side processing or to be coupled with CSS for a cosmetic revamp of the UI.
Optional: Apex Extensions – These are used to perform logical operations that are not housed within the standard or custom controller.
Lightning was designed to follow an App-Centric model. This essentially means that it has been designed to create self-contained components that build on top of each other. To put this in perspective, with Visualforce you would send an interaction to the Salesforce server and then update the entire page. However, with Lightning, you can send an interaction to the Salesforce servers and then update a specific component. This has huge implications for performance and for the fluid motion of a UI. This allows us to design UIs that are inherently responsive to the user interactions, meaning we update the things the user is interacting with and everything else remains untouched.
The components themselves can either have the logic process on the Client-Side (using JavaScript code) or on the Server-Side (using Apex Code) depending on what the component is designed to do. There is a great Blog Tutorial on how to use both types of processing within the Lightning framework. The Lightning Components and Applications come in “Bundles” that store all of the necessary files to run. Let’s take a look at what a Lightning Component Bundle includes:
Component – Markup language used to structure the layout of the component.
CSS Styling – Used to change the cosmetic look or style of the component.
Controller – Use a JavaScript Controller to handle Client-Side logic processing or use an Apex Controller to handle Server-Side logic processing.
Design File – Used to describe the design-time behavior of the component when used in Lightning Pages, Lightning App Builder, or in Community Builder.
Documentation File – Provides sample code or reference documents for others to use when they get your component.
Renderer – Used to override the default Client-Side render settings of a component.
Helper – Used to store reusable JavaScript functions that are handled by the Renderer or Controller as well as executing Server-Side actions.
Optional: SVG File – Allows you to include custom icons for reference within your component.
Will Visualforce go away now that Lightning is here?
There are still plenty of things that Visualforce can do that Lightning cannot currently handle. To name a few, Lightning can’t make a Homepage Component, email templates, or render pages as PDFs. This is likely something that will change with future releases of Lightning, but for the time being this is the situation. For a full list of things that you should consider when deciding Lightning or Visualforce for a project, you can read this Trailhead exercise.
Until now, there really wasn’t a large advantage to building and designing Lightning Components compared to Visualforce Components other than it is the new technology that Salesforce will be developing moving forward. Now that Lightning for Desktop is here we can really begin to see how creating and designing modular components to be used both in mobile and the desktop experience will change the design structure of things. Lightning also brings out a native approach to allowing people to drag-and-drop components onto a canvas to quickly create a new page or application. If you wanted to do this with Visualforce you would have to use a platform like SkyVisualEditor to get this done, otherwise, you are stuck digging through code. This brings about a new level of design to the ISV community so that they can package and distribute smaller re-usable components to their customers.
Will Lightning kill Visualforce the way Visualforce killed S-Controls? My guess is probably, but it will take many years to do so. S-Controls were quickly killed off in favor of the rapid expansion of Visualforce and the scalability that Visualforce had over S-Controls. Lightning will likely do this as well, but because Lightning is being rolled out in phases it will take several years for Lightning to be accessible in all of the locations that Visualforce currently is. Then you have to account for the several years before people begin to actively rework their Visualforce code into Lightning Code to support the architectural changes. I’m not talking about simply taking your Visualforce page and inserting it into a Lightning Component, I mean really reworking the Visualforce Page to utilize the component methodology that Lightning brings to the table. I predict that Visualforce will eventually die off, which is quite a statement coming from someone who works at a company that offers a platform to create Visualforce code, but it will probably be 6-10 years down the road before the tides really shift in favor of Lightning and Visualforce becomes that thing we used to do.
What’s going to happen to all of my current Visualforce stuff?
Nothing in the short term. You can continue to use your Visualforce pages without any change needed in the new Lightning Experience. However, it would be to your advantage to investigate what it would really take to slowly begin the process of changing your Visualforce pages into Lightning Pages over the next several years.
There is quite a learning curve to switch from Visualforce to Lightning. The changes aren’t as easy as one would think unless you lived and breathed Visualforce, Apex, and JavaScript for the last several years. Times are changing though, so get ready…
Is there a way to convert Visualforce to Lightning?
There is no simple method of converting Visualforce to Lightning. The two models of development are completely different. Lightning is designed to be a series of independent components that send and receive events to one another whereas Visualforce is designed to handle everything within the page itself. There just isn’t a simple way to translate that.
Summary
Visualforce and Lightning currently each have their own pros and cons that should be considered the next time you head into a development project. If possible, go the Lightning route so that you don’t have to translate your project into Lightning in the future. Overall Visualforce will be here to stay for many many years. There are simply too many Visualforce pages in existence for Salesforce to terminate support for them any time soon. Use Visualforce to your heart's content, but ensure you have a strategy to eventually move to Lightning.