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.
What is the business need?
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.
Do you need code at all?
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.
You can do most things with either of them
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.
You can’t do some things with one of them
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.
What have you used in the past?
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.
What is the existing skill set?
What is the budget?
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.
What is the complexity?
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.
What do you want out of it?
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.
Are there existing artefacts?
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