Today, I have the pleasure of sharing my conversation with Kevin Hill, Senior Director of Product Management for Lightning Web Components at Salesforce. Kevin and I discuss the development of Lightning Web Components as well as some upcoming LWC features. We begin our conversation with a discussion about migrating Aura components over to Lightning Web Components.

Show Highlights:

  • Some of the features and ideas Kevin and his team considered when migrating Aura components to LWC.
  • How Mysore is different from LWC.
  • The core technology of LWC is developed in open source. 
  • Kevin talks about the origin story of LWC recipes and why you want to use them as a catalyst for writing the best components in Salesforce.
  • Lightning Web Components roadmaps are open source in the form of RFCs and are publicly available.
  • LWC upcoming features: CSS-only modules and server-side rendering.
  • Kevin’s effort to have office hours with developers.

Resources:

Episode Transcript

00:06

Kevin: You know, talking about love of enterprise software. The first rule of enterprise software is don’t break enterprise software.

00:13

Josh: That is Kevin Hill, Senior Director of Product Management for lightning web components here at Salesforce. I’m Josh Birk, a Salesforce developer evangelist. And here on the Salesforce developer podcast, you’ll hear stories and insights from developers, for developers. Today, we sit down with Kevin to talk about a variety of things regarding LWC, including how they’re developed here in Salesforce, some upcoming features. But first, we start with something that’s familiar with this about everybody porting aura components over to lightning web component.

00:42

Kevin: There’s two pieces I want to talk about the first piece is what is Salesforce doing? Because we’re migrating from aura to LWC to so like anyone else who’s made an order project, Salesforce is probably the biggest user of aura, right? So the first avenue we look at is if it’s new, we want to go right in lightning Web Components because Anything that’s new is starting with this, you know, is, is going to be faster to market a little bit, you get better performance when you’re rendering. But if you have a large code base, the question is like, Why go invest in something that may or may not work? Well, the second input we put is like, is it performance? Because we know with aura, or was a great technology, especially first time, there’s some areas where it is not as performant. And so any of these avenues, we’ve had developers go and rewrite pieces of these larger components. And they can actually see the performance gains. We have a kanban view in our internal engineering system. And it was rewritten in aura. And the performance from the drag and drop was actually quite noticeably janky. So one of the engineers went and they rewrote just the card like one of the lowest level components on the Kanban board and they use modern, the modern HTML drag and drop event. And it was buttery smooth. And so like, these are the things that we We looked at like is can we increase performances right there and then naturally over time, the third area of that is, well, do I have enough of my code base now kind of in, Lw see that I just want to bring all my code base forward. So I’m not maintaining two different code bases. And so that’s the progression we’re taking within Salesforce. And I think it’s a fairly natural progression for ISVs to take in anyone who’s written or components. Now, I will give the caveat. The second point is, there’s still some areas where, or a functionality is desirable. And we’re still having to fill a few of these gaps like, we don’t yet have dynamic component capabilities available in Lw C on the platform. And so there’s still some scenarios where people want to go use dynamic components, and they they can’t quite make the leap. There’s some containers that we haven’t added first class support like quick actions, you still have to use an aura wrapper component. So there still are some cases where You’re going to use maybe aura as the wrapper and then put LDPC inside. And, and that’s that’s the things to consider, you know, coming from Laura, tell WC, there still are a few cases that we’re filling gaps in.

03:10

Josh: Now going back to the opening quote about not breaking enterprise software. Remember that one of the key things about aura and LDPC is its interoperability.

03:19

Kevin: When LWC came to market, very proud that the team had focus on two things, one, making sure it worked in our favorite browser, IE 11. That was it. And there’s a there was a lot of work that went into into that. And then the second area is the fact that you can just talk to aura components, the interoperability, it’s just through JavaScript events, and it’s very natural. And so you can you can achieve this very easily. I was very proud of the team for for doing that.

03:47

Josh: Now, we really want our developers to start adopting lightning web components. And that approach is interesting because, well, the two frameworks are similar, but they’re very different.

03:57

Kevin: Yeah, if you’re comparing lightning, it’s different. And the first way it’s different is it’s actually like a lot of the other web frameworks that exist react and Angular. In fact, if you’re coming from that background, the ergonomics are going to be very quick to learn before, before we released, LWC, I actually had reached out to a few developers that were never exposed to it. But I know that they had written code and view or Angular or react. And I just, I gave them like a little demo, I said, Hey, here’s how you write a component. And then for the next half hour, I had them actually write a component that give me feedback on the experience. And in general there, this is easy to learn or like and then you’re like, wow, this wire things kind of cool. Like, I can just get data into my component that’s kind of this kind of neat, and so that the concepts themselves are more akin to what you would find in the broader industry verse. For I was very Salesforce centric, like we were solving Salesforce problems and really focused on our stack and not looking at the broader interest. Whereas with Lw see any background, you’re coming from the JavaScript, you’re gonna find it’s kind of a nice home. And so, like we’ve released some great resources on trailhead, like getting started, there’s the essentially we even tell you like, here’s how you can set up your tooling and use our SFDX CLI, which is super powerful for getting up and running. We put a lot of effort into making visual code a first class citizen as an editor, because this is the main editor of the web these days. But yeah, coming into the ecosystem is quite easy. There’s actually even some third party content out there that’s been developed that helps augment what we have in trailhead, and maybe goes like a little bit deeper for some some areas. But we’ve also released a new bid on trailhead for open source like we talked about developing on the platform, but then we also give you Hey, if you are coming in developing off the platform, and then want to come back on and move your component around, like we’ve done a lot of great content On trailhead to make you feel at home,

06:03

where no matter where you’re coming from.

06:04

Josh: Okay, so focusing on some of the core technology itself, you might have noticed a trend at some of the recent episodes about how we’re talking about the how open source has really become very central to developing some. So the Salesforce technology and lightning web components is no different.

06:20

Kevin: The core engine itself, though, is developed in open source, right. And so we have our GitHub project in all of our source because there you can actually see it as our engineers are doing check ins daily or fixing issues or whatever, like it’s all developed in the open. And we get features there first before they come on platform because our job is really to integrate the open source code into the force cop environment as we do releases for spring, summer and winter.

06:47

Josh: Now, it’s not just the core technology, which has gotten open source. There’s a lot of side projects that kind of settled around lightning web components in order to help developers learn the framework. And one of them recipes. Well, it’s got kind of an Interesting origin story. To do this,

07:01

Kevin: I actually tell the story quite often it’s about your boss Christophe. So when I first joined the team, we had this kind of sample repository that we were developing to help educate developers. And we were the intention was put on GitHub, but quite honestly, it was just not what was needed to help Salesforce developers. I mean, it was like the to do applications in these things. It was it was great code on its own. But we want to take a step further, and Christoph had, you know, kept asking the team like, hey, how do you do this? What’s the best practice for this? Or do we want to emphasize this pattern over this? If so, the team engaged with him quite a lot. But then an unfortunate thing happened. As he did back in these days, he would go on very long vacations. I think that’s like, what people from Belgium do. They take a month off every year. So he took us he took his vacation, travel so family had fun came back and forgot everything.  So he apologized. He’s like, Oh my gosh, I’m sorry, I’ve forgotten everything.

08:04

So what he started doing was writing recipes. And, and this way, he’s like, I’m gonna check it into GitHub. They’re gonna be like these small pieces of code that I can copy and paste later. And I’m like, Christoph, that’s the thing we need like me. And so he with Rene actually went and wrote a ton of these recipes. And then the core Lw c team, like all of the engineers working on the engine reviewed every bit of code and went over for best practices patterns, you know, and this was both for JavaScript and on platform like how do you do navigation? And should we do this like we, we argued over these things for hours and hours and hours, and sweated blood, sweat and tears, and we actually even went and put in unit tests. So the Lw c recipes repo on trailhead apps. I’ve heard time and time again from developers starting that that is the number one tool for getting up to speed quickly and I actually use it all the time. Because it’s perfect. I know, I was joking a bit about Christoph, you know, just a developer problem in general, we get we go for a coffee break, we have to go search Google again.

09:13

Josh: Right?

09:15

Kevin: Right.

And so I can’t emphasize LWC recipes enough like if you don’t know about it, you definitely want to go check that out and use that as a as a catalyst for getting up to speed for how to write the best components in Salesforce.

09:27

Josh: Nice and you know not to give Mr. Rene Winklemeyer too much credit but he is also responsible for the lwc-create application.

09:37

Kevin: Yeah, no. And by the way, he should have credit like this. This was an area where he was very passionate about and you know, how things tend to work on on feature teams, as you have so many resources to work on, on the actual, you know, features of the core engine and this and Rene said, Hey, wouldn’t it be great if we had a create LBC app for the developers who wanted to just quickly start in that, that on it sound like it’s the way I prefer to prototype my components, because a lot of what I’m doing is sort of custom components and trying new things out. And so if I’m going to go fly in an airplane, I’m usually using create LWC app, and starting my project, and then doing a demo on the way to like Denver or something before I have to go deliver, like in person training. So like, that’s an invaluable tool. And we actually see fairly consistent usage of it in the ecosystem, like it’s one of those things you can track on NPM for downloads, and I think every week it’s it’s between 305 hundred people are going and playing around with this. I’ve recently started doing office hours with the community. And one of my goals was to find out like, Hey, what’s everyone building with this, since it’s all in open source, like it’s not deployed on platforms, it’s harder to see and understand. So trying to get some more more than information, but yet, the LWC app is a very valuable tool to prototype quickly, right and you can do this locally on your money. Without being connected and just sort of a quick web application workflow.

11:05

Josh: And finally, I know that a lot of developers like to talk roadmap with our product managers. And when it comes to lightning web components, you’re actually in luck because lightning Web Components has their roadmaps open source in the form of RFCs publicly available.

11:20

Kevin: The timeline was a little like this last January, we actually released lightning web components for you know, so it was on the platform, people use it. And then the TD x of that year, we actually open source, the core LDPC repo, and we’re like, Hey, you can see the code and open issues and that was great. then towards the end of last year, around December, we said, hey, why aren’t we just publishing all of our design docs? Like, shouldn’t we be doing that too, so we actually have a website called rfcs.lw Dev and these are active designs. So as we are designing things today, You’re seeing them in real time, there’s no delay, like you can see exactly what the team’s working on. The designs are very dev focused. And it’s not the RFC process is nothing that Salesforce invented. we adapted it from other UI frameworks. So it’s a very common kind of industry practice for how people express designs and communicate them.

12:20

Josh: To be clear, the RFCs that you’re seeing online are pretty much one on one with what the team is working. There’s no secret Safe Harbor Branch or anything like that. There might be some internal drafts that haven’t actually made it to the RFC stage. But it’s a pretty clear transparent way of what the team is working on, and not just working on. But you can also see features that have been confirmed and also features that have been rejected. And I can tell you, it’s actually kind of an interesting read, because you can really kind of go into detail and nuance as to why some features are moving forward, and some are not. And we’re talking about these kind of features. Remember that we’re also trying to line up with web standards. One of the goals of frameworks like this is to try to have the browser’s doing as much of the heavy lifting as possible. Part of that we’ve actually been working with the standards bodies themselves.

13:04

Kevin: Last year, we joined officially TPAC, which is one of the governing bodies of web standards. It’s where a lot of the browser vendors show up and a broader team works on that, like a lot of people at Salesforce end up being part of the standards. But we use what we have in open source to say, here’s the scenario, like, here’s the enterprise scenario we’re solving for. So a lot of it is about transparency being open, but then also using that to do that. I think the browser’s we, we would love to not build the UI framework. We would love to, like get rid of so much of the code. But the reason we have coded the way we have in a lot of, you know, UI frameworks is like, well, you want to have an easy authoring format, or you actually have a scenario that’s specific, and we have a lot of enterprise scenarios that we advocate for and they’ve actually pushed standards a bit farther. Like when we show up for tea pack meetings, a lot of times, you know, Salesforce has asked us See, can you present on how you use web components and Salesforce and how you do it at scale is our architects have showed up at, you know, Google i o and a couple of large meetups on HTML and talked about, like, the scenarios we saw for and I think it opens up a lot of eyes because everything on Salesforce is a component. And this is just it’s crazy to think about the scale like so. This has 6000 components. And I mean, this rivals some of the more complicated applications that you’ll find on internet today.

14:28

Josh: We keep teasing roadmap roadmap roadmap. So let’s talk about a couple of upcoming features with Kevin. The first one being CSS only modules.

14:38

Kevin: Yeah, CSS only modules is kind of a fun one. It’s another tool to help folks who might want to centralize their logic around themes within their orgs or even an open source like today. On platform. We support UI modules, which means you need to have an HTML file and you need to have a JavaScript file and we work on Kind of API modules, which is just the JavaScript file. So that’s what we have today deployed. But we are deploying support for CSS only modules. So now you can have a CSS file, and then your JS meta data to deploy to Salesforce. And then that’s where you can put like your branding and your themes and your colors, and then your other components that you want to import that into, you just have a nice little import statement, you say at import, and then you say C slash your module name, right. So what we’ve seen is a lot of folks are like copying and pasting the same styles into components to do their overrides or do their theming and do their branding. And we’ve made it a ton easier. And by the way, this has been in the open source project for one full release prior because like I said, one of our things is release it in open source. First, give people a chance to play with it, give feedback, let us know if there’s some other ergonomics that they think makes sense or something that isn’t quite working right. And so you’ve been able to use this in officers, but also Obviously, on the platform, it’s a desirable thing to have, it actually simplifies your code.

16:04

Josh: And the second one we want to highlight is something that is going to have something of a small release, but might have a long lasting impact on how the framework is used, server side rendering.

16:14

Kevin: One of the core problems that exists with server side rendering is all of the decisions you have to make about data that’s coming into a component because there’s no data and it’s just static. It’s not a big problem. Sure, just return the HTML and you’re done. Well, at Salesforce, we actually have a need to send emails, and there’s no browser involved in that process, right, like, but you need HTML as an output. So how do you build a component for that? Well, so we have an RFC out there, I forget the name off the top of my head, you may, you may have it in front of you. But it’s like LWC server, something that I don’t think it says server side rendering, but we have to design a way to render components without a browser without the DOM without the API’s that the browser gives you. So we’re working Right now on enabling, just rendering web components from the HTML, CSS JS that you’ve authored in core JavaScript with no extra special API’s. And so that’s actually the the first phase that a lot of frameworks go through to figure out like, how do we how do we get the sun in our first scenario is really solving this email scenario that exists on the servers like a true server side scenario. And then we will continue to design like how this could be then materialized back into a browser or a lot of people say hydrated back into a browser in future releases. Right now we’re focused on the server side aspect. And like I said, The cool thing is, this will show up in the open source project first, right so it’ll be there. It’ll be vs. We check it in. So if other people want to go and do the same thing like render LWT components on the server, they’ll have all the infrastructure they need to go get some basic rendering happening on the server.

17:57

Josh: The last thing I want to highlight with Kevin is an effort that he is putting forward to have office hours with developers so that you can talk to him one on one.

18:07

Kevin: Like, it’s great to connect directly with developers and get that one on one time. It’s way better than, you know, a webinar where people can’t talk back. And all they can do is, you know, post a question you have to answer. And it’s sort of this kind of one way dialogue and like, it’s very rich and interactive. I do half an hour sessions. And so it’s five minutes of greeting. And then it’s like, hey, what, what are the problems you’re seeing? And I love it, because I get a lot of honesty, and, you know, like, Hey, this is a real problem for me. When do you what are you gonna fix it? And it’s amazing. And so what I do with that is I actually take very brief notes, and I take internal folks who actually own some of these problems as well, because I, I obviously don’t have influence over every single thing in Salesforce. They work on UI frameworks, but I know generally, who could go and have influence

18:52

Josh: And that’s our show. Now, before we go, I did ask him about his favorite non technical hobby and it turned out to be well, something that may be turning into a bit of a trend with product managers, woodworking.

19:02

Kevin: it’s a great question because I was very surprised by that I, I took working class just kind of man I really like to do something that’s not a keyboard and a mouse. And I had a lot of fun it was it was like this five week long class three hours a week, he showed up with a group of people and he built a table. And so I did that and I mean the whole purpose is you’re learning how to use the tools, the planners, the joiners the table saws without cutting off your fingers. Right. Right. And so I thought this was a lot of fun, it was relaxing and I I feel like I had to focus on this task and every single time it came out of it, I was I felt refreshed because I wasn’t staring at a screen. I made something physical you know, like that I could I could touch and I started this four year journey to making a dining room table. Wow. And the reason it takes a long wasn’t as much as the hours I put into it took four years to make. It’s then I was able to sign up for Like one class every three months, and I only know the same sort of pattern. So I didn’t I didn’t like keep going throughout because I was pretty busy. inside joke people was like, yeah, it took me four years to make this table. But if you add up the hours, I want to say it was about 75 hours.

20:15

Josh: Now if you want to learn more about this podcast, head on over to developer.salesforce.com/podcast where you can hear old episodes, see the show notes, and have links to your favorite podcast service. Cheers, everybody. I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.