What is involved in moving over to Lightning Web Components?












10















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.)










share|improve this question





























    10















    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.)










    share|improve this question



























      10












      10








      10


      3






      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.)










      share|improve this question
















      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.)







      lightning-aura-components aura lightning-web-components






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 14 '18 at 19:06







      Keith C

















      asked Dec 14 '18 at 18:42









      Keith CKeith C

      95.5k1092208




      95.5k1092208






















          4 Answers
          4






          active

          oldest

          votes


















          9














          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.






          share|improve this answer


























          • 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.






          share|improve this answer
























          • 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






          share|improve this answer































            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






            share|improve this answer























              Your Answer








              StackExchange.ready(function() {
              var channelOptions = {
              tags: "".split(" "),
              id: "459"
              };
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function() {
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled) {
              StackExchange.using("snippets", function() {
              createEditor();
              });
              }
              else {
              createEditor();
              }
              });

              function createEditor() {
              StackExchange.prepareEditor({
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: false,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: null,
              bindNavPrevention: true,
              postfix: "",
              imageUploader: {
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              },
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              });


              }
              });














              draft saved

              draft discarded


















              StackExchange.ready(
              function () {
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f242664%2fwhat-is-involved-in-moving-over-to-lightning-web-components%23new-answer', 'question_page');
              }
              );

              Post as a guest















              Required, but never shown

























              4 Answers
              4






              active

              oldest

              votes








              4 Answers
              4






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              9














              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.






              share|improve this answer


























              • 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
















              9














              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.






              share|improve this answer


























              • 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














              9












              9








              9







              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.






              share|improve this answer















              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.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Dec 14 '18 at 19:30

























              answered Dec 14 '18 at 18:59









              Jayant DasJayant Das

              14k2824




              14k2824













              • 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



















              • 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

















              Any insight into VSCode extensions for LWC?

              – Keith C
              Dec 14 '18 at 19:07





              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





              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





              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




              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





              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





              @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.






              share|improve this answer
























              • Thanks for the example - always helpful.

                – Keith C
                Dec 14 '18 at 20:27
















              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.






              share|improve this answer
























              • Thanks for the example - always helpful.

                – Keith C
                Dec 14 '18 at 20:27














              7












              7








              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.






              share|improve this answer













              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.







              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Dec 14 '18 at 19:12









              sfdcfoxsfdcfox

              254k11198438




              254k11198438













              • Thanks for the example - always helpful.

                – Keith C
                Dec 14 '18 at 20:27



















              • Thanks for the example - always helpful.

                – Keith C
                Dec 14 '18 at 20:27

















              Thanks for the example - always helpful.

              – Keith C
              Dec 14 '18 at 20:27





              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






              share|improve this answer




























                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






                share|improve this answer


























                  4












                  4








                  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






                  share|improve this answer













                  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







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Dec 14 '18 at 19:17









                  codeyinthecloudcodeyinthecloud

                  3,5351426




                  3,5351426























                      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






                      share|improve this answer




























                        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






                        share|improve this answer


























                          0












                          0








                          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






                          share|improve this answer













                          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







                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Dec 17 '18 at 16:11









                          joshbirkjoshbirk

                          3,350720




                          3,350720






























                              draft saved

                              draft discarded




















































                              Thanks for contributing an answer to Salesforce Stack Exchange!


                              • Please be sure to answer the question. Provide details and share your research!

                              But avoid



                              • Asking for help, clarification, or responding to other answers.

                              • Making statements based on opinion; back them up with references or personal experience.


                              To learn more, see our tips on writing great answers.




                              draft saved


                              draft discarded














                              StackExchange.ready(
                              function () {
                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f242664%2fwhat-is-involved-in-moving-over-to-lightning-web-components%23new-answer', 'question_page');
                              }
                              );

                              Post as a guest















                              Required, but never shown





















































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown

































                              Required, but never shown














                              Required, but never shown












                              Required, but never shown







                              Required, but never shown







                              Popular posts from this blog

                              Wiesbaden

                              Marschland

                              Dieringhausen