Alba Rivas, who joins to talk about LWC for VisualForce Developers, is the Lead Developer Advocate at Salesforce, former Salesforce MVP and dreamOlé organizer, 9x Certified.
Main Points
- The resource collection on this topic (a sample app, 3 trailhead modules, and the webinar series in English & Spanish)
- How to leverage Low-code tools in LEX to replace Visualforce
- The benefits of using LWC comparing to VF
- The architecture of LWC v.s VisualForce
- Coding LWC vs coding VisualForce
- The future roadmap
Links
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:13] Hey everybody! This is Xi Xiao. This is yet a new episode of Salesforce Way podcast. Today I'm sitting with Alba Rivas, a lead developer evangelist in Salesforce. Hello, Alba. Hello, Xi. Thank you for inviting me, and hi everyone. Alba, I understand that you have made a blog post collecting the resources yourself built for Visualforce developers to learn the new Lightning Web Component. Am I right? Yes, exactly. So this is a project I worked on last year during a couple of months. And the motivation for this project was that we wanted to help Visualforce developers to do the make the move. To lining with components, we wanted to facilitate that step. We wanted to make their their lives easier, and we found out that there was no much content out there that was specifically for this topic. So we decided to work on a series
[01:31] of resources. That I summarized in that blog post. What kind of content do you have on the blog post? Could you just brief us?
[01:46] Yeah, exactly. So, first of all, the the first thing I started working on the first resource was a new sample app. Do you know the sample apps in the sample gallery? Yes, I had a look. There are a lot of different sample apps over there, right? Yeah. Yeah, exactly. So we have many sample apps that showcase how to use Salesforce development features, following the best practices. And I started working on one called Visualforce to LWC. So the sample app. What it contains are simple code examples, code recipes, right, that are written both in Visualforce and Lightning Web Components. So, if you're a Visualforce developer and you usually and use a specific Visualforce tag to create records, for instance, or visualize a record with the parent record data, you can go there to that app. And see the equivalent piece of code written on Lightning Web Components. That way, you are going to to learn very easily. And how to do exactly the same task, obtain the same result, but with the new technology with Lightning Web Components, right?
[03:16] So that was one of the things. But obviously. If you try to learn Lightning Web Components just with that, that's not going to be enough because while you are going to see the code, but obviously you will need some explanation. So we decided to publish also a couple of Trailhead modules that give context to the examples on the sample app. This means that these two resources are complementary. We have, for instance, one of the Trailhead modules is called "Lightning Web Components for Visual Force Developers." And what we try to do in that Trailhead module is to take advantage of the knowledge that you already have about Visualforce and try to extrapolate those concepts so that you can learn Lightning Web Components easily. I mean, it's Lightning Web Components explained for a Visualforce developer mind. Right. Yeah. Then, apart from that, we have other trailhead modules. One of the trailhead modules is a quick start for the sample app. We have created quick start trailhead modules for several sample apps, not only for Visualforce to LWC, and it is a nice way to
[04:46] get started with them because they explain to you how to deploy the app, why the app was built, what the app is. Explaining and what you are going to to learn from it, and I think it's a it's a great way to to start. And on top of that, so those two resources, the sample app and the Trailhead modules, are complementary, right? To learn at your own path. And on top of that, I did a series of webinars on Trailhead Live, in which I explained. All these concepts that you need to understand, being a Visualforce developers, to to to make the move to Lightning Web Components, but step by step. So, so the the webinars are four webinars, and in the first one, I talk about how the architecture of Visualforce and Lightning components differ. In the second one, I talk about coding concepts. In the third one, I talk about how you retrieve Salesforce data from Lightning Web Components and how that is different from what you did in Visual Force, which I think is the biggest topic and the biggest challenge to understand for a Visual Force developer. And in the last
[06:16] one, I talk about how to make your Visual Force pages or components. Coexist with Lightning Web Components, which is something that is possible, and that sometimes is is is a recommendation, right? Because we don't want to rewrite everything that we have in Lightning Web Components. Indeed. So, so for this blog post, URL I will put in the show notes because a lot of our listeners definitely will we want to have a look after you know listening to what you just mentioned. When I read this blog post, that I understand, you have collected really, really good resources. Some of them you just read through to understand the concepts. Some of them you really need to practice by coding. And the last part is the webinar, which contains multiple hours of like presentations. You. You prepared, so kind of like hold us hand by hand to really go through the technical details, the difference between the Visual Force page and the Lightning Web Component as well. So, yeah, I really enjoy those those resources. Thank you. I I also wanted to add that the webinars they are published in YouTube and there is a playlist in which the webinars are given
[07:47] in English. But as I'm native Spanish, right? So I what I did was to create the same webinar series in Spanish. So if you're a Spanish speaker, you you can listen to them in Spanish too. Yeah, perfect. I want to have. A question about the declarative tools. So, on Salesforce platform, the declarative tools has been you know improving all the time. So, is there any chance you know the old Visual Force page functionalities can be now already replaced somehow by the declarative tools? Yeah, exactly. So, well, when when you think about migrating a Visual Force page or an application that you have written in Visual Force to Lightning. Some developers, first thing that they do is say, "Okay, I'm going to rewrite everything with Lightning Web Components or with Aura Components, right?" But sometimes that's not the the the best approach because what happens is that the declarative tools we call them now low code tools, right? That we have in inlining or that we have developed in the last years. And are much more advanced and have many more cap capabilities than the
[09:17] ones that we had ten years ago, for instance. So there are big chances that the functionality that you wrote with Visualforce now it's something that you can. Build declaratively with no code or with just a bit of code, and sometimes that is going to speed up your development process, and it's going to to make it easier to be to keep up to date with the changes that we perform. Because, for example, if you build a UI with Flow, right? The that UI is going to, we are going to maintain that UI for you. We are going to make it keep up today with all the changes that we do. For sta, for instance, styling changes, or anything that we include in the platform. Right, so there. Certain bits of code that before you needed Visualforce to to build them, but now you are going to be able to build them just with Flow or with App Builder, or for instance using the Utility Bar. So what I recommend you to do as a developer is to learn apart from. Aligning with components and the power of the different declarative tools that we have in the platform as of today, because Salesforce is investing a lot in improving these tools, and we're going to keep doing that for for
[10:47] for a long time, right? Okay, so it's definitely wise to. Spend some time to understand the old Visual Force page functionality and to see what the low code or declarative tools can really replace. And then, with the combination of that and the Lightning Web Component, for the migration project, that would be the good idea.
[11:13] Exactly. Okay. In the past of episodes, we have guests coming to talk about Lightning Web Components, but we haven't really spend time to compare the differences between the Visual Force Page and the Lightning Web Component. So, could you brief us what's the benefits for us to really using the new technology, the Lightning Web Component?
[11:41] Yeah. So, if you think about it, Visualforce is a server-side templating language, right? In which what you do is that you render the pages on the server. Well, not you, but the Visualforce engine, right? And then the whole page is sent to the browser. Then, if in a future moment the user makes an action on the page, in the traditional Visualforce lifecycle. What would happen is that the server has to render the whole page again, right, and send all that information back to the browser. So this was okay for for the time in which Visualforce was built, but now we have much more performant ways of rendering pages. Right, that's how modern web applications work, and that's how Lightning Web Components work.
[12:51] In Lightning Web Components, the all the rendering happens client side. Right. That means that the the LWC compiler is going to generate a set of JavaScript files, and those JavaScript files are going to be in charge of rendering your component. If you perform an action on the page. In most of the cases, unless you need some server data, it's the client, the browser, the one who is going to re-render the component. And if we need to retrieve Salesforce data, data from the server, Lightning Web Components is going to retrieve only the minimal required data. Right, the server calls are going to be much thinner, much. They are going to to contend or to have to carry much less content, and they are going to happen less often. Not only because we have that rendering happening in the browser, but also because we use caching. There is a cache in in the client side that we use the Lightning Data Service cache, and if you are using Lightning base form components or you are using the Lightning Data Service. Wire adapters or wire functions,
[14:22] or if you are using Apex cacheable methods, and the results of those calls that you are doing to the backend are going to be stored in that client side cache. That means that if you need to retrieve exactly the same subset of records in a future call. The Lightning Web Component framework is going to retrieve them from the cache if they are there, and that's going to mean performance. I see, I see. So, based on what you just mentioned, the modern browser and the modern JavaScript has much more toolset to perform the retrieve the exact data set that you want. So, there's no waste of travelings over the network. And also, you mentioned the cache as well. So it just for the speed of rendering and to retrieve data from the server side. Yeah, yeah, and it's also the fact that the rendering happens client side. Hmm. Indeed. Okay, I see. I see. How how about the architect part? So I would assume the architect is is totally different. Yeah, exactly. So, so basically, what happens when you when you create Lightning Web Components, right? When you
[15:52] deploy a Lightning Web Component to your org, what's happening there is that there there is a compiler. There is compiling your code. The compiler is doing several tasks, right? One of the things that we do is to transpile the code. To well, we really the compiler really generates two versions of the code. One of the version is the compatibility version. That version is going to run in old browsers that don't support ECMAScript six features, as for example Internet Explorer eleven. And the second version of the code is going to be a modern version in which we use ECMAScript six. Right, to create that, what we do is that we transpile the code, we transform the code to ah the required version, ECMAScript five or ECMAScript six. We do that to support backward compatibility. Right. And that code is going to be like stored in your org. So when you access a page in which that Lightning Web Component is being used. The definition file, not the definition file, but the JavaScript files that shape that Lightning Web Components are sent to the browser. Right, and
[17:23] the browser is the one that is going to render the component and connect it to the page. Right, this is what we were talking about the difference between server side and client side. Then there is another topic that is important to highlight here, which is statelessness. Right, in Visualforce. We had the view state. That was the way to maintain a state between subsequent server-side codes. Inlining with components. As what we use to communicate to the backend are simple HTTP HTTP requests. We are not going to maintain a state between the client and the server. Everything that you need to the server to know. In each server call, you are going to need to send it to the server in in your server code, right? And the same happens when that information is sent back from the server to the browser. And the third implication of the architecture that we mentioned, we have already talked about that, which is the caching, the server-side cache, sorry, the client-side cache that we use in Lightning Web Components, and that is going to have implications on the performance that
[18:53] your applications are able to reach. You just mentioned the stateless. I. I kind of understand the power of stateless, which means the following request to the server doesn't need to understand the previous request, right? But why is there such a difference? Why in the old Visualforce page, why do we need to keep the state? That's something I don't understand. Yeah, because in Visualforce pages, you we had this thing called View State. Are you familiar with View State? And not too much. Okay, so so the view state was an an object that stored all the values of the inputs and items with which the user could interact in your page. The view state was passed to the server. With every request, and this was a big headache for some developers because the view state had a limit, right? And there is a famous Salesforce limit, which is like you have reached the maximum view state in kilobytes, whatever, whatever. I don't remember the number, right? Okay. So now
[20:24] it's the the the way in which we we pass information to the server is that the developer has to to decide what do I want to send to the server on each request, right? That is much more performant. It has an additional work that the developer has to do, but as you can imagine, the the result is substantially much better, right? Okay, now I get it. Yeah. So instead of passing everything as one package to the server each time, now it's up to the developer to to decide what parameters, what attributes you want to talk with the server, which is much thinner, as you just mentioned. Yeah. Hmm. So, how about the coding practices for Lightning Web Component Visualforce? I know now the VS Code is like the standard tool for us to use. So, is that already like the best practices? Do we have some other tools? Also, could you give us some some information as well?
[21:40] Yeah, so for creating Lightning Web Components, they are not supported in Developer Console, right? And they are not going to be supported in Developer Console. There's no roadmap for that. And what we recommend to to use is Visual Studio Code. Why? Because we have a a set of extensions that we have created for Visual Studio Code that are going to make it. Much easier to develop not only Lightning Web Components but also Visualforce or Apex or Aura. These extensions, what they provide, are things like auto completion capabilities. This is when while you are writing, for instance, I was writing yesterday a component in which I was using the Lightning Design System, and if you try to write a class. That starts with SLDS, then one of the extensions is going to auto complete that class, and tell you all the different SLDS classes that you can use. So it's it's much more productive. to To code using Visual Studio Code that using than using the Developer Console right and also is like the most extended IDE not only for Salesforce development
[23:10] but for any kind of development. It's going to provide also syntax highlighting. It's going to be super easy to see the help for the base components. For instance, if you have a lining card component, and you want to take a look at the help. You don't have to navigate to a browser and go to the Lightning Web Components help. In VS Code, you just place your mouse over the component, and then the help is going to appear. Right, and then as if you are using VS Code, this is something that you normally have installed in your machine. Meanwhile, a code builder comes up. Right, we don't have code builder yet. Um. So as this is something you have installed in your machine, um, you need a way to send the files that you are modifying to your organization, right? And for that, we normally. The Salesforce CLI. So another thing that the VS Code extensions provide are shortcuts to use the Salesforce CLI. So, if you don't remember a specific command, for example, I use a lot the create Lightning Web Component one. This is a command that creates. All the scaffolding, the files that you need to to create a
[24:40] Lightning Web Component. I normally use the shortcut that comes with the with the VS Code extensions because I don't remember the command exactly how to type it. And with the shortcuts, you can just select a a command. from from the shortcuts panel with with a click right so it's much easier to use as for CLI with with the with with the VS Code extensions yeah just just to be clear the VS Code tool can still be used to develop Visualforce page am I right. If I want, yeah, exactly. So anything that you want to develop in regards to Salesforce development is available in Visual Studio Code. I mean, it's going to be much easier to develop that from Visual Studio Code because all those features that we have added of auto completion and syntax highlighting and so on are for lining with components, but also for Visual Force and for Apex. Right? You can run your Apex tests. From Visual Studio Code, for instance, and you can use the Apex Debugger from Visual Studio Code. Excellent, excellent. Before closing this session, I still have one more question to ask, which is more like general. So, in the Lightning experience, the front end part, we had the Visual
[26:10] Force page, we had Aura, we had the Lightning Web Component, which is the newest. So, do you have any information to share with us? What's like the roadmap on this on this you know direction?
[26:25] Yeah. So what we plan to do is to continue improving Lightning Web Components and all that relates to Lightning Experience. We have added capabilities in Lightning Experience to keep using Visual Force and Aura when needed. I don't know if you have talked in the podcast about Lightning Message Service, for instance, that allow you to communicate Visualforce components with Aura components with Lightning Web Components, and we. Yeah, and we plan to continue supporting. I mean, we we we as far as I know, we don't have a plan to deprecate Visualforce or or or components. But it's true that the major investments that are being done as of today in what regards to UI development in Salesforce are in lining with components. It's our newest technology. is based on web standards. If a developer knows JavaScript already, is going to be super easy for him or for her to pick Lightning Web Components. And if you learn Lightning Web Components, is going to be super easy for you to to make the move to another JavaScript. Based technology, right, and on top of the all the performance benefits that we mentioned before, so that's definitely the area
[27:55] in which we we are investing more, and of course, declarative functionality, right, like Flow Builder, and so on. Hmm. Excellent. Thanks for sharing all this with us. Then back to your blog post. I recommend all the listeners to really check the show notes. We have a link there, which have all the information we just talked about, and then those are really in details, including coding practices, like the sample gallery as well. So definitely go there to check all this information shared by Alba. Thanks, Alba. Thanks for your time this to to come to the show. Yeah.
[28:37] All right. See you next time then. Bye bye.
