9

I read:

  • Aura Components, leveraging its own component model, templates, and modular development programming model.
  • Lightning Web Components, built on top of the web standards breakthroughs of the last five years: web components, custom elements, Shadow DOM, etc.

Apart from both using SLDS, and perhaps common component names, at first sight, these look as different as Angular 1 and 2 are.

Can anyone who has worked hands-on with both Aura Components and Lightning Web Components - pilot participants? - comment about how much commonality there is in the framework and tools, and what the learning curve is like for Lightning Web Components?

(I'm hoping this doesn't get closed for being a matter of opinion; my aim is to get some insight into how easy or hard it will be to switch over.)

8

My take on this.

I have only been playing around with LWC since it was officially announced yesterday. I am not sure if a broader audience would have a detailed hands-on in LWC unless they were part of Pilot. With LWC announced only yesterday, it still has a long way to go before it can be widely adapted. Going through the documentation this morning, Salesforce seems to be working on quite a few things as LWC is not yet available on all Salesforce Experiences, viz., Lightning Out, or Standalone apps (as of today).

In my opinion, you don't need to make an immediate switch necessarily - it's more about choice of the framework you want for your UI customizations: Lightning Components OR Lightning Web Components, they both can/will co-exist. But over the time and with the recommended approach to go the route of Web Standards, it has to be LWC.

From a commonality perspective, even though the bundle structure of Lightning Web Component is different from Lighting Component, you will still find the markups and JS all around. Primarily the HTML Template and ES Modules.

From Learning curve perspective, I would think as long as you have a good hold of markups and JS, the learning curve will not be that significant. Whoever has worked with Lighting Components, will be easily able to co-relate things going around in Lightning Web Components. However, there will be significant learning required if one is not very familiar with ES6+ JS modules.

Based on my "limited experience", below are the key takeaways when going for LWC:

  • Learn about Web Components. Brush up your HTML and Javascript skills
  • Get yourself started with Salesforce DX (if you haven’t already done)
  • Make VS Code your choice of IDE. With what I could see on the Spring ’19 pre-release Scratch org, you cannot create LWC from Developer Console

I have a quick run down on LWC on my blog post here, if at all that provides any further insight.

  • Any insight into VSCode extensions for LWC? – Keith C Dec 14 '18 at 19:07
  • There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead. – Jayant Das Dec 14 '18 at 19:08
  • P.S. While we don't have Developer Console support, the Playground can serve as a suitable quick mock up tool (log in your spring 19 org, and visit /docs/component-library/overview/components. I've been playing with this, it's pretty cool, like jsfiddle but for LWC. – sfdcfox Dec 14 '18 at 19:19
  • 1
    Just a side note, The playground can’t access Salesforce organizations, so it doesn’t support features that require data from Salesforce. For example, the playground doesn’t support the wire service, Apex methods, scoped @salesforce modules, or components that require a record ID, like lightning-record-form, lightning-record-view-form, and lightning-record-edit-form. as quoted in the developer guide – codeyinthecloud Dec 14 '18 at 19:20
  • @sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting! – Jayant Das Dec 14 '18 at 19:20
7

LWC follows the "web standards breakthroughs of the last five years", which means it resembles coding similar to React and other languages that have moved on to ES6+. There is a learning curve, as things have changed (for the better!).

Having Aura familiarity isn't a bad thing, though. While things have changed, they've done so in a mostly predictable manner. For example:

<!-- Aura-based -->
<aura:iteration items="{!c.items}" var="item">
  <ui:outputText value="{!item.name}" />
</aura:iteration>

<!-- LWC -->
<template for:each={items} for:item="item">
  <ui-output-text value={item.name}></ui-output-text>
</template>

As you can see, everything changes subtly, but not significantly. The component names change based on a predictable pattern, things are shifted around, etc, but with the documentation in hand, you should find it's not too far off from what you already know. It's mostly the small "gotchas" that will take a while to solidify in your brain. I feel that any experienced Aura-based developer should be able to pick up most of the stuff in a few hours/days (I've only had a day with it, so far...).

Instead of Developer Console support, we have a Playground where we can write code and watch our changes practically live. It has solid DX support, allows new types of components like Service components (no UI required), shared JavaScript libraries without using static resources, faster loading/rendering times based on standards-based optimizations, much better ES6 support with automatic polyfills for IE 11 (so whatever code you write will work without needing to detect support), and so on.

  • Thanks for the example - always helpful. – Keith C Dec 14 '18 at 20:27
4

On top of others answers salesforce had a good documentation in the developer guide about migration too.

The programming model for Lightning Web Components is fundamentally different than the model for Aura components. Migrating a component is not a line-by-line conversion, and it's a good opportunity to revisit your component's design. Before you migrate an Aura component, evaluate the component’s attributes, interfaces, structures, patterns, and data flow.

The easiest components to migrate are simple components that only render UI. You get more gains in performance and developer productivity by migrating larger trees of components (components within components) rather than an individual component. However, it's a useful learning experience to migrate one component and see how concepts in the Aura programming model map to concepts in the Lightning Web Components programming model.

After migrating one component, you'll be in a better position to determine whether it makes sense for you and your org to:

  • Undertake a larger migration effort
  • Use Lightning web components for new components only
  • Stick with Aura components for now

The choice is down to you and differs for everyone, depending on use cases and available resources. Whatever decision you make, migrating a component is a valuable learning exercise.

Read more about migration strategy at: https://yourdomainforspring19prerelaseorg/docs/component-library/documentation/lwc/lwc.migrate_strategy

0

If you want to compare similar functionality between apps, you can look at the new LWC enabled Dreamhouse sample app:

https://github.com/dreamhouseapp/dreamhouse-lwc

And then the original, Aura based application:

https://github.com/dreamhouseapp/dreamhouse-sfdx

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.