I know in the trailhead there is a comparison between Visualforce and lightning component. And I even made an answer to one question about this the other day.

But the question is, nowadays, most of us are not actually using much Visualforce tags in our Visualforce pages, it is pretty much an html page wrapped inside Visualforce. And for the client side logic, we can use frameworks like React, Angular or backbone.

So my question is, is there any good reason for us to use lightning? Or is it truly better? Frameworks like React, Angular or backbone have much more github tools supporting them, a bigger community and thus more built in tools. For example, consider adding filtering, sorting and pagination to a datatable in Angular or React, and then consider adding it in lightning component, the former is obviously much easier.

One good reason for using lightning component is it can be very componental. However, this can be achieved via other frameworks as well, although in a less decent way - using static resource. Is there any other good reason to use lightning?

  • 4
    Because sf told all app vendors they must be lightning ready by 3-2017 or else. I am with you though. A vf page is slds is much easier for me at the moment. But, using lightning does get you the components to display on the record detail page. Something I do not believe any vf page can do in lightning st the moment (I could be wrong though)
    – Eric
    Oct 22, 2016 at 13:03
  • @Eric I'd appreciate any links you have to "must be lightning ready by 3-2017".
    – Keith C
    Oct 22, 2016 at 14:01
  • It was said at Dreamforce. I did not her it but our cto was the one who said that was hat was stated at one of the sessions. Guess hearsay for now
    – Eric
    Oct 22, 2016 at 14:03
  • 3
    lightning ready does not imply lightning components Oct 22, 2016 at 14:21
  • @KeithC - Was in the partner keynote, Adam Seligman said it
    – Eric
    Oct 22, 2016 at 21:07

3 Answers 3


It really depends on your business Scenario of what you are trying to achieve and your UX approach and design decisions .If you want your users to completely align to standard lightning experience going lightning components route will benefit them in long term

If you are in ISV space ,then you want to try and use lightning component framework to provide end users(Your end users are other salesforce orgs where your apps are installed) flexibility to use the builders that salesforce out of box provides .

Building with React or Angular will imply admins or business consultants wont be able to configure or control the layout .Lets say you provide that ability then you are rebuilding the builders that salesforce has already built for you .

Salesforce is trying to provide a framework that does handle lot of things for you OOB .Lightning Action Services are great step towards that where salesforce will be providing a single tag that handles CRUD respecting org CRUD/FLS and sharing configurations.

In angular or React you are simply rebuilding lot of stuff that platform automatically gives in lightning component framework (Examples include Internationalisation , labels, Locale Date formats etc).

If you ask me as of today (22nd oct 2016) its lot better than how it was an year ago and its keep getting better and better .The base components ,Utility bars ,Quick actions , Lightning Out ,Added Interfaces all are pretty robust now to build a functional apps .While there are few gaps being a new technology with a learning curve and not much libraries available open source compatible its an extra pain which i am sure with time it will be sorted .So if you are thinking of future and planning to use salesforce wont be bad idea to go with lightning component framework and If you feel you are invested in SFDC for short term then frameworks like angular or react makes sense as that can be used with any other Technology Stack .

  • 3
    Definitely a lot better than it was a year ago. For me, at least, it was not even an option until it became available for use in Visualforce Pages. Now it's a sensible choice and I just haven't invested the time yet.
    – Adrian Larson
    Oct 22, 2016 at 15:35
  • I think for ISV's its right way to go as most of new orgs and new customers will straight start from the lightning experience just looking at UI after winter 16 and older orgs that heavily invested in VF will definitely still use VF .I started with S controls on platform and in an year i was outdated and everyone used VFs to build their UI and now i feel coming year from now will definitely see change .We as a developer have less say in terms of decision making as mostly its CTO and other executives who make purchasing decisions Oct 22, 2016 at 15:39
  • @MohithShrivastava - What I am struggling with is the "Lightning Ready" Is a VF page written using SLDS that does Visualforce remoting considered Lightning ready? I have not invested the time yet either. I am struggling with the ricght choice between a bunch of isualforce components or a single VF page. Right now Lightning seems overwhelming but the time has come to stat playing with it.
    – Eric
    Oct 22, 2016 at 21:13
  • Actually I had answered what is lightning ready certification ?Vf with SLDS is for sure lightning ready .You have to demonstrate salesforce that your app works under lightning experience Oct 22, 2016 at 21:16
  • 1
    interesting answer, although i would contend that alot of the things that are "OOB" with lightning framework could be thought of as "you just get the one implementation salesforce provided", in contrast with other libraries you get an entire universe of battle hardened libraries to choose from (along with amazing dev resources to go with it) Nov 5, 2018 at 18:27

My .02 for what it's worth...

I've never liked Visualforce development. It always felt like either I was wrestling with it to do what I wanted, or that I was faced with using it just as a wrapper for something based on Javascript, React, etc (which I don't know). And if I was going to use it just as a wrapper, I'd rather let dedicated UI and presentation folks write that part and just use APIs I'd write to pass data back and forth.

At Dreamforce 2015, there was a major push for Lightning but it was all new to me. It was overwhelming because I'm not a HTML, CSS, Javascript, etc, person and I didn't see any mature examples of what Lightning Components could do. At Dreamforce 2016, I attended nothing but Lightning sessions so I could wrap my head around what this thing is, and this year could see more mature examples of how everything worked. Everything "clicked" for me.

Now, I've started playing around with it and even though I don't have HTML, CSS, or Javascript skills, I'm slowly starting to figure things out and so far I really like it, and am taking baby steps piecing some components together to see what they can do.

One thing that's a major factor for me is that I work at a small startup and my main customer is a Support team made up of only 4 people, and I have a really good understanding of their workflows. They've been using a Service Cloud console up until now, and while it's usable, they could be a lot more efficient with a custom case management system.

I would never have tackled such a thing with Visualforce (either native or as a wrapper) but with Lightning, I'm really feeling like we can develop exactly what we need, use native Salesforce technologies, and explore mobile options for case management down the road.

Maybe frameworks like React, etc, are better in some way, but I wouldn't know because I don't know those frameworks. But just in my short time working with Lightning, my gut instinct is that it just "feels" right. I can learn it, make it do what I want, and develop a great solution using it for our Support team.

And from a maintenance aspect, there's a lot of appeal for using native Salesforce technologies because down the road if we hire additional Salesforce developers, we don't have to worry so much about finding people skilled in both Salesforce and React/etc, but can concentrate on finding somebody really good at Salesfroce development in general and they could probably pick up on Lightning pretty quickly if they don't already know it (like I am today).


If you must deliver soon, I suggest you keep using VF, which seems to respect ascending compatibility, which Lightning DOES NOT ( 1 year I use lightning, I know what i'm talking about :/ )

Undepending all the benefits provided by client applications ( lightning ) instead of server applications ( vf ), Lightning framework is highly unstable for now, so if you need to put something in production in the next month, DO NOT use lightning.

Just by browsing forums, you can see that each time there is a new update ( most famous one is "LockerService" , any lightning component who used to work perfectly doesn't work anymore) , so except if you want to have to debug your developments before each SFDC platform release ...

Most fun is sometimes you can adapt your code, and sometimes you simply can't , even if you try to rewrite everything, you are forced to wait for new SFDC platform updates , and the answer "it doesn't work but it's not supposed to work" or "use some crappy homemade workaround" comes too often from SFDC :/


You must log in to answer this question.

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