What is involved in moving over to Lightning Web Components?

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.

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.

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