Greg Whitworth is a Senior Director of Product Management here at Salesforce. Greg started with Standards Committees in 2011 before getting involved in web platform testing and CSS Working Group, then Open UI. Today, Greg focuses his efforts on MWC, LWR Node, and standard web platform browser engagement.
In today’s episode, we talk with Greg about some distinctions between our old component framework Aura and our new, modern framework, Lightning Web Components (LWC). We dive into how the evolution of web standards at Salesforce is driven, the different styling of LWC, Aura’s file structure compared to LWC, and much more!
Show Highlights:
- Aura in relation to the rest of the Salesforce frameworks.
- Greg’s experience with JavaScript.
- How Aura’s eventing compares to LWC.
- What GraphQL is and how it compares to other API endpoints.
- Strategies to start moving an org into an LWC.
- How the language is continuing to evolve and improve the developer experience.
- What is on the roadmap.
Links:
Episode Transcript
Greg Whitworth:
Kind of as a product person, this is actually where you go, “Well, they’re kind of treating it like one file. They’re almost treating the controller as almost an interface into a helper.” I’m sure some engineers are going to be like, “That’s not what an interface means,” but…
Josh Birk:
That is Greg Whitworth, senior director of product management here at Salesforce. I’m Josh Birk, your host for the Salesforce Developer Podcast. Here on the podcast, you’ll hear stories and insights from developers for developers. Today, we’re going to sit down and talk with Greg about some of the distinctions about our old component framework, Aura, and our current modern one, Lightning Web Components, but, first, we’re going to start as we often do, with his early years with a computer.
Greg Whitworth:
Probably playing video games on the old school … I mean, I don’t even know if it was a Mac or a Windows at this point, but you remember the old tank games where it’s geometric figures, but they’re just lines, and you shoot triangles at other tanks?
Josh Birk:
Yes, which I can’t believe-
Greg Whitworth:
Yeah, it was all green and black.
Josh Birk:
I can’t believe I can’t remember the name of it because it’s something really straightforward, like Battle Tank.
Greg Whitworth:
Yeah. There’s that, and then, of course, Oregon Trail.
Josh Birk:
Right, of course.
Greg Whitworth:
Definitely at school, but, yeah.
Josh Birk:
The best school-indoctrinated game ever.
Greg Whitworth:
Exactly.
Josh Birk:
When did you first start working not just on web development, but on standards committees, as well?
Greg Whitworth:
Oh, standards committees came in actually, goodness, 2011, I think. I started getting 2011, 2012, something like that, started getting involved in web platform tests, and then, yeah, got more involved in the CSS Working Group, and from there, open UI as well.
Josh Birk:
We kind of got through this in the last interview, but just sort of as a recap, how do you see the involvements in companies like Salesforce and Microsoft having a seat at those committee tables, and how do you think that that kind of drives the evolution of web standards?
Greg Whitworth:
Oh, it’s super important. I think anybody happening to listen to this podcast, it doesn’t matter how you’re using Salesforce, you’re using web technology in some form or fashion. While the teams I’ve heavily engaged with, Lightning Web Components heavily involves web component standard discussions, CSS and so on. There’s all kinds of stuff, whether it be protocols, probably the most engagement I actually do is with a bunch of browser vendors as they want to deprecate APIs or things of that nature.
It’s very important from a relationship perspective, to ensure that our customers, actually, continue to have a great experience, no matter which browser they’re in, what technology they’re using.
Josh Birk:
Got it. And to round that up, how would you describe your current job at Salesforce?
Greg Whitworth:
Oh goodness, I’m a product manager, so I work across a few different technologies, LWC, LWR Node, as well as standards wide platform, browser engagements. But yeah, anything and everything customer-related, how we can continue to improve the platform, to make our customers successful, is everything that I’m focused on.
Josh Birk:
Nice. Now, on the show, we’ve talked about Aura’s place, in terms of its evolution and the accompanying frameworks, how would you describe Aura in the family of frameworks, especially compared to things like LWC?
Greg Whitworth:
In the family of Salesforce frameworks, again, it’s super popular. It’s got a lot of great capabilities that people lean on, especially given my close proximity to LWC, and I’m sure this is something we’ll get into, is there’s a lot of capabilities that, unfortunately, have hindered people from being able to move through Aura to LWC.
But I think it’s, I wouldn’t say generally loved, by customers. We actually sent out a survey, which hopefully we’ll share the results for in a few months. The results, the outputs from that but it’s not necessarily loved. And then, if you look at the broader industry, so anybody hiring developers, LWC is much more in-line with what industry developers expect. If you’re going to boot camps or going to college these days, learning to become a web developer, Aura’s very proprietary to Salesforce.
Josh Birk:
I mean, I think there’s a lot of advantages to web standards we’ve talked about, overall speed and the less technology that’s required to use as a shim, et cetera. But touch on that a little bit, if I am a React developer, how much easier is it for me to adopt LWC, as opposed to sticking with Aura.
Greg Whitworth:
Yeah, I would almost say it’s night and day. This is speaking from a personal experience…
Josh Birk:
Great.
Greg Whitworth:
Coming from working on standards and coming into Salesforce, having to learn, hey, here’s where you hook up to your class constructor rather than just doing a JavaScript import of a class, thinking of APEX and so on. All the ways in which data binding works. It being a two-way binding by default. It doesn’t follow any of the industry paradigms, it doesn’t matter if it’s React, Vue’s, Svelte’s, any of those. Yeah, it’s a relatively steep learning curve.
Josh Birk:
Yeah. And one of the things that always got me about Aura was its, shall we say, fondness for a very specific file structure. How does that compare to how I could set up a component in LWC?
Greg Whitworth:
It’s verbose, for sure. There’s numerous different… I would say, the one that befuddles me, probably the most, is the fact that you have both a controller and helper JS files. If you aren’t in VS Code or using any of the code builder extensions, you create just a Aura component versus a Lightning Web Component. The scaffolding of the component files is drastically different and, quite often when I’m looking at various Aura component code, people within the controller JS, just call out quickly to a helper JS, which kind of implies…
And this is where, as a product person, this is actually where you go, “Well, they’re treating it like one file.” They’re almost treating the controller as almost an interface into a helper. I’m sure some engineers are going to be like, “That’s not what an interface means,” but you get my point, it’s a pass-through.
Josh Birk:
Yes. Right.
Greg Whitworth:
And with an LWC, you end up with one JavaScript file. Likewise, with all of the integrations into Salesforce, whether it be your builders and so on, and Aura components, you have a dot design file and then a component meta file. In LWC’s, you only have one. And then even then, it’s even not a one-to-one there, because an Aura, likewise you sometimes define this in your .CMP folder or file. It’s one of those things, where it’s spread around and this goes back to when you think about the on-ramp to just learning Salesforce, as whole. As a product, as a platform, to build with it, to then add in these layers of the developer experience, the learning curve, again, it just, unfortunately, is just an added barrier. Something that we’re looking to help facilitate people migrating over to LWC.
Josh Birk:
Got it. I was laughing out loud to that because I believe you described every Aura component I ever created. I’ve tried to think of an instance, where I didn’t do exactly what you’re describing, controller to helper, do a bunch of stuff in helper. In LWC, it’s not that you’re stuck with a single JavaScript, if you have a utility JavaScript, for instance, you can bring that in…
Greg Whitworth:
For sure. Yeah.
Josh Birk:
You make the choices, as opposed to Aura enforcing how it wants it to be seen.
Greg Whitworth:
Exactly. Yeah. It’s a lot more flexible. That said, we’ve gotten feedback of some folks wanting single file components, similar to how View is structured and the capability of having more folder management. Those are things we’re always entertaining. This is true with any framework, they have to do something in order to go compile but we’re always open to feedback and use cases, where people are like, “Here’s a better folder management.”
It’s not necessarily dogging itself on Aura, it’s just this is how technologies evolve and we notice ways in which things can be better and LWC made that choice and, personally, having to learn both of them, I found LWC is way more approachable than Aura.
Josh Birk:
Right. Before we turn this into an Aura bashing session, it’s probably good to note the timing-
Greg Whitworth:
Yeah, that’s not the goal.
Josh Birk:
… Of Aura. Right. Exactly. It was innovative at its time and we released it before these industry standards really started to, I want to use the word congeal, but before they formed, really. It’s a victim of its own timing, so to speak.
Greg Whitworth:
For sure. And that is definitely something I wanted to reiterate. It’s not about bashing Aura, it’s more of, hey, here’s the goodness that LWC can bring to the table and why we’re investing in it and the changes that we made. Yeah, the goal is not bash on Aura itself because it had its time in the sun and, to your point, time had a big thing to do with it.
Josh Birk:
Right. I mean, I still think Remote Objects in Visualforce was actually pretty cool tech, it doesn’t mean I’m ever going to use it again.
Greg Whitworth:
I’ll have to take your word for that. I’ve actually never had to go use that, so I’ll take your word for that.
Josh Birk:
I always joked that when Visualforce first came out, it was the least JavaScript-friendly container ever… I know it wasn’t intentionally designed that way but I like to use the anecdote that if you didn’t spread out your iterator correctly, it would parse your tag as a script tag and then tell you that it couldn’t process the script tag and break your JavaScript.
Greg Whitworth:
That’s great.
Josh Birk:
And it got from there to, basically, an empty slate, that was like, “Hey, do no harm but write whatever JavaScript you want and we’ll run it without having to do…” Basically, it was standard controllers for JavaScript, you could talk directly to the data layer.
Greg Whitworth:
Got you.
Josh Birk:
It was neat but Aura started getting us talking about components and single page apps and stuff like that and getting away from a view state and now we’re into the world of standards. I was the old-school JavaScript guy, who then jumped into the latest version of ECMAScript and there was stuff like import tags. It was culture shocking to me but then, my Java skills kicked in, I’m like, “Oh my god, this is amazing.”
Greg Whitworth:
Yeah.
Josh Birk:
“This is so much better.” Did you have any experience like that or have you just been learning JavaScript as it’s been rolling out?
Greg Whitworth:
Oh, well, to your point of having lived in the standards world.
Josh Birk:
Yeah.
Greg Whitworth:
Yeah, I’ve been able to watch those land and evolve so, to your point, of add imports, the introduction of class, the introduction of let versus var and const and all those types of things. As those lands have just been awesome because, for those of us that have authored in typed languages or other languages, then you see the value in those, while also understanding the value of the scripting language. It’s been great watching that coalescence to improve the developer experience, which actually makes a lot of syntax highlighting and all those different capabilities a lot easier than us being able to grok. You go into somebody else’s code, being able to understand, “Oh, that can’t change.” Versus everything was just var for the longest time.
I love how the language is continuing to evolve and continuing to improve the developer experience.
Josh Birk:
Yeah, completely agree and for people who are going through that culture shock a little bit, I have to say, I compare it to those 3D images at the mall. Once you just let your eyes un-focus a little bit and then you realize the nice structure that you’re looking at and just…
I think you hit the nail on the head right there, how much easier it is to read a random set of code, as opposed to the wild west that it was, that JavaScript was when I grew up.
Greg Whitworth:
Yeah. For sure.
Josh Birk:
Now, talking a little bit more about the data layer. Well, actually, before the data layer, let’s talk a little bit about eventing because it’s a common thing that anybody who has to do a slightly complicated application, is going to run into. How does Aura eventing compare to Lightning?
Greg Whitworth:
Yeah, Aura eventing, you have the Aura event stack that you can basically set up an Aura event, which basically, any other Aura component can then subscribe to that Aura event, and basically, listen to it. LWC has a native web component eventing so basically you can do a eventing propagation and funnily, those can be subscribed to as well, just in the native stack.
However, unfortunately, this may not cross shadow boundaries, you may not know which ones are actually available to you, to subscribe to. What we recommend is using the Lightning Message Service, which basically, you end up with an XML file, where you go to describe that channel and then, like we were talking about earlier, in JavaScript, you actually then import your add import into your component, the Lightning Message Service in that specific channel, which again, you then are basically evoking this channel on passing some data, some type of events that you want to pass around to various components across the Salesforce application, which then can be subscribed to and ultimately, you can then do whatever logic you wanted to, based on that events chain.
Josh Birk:
Got it. And moving from the messaging down to that deal there. For data integration, we’ve got things that Aura didn’t have like the @wire annotation and Lightning Data Service. How does that change the game between accessing the data layer between Aura and Lightning?
Greg Whitworth:
Yeah, it drastically changes the game and the fact that… One thing that’s important to note is that @wire is using the standard build decorators from JavaScript. @wire is, in a lot of respects, a simplicity on the Fetch API, call that as a standard but the real magic happens in that, we actually do a bunch of caching, within LDS or the Lightning Data Service, which owns the @wire. If you make calls through LDS, we actually will cache those things and things haven’t changed.
Ultimately, you greatly improve your users’ experience, due to us caching-
Josh Birk:
Because that really rounds up what my next question was going to be. This is seriously more performant than having to go back to the well every time.
Greg Whitworth:
Yeah, 100%. Saves you, your users a ton of [inaudible 00:14:42].
Josh Birk:
Now, Data Service also gives us access to GraphQL, we’ve covered that on the show a little bit but give us a recap. What is GraphQL and how does it compare to SOQL?
Greg Whitworth:
Yeah, GraphQL is, in my opinion, one of those breakthrough technologies that anybody that’s written and been… It’s not even Salesforce specific, where you had to write a JavaScript application and you’re like, “All right, here’s all the data I have,” and it’s spread across these five different REST API endpoints and so, hey, I’m going to go basically build an adjacent object, let’s say, I want profiles, username and their address and then, over here, I want the content object and something else. If you were going to go hit this with SOQL, you’d have to build on that period completely, and potentially make numerous different calls.
As it relates to GraphQL, you can just say, “Hey Salesforce, here’s the data that I need across the different objects,” and you can also provide variables. As GraphQL, again, it’s an industry standard, you can provide variables into this and you’ll say, “Here’s specifically the information that I need,” and it will return you one adjacent object. You’re not having to pull a PCL across numerous different REST APIs, you can just hit one REST API endpoint and, again, they’re adding support for @wire support so this brings in all those benefits we were just talking about, for caching. And again, the caching in the SOQL here is prior to an exist, whereas, on the GraphQL, those will now exist.
If you’re hitting the endpoint and you’re asking for the same content and it hasn’t changed, you’ll get the same response without having to.
Josh Birk:
Got it. Currently, for production, we can access GraphQL, it’s not on the wire so we can do the cool JSON, not object but in the future, we’ll get the performance of that caching. What does that roadmap look like?
Greg Whitworth:
Yeah, good question. The GraphQL Wire Adapter is currently in pilot of Spring ’23, with the expectation of the Wire Adapter going GA in winter ’24 and around that same timeframe, there’s the expectation that we’ll add a mutations port in pilot. Basically, you’ll be able to update and modify via that Wire Adapter in GraphQL platform as well.
Josh Birk:
Got you. That sounds pretty cool.
Greg Whitworth:
Yeah.
Josh Birk:
Nice. All right. Let’s move onto styling. I found Aura to be, shall we say, very brute force in what I had to do in order to get a component to style close to what I found the native UI to be. I had to keep reproducing stuff in that CSS class to insist on my own styling. How does styling differ in Lightning?
Greg Whitworth:
Yeah, there’s actually quite a bit of differences. For one, again, LWC’s based on native web components, which comes with a Shadow DOM and the TL;DR of Shadow DOM is everything’s basically encapsulated. By default, a component, if you don’t own it, if you actually can’t style it by default. But, of course, we understand that people are going to want to be able to style, let’s say for example, the base components.
The SLDS and the base components team adopted styling hooks, which are actually built on top of a CSS center called Custom Properties. They have all these styling hooks that you can basically go modify any of the properties and this will propagate to the various components. This is probably the most drastic change.
And then, if you leverage, for example, we introduced into LWC, a new capability called mixed mode and this will actually allow you to leverage native Shadow DOM. The reason why this is beneficial is, again, going back to the timing. We introduced a synthetic, basically, a polyfill of Shadow DOM because we had to support IE11, Legacy Edge, all these different browsers but there’s new capabilities that come out with new web components that we don’t necessarily want to polyfill forever.
If you leverage mixed mode, which you can go do today, you can then leverage the part pseudo element, which allows you to hoist these items in your shadow, which allow others to style them. But again, they don’t, to your point of… You then don’t take a dependency on the DOM structure, you want it to be copying all of the classes so that you have the same specificity, to ensure that your styles work.
It’s a much better way in that it allows the component to say, “Hey, I’m going to keep my encapsulation,” which is very similar to what they’re trying to achieve with styling hooks, which is, hey, I’m going to keep my DOM encapsulated so that if I need to change it or add new functionality, it doesn’t break your styles. While, at the same time, giving you that flexibility. And I know that they’re looking even more into that area. If you’ve got a chance to visit their booth at TDX, they’re looking even at global communicabiliies to unlock that, so stay tuned for that. Super excited about what they’re playing around in that space.
Josh Birk:
Very cool. Just a quick jargon check, synthetic polyfill. First of all, the name of my next techno band, I believe. Synthetic polyfill is basically a code shim that you need to use because a legacy browser, like old-school IE, doesn’t have it in its native capacity, to do what you need in order to make the DOM work? Is that an accurate paraphrase?
Greg Whitworth:
Yeah. A polyfill is basically, hey, the browser doesn’t happen to support this native feature that maybe other browsers do and so, we’ve written a JavaScript shim of Shadow DOM and we call it synthetic Shadow DOM and we want to slowly chip away at that and it’s more and more browser supported. You may have seen, the beginning of this year, we ended support for IE11 and will continue to march forward as technology advances and evolves. That is what synthetic Shadow DOM is. It’s meant to be a shim for browsers that don’t support aspects of native web.
Josh Birk:
Cool. Now, let’s talk logistics a little bit. Let’s say I’m listening to this episode, I’m getting sold on the bonuses and advantages of LWC. I haven’t moved to there yet, I’ve yet to build my first Lightning Component, shall I say, and I have a hefty amount of Aura that I’ve been slowly maintaining over the years. What are some good strategies for me to start thinking about moving my Aura into a Lightning world?
Greg Whitworth:
That’s an awesome question and one thing, we all, at Salesforce, work on software. We understand you need to be pragmatic. It can’t just be this, “Hey, tomorrow we’re going to go re-write everything over to LWC.” Salesforce itself has not re-written all of Salesforce from VF and Aura over to LWC. We’re super pragmatic about it, we’re like, “Hey, what is the most used? Where would they see those largest performance gains? Where are the largest functionalities where we’re investing?”
One of the key things that I say is, the easiest thing you can probably do is say, “Hey, all net new components got to go. Are going to be in LWC.” That’s the easiest entry and then you can start saying, “Hey, if you have an application or components that are heavily used.” A good example of this at Salesforce is the record things. Probably the most commonly visited and we have related lists and all these other capabilities. Those are worth considering to move over to LWC because of the fact that we see, on average, 20% performance improvements for your users.
It’s one of those things where take each component, in isolation, the key thing that I recommend is all net new going forward, builds on LWC because that’s where we’re investing, that’s where the new features are coming, that’s where the tooling time is being spent.
Josh Birk:
Nice. Are there edge cases that people need to be aware, where maybe we don’t have feature parity on LWC from Aura yet?
Greg Whitworth:
Yes, 100%. There’s actually very intentional, where we didn’t go one-to-one from a functionality perspective and say, “Hey, everything in Aura needs to be in LWC.” But at the same time, we really have been listening to customers and saying, okay, a good example of this was dynamic components. Dynamic components are available on Aura, they’re not available on LWC so some people are… Especially ISV’s of people building applications, are like, “Guess what? I don’t know which components are going to be there, so while I leverage LWC everywhere else, I have to write an Aura component, at least for this scenario because I need dynamic component capabilities.”
We actually, over the past year, have taken the time to come up with a design because one of the reasons we initially didn’t have it in there was because it impacted performance. One of the key reasons we leaned into LWC was to improve performance. We came up with a design for dynamic components that doesn’t negatively impact performance. It’s actually been in pilot for a few releases and it should be going GA in winter.
Josh Birk:
Nice. Anything else on the LWC roadmap you want to give a shout out to?
Greg Whitworth:
Yes. Third party web components, I’m super stoked about this. And one of the key reasons I’m so excited about third party web components, just for context, is let’s say that you have a design system, you maybe authored it in some other language, some other framework, Vue’s, Svelte’s, React. Something of that nature. Or maybe you even authored it in Vanilla native web components. Most of these frameworks actually allow you to compile down to custom elements with probably a very small amount of JavaScript.
What’s great about it is, you then can just wrap that in LWC and now you can just reuse it anywhere within Salesforce. If you want to be able to point it, use it in our app builder, we showed this off at the LWC demo booth. Super excited, we’ve got a ton of interest. Folks have been playing around with it and they’re just super excited about being able to reuse those components. Additionally, you can then go across the lab and say, “Hey, I found a component I really like. I want to be able to bring this onto Salesforce,” you then don’t have to completely rewrite that into LWC. You can say, cool, it’s a native web component or some examples, CI/CD flow, now I have a build step that compiles it down.
Again, most frameworks actually have an API you can call to compile them down to native web components.
Josh Birk:
And that’s our show. Now, before we go, since we did already ask after Greg’s favorite non-technical hobby, I asked him what non-technical hobby would he like to take up?
Greg Whitworth:
One that I would actually love to do, except for definitely would not be able to do for a variety of reasons, is rock climbing. Rock climbing, I’m scared of heights and I don’t have the greatest of shoulders so I wouldn’t be able to really pick myself up. But it’s one of those things that it’s such a cool… The shots always look amazing and it breaks my brain, especially when you see them sleeping on the ledge, they set their tents up.
I love the premise and the idea of it but yeah, I would never be able to do it. But yeah, I think that would be a really cool hobby.
Josh Birk:
Yeah, I’m a 100% with you on all of that. My fear of heights is not great but it extends to that scenario. I have found out that between my wife and I, she’s the one with the upper body strength, go figure.
Greg Whitworth:
Got you.
Josh Birk:
There is a VR game coming out, I think, that’s rock climbing and that might be the neutral ground for me.
Greg Whitworth:
Not me, although, I’ve also seen the videos where people are just on a board and their brain gets so used to thinking that’s real. I don’t know, we’ll see, I may have to give that a shot because I do have a VR headset.
Josh Birk:
Very cool.
Greg Whitworth:
I may have to give that a shot but if I end up falling down, crying on my floor, I’ll make sure to send you the video.
Josh Birk:
I want to thank Greg for the great conversation and information, and as always, I want to thank you for listening. Now, if you want to learn more about this show, head on over to develop.salesforce.com/podcast where you can hear all the episodes, see the show now and have the links to your favorite podcast service. Thanks again, everybody and I’ll talk to you next week.