Why should Salesforce developers consider moving to Lightning Component development?
For starters, Lightning is the future of Salesforce development. There is no way around it – Salesforce is betting the company on Lightning.
If you ignore that and simply focus on the value that Lightning can provide, you will find that there are many compelling reasons for making the jump to Lightning.
From a single code base, you can create reusable components that will give your users a unified experience across all form factors. You no longer have to maintain separate desktop applications, tablet applications and mobile applications.
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.
Admins can 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 and programmatic 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.
Rendering on the client side will reduce the need for mobile applications to make expensive calls to a server API, significantly improving performance in low bandwidth situations.
If you have at least a cursory knowledge of web development, Lightning follows open standards and practices that you are already familiar with.
For new developers coming onto the Salesforce platform, Lightning provides an opportunity to quickly existing 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 user-driven events occur such as clicking a link or a button.
Granted, you can use specialized Visualforce tags 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.
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.