[SalesForce] Lightning Web component and Aura component performance difference due to the change in architecture

I am new to salesforce lightning web component.I did some of the example and found that lightning web component is way more faster than Aura component. This is due to the web stack architecture of aura component and lightning web component.

Aura component follows traditional web application architecture:

Lightning web component follows web application with web component:

can anyone please explain me with example, how lightning web component manages most of the processing at web standard level whereas aura component is handling those at Framework level when both have same javascript and apex controller at the backend?

Best Answer

Aura was originally developed before the finalization of the web standard Web Components. Before this specification came out, each framework (ReactJS, Aura/Lightning, etc) had to fully take over the DOM that JavaScript provides, providing custom filter functions to enforce security, transpile CSS rules to prevent components leaking CSS to other components, and so on. In other words, the framework was only as fast as the JavaScript engine it ran on.

After this standard was released, and browser vendors implemented it, many tasks that were previously performed in JavaScript could now be enforced by the browser. This is a much faster solution, because it can be optimized in a way that JavaScript cannot; the browser is much faster at rendering the DOM than it is executing JavaScript.

If you read the linked page (Web Components), you'll notice many similarities to LWC. This is because LWC is based on the standards. Salesforce and other vendors originally helped create the standard to begin with.

To give a different comparison, Aura is like software 3D graphics rendering, while Web Components is like hardware 3D graphics rendering. Hardware always performs better than software for the same algorithm. As stated before, this is the main difference between Aura and LWC; the former must be rendered entirely in software, while the latter is rendered mostly by the browser.

Note, however, that for supported platforms that do not implement Web Components (e.g. IE 11), performance for both Aura and LWC are about the same, since LWC has to be "emulated" by JavaScript software instead of browser functionality.

Finally, as an aside, newer frameworks are also using Web Components. It's not specific to just Salesforce. They implement them using different syntax structures, but the main benefits of moving to Web Components are improved encapsulation (and thus, security), as well as improved performance. The "traditional web application" model is slowly falling out of favor in exchange for a faster, more secure World Wide Web.

Related Solutions

[SalesForce] How to get the Value of a ui:inputCheckBox Lightning Component

Mohit points out that right now you aren't binding the value of the ui:checkbox to a component attribute, but that's not of concern here.

Using your code copied and pasted into a new component, I cannot reproduce your error. The checkbox state changes and it reports to console. Is there other code in the mix here? Is that your code verbatim?

That being said, both the dev guide and your code follow a bit of an anti-pattern in the event handler. Instead of setting a findable aura:id and hard referencing that in your controller, your code is much more useful (and would handle a list view) if you use the event source instead. Example:

handleChanged : function(cmp,evt,helper){
    var checkbox = evt.getSource();
    console.log(checkbox.get("v.value"));
}

This will fine the component that fired the event.

[SalesForce] Lightning experience page rendering is slow

Been there, done that. The practice shows that XHR is only a tiny bit of the page load performance, the biggest part is actual rendering. every single html element turns into aura:html component. Unnecessary two-way data bindings consume lot of resources.

The first recommendations would be conditional lazy-rendering of every category. In more details: render only first category, attach the scroll listener to vertical scroll, if scroll position is N pixels close to the bottom - load next category. Or simply just start with adding "Load More" link at the bottom.
adding pagination to the table will significantly help. In that case Lightning would need to render only particular subset of the whole long data set, make sure how long the tables could be, cause i saw lightning pages rendering two minutes or more until something will popup (1000 rowsX50 columns). Also make sure how many columns will be in your product, every single columns is miltiplier in performance.
if you ARE NOT going to change values in table, i would change by-reference expression, for example {!product} to by-value, for example {#product}, this would skip creation of two way bindings, make dom much lighter. In general, use by-value expressions as often as possible, try to refrain from by-reference two-way data binding
If you ARE going to change values - use inline-edit pattern, in short do not render inputs until user click/double-click on table cell.

Best Answer

Related Solutions

[SalesForce] How to get the Value of a ui:inputCheckBox Lightning Component

[SalesForce] Lightning experience page rendering is slow

Related Topic