Lightning Framework vs Standard Client Side Frameworks (i.e. React) // Which to chose when, and why?

Question

Disclaimer

Keep it objective! This one can get a little opinionated, please try to keep your answer specific to the facts a developer should be considering when choosing between two viable options for architecting applications.

How to choose lighting framework vs other client side frameworks

These days we seem to have more choices than ever as Salesforce developers.

The Lightning/Aura Framework definitely is the gem of the Salesforce community and is a game changer from the view state hell of VisualForce.

On the other hand, there are a ton of amazing client side frameworks (React/Angular/Vue/Redux), that have a monstrous mind share in the broader web dev community and play quite nicely in hosted visualforce pages.

There are clear advantages and disadvantages to each approach. But what does the community think about this? In what cases are lightning components the right choice? And in what cases would another front-end framework make sense? What are the pros and cons of each approach?

Key areas to consider:

• performance
• learning curve
• resource availability (React vs. Lightning Devs)
• 3rd party support
• security
• project complexity
• support resources (tutotorials, trainings, walkthroughs, api docs, example repos)

Answer 1

I haven't done much lightning development outside of a handful "hello world" apps, but I've been building React/Typescript/Visualforce apps on salesforce for several years and I'm confident that non-lightning/aura frameworks can work wonderfully with Salesforce.

It is possible to use most these frameworks INSIDE lightning containers, so I will speak mostly to developing a Visualforce SPA with something other than aura.

PROs of using React/Angular2/Vue with Visual Force

1: Get to enjoy a much larger ecosystem of packages, pre-built components, knowledge-base & community.

2: You get to use modern & robust development processes and tooling like Hot Module Reloading, type systems (typescript/flux), local debugging, application bundling, test frameworks, etc.

3: You can recruit developers from a much larger pool. The number of salesforce lightening developers is TINY in comparison to the number of react or angular devs. It also seems that the vast majority of them are junior (at least when it comes to javascript development).

4: You are free(ish) from the platform. If you write an application using aura, that application is never going to live anywhere else. If you write something with angular or react, it could more easily be migrated away from salesforce. If you wanted to keep the SF backend, it could be moved to heroku/aws with almost 0 effort.

*: Most the frameworks are just simply more performant, better designed, and more productive than aura. From what I've seen from aura so far (which isn't much), it's still not on the same playing field as react or angular2.

**: Even Salesforce sees the value of react. They are officially supporting the SLDS react component framework (even committed to an official web page). In the future, this question may actually be "Should I use React or Aura in my Lightening Component".

When you probably want to use lightning:

1: You're creating an encapsulated component (not SPA) that you want to live along side & communicate directly with other lightning components (you can still do this with react inside a lightning container). While VF pages can be embedded along side lightning components, it may not be as integrated/seamless.

2: You/your team doesn't have with any experience writing client side web applications. Modern web application has become much more complicated than it used to be. You need to understand dependency management, bundling, environments, etc. Architectural choices must be made on which framework, tooling, etc should be use. When developing on salesforce native tech's, you trade freedom, flexibility and capability for simplicity.

3: ??? I'm sure there are many other use-cases beyond the scope of my knowledge where platform restrictions might limit your ability to use these outside frameworks.

UPDATE

Even with the release of LWC I think most of the above still holds true. LWC are definitely an improvement over Aura (especially in performance), but IMO still way behind react/vue/angular in terms of productivity, scalability and community. LWC is still more of a framework for writing "widgets" than full blown SPA.

If you need uncompromised control over your application, the a VF page + React/Angular/Vue is the way to go.

Answer 2

To begin with I would approach your question different way rather than

In what cases are lightning components the right choice? I would ask my self

In what cases are lightning components not the right choice?

Which Library Do You Need?

Third-party libraries usually fall in one of the following categories:

1. DOM manipulation libraries (jQuery, etc)
2. Specialized utility libraries (moment.js, numeral.js, etc)
3. UI libraries (Bootstrap, jQuery UI, etc)
4. Data visualization libraries (D3, Chart.js, Leaflet, etc)
5. Component Based frameworks (React, Angular, etc)

Before we look at how you can use a third-party library in a Lightning Component, it’s useful to ask yourself why you are using it, and if you really need it. In some cases the answer will be a resounding yes: nobody wants to reinvent a data visualization library like D3 or a mapping library like Leaflet. In other cases the answer will be less clear. Let’s take a closer look at DOM manipulation libraries, UI libraries, and MVC frameworks in particular.

DOM Manipulation Libraries:

JavaScript has come a long way in recent years. Many DOM manipulation utilities we couldn’t live without in libraries like jQuery are now standard in the language. Modern frameworks like the Lightning Component Framework also provide abstractions that make jQuery less relevant

In the Lightning approach, the model and the view are decoupled: your code doesn’t have to reach into the DOM. This leads to more robust and more maintainable code. Avoiding direct DOM manipulation is a best practice in the Lightning Component Framework (like in most modern frameworks), and you might just discover that you no longer need your DOM manipulation library.

UI Libraries:

You may also want to reconsider the use of UI libraries like Bootstrap and jQuery UI. Although these libraries provide useful components, they have their own UI identity that can clash with the Lightning Experience identity. The Base Lightning Components and the Lightning Design System offer similar capabilities while providing a consistent user experience.

Component Based Frameworks:

At a high level, libraries like React and AngularJS have the same focus as the Lightning Component Framework: They provide code organization and utilities to create components. If you are looking for a component framework to develop applications on the Salesforce platform, you should use the Lightning Component Framework because it’s tightly integrated with the platform. But you can also use other frameworks if you so desire. All you have to do is choose the isolation mechanism (LockerService or Lightning Container Component) that works with your framework to avoid security exploits.

My Personal Experience:

I started with lightning back in 2016. Back then I get to mess around with jquery, kendojs(and couple of others too).

There are couple of reasons for using jQuery:

1. Leveraging data tables
2. Slicing and dicing the data and pushing it to the DOM

Kendo.js : Mainly for UI specific functionalities again like kendo grid, slider and many other one's.

Back then it made sense because lightning was new to broader community plagued by issues and bugs and bad documentation. I felt the need to depend on third party libraries and even slds was not what it was today. No well documented examples. Ahh it was a nightmare.

If I want to think about using the same-thing today I would rethink about it, because lightning as a framework matured a lot and keep getting better with every release I would want to make sure I truly need them.

And also with Locker service in picture it's hard to use libraries that doesn't adhere to its rules. Remember locker service is not the issue. It was built for a reason and that reason was security. Locker service also opened up and kept getting better for ex:usage of evals.

What made sense recently was using frameworks like D3 and chartjs or util libraries because you don't want to write everything from scratch that are not available in lightning. So in the end the idea is to look what you can do with lightning and look out for 3rd party libraries when you can't do the same things with lightning or it's not worth the time rebuilding it in lightning.

I might be right or I might be wrong but this is just out of my experience.

Update with Lightning Web components:(Spring 19)

Lightning Web Components is a new programming model for building Lightning components. It leverages the web standards breakthroughs of the last five years, can coexist and interoperate with the original Aura programming model, and delivers unparalleled performance.

If you are already developing Lightning components with the Aura programming model, you can continue to do so. Your Aura components will continue to work as before. You can build new components with Aura or Lightning Web Components. Your Aura and Lightning Web Components can coexist and interoperate. Over time, you can consider migrating your Aura Components to Lightning Web Components, starting with the components that would benefit the most from the performance benefits of Lightning Web Components.

If you are new to developing on Lightning or if you are starting a new project, we recommend using the Lightning Web Components programming model.

Answer 3

Wow, with the very good and detailed answers already provided, mine is going to seem almost meaningless by comparison.

I've been working with Lightning for a couple years now. Before I started, I had no experience with HTML, CSS, or Javascript, and had never worked with any of the other frameworks, and still haven't.

Although Lightning is still a young framework, I've managed to build solutions using it without feeling the need to go investigate or learn another framework like React, etc. Any pieces that were missing, I've managed to fill in by using other tools. The biggest missing piece I run into consistently is advanced data table handling, but I fill that gap quite handily using things like jQuery and DataTables.

So far, there hasn't been a gap in Lightning big enough that I felt compelled to go investigate another framework. To be honest, I have no desire to, nor the time. I suppose learning another framework would make me a more well-rounded developer for career purposes, but my Salesforce and Lightning skills have been VERY good to me. In fact, I'm on week two of a new job that was a major career advancement for me, due in large part to my Lightning skills. Based on my own experience (YMMV of course), I find more value in keeping my Salesforce and Lightning skills up to date than pursuing other frameworks, especially since as a young platform, Salesforce is introducing new things to Lightning all the time.

Bottom line - since Lightning is so tightly integrated with the platform, gaps can be filled with a few other tools, the solutions work for customers, and the skills are very marketable (selfish reason, I know, but still a realistic one), I haven't looked at other frameworks. But I'm sure they do provide value in the right scenarios.

So, there's my .02 for what it's worth. I wish I could contribute more towards the "other framework" discussion, but I'm just not familiar with them enough to contribute anything.

Answer 4

Considering that the Aura Framework has now been archived. Not worth investing much in it. However, it has been replaced with Lightning web components which follows another model that leverages building custom HTML elements built using HTML and modern JavaScript. And most pre-build components have been migrated.

In my opinion, the learning curve here is not as steep as the Aura framework for developers that are not SF natives. Lightning Web Components are basically, Web Components, which adhere to modern web standards and act as extensions of HTML. Any web programmer which is up to date will have an easier time with this programming model.

Web components are based on existing web standards. Features to support web components are currently being added to the HTML and DOM specs, letting web developers easily extend HTML with new elements with encapsulated styling and custom behavior.

Web Componenets have been around for some time and have been the subject of many discussions. (similar to this post, should you use web components or other frameworks,such as react, however, both are complementary and serve difefrent purposes).

In what cases are lightning web components the right choice?

• Whenever you need to interact with data from the server.
• If you need performance, today, this might way up in the list.
• Due to encapsulation, LWC's are more secure.
• if you can use a namespaced lwc's, use them

support resources:

• Developer docs - Introducing Lightning Web Components
• Many other online resources (ES6, web components, Javascript)
• Trailheads

In what cases would another front-end framework make sense?

• Well, if its already build, why re-invent the wheel? however, you have to ensure that that framework is locker-service compliant. In most cases, you might end up using a combination of both.

What are the pros and cons of each approach?

LWC Pros

• Performance
• Secure
• encorouages/enforces some best practices when coding
• Develop Locally (imo - this is a pro)

LWC Cons

• Namespace'd components - not easily customizable

• Most of the time, end up buidling from scratch using SLDS Blueprints.

• Not supported everywhere, refer to Supported Salesforce Experiences and Tools

Other Framework Pros

• Depending on the frameworks purpose, less code to write to achieve an end

• Easier to find developers with a frameworks expertise

Other Framework Cons

• Size of the library

• Must adhere to specific versions supported by locker service

• Need to integrate in LWC's and not all library methods may work.

Refer to: Securely Using Third-Party Libraries in Lightning Components Key areas to consider: