Greg Whitworth is the Director of LWC’s application and backend services. He’s also the Director of Standards and Web Platform here at Salesforce. Today, I am talking with him about his long history of working with web browsers. Specifically, we get into his experience with web standards committees, discuss how these standards come about and the benefits they can have for Salesforce and it’s developers.

Greg has a very unique perspective and history with these topics. Tune in to hear it and lots of great background information on web standards.

Show Highlights

  • What Greg’s job looks like day to day.
  • All about web browser committees and how to join one.
  • How something becomes a web standard.
  • How his input on standards benefits Salesforce, its developers, and its customers.
  • Examples of standards that are helpful to Salesforce.
  • How standards improve developers’ skills and user experience.
  • What the composite layer is.
  • What polyfills are and how to work with them.

Links

Episode Transcript

Greg Whitworth:
… and I was on Twitter and somebody was like, “Hey, Microsoft is holding a job fair for the IE team,” and just inquired about that. And they happened to have a position open for the IE team and DM-ed me about that, and kind of the rest is history.

Josh Birk:
That is Greg Whitworth, director of LWC’s application and backend services as well as our standards and web platform here at Salesforce. I’m Josh Birk, your host for the Salesforce developer podcast. And here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Greg about his long history in working with browsers, and, in particular, web standards and the related committees. But we begin not necessarily with his early years, but how Salesforce stole him away from Microsoft.

Greg Whitworth:
Again, I think it just kind of comes full circle. The networks that you kind of run in are very similar. And some of the work that I was doing within Open UI, I’m a co-chair of that community group, definitely resonates. Again, everything I was working on at the platform level, the browser engine level, was all on the front end. So, think basically HTML through the rendering stack [inaudible 00:01:23] the browser. Yeah. Basically, the platform team needed was interested in having a PM for LWC and kind of the standards efforts that were already underway, but just wanted to have me get engaged there, and likewise on the team there’s SLDS and base components. So, it’s a good natural fit for me to be able to engage with those teams.

Josh Birk:
Got you. And I like to ask people in your position this question, because I find people with similar roles still have wildly different answers to it. What is the day to day look like for a job like yours?

Greg Whitworth:
Oh, goodness gracious. A lot of meetings. And I would say the most important part, if you’re going to talk to somebody what the product is. Engaging with the customers, seeing what they like, what they don’t like, whether that’s LWC, whether it’s the services, whether it’s the full end-to-end. The cool thing about engaging with the customers is rarely is it ever about just your product. It’s usually the end-to-end flow. So, you find opportunities for teams all across the company, not to mention, like we were talking about at the web standards, web platform level, you find opportunities everywhere.

Josh Birk:
So, let’s talk a little bit more about those web standards. Which committees are you currently on?

Greg Whitworth:
So, myself, or Salesforce in general?

Josh Birk:
Yourself.

Greg Whitworth:
Myself? So, I’m involved with the CSS Working Group. I’ve been there pretty much since I started at Microsoft, at least seven years now, roughly. And then you’re not necessarily a part of it because it’s not an official group, but I engage in the HTML specification with [WHATWG 00:02:56]. To a lesser extent, [inaudible 00:02:58] given the Open UI as the other one that I co-chair, like I said, is the other group I’m heavily engaged in. Likewise, given LWC, the web components working group. Yeah. So, those are the primary ones I’m engaged with.

Josh Birk:
And so, I kind of find it… because I’ve been doing web development for a really long period of time. And I think it’s safe to say that the W3C has had a profound impact on my life. Right? I’m a veteran of the browser wars. I have a denim color Netscape t-shirt that I bought from the Netscape corporate store. But the thing is, I don’t know anything about these committees and how they operate. They’re just kind of nouns to me. So, for instance, how big are these committees, and how does one actually join them?

Greg Whitworth:
So, it’s actually quite varied. It really depends on the group you’re engaged in. If you were to go attend the CSS Working Group, you’ll have, potentially, anywhere from 20 to 40 people in the room just because of the breadth of CSS where you talk about fonts, layout, the cascade, animations. It’s very, very broad. Whereas, there’s groups I’ve been engaged in the past like the Media Working Group where there’s very few people in the world that truly understand Codex and how to bring those to the web. So, there’s maybe five to eight people on a call regarding the media capabilities that run on the web.

Greg Whitworth:
How to join them, it likewise varies. There’s there’s different tiers. So, a community group, anybody can join, which is basically, “Hey, we want to just get a community of people together.” Anybody can actually go spin one up. You don’t have to be a part of a member org in order to engage there, and it’s one that I highly recommend people start getting in touch there. Likewise, you don’t necessarily have to join them to influence the direction. Most of the editors of specifications post tweets or statuses, places. All the issues, the majority of the places now are on GitHub. So, you can jump on an issue and leave feedback. So, there’s a variety of ways of getting involved.

Josh Birk:
When doing this research, it seems like you’ve been on a lot of listservs over the years.

Greg Whitworth:
Yes. Yeah. Yeah. Although, I was pretty lucky about three years into primarily working on the CSS Working Group. They moved over to GitHub. There still is a email list for archival purposes, and a lot of the GitHub issues auto-generate into that, so that there’s archival purposes for history.

Josh Birk:
So, that I can research you on the internet at some point.

Greg Whitworth:
Exactly. So, if, hypothetically, something were to happened to GitHub, it’s stored somewhere else, why decisions were made the way they were made.

Josh Birk:
Well, let’s talk about that a little bit more. And this might be difficult because I’m asking you for the Cliff Notes version of it. And feel free to tell me that it’s simply doesn’t exist, but what’s the Cliff Notes version of something actually becoming a standard?

Greg Whitworth:
Oh, no. Yeah. There’s a Cliff Notes version, for sure. And we’ve actually had a few that just kind of came out and are going through this process where it kind of just starts as, obviously, there’s an idea, and you kind of have to get a gauge for how likely is it for people to use it. Because just like anybody, everybody has only so much bandwidth of time to spend, whether that’d be authoring the spec or implementing the spec. And so, then write up an explainer, and that effectively is, “Here’s the problem. Here’s my proposed solution. Here’s the venue I kind of foresee people going to it.” And let’s say, hypothetically, the person proposing this as not an org member, so can’t just necessarily go right to the CSS Working Group in an easy way, outside of filing a GitHub issue.

Greg Whitworth:
There’s actually something called the Web Incubator Community Group in the W3C that you can kind of go into and say, “Hey, I have a proposal for this.” And if browser vendors kind of come on there and say… or spec authors, if you have enough people to say, “Yeah, this should happen,” they spin up a repo where you start working on a rough draft specification. And then, at some point, you kind of cross this threshold, and it kind of varies spec to spec. But, basically, people have said, “We’ve asked the majority of questions. We’re going to graduate this to one of those standards body,” so those working groups.

Greg Whitworth:
So, we’re going to say, “Hey, this is actually,” let’s say it’s a new selector in CSS. Like, “Okay. Cool.” It’s going to graduate out of here into the CSS venue. They’ll pick it up. They’ll actually land it into one of the specifications that has all the wonderful legal IP, all that kind of stuff that gets wrapped into it as it goes through the normal standards process. And then, ultimately, for it to become a standard [inaudible 00:07:38], usually need two to three implementations in a user agent. So, at that point , once you’ve got it in the group, it’s pretty solidified, and people go implement it, and it’s a standard.

Josh Birk:
Selector and CSS is an interesting example. How often is [inaudible 00:07:56] fine-tuned as that, or is it a bigger concept like a new tag or something like that?

Greg Whitworth:
Well, so, unfortunately, they’re never that… to your Cliff Notes statement, they’re never that simple. Everything that seems simple as always complex, unfortunately. Yeah. Coming in with a new selector, it just varies on what that selector is trying to do. Yeah. There’s always these devil’s in the details type things.

Josh Birk:
Right. I would imagine arguing over background color would probably be different than arguing over [inaudible 00:08:31] important.

Greg Whitworth:
I truly can’t answer that, because every single time I go into a meeting, I’m like, “Oh, this will be quick,” and then we argue about it for 40 minutes to an hour, and all of the points are valid. So, it’s like things you hadn’t thought about. So, it’s always fruitful discussion.

Josh Birk:
Okay. So, you have a long history working with Edge as a browser, browser technology in general. What are some of the standards that you have been deeply involved in that you’re either proud of or you think were really kind of important to making…

Josh Birk:
…or you think were really kind of like important to making browsers better today?

Greg Whitworth:
Oh goodness. That’s a good question. Yeah. Yeah. So when I first joined Edge and got started working in the CSS working group, this was the Edge HTML days, we had actually just moved away from IE 11. And so much of it was interoperability. And it’s very common for web developers to effectively see an interoperability issue in their developer browser of choice they assume is the correct one. And so we would just have bugs upon bugs upon bugs of, hey, you’re supposed to be rendering it this way, but you’re not rendering it this way. And so a lot of early on things were actually just, hey, our multi column rendering is different than the other browsers. Technically we’re following the spec. Or hey, we’re not following the spec, but it actually makes more sense than maybe what the spec says for this given use case. So there’s a lot of actually just aligning implementations, which is referred to interoperability, because ultimately you want all the browsers to be rendering the same while having separate implementations, thus validating the specification.

Greg Whitworth:
Additionally, there actually was never one single, this is going to sound amazing, there is no single table specification for the layout of HTML tables. And so basically we had a ton of interoperability issues with tables, table layout, and that stems from the fact that I had tables, it was reverse engineered and then reverse engineered by Mozilla and so on and so forth. So it was one of those things that because of the fact there is no standardized here’s what happens when these attributes are applied, here’s how you lay out rows and columns and stuff. What we did is we actually take the three or four different specifications, a colleague at the time, [Francoise Remy 00:10:50], [David Behr 00:10:51], and other folks that have been around for a long time got that one together. And so we still have issues filed on it. Francois primarily drives that one these days. But yeah, that was another big one.

Greg Whitworth:
One that was thrilled to be able to be a part of was both CSS Grid, the interoperability issues with CSS Flexbox and landing that, as well as custom properties kind of being there, which a lot of people refer to a CSS variables. But just being able to bring that dynamic content. And in all honesty I feel like those three really moved us away from document type web building to web application in CSS. So you had dynamic capabilities of theming and styling and Grid basically gave you that two dimensional layout capability. Now we’re even starting to talk about, [Miriam 00:11:40] is doing a great job driving container query. So all these capabilities for web application layout and design is now achievable. So I would say definitely was thrilled to be a part of Grid. That started in IIE way, way, way back. And then finally, Gallia stepped up on behalf Bloomberg to implement it in Chromium and WebKit. Not many people know that. But it was just super awesome to see that come to fruition. A lot of hard work went into that with the editors and the CSS working group and general web developer feedback. So just great to see those specifications and then any interoperability. It’s a dirty task, but it’s a very important one because people do expect interoperability within the web browsers.

Josh Birk:
Yeah. So I think that’s interesting because it sounds like you’ve got two sides of the coin there. You’ve got the kind of the dirty grunt work, which is simply trying to make the browsers behave better together or in parody I guess is one way to put it. Most people probably don’t see those benefits when they’re looking up something like a CSS Grid. And then CSS Grid is kind of like the shiny object that allows people to do new layouts and stuff like that. Is that kind of a fair spectrum of the work that you’re doing on standards?

Greg Whitworth:
Yeah. Yeah. I think anybody that engages in standard, I would say software engineering in general kind of, they know that it’s one of those things that if it isn’t broken, you don’t notice it. And that’s weirdly the thing. You actually don’t want anybody to notice the Grid interrupt issues because of the fact that’s inherently a flaw and we need to either address the spec or the implementation in given browsers. That said, and I have a colleague, a friend, colleague that is super into font rendering. And it’s one of those things that it’s very easy to just be ah, font rendering, fonts, but when you get blurry text or texts not rendering correctly, you notice it and it hurts to read and all that other stuff. So it is a thankless task because somebody will come out with a new font and that gets all the praise, right? They’re like, oh my gosh, did you see this new typeface? It’s so gorgeous. But the person spending the time making sure that the sizing and the rendering on the new display is [crosstalk 00:13:53] doesn’t really get much praise. But if it’s not right, you notice it because it’s so fundamental.

Josh Birk:
Yeah. The guy actually putting the pixels on paper. And second, I think I might be interested in interviewing that guy because it sounds like that’s the kind of person that I could simply ask the question, what’s interesting about rendering a font and then go make a cup of coffee because he’s going to just talk for 20 minutes about it.

Greg Whitworth:
For sure. There’s actually open discussions. There’s actually a CSS Houdini project. Numerous people within the CSS working group have an interest in trying to expose those wonderful font metrics because a lot of people want to do their own text layout and do things with those metrics. The problem is, as you know, many of the folks that know fonts way better than I do will tell you, basically they all lie. So you start going down the rabbit hole of now we need to standardize the font metrics and everybody does their own appeasing of those lies. Like, okay, it told me the X height is 10, I’m going to manufacture that because I actually believe it’s H. So yeah. It just opens up a whole nother can of worms. But yeah, there is still a desire to see that come to fruition.

Josh Birk:
So I love the concept of a bat twist on lies, dirty lies, and statistics. It’s like lies, dirty lies, and font statistics. To go back a little bit to CSS Grid, because there’s an article you are mentioned in, and it goes into the long history of CSS Grid. And I’ll try to remember to get it on the show notes because I was fascinated that prior, the conversation about this kind of feature prior to CSS Grid actually started around like 1996, which is sort of mind blowing in web era terms. But then you also mentioned Bloomberg got involved in that. Is that normal for a corporate entity like that to kind of swoop in and be like, hey, we have an interest in the standard and we want to help you build it?

Greg Whitworth:
So I presume when you say 1996 it’s probably the wonderful old school email archives of, hey, it would be cool if we had auto layout sizing.

Josh Birk:
This big. Yeah.

Greg Whitworth:
I would presume so. Because I do know Bert Bos, one of the co-creators of CSS, had talked about template layouts and auto layouts for years. And then to just give a quick summation [inaudible 00:16:07] effectively, Grid layout, IE introduced that and it actually came from the XAML language and [Bo Cup 00:16:14] actually was the one that initially introduced it. [Peter Sallis 00:16:17] did the initial implementation. And that kind of showed people in the CSS working group it’s feasible. It’s performant, it’s possible on the web, a browser can implement it. The problem is, is okay, well now we need to go spec it and well the developer ergonomics weren’t so great with that. Design, you had to remember all the line numbers and stuff in order to place the items. And so there was this kind of merging of different specifications to ultimately create a great Grid experience.

Greg Whitworth:
And I think probably the article you’re referring to is probably authored by [Rachel Andrews 00:16:44] who really, really pushed early on. And I hadn’t even when I joined, I hadn’t even heard of Grid and she pinged me and was like, hey, I heard that you’re the new layout PM on Grid. So she was remarkable in making sure that the developer ergonomics and the use cases were covered really well. And [Elica 00:17:03], [Ethmad 00:17:04], [Rossin Atimasov 00:17:04], and [Tab Atkins 00:17:06] and the rest of the CSS working group spent a ton of time ensuring that Grid would just be kind of the end all be all of application layout. And so it was just super cool to see that come to fruition and ultimately be a great experience in continuing to see people on Twitter that are like, hey, I moved to this.

Greg Whitworth:
That said, to your point of Bloomberg, yeah, they actually had it on their terminals. They wanted it for their terminals, for the terminal layout, the little tickers and stuff. And it was one of those things that they, I do remember them initially attending and kind of pushing that forward, but then they kind of started having Gallia advocate on their behalf and really put in the time and energy into not only helping with the spec of the different issues, but beginning to do the implementations as noted earlier with regards to WebKit and Chromium which allows them to uncover issues that you just don’t, when you’re talking about just the use cases and the stuff of that nature, it gets you a good 70%, 80% of the way.

Greg Whitworth:
… cases and the stuff of that nature, it gets you a good 70, 80% of the way there. But then when somebody starts trying to implement that new specification and then web developers finally start playing with that behind a flag, you start finding all these other caveats, because it’s basically, you start doing kind of the finishing work on the specification. So I would say these days it’s very common. It was kind of uncommon to me at the time –

Josh Birk:
yeah.

Greg Whitworth:
– to see that level of, I would, say funding, to an extent.

Josh Birk:
Got it.

Greg Whitworth:
Because you always had corporations and other entities involved, but for me, it was almost always a driving perspective, whereas they kind of said, “We’re going to kind of do an end to end very similar to what browser vendors did.”

Josh Birk:
Interesting, interesting. So to kind of follow up on that then, where does Salesforce lie on that? What’s the advantage and benefit to us and our customers and our developers for you to kind of be in that room when these standards are being talked about?

Greg Whitworth:
Oh, it’s pivotal, just because of the fact that Salesforce is a platform itself. So obviously, we build on the web browser as a platform, and then on mobile, it’d be web views, but underneath of that, there’s other platforms, DOS and so on. But we likewise have App Exchange and people … ISV is built on top of the Salesforce platform. So we have scenarios that not many websites actually have, where an admin can actually go install a complete application from the App Exchange –

Josh Birk:
Right.

Greg Whitworth:
– or drop components in, in the app builder. And everything needs to seamlessly function together, be very performant, and then also be very secure. So there are things that we have that we’ve implemented polyfills for. We were early on the train with web components in a few of the browsers, like ironically, the one I came from. It didn’t necessarily support everything for web components when LWC, the lightning web components, was coming to fruition.

Josh Birk:
Yeah.

Greg Whitworth:
So we actually created a full polyfill for Shadow DOM. And I think it’s a good example of us leaning into it, because we’ve seen with the polyfills, when you’re writing JavaScript, there’s only so much optimization you can do there. And I mean, when I’m saying optimizations, I mean for a performance memory consumption, all that kind of stuff –

Josh Birk:
Yeah.

Greg Whitworth:
– to provide a great user experience. One of the ones that I love to show off here internally when I’m trying to be like, “Hey, you all should get engaged in standards,” is the HTML-5 drag and drop. I know it’s a while back, but there’s a great before and after of our Kanban board of the JavaScript version versus the HTML-5 one, and it just enables you to kind of go see the performance optimizations a browser can do that, unfortunately, you just can’t do in JavaScript today. And going back to kind of the security aspects, we really need to ensure that web components and the various different specifications we’re engaged in cover the use cases that are relatively unique to us, but ultimately we want to be able to delete those polyfills and those solutions. We want to be able to hand them over to the browser vendors that can ultimately provide the best user experience to our customers, while still ensuring that the great platform we’re providing to our users is maintained.

Josh Birk:
So going back to that list of polyfills, are there other standards that kind of reach out to you, come first to mind that are going to be helpful for Salesforce to be able to replace with proper standards?

Greg Whitworth:
Yeah, there’s quite a few. One of them is scope custom element registries. That’s one that we’ve actually been talking about in the web components working group, Carry Pitino, Leah Baltar of our team have been driving that one, as well as Realms, the same folks. Rick Waldren’s gotten involved in that as well.

Josh Birk:
Got you.

Greg Whitworth:
With regards to basically keeping the scope customer element registries ensures that, again, we can drop numerous of the same component type. So just imagine you have your own custom element named button, this ensures you’re not using the same global registry, because then you have named conflicts.

Josh Birk:
Right.

Greg Whitworth:
So we need to be able to have numerous on a single page. So we have to have our own scope custom element registries. And then likewise, Realms effectively enables us to kind of say, “Hey, you get your own little isolated world. You can’t necessarily reach and go to other different elements on the page and be able to get their content for kind of an isolation boundary opportunity.”

Josh Birk:
Got it.

Greg Whitworth:
So those are two of the main ones. And then another one that we’re heavily engaged in is Open UI, which is effectively we already shipped base components that are great, accessible, and provide great functionality that any admin can go use or ISV, to just get their UI up and running really quickly based on the lightning design system. And ultimately though, so many of those, every company kind of rebuilt. So the goal of Open UI is trying to drive those controls and components that everybody rebuilds right back into the browser, very similar to those polyfills. So hopefully over the next couple of years, we’ll actually be able to say, “Hey, lightning button actually just uses …” actually, this is a bad example, but let’s just take the drop-downs, and it actually just uses the built-in one. And you saw the same extensibility and styleability capabilities you have with the built-in ones.

Josh Birk:
Got you.

Greg Whitworth:
We just don’t necessarily have to maintain all of that JavaScript again –

Josh Birk:
Right.

Greg Whitworth:
– allowing us to reuse the expertise that the accessibility working groups and all those folks can bring to the table, the optimizations for performance, as well as they all have wonderful relationships with the various AT vendors. So they can then ensure that in VA narrator, voiceover, all those wonderful assistive technologies are likewise testing those same components. So it’s just a great initiative. It’s not a short-term thing, as no standard is.

Josh Birk:
Right.

Greg Whitworth:
That said, but yeah, all of it is very exciting, and definitely Salesforce being there helps us ensure that that entire vertical stack, so the platforms that we’re rendering within, provide a great user experience to our customers.

Josh Birk:
No, I remember from my early e-commerce days, I think actually one of the first things I wowed people with, with early web development stuff, was a drag and drop cart implementation, but it was kind of terrible.

Greg Whitworth:
It’s hard to get right.

Josh Birk:
It’s really hard to get right. It was cool really kind of only because it worked.

Greg Whitworth:
Yeah.

Josh Birk:
If the layer of success was that it actually did drag one thing to another thing and then it worked, but it wasn’t the thing in your head that you wanted to be super smooth. And I think that’s a really interesting example, because if you think about the user interfaces that we use for our low code tools and our data modeling tools, even just simply drag and drop working efficiently is making a more efficient developer, right?

Greg Whitworth:
For sure. And just literally up and down the stack we should be engaged, because just thinking about how any of the network protocols that we can get engaged on, all those different type of capabilities so that we can improve just page load times, like adding … one of the members on the team is heavily interested in bringing forward perf metrics for single page applications, because right now we have to kind of build out a heuristic that makes sense for our end users. And we’re definitely not the only web applications that’s a single page application.

Josh Birk:
Right.

Greg Whitworth:
I mean, the majority of websites that people engage with every single day –

Josh Birk:
It kind of rules the world now.

Greg Whitworth:
– the metrics are kind of … yeah, but the metrics, the first time, first Contentful paint, and all those other ones, they’re useful, but they only truly help if you just only care about the single paint, whereas a lot of times you care about at the component level and down, and all these different things.

Josh Birk:
Yeah. Well, I’m going to invite you to be nerdy and geeky and go back a second.

Greg Whitworth:
Okay.

Josh Birk:
So what is the composite layer and how does that attach to all of this?

Greg Whitworth:
Oh, so I actually have a talk and you can link to it.

Josh Birk:
Okay.

Greg Whitworth:
I’ll cover it real quick. I’ll cover it real quick, but it actually goes over how a browser works from end to end.

Josh Birk:
Oh yeah, okay.

Greg Whitworth:
But basically what the composite layer is, is … so quickly, you end up having HTML that gets parsed, that produces the DOM, and then you have CSS that gets parsed that produces a style tree that gets applied to that DOM tree. And then ultimately, you go into the layout mode after that. So after those two steps happen, you go out to the layout mode. All the boxes are laid out and positioned and stuff. And then ultimately you need to paint that.

Josh Birk:
Okay.

Greg Whitworth:
So you ultimately produce a bit map. So just think a picture, right? Okay. So you then need to be able to interact with that. And that’s ultimately where you end up being able to have the click events come through. And the area where you really see the composite layers come in is that bitmap gets put on a single layer initially, if it’s a single bit map, and it’s not interesting. It’s just a single page, just static content. It just gets rendered once. But now let’s imagine that you have a logo or something that you want to animate from left to right, across the screen. Well, it doesn’t make sense for the browser to say, okay, we’re going to repaint the entire thing, every frame.

Josh Birk:
Right.

Greg Whitworth:
Because that’s bad for performance, it’s bad for memory, all kinds of CPU, everything.

Josh Birk:
Right.

Greg Whitworth:
Because that’s bad for performance. It’s bad for memory, all kinds of CPU, everything. So ultimately what it does is it says, “Okay, because I can isolate this tree down to just these pieces, I’m going to put them on their own layer.” And so ultimately I’m going to be able to render that animation very smoothly because I’m only repainting just this segment. It’s actually very similar to what happens in like 3D models where technically they’re not rendering the entire 3D space. They’re actually rendering only what the user can see.

Josh Birk:
Right. Mm-hmm (affirmative).

Greg Whitworth:
And so it’s very similar to that. And that’s where I get into that talk like, you actually want to leverage that to your benefit because if you change your CSS, and this is why I was saying the selectors and stuff, it’s really hard to really narrow in on what it is because I show that there’s two ways to animate a blue box from left to right. And if you use layout to move that box, all of a sudden you throw away that composite capability because it needs to keep going back and doing layout. And so you now are painting on every frame.

Josh Birk:
Gotcha.

Greg Whitworth:
And so you throw away that performance optimization. So I highly recommend it. It’s called Braces to Pixels.

Josh Birk:
Okay.

Greg Whitworth:
Like I said, I’ll provide you the links.

Josh Birk:
Okay. So we’ve mentioned the word a couple of times now. Let’s define it just so that we can level set with everybody. What exactly is a polyfill?

Greg Whitworth:
Yeah, so they’re effectively like a necessary burden that are a required standard.

Josh Birk:
Okay.

Greg Whitworth:
So let’s say again, that explainer scenario we talked about earlier in the call. Usually when you’re putting that together, you kind of have a rough idea. You’re putting together the paradigm of how that should work. You may be even offering it in JavaScript or web code that you have access to. And so ultimately, what you end up with is JavaScript code that works JavaScript, HTML, and CSS, that functions like the thing that ultimately will ship in the browser.

Greg Whitworth:
And so what that enables the browser to do is go and say, “Cool, I’m going to ship this natively.” And then we can then do a features detection on the front end and say, “Oh, do you support this capability?” If not, we’re going to polyfill it all, which is a lot of work for us to do, but it also helps influence the direction of the standard.

Greg Whitworth:
A couple areas that we’ve done this, and I’m really thrilled with, again, the LWC team prior where we have somewhat unique needs, where ultimately we have AppExchange where you can grab components from numerous people that have built them and drag them in into the app builder and stuff like that. And so like a global registry for custom elements just isn’t sufficient. So we need a scoped custom element registry. That’s being driven through in the web component working group and making great progress.

Josh Birk:
Gotcha.

Greg Whitworth:
Likewise, we have areas for security where we need to be able to say, Hey, this component can’t necessarily reach into other components and maybe scrape the data and do something with it. So that’s why we’re really championing this proposal called Realms, which is already actually built into browsers. And we’re just saying, “Hey, can you surface to that in a meaningful way?” So that again, we can kind of delete these polyfills. They may need to exist for, like I said, for that feature detection to all browsers that support them.

Josh Birk:
Uh-huh. (affirmative) [crosstalk 00:29:49]

Greg Whitworth:
But ultimately again, that unlocks that capability I was referring to earlier where those optimizations can really kick in-

Josh Birk:
Gotcha.

Greg Whitworth:
… where we can delete those JITs that we’re sending down the wire because they now ship with the thing. You actually remove the JIT-ing by the JavaScript compiler. All those kind, those alone, but then of course, the browser can take those hints and things and go, “Cool. We’re going to optimize beyond what you could do at a JavaScript layer.”

Josh Birk:
Got it. So my lousy JavaScript drag and drop could be the polyfill that will eventually be collapsed because the browser just knows how to do it.

Greg Whitworth:
Exactly. Exactly. Yeah, yeah.

Josh Birk:
Got it. Okay. Okay. So I mean that feels like the narrative moving forward is do the things until the browser can do the things, and then stop doing the things and let the browser do its thing. It feels like the goal is almost, I’m trying to remember the tech term for it. It’s not planned obsolescence, but it’s something like that. It’s like the goal is to have no code eventually. And I feel like you’re a unique person to answer this, but what’s your prediction? Where do you think this timeline is going along those lines?

Greg Whitworth:
For which specific one? Are you talking about kind of LWC or what?

Josh Birk:
Yeah. Let’s stick with, like how long do you think it’s going to take to like start reducing our code level down to the bare minimum of just implementing something which is effectively standard components that work with Salesforce?

Greg Whitworth:
Oh goodness. I’m actually super, I’m probably bullish on this, probably a little bit too much.

Josh Birk:
Okay.

Greg Whitworth:
But because of where scoped custom element registries are and Realms are, I could see it in then the next couple of years. And I understand some people are a little bit like, may hear that and go, “Whoa, that’s so far away,” but it’s actually, again, that doesn’t mean that we won’t be able to support native web components, just general web components on the platform. That’s when we could potentially say, “Hey, we’re going to remove.” And we can do it in stages. It’s not remove all of it. Like I said, there’s numerous things that we polyfill right now. We have a thing called synthetic Shadow because we had to polyfill for native Shadow. So we can start on paths for different tiers of these for deprecation and removal.

Josh Birk:
Right. We don’t have to wait for the singularity.

Greg Whitworth:
Exactly.

Josh Birk:
We’ll get progressive gains over time. Though, so my reaction having fought the div versus layer war for gosh knows how many long, when you said two years, I’m like, wow, that’s really fast!

Greg Whitworth:
Yeah. And I think it’s just kind of gauging based on discussions around these few gaps that we have to be able to kind of say, cool, these three or four major polyfills we would then be able to kind of delete. That doesn’t mean we’re done by any stretch.

Josh Birk:
Right, right.

Greg Whitworth:
Like there’s more and more things where we’re discovering and continuing to drive.

Josh Birk:
And that’s our show. Now we’re going to add various things to the show notes, including a link to that article about how CSS Grid eventually became a reality. We’ll also link to some of Greg’s other presentations and writings. Let’s just say he has a very unique history and perspective when it comes to the select tag. Now I did ask after, Greg’s favorite non-technical hobby.

Greg Whitworth:
Favorite non-technical hobby. I love to golf.

Josh Birk:
Really? Nice.

Greg Whitworth:
Yeah.

Josh Birk:
When did you learn?

Greg Whitworth:
I mean, a while back. I’m not good. So when you say learn, it’s like I learn every time because I continue to improve my terrible handicap.

Josh Birk:
So you might think you’re bad at golf. I had a roommate in college who was really into golf, and he really wanted me to play. And so he really wanted me to learn. And so we’re on the course, and he’s trained to teach me. And I think it was a nine iron that I whacked him in the chest with accidentally.

Greg Whitworth:
Oh goodness!

Josh Birk:
And that ended my my golfing career right there.

Greg Whitworth:
Goodness gracious. Well if you ever make it out to the Seattle area, I’ll make sure to take you to a course around here. And I’ll stand way back. I’ll stand a little back.

Josh Birk:
Stand a little bit back.

Greg Whitworth:
Yeah. I’ll stand way back.

Josh Birk:
Now as a Midwesterner, I truly appreciate Greg’s sense of hospitality, but also his bravery. I want to thank Greg for the great conversation and information. And as always, I want to thank you for listening.

Josh Birk:
Now, if you want to learn more about the show, 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. Thanks again, everybody. Stay safe out there, and I’ll talk to you next week.

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