In 2015, I was part of an Agile team that was tasked with the initiative to convert a customer from Microsoft Dynamics to Salesforce. Prior to this change in direction, our team had been working on application utilizing AngularJS (client) and Spring Java (API). Salesforce was something new to all of us.

This was when Salesforce Classic was still the primary user interface. The Lightning look and feel was still being developed. I am sure you can image the shock we felt as developers when we started building an application that had a very-dated user interface. I even talked about our team's original reactions in the following article... my first article on dzone.com:

Into The Development Time Machine

On our project, I remember our team including JavaScript frameworks as static resources in the code, so that we could offer a more modern look and feel to some of the interfaces used by the application. Even more frameworks were added to make geolocation a functional aspect, which was a requirement for the minimum viable product (MVP) we successfully deployed six months after starting development.

Fast forward to now. Salesforce has continued to evolve their Lightning interface and to build out their Aura framework. This has been a great approach for those who are focused on Salesforce development. However, a majority of front-end developers have not ventured into the Salesforce development space, because Aura is considered a bit proprietary.

Introducing Lightning Web Components Framework

With the development teams at Salesforce realizing there are ~7 million active JavaScript developers, they have officially announced the Lightning Web Components framework.

Lightning Web Components provides a layer of specialized Salesforce services on top of the core stack, including:

• the Base Lightning Components, a set of over 70 UI components all built as custom elements.

• the Lightning Data Service which provides declarative access to Salesforce data and metadata, data caching, and data synchronization.

• the User Interface API, the underlying service that makes Base Lightning Components and the Lightning Data Service metadata aware, leading to substantial productivity gains.

According to Salesforce, Lightning Web Components "are built on top of the web standards breakthroughs of the last five years: web components, custom elements, Shadow DOM, etc."

In order to facilitate communication with existing Aura components, Aura and Lightning Web Components are designed and intended to coexist and interoperate.

Lightning Web Components Framework is currently in a pre-release mode with a plan to be part of the Spring 2019 release of Salesforce.com early next year.

My Concerns

Without diving into the details yet, I have to wonder if requests made via the Lightning Web Components framework will count toward daily API request limitations.

Back when we were building our Salesforce instance, we initially considered using a standard JavaScript framework (Angular or React.js) to build a better client experience for our customer. When we performed the analysis, we quickly realized there was a potential for exceeding daily API limits by having our custom application make API calls into common or custom API methods to obtain and update the Salesforce data for our implementation.

If this is not a concern, then this long-overdue functionality should provide a compelling reason for JavaScript developers to consider leveraging the Salesforce.com platform.

Of course, my secondary concern would be the licensing costs associated with utilizing the Salesforce.com platform.

If the organization is already subscribed to the Salesforce.com service and the Lightning Web Components Framework requests do not count toward daily API limits, then this should be a win-win for everyone involved. Oh... and finding resources just got a lot easier.

Have a really great day!