↓Skip to main content
  1. Salesforce.com/

3 Things I Don't Like in Salesforce Lightning

·4 mins
Salesforce Technology
Recent Articles

3rd Party API Integration Using Lightning Web …

Switch to Salesforce Consumer Goods Cloud and …

Salesforce Winter '24 Release Highlights for …

5 Tools for Salesforce Gurus

What is Salesforce Data Cloud (with use cases)?

Salesforce Lightning is great.

We have a sophisticated UI for the Salesforce product in Lightning-

  1. Choose a wide-array of layouts and display graphical and text data
  2. Provide responsive UI for users on any device
  3. Enable layered security for data access and extend the business layer functionality well into the UI
  4. Make it easy to implement data-driven behaviour

Lightning web components leverage the latest in web standards to provide a scaleable framework that can be well-supported in the foreseeable future. Having created products from scratch, I can get behind the innovations that go in the design and development of a product like Lightning.

But, I yearn for more. I want Lightning to take its rightful place with all the super-powers that are known to human-kind. Here are the 3 features that in my opinion are helpful in nudging Lightning in that direction.

1. Performance #

Have you switched to Salesforce classic recently? You must from time to time. I enjoy the smooth performance, navigation and respose from Classic UI.

Probably, much more than that, I enjoy the modern SPA behaviour as a user and can see the rapid transformation towards the modern UI stack everywhere - be it React, Vue and friends, the pluggable IntertiaJS for the old-guard, or Live Wire of Laravel. The modern UI stack encourages elements that are slick, (mostly) highly performant, reasonably light-weight, accessible, developer-friendly, and highly user-experience focused.

I get it - Salesforce Lightning is not simply a “UI framework”. It has many functions that go beyond just a simple SPA - may it be security, enabling dynamic behaviour, providing the right information at the right time, or enabling a seamless upgrade process thrice an year.

But, that should not prevent us from wishing Lightning to be fast - much more than what it is right now.

  • Fast loading
  • Light-weight
  • Speedy response to user actions

Salesforce has done quite a few things in the performance area.

  • LWCs are standards-compliant and are more light-weight than earlier
  • There are tools to measure page performance including load time measurement, an analysis tool to check performance and know why your page may be slow (click on Analyze button in Lightning page builder) and more.

2. Configuration #

Salesforce no-code / low-code solutions have set blazing standards in the industry for sometime now. A few clicks can give you a fully functional UI with security built-in and subject to automatic upgrades / enhancements. That was considered a pipe dream for enterprise products even a decade back.

Salesforce UI configuration has undergone drastic changes while staying true to the core values. To enable a Lightning UI, we now need -

  1. Create a layout with controls (buttons / fields / other)
  2. Assign layout to requisite profiles/ permission sets
  3. Repeat process if you need different UI behaviour for any profiles
  4. Create Lightning record pages, include appropriate layouts and assign them to profiles / permission sets
  5. Tag pages to supporting UI structures like tabs / apps

Sophisticated UI configuration may be the most basic ask of many large enterprises, but the complexity built up over years have overlaps and cause confusion with design decisions -

  1. Where would you map layouts and/or pages to profiles/ permission sets?
  2. Why create duplicate layouts even for simple differences in UI behaviour for different profiles or record types? ( Dynamic form is the right way to start solving this problem)
  3. Enabling required/read-only behaviour at various levels (control / layout, record page, SObject) may cause confusion when debugging the problem
  4. Which are the defaults for apps / record types / profiles? How and when did we start duplicating work and where are we today?

Ideally, I would provide one way to configure “stuff” and one window to see all that configuration.

Development Experience #

Custom Lightning UI with LWCs can be developed locally in VSCode. Any UI development is iterative and this should provide a boost to the development process. However, the local “simulator” shows a basic UI layout, allows a few “front-end"y things and not much more. Typical development process also includes testing with different data, validations, and a larger view of how the current UI fits in the overall application flow. We can only do all that after committing the code to the org.

While Salesforce metadata-driven development is fast compared to the extent of configuration it provides, the UI development process has room for improvement and provide better “local development tools”. This, I am sure, is a super complex engineering problem.

Finis #

Again, I am in love with of the powerful low-code platform that is Salesforce. As developers and implementers there are advantages and limitations that we accept and make it our own. Salesforce delivers a stream of innovations YoY, and I am sure there’s an army of engineers carefully evaluating the latest of technologies and charting a way forward for Salesforce. It will be great to see user and developer experience of UI accorded priority somewhere among the big list of things that need to be done.

↑