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.
- 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.
- Kevin on Twitter
- Kevin on LinkedIn
- Kevin on Github
- LWC OSS (with create-lwc-app)
- LWC Recipes
- LWC Sample Apps
- LWC RFC
- Kevin’s Calendly
Kevin: You know, talking about love of enterprise software. The first rule of enterprise software is don’t break enterprise software.
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.
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.
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.
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.
where no matter where you’re coming from.
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.
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.
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,
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.
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.
Josh: Nice and you know not to give Mr. Rene Winklemeyer too much credit but he is also responsible for the lwc-create application.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.