19

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...

16

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

Embedding

  • Use Lightning Components in Visualforce [VF+]
  • Use Visualforce in Lightning Components [LC~]

Navigation

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

Media Output

  • PDF Generation [VF+ LC-]

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

  • @crmprogdev thanks for adding your points to this article, I really appreciate the teamwork and you are the only one who provided anything so far. But I have a question on them: are they really features we can compare as VF- and LC+ ? For me they are more kind of important things you should be aware of but not features in a narrow sense. So I would suggest to collect all of them under a new bulletpoint toplevel node, e.g. Lightning Details. Would this make sense? – Uwe Heim Nov 2 '15 at 7:51
  • @crmprogdev it is about $A.getCallback(), My Domain, Slimmed Down JavaScript API Doc – Uwe Heim Nov 2 '15 at 7:54
  • however you'd like to handle them is fine by me. Was preparing W16 presentation when I came across some of them. As FYI, slimmed down JS API is distinct from deprecated $A.run(). Std JS isn't safe for use in components if not in slim API. Can only run in underlying framework, so be careful of what you call. Is huge limitation in my view of what one can do. – crmprogdev Nov 2 '15 at 16:17
  • 1. This should be a community wiki. 2. You have several features where your description indicates LC~ but your header reads LC-. – Adrian Larson Feb 16 '16 at 17:33
6

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.

  • does the wiki-feature on SFSE-Meta support tables? Any other idea how or where to create such a public document (Read-Write for everyone)? I could provide almost 10 line-items right now. Doing it here with bullet-points will end up in a kind of unreadable tapestry, I guess... – Uwe Heim Oct 21 '15 at 17:18
  • The forum now supports the use of some html tags which at one point it didn't. You might test it out to see what you can do. A wiki is more of a post that's been "declared" as a wiki using the checkbox underneath it by it's author or by a moderator. See salesforce.stackexchange.com/help/privileges/community-wiki. – crmprogdev Oct 21 '15 at 23:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.