What is involved in moving over to Lightning Web Components?











up vote
5
down vote

favorite












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




























    up vote
    5
    down vote

    favorite












    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


























      up vote
      5
      down vote

      favorite









      up vote
      5
      down vote

      favorite











      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-components aura lightning-web-components






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 1 hour ago

























      asked 1 hour ago









      Keith C

      93.8k1088199




      93.8k1088199






















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          4
          down vote













          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
            1 hour ago










          • There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
            – Jayant Das
            1 hour ago










          • 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
            1 hour ago










          • 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
            1 hour ago










          • @sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
            – Jayant Das
            1 hour ago


















          up vote
          3
          down vote













          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




























            up vote
            2
            down vote













            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





















              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',
              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

























              3 Answers
              3






              active

              oldest

              votes








              3 Answers
              3






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes








              up vote
              4
              down vote













              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
                1 hour ago










              • There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
                – Jayant Das
                1 hour ago










              • 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
                1 hour ago










              • 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
                1 hour ago










              • @sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
                – Jayant Das
                1 hour ago















              up vote
              4
              down vote













              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
                1 hour ago










              • There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
                – Jayant Das
                1 hour ago










              • 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
                1 hour ago










              • 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
                1 hour ago










              • @sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
                – Jayant Das
                1 hour ago













              up vote
              4
              down vote










              up vote
              4
              down vote









              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 55 mins ago

























              answered 1 hour ago









              Jayant Das

              11.6k2523




              11.6k2523












              • Any insight into VSCode extensions for LWC?
                – Keith C
                1 hour ago










              • There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
                – Jayant Das
                1 hour ago










              • 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
                1 hour ago










              • 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
                1 hour ago










              • @sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
                – Jayant Das
                1 hour ago


















              • Any insight into VSCode extensions for LWC?
                – Keith C
                1 hour ago










              • There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
                – Jayant Das
                1 hour ago










              • 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
                1 hour ago










              • 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
                1 hour ago










              • @sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
                – Jayant Das
                1 hour ago
















              Any insight into VSCode extensions for LWC?
              – Keith C
              1 hour ago




              Any insight into VSCode extensions for LWC?
              – Keith C
              1 hour ago












              There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
              – Jayant Das
              1 hour ago




              There's one already available n VSCode marketplace. I installed it yesterday while doing the trailhead.
              – Jayant Das
              1 hour ago












              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
              1 hour ago




              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
              1 hour ago












              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
              1 hour ago




              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
              1 hour ago












              @sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
              – Jayant Das
              1 hour ago




              @sfdcfox Yeah, I saw that this morning. Lot more to come for sure, but getting an early hands-on is always exciting!
              – Jayant Das
              1 hour ago












              up vote
              3
              down vote













              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

























                up vote
                3
                down vote













                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























                  up vote
                  3
                  down vote










                  up vote
                  3
                  down vote









                  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 1 hour ago









                  sfdcfox

                  244k10185418




                  244k10185418






















                      up vote
                      2
                      down vote













                      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

























                        up vote
                        2
                        down vote













                        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























                          up vote
                          2
                          down vote










                          up vote
                          2
                          down vote









                          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 1 hour ago









                          codeyinthecloud

                          2,778321




                          2,778321






























                              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.





                              Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                              Please pay close attention to the following guidance:


                              • 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

                              flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

                              Mangá

                               ⁒  ․,‪⁊‑⁙ ⁖, ⁇‒※‌, †,⁖‗‌⁝    ‾‸⁘,‖⁔⁣,⁂‾
”‑,‥–,‬ ,⁀‹⁋‴⁑ ‒ ,‴⁋”‼ ⁨,‷⁔„ ‰′,‐‚ ‥‡‎“‷⁃⁨⁅⁣,⁔
⁇‘⁔⁡⁏⁌⁡‿‶‏⁨ ⁣⁕⁖⁨⁩⁥‽⁀  ‴‬⁜‟ ⁃‣‧⁕‮ …‍⁨‴ ⁩,⁚⁖‫ ,‵ ⁀,‮⁝‣‣ ⁑  ⁂– ․, ‾‽ ‏⁁“⁗‸ ‾… ‹‡⁌⁎‸‘ ‡⁏⁌‪ ‵⁛ ‎⁨ ―⁦⁤⁄⁕