Feature matrix comparision: Lightning Components vs. Visualforce (now and roadmap)

Question

Within the last view days I found that a lot of basic functionality available in Visualforce is not available in Lightning Components right now. At some features I was surprised a bit, because I considered them as the heart-and-soul of the force.com platform. But since Lightning Components are evolving and still in BETA, it's fine.

Now to save time for digging and testing each single feature individually, it would be very helpful to have a feature-matrix what we have (or have not) in Visualforce and Lightning right now and what is on the roadmap with a target date - and on the other side what is not on the roadmap and maybe why.

I know, I ask for a lot, but this is very important for developers to pick the right framework for a set of given requirements today.

Also to make reasonable decisions if a developer should start to build a feature on his or her own. Imagine you need to automatically populated picklist-values from metadata-definition: is it really not available?? should you start to implement it or not? If it comes within the next 6 months as a native feature, you might wait or continue with Visualforce. If it's not on the roadmap at all, you might start to implement it immediately today...

Other features might be obsolete or there are best practices with entirely different approaches.

Is there any feature-matrix available? Should we start something right now? Maybe here as answers? I could contribute some points I found out. Unfortunately no tables are supported here at SFSE, otherwise I had had started already...

Answer 1

Please feel free to edit this answer! Caveat Emptor: I'm doing my best to update it as precisely as possible, but can't promise everything is correct and stays correct.

To get things rolling, here is a collection of topics which belong to the feature-matrix I have in mind. Since most them have no final answer, I think this format might be a good start. I've added the intermediate (maybe wrong) results in square brackets at the end.

Legend

• VF = Visualforce
• LC = LightningComponents
• + = available
• ~ = partly available
• - = missing
• ? = unknown, not tested

Bugs or necessary workarounds I would count as missing.

Any suggestion on how to create a matrix or table here is welcome. Feel free to extent.

Forms and Inputs

• Field-Labels from Metadata [VF+ LC-]
  • LC: confirmed missing feature (2015-10-28). No ETA yet.
• Custom-Labels using $Label [VF+ LC+]
• Dependent Picklists [VF+ LC?]
  • can anyone test this please?
• Picklist Values from Metadata [VF+ LC-]
  • LC: with force:inputField but buggy. Workarounds available
• Lookup Inputs [VF+ LC-]
  • LC: with force:inputField but confirmed bug (2015-10-28), workarounds available. Safeharbor ETA Spring'16
• Polymorphic InputFields [VF+ LC~]
  • LC: force:inputField and force:outputField are working partly
• Localiced Numeric Inputs [VF+ LC-]
  • LC: confirmed bug (2015-10-30). No ETA.
• Inline Editing [VF+ LC-]
• Supporting a Viewstate [VF+ LC-]

Embedding

• Use Lightning Components in Visualforce [VF+]
• Use Visualforce in Lightning Components [LC~]
  • only partly: there is a Component for App Builder but not yer for Community Builder

Navigation

• Using URL-parameters and #anchors in Communities [VF+ LC-]
• SPA-Navigation out of the box [VF~ LC~]
  • VF: I count the rerender-attribute as partly
  • LC: you have to swap, add, delete, hide or show components in your own logic. There is no strong customizable pattern as $route in AngularJS
• Support for Browser-History, Forward/Backward, Deeplinks, Open-in-tab/window [VF+ LC-]
  • possible unexposed feature in S1/LE. Not available for Community, Standalone Apps or subnavigation

JS Frameworks and Libraries

• General Usability [VF+ LC~]
  • LC: you need to be careful since Aura in LC itself is a JS-Framework and might clash with additional frameworks. At dreamforce'15 they encouraged us to use additional frameworks as rarely as possible.
  • LC: See W 16 release notes on JS usage: only use the set of supported JS methods in the "Slimmed Down JavaScript API Doc". SF is not guaranteeing support for code that uses unsupported methods.
  • VF: almost all frameworks will work nicely
• Use CDNs [VF+ LC-]
  • LC: CDNs blocked by CSP, need to use Static Resources
• Caching Prevention for updated Static Resources [VF+ LC?]
  • having an premier+ case open, yet

Development

• It's essential as of Winter16 that "My Domain" be enabled both to use and to develop new or existing Lightning Components. See Important Change to Lightning Components in Winter 16. [LC]
• Not possible to see all JS-errors in Communities [VF+ LC-]
• LC: Use $A.getCallback() instead of $A.run() which has been deprecated.

Media Output

• PDF Generation [VF+ LC-]

Your feedback is very welcome, especially if I got something wrong, please let me know!

Answer 2

I would certainly agree that a wiki of sorts would be appropriate and useful to our members. This post might best be migrated or reposted in SF.SE Meta for further discussion to address the issues you mention regarding a matrix.

As for feature Matrix, the most glaring issue that I'm aware of is support for PDFs. We all know that this has been a bane for even Visualforce pages for quite some time. When you can't even render HTML5 pages as PDFs, there's absolutely no way you're going to render Lightning pages as PDFs. In fact, it's in the release notes.

It's also in the release notes that some pages can't even be printed. This doesn't especially surprise me when you have layer upon layer of JS active content running that the browser and OS may not be able to freeze long enough for it to compose instructions to send to a print driver. Printing a screen capture would be a different matter, but of course, that would be a huge PITA and not very scalable.

As you've mentioned, there are many other "gotchas". In my view, Salesforce Lightning is something of a "public beta" that's intended to appease the critics of Salesforce who've wanted a more appealing interface by showing them in advance what they've been working on. Unfortunately, they've done that before it was ready for "prime time" and we'll be helping them develop it.

It's also something that has huge appeal for meeting their goals of making as much as possible "point and click". That said, just like Process Builder, there are going to be "pain points" for those who don't know or understand the limitations. Imagine adding lots of components that don't work well together through point and click? Think of what will happen when you have layer upon layer of JS running in the background constantly checking for events from the client side, plus talking with several controllers on the Server Side?

That said, what Salesforce has accomplished for their benefit is transferred page composition from their servers to the client. Think of the benefits to them in terms of overhead. That's got to be a huge gain for them. It must be freeing up huge amounts of processor time; enough that they can afford to increase the roll-ups on M-D relationships from 10 to 25 for free!

Apologies if this sounds like a rant. It's not intended as one. It's a case of also wanting to share how I view some of what are the issues that surround Lightning and it's implementation as well as the motivation that's behind its architecture. As you're learning, there's much more responsibility being placed on Devs who design components than there are Devs who write VF pages using standard controllers.