Should You Build it with Lightning Components or Visualforce

A question I’m often asked at the moment is which technology should be used to build new Salesforce UI capability — Visualforce or Lightning Components. The answer I give, from the perspective of those asking the question, is somewhat less than optimal. It depends … on so many things.

This is what you should be focused on from the start. In my experience, most customers won’t care what technology you use to satisfy their requirements. What they won’t be happy about is you expecting them to compromise their experience so that you don’t have to compromise your technical integrity.

The purpose of the exercise is not for you to demonstrate your mastery of the most complex combination of languages and libraries, it is to deliver the experience the customer wants with maximum ROI, and ease of maintenance going forward.

This should always be the first question that you ask yourself when considering custom functionality on the Salesforce platform. If you can find a declarative solution, potentially even one that sacrifices some ease of use for ease of maintenance, always go that route.

Want to use the Salesforce Lightning Design System? Works fine with both (even with standard Visualforce components, with a little jiggery pokery).

Want to keep the business logic on the client side? That means you either need Lightning Components or Visualforce remote methods.

Want to use a third party JavaScript library? No problem, you either include it via a standard Visualforce component or a standard Lightning Component.

Lightning Components don’t have a built in unit test framework.

Visualforce embedded in Lightning Experience record pages won’t be sized correctly.

If you have hard requirements that only one technology supports, then you are golden and the decision is easy. However, its more likely that you’ll have hard requirements that only a combination of both technologies supports. In which case you have to continue evaluating the pros and conse.

Consistency is important when creating apps or extending standard Salesforce functionality. Being able to jump straight into a customisation and understand the technology and approach used means that productivity is maximised — something both your employers and customers will like.

Also, while its great for developers to play with the latest and greatest, a customer that finds themselves looking for recruits with Apex, Visualforce, JavaScript, Angular, React, <insert popular framework of the day here> is probably not going to be pleased that they have indulged themselves. Always think about what you are leaving behind for others to maintain.

If you are an Apex and Visualforce shop, building functionality using Lightning Components requires your developers to skill up in JavaScript. Conversely if your developers have been building rich web applications with the business logic in the front end, choosing Visualforce will require them to learn server-side technologies.

If your customer has presented you with a tight budget, then there probably isn’t money available to skill up existing staff, unless your employer is prepared to pay for that themselves. Even if the money is there, an aggressive timescale (when are they ever not?) means that finding the time to learn will be a challenge. A combination of both means that you should look to play to your strengths rather than take a punt on the unknown.

As Visualforce is a mature technology, it has a number of rich standard components that take a lot of the effort out of development — the inputfield component, for example, generates the appropriate widget to capture input based on the field type. Security is also baked in — using a page managed by a standard controller, if a user doesn’t have access to a field then it will be hidden from them.

Lightning components, however, are much younger and only provide the basics. You’ll find yourself writing a lot of code to provide features that you would otherwise get for free, and the chances are that you’ll be able to throw a lot of that code away as the Lightning components framework matures and provides these features out of the box.

If you are looking for a collection well-designed, well-written and highly re-usable Lightning components out of a piece of work, you won’t get them from your first attempt, especially if you are relatively new to JavaScript. You’ll make decisions that will turn out to be misguided, the framework and requirements will change underneath you, and you’ll end up making compromises to hit the deadline.

These compromises usually mean fixing a component in the current use case, as you don’t have the time or the budget to continually refactor and maintain the high re-usability bar that you started out with. That’s okay — the purpose of doing work is to turn a profit, and burning through the budget (and more) in the pursuit of artificial purity is a pretty quick route to financial problems. Treat it as a learning experience — you might not have achieved Valhalla this time out, but you know at least one misstep to avoid next time around.

If you have a bunch of business logic currently sitting in Apex classes on the server, then you probably want to favour Visualforce. If you were to use Lightning Components you’d either have to re-implement in JavaScript (and now you have two versions to maintain — congratulations!) or go back to the server every time the user did anything, which rather misses the point of a client side framework.

If you’ve already built a number of re-usable set of Lightning Components that will satisfy many of the customer’s requirements, it makes perfect sense to build these out to satisfy the rest of them. Re-implementing in another technology rarely makes sense — the best case is that you are on another “platform” and the user’s don’t notice any difference, the worst case is that you break loads of stuff that nobody asked you to change.

There is no right answer. At least not yet. Once the Lightning Component framework achieves the same richness as Visualforce in terms of standard components and declarative controller functionality, the decision will be more straightforward.

As of now, there’s nothing wrong with building in Visualforce, even if it feels like Lightning components are the future. There are millions of Visualforce pages out there. Salesforce have put a lot of effort into making sure that these work correctly in the Lightning Experience, and Visualforce isn’t going away any time soon, so don’t feel guilty for not forsaking it.

I’m better known in the Salesforce community as Bob Buzzard — Umpteen Certifications, including Technical Architect, 5 x MVP and CTO of BrightGen, a Platinum Cloud Alliance Partner in the United Kingdom.

You can find my (usually) more technical thoughts at the Bob Buzzard Blog

CTO at BrightGen, author Visualforce Development Cookbook, multi Salesforce Developer MVP. Salesforce Certified Technical Architect. I am the one who codes.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store