Learn About Bundles and the Request Lifecycle



Since Lightning Web Components is the preferred way to build UI with Salesforce, head over to the Migrate from Aura to Lightning Web Components trail to learn how to use LWC and comply with current web standards. Otherwise, continue with this badge to learn more about Aura.

Learning Objectives

After completing this unit, you’ll be able to:
  • Describe the difference between a Visualforce page and an Aura component bundle, and how each is represented in resources locally and on Salesforce.
  • Describe basic differences in the Visualforce and Aura component request lifecycle, and where component code runs.

Before You Go Further

You should have a basic understanding of Salesforce DX projects and Salesforce CLI. You’ll also need to use a properly configured org in your Trailhead account and VS Code with the Salesforce Extension Pack. You can learn about all of this by completing the first two units in Quick Start: Lightning Web Components. There, you'll set up your Salesforce DX environment and Visual Studio Code.

Core Concepts

In this module, we look at Visualforce concepts and features, and then describe the closest translation into Aura components. Not everything maps cleanly across. Visualforce and Aura have fundamental differences in architecture, and different requirements for how you use them to build apps. We’ll explain as many of those differences as we can, using the individual features as our signposts.

Note that we’re not explaining how to use Aura components features in detail here. (That’s the Aura Components Basics module.) Instead, we’re focused on making essential differences clear, so that you can avoid turning things that sound the same into chutes you spend time sliding down.

Concept: Page vs. Bundle

Before we tackle some of the abstract concepts, let’s look at something that’s fairly concrete: how an individual page or component is stored on Salesforce.

Visualforce pages (and Visualforce components, but let’s set those aside for now) are stored on Salesforce as a single entity, an ApexPage. When you use Salesforce Extensions for Visual Studio Code or another tool to copy your Visualforce pages to your local storage to work on them, an individual Visualforce page is represented as two files in the metadata/pages directory:

  • yourPageName.page
  • yourPageName.page-meta.xml

The first is the code for the page, and the second is the page metadata (API version, mobile settings, and so on).

Although your page might have dependencies on other artifacts, like an Apex controller or extension, static resources, and so on, they are separate from the page. Your page references them, but doesn’t include them.

An Aura component has more to it than a single code artifact plus metadata, with up to eight code artifacts plus metadata today (nine total). For this reason, an individual component is stored in a bundle that includes resources. This bundle is represented as a folder of files when you save it to your local storage. A complex component might look like this: An example component bundle

We’ll talk about the most important resources in the component bundle throughout the rest of this module. For the remainder, see the details in Component Bundles and elsewhere in the Lightning Aura Components Developer Guide .

Ladder! Use these steps to create an Aura component bundle in Visual Studio Code with Salesforce Extensions installed:
  1. Press Command + Shift + P on a Mac or Ctrl + Shift + P on Windows or Linux to open the Command Palette.
  2. Create a project in the Command Palette using SFDX:Create Project.
  3. Create a component bundle in the Command Palette using SFDX:Create Aura Component.

In the challenge for this unit, you authorize Visual Studio Code to deploy files to your org. You need to know the username and password for your org. To get your Trailhead Playground username and password, see the Trailhead Playground Management module.
For more information, see the Aura Components Skills & Tools module.

Concept: Server-Side vs. Client-Side

This is one of the two “obvious” biggies. Except, actually, what’s obvious about it? Let’s be clear about what this means, and then make sure some of the implications are clear, too.

Classic Visualforce runs “on the server side.” That is, when a page is requested, a Salesforce server processes the markup, and then the resulting HTML is sent to the requesting user’s browser for display. If the page has an expression (those things inside “ {! }” delimiters), it’s evaluated by the server. References to global variables are resolved on the server. If the page accesses a controller property, that’s processed on the server. And so on. For the purposes of this conversation, all of the “framework processing” happens on the server. (Note that we’re setting aside using Visualforce + JavaScript remoting as a mere container for your JavaScript app. But then you’re not really using Visualforce, except as a web server.)

The process for Aura components is the opposite. When a component is requested, the component’s resources are packaged up and sent to the requesting user’s browser. Most of this is JavaScript, with some markup providing structure. The browser runs that JavaScript, which renders the resulting HTML and inserts it into the existing “page.” (We’ll explain those quotation marks shortly.) Expression evaluation, global variables, controller properties—those are all resolved on the client.

Visualforce Request Cycle Aura Components Request Cycle
Visualforce request lifecycle Lightning component request lifecycle
  1. User requests a page
  2. The server executes the page’s underlying code and sends the resulting HTML to the browser
  3. The browser displays the HTML
  4. When the user interacts with the page, return to step one
  1. The user requests an application or a component
  2. The application or component bundle is returned to the client
  3. The browser loads the bundle
  4. The JavaScript application generates the UI
  5. When the user interacts with the page, the JavaScript application modifies the user interface as needed (return to previous step)

This major architectural difference has major consequences. For example, your component can interact with a user without requiring a new server request, but if your component needs to save or load new data, that does require a server request.

That sounds straightforward, or even obvious. But keep in mind, with classic Visualforce that interaction would come with a new, visible page request and reload. With an Aura component, the user’s interaction with client-side JavaScript feels more “live,” more responsive, so when the time comes to load new data, the latency of a server request can suddenly feel slow to the user—even if the overall experience takes less time than a Visualforce request!

You’ll find that Aura components perform well overall. However, without careful design of your server requests and how they affect the user experience, your users might very well think an app is “slow.”

We cover additional aspects of this divide in upcoming topics, but you need to keep the client-vs-server-side thing clear in your head when thinking about how the frameworks behave.

Keep learning for
Sign up for an account to continue.
What’s in it for you?
  • Get personalized recommendations for your career goals
  • Practice your skills with hands-on challenges and quizzes
  • Track and share your progress with employers
  • Connect to mentorship and career opportunities