3

I have seen many Community Implementations in Visualforce and for whatever reason, migrating to lightning is not always in the roadmap, so we usually find ourselves either extending visualforce pages with more and more code.

I recently learned of being able to embed lightning components in visualforce pages, meaning we can re-use our existing lightning components, however, there is some effort to be invested in making them usable through visualforce.

Is there any benefit in doing this long term (5-10 years)? or should we just keep extending/adding code to Visualforce page implementations?

For those interested in the above -> Communicating between Lightning Components and Visualforce Pages

My first thought is that a customer will Eventually migrate, so the lightning component used in the VF page can be reused in the future, and in this case it will be the opposite, we would simply need to migrate the remainder of the VF page to a Lightning component.

1
  • I haven't really involved in communities implementations but the lightning component in vf page approach the way I look at is vf pages should be used just as dummy containers with actual implementation sitting in lightning components, so going forward it won't be painful to migrate and retrofit any vf logic to lightning components. Jun 22, 2018 at 1:52

2 Answers 2

4

Lightning is salesforce.com's future. They've invested heavily in it, and I don't think Visualforce has even had more than 5-10 features released for it in a number of years now, and those were mostly security- and Lightning-related. You may as well starting rewriting your UI in Lightning Components now, completely as possible, because if history is any indicator, Visualforce doesn't have a lot of life left in it.

I'm pretty sure that salesforce.com doesn't have a planned obsolesce date yet, as Lightning still lacks some core features of Visualforce, but salesforce.com is heavily encouraging the move, with such things as forcing all new AppExchange apps to be Lightning-Ready, etc. In ten years, Visualforce might still be supported as a "legacy" system, like S-Controls are today, but orgs will probably lose the ability to create or update Visualforce pages, etc.

Visualforce, as a technology, is already past its first decade of use, and Lightning is clearly meant to replace it for all practical purposes. Some of the underlying features might hang around (because PDF generation is useful), and I'm pretty sure they don't have a replacement for Visualforce Email Templates, but with technology like Lightning Out making it possible to embed Lightning Components on a page in about 10 lines of code, there's no reason to keep updating your Visualforce pages. Just build a new component, call it via Lightning Out, and everyone wins.

2

A key question here is cost vs benefit for you. If something is built out and working in Visualforce, and changes can be be made quickly and cheaply, then there is little incentive to introduce Lightning Components now.

The half-way house of embedding Lightning Components inside Visualforce pages suffers from additional development complexity - both learning the (very large) Lightning Component stack and dealing with the boundary between the two technologies - and typically results in pages that open more slowly. Also the styling of the two can be hard to get consistent. While the "how to write Lightning Components" knowledge you gain from doing the work can be carried forward, the actual components are likely to either be discarded or require significant rework when you move to a fully component based solution. The Lightning Component framework is still being improved: a component you wrote a year ago would be cleaner (and cheaper) to write now e.g. it is only in Summer '18 that lightning:datatable supports inline editing.

Not sure what special considerations might apply to Communities, but do suggest you research that specific situation.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .