This week I welcome Kris Gray, Principal Software Engineer at Salesforce, to the show. He shares how JavaScript frameworks have been used at Salesforce throughout the years. In the early years, the main challenge was a wild west of different frameworks.  Then as development standards were changing, Salesforce was trying to get its own component framework up and running. It’s been a long and complicated route to get to Lightning Web Components, so enjoy this brief history of JavaScript frameworks at Salesforce.


Show Highlights:

  • Kris shares the evolution of JavaScript Frameworks, including the technology and programming used originally and how it shifted over time
  • Why the difficulty with versioning and the desire for a less bulky framework wins out over a highly complex interface every time
  • JavaScript is just one of the aspects used in rendering a web interface, another important component is CSS
  • The current iteration of JavaScript with Salesforce in the form of Lightning Web Components


Shout Out:

Episode Transcript:


Kris: Well the advice of the time was use whatever framework you’d like. And then in those days, it was quite a few right as you had Dojo, jQuery,EXT. And so there was no one said, “use this”.


Josh: That’s Kris Gray, a principal Software Engineer here at Salesforce. I’m Josh Birk, a Developer Evangelist with Salesforce. And here on the Salesforce Developer Podcast, you’ll hear stories and insights from developers for developers. Today, we sit down with Kris to hear a brief history of JavaScript frameworks as they’ve been used Salesforce throughout the years. There he is starting out in the very early days of classic before words like lightning and framework were ever used together. And those days, it was a bit of wild west of options. But Salesforce itself often use a solution called ExtJS.


Kris: Well the big thing was, is that they were we paid them a bunch of money to support us and in enterprises That always gets you a huge put up, right? Even though everything else was free and open source supported, we can always call them up and say, hey, we’re having this issue. Also, it had some really complex tools that were really important to Salesforce, such as the enhanced list view. Which for use cases is one of the kings. And they had an amazing one. And it had things where you can click on it and edit a cell for in line edit, it would get a little red triangle to show you this change. Wish you could save back. And so we thought this has to be the next big thing for us is getting these grids and components driving our UI. And obviously at this point, right, we’re doing page to page which is still how classic it is. And some of the features are going to be more long lived. And so you’ll go to like the Page Layout Editor or Chatter and you kind of do all your work and then you go to a new page, but we already have this ambition where we’re going to try to spend more time on a single page, which is eventually what we came to look like. But the team that was there their mission, right, they have a single page, bunch of components, just swapping out interactivity.


Josh: Kris is describing a fundamental shift in web application design that was gaining strength at the time, page to page applications versus single page applications. Now, single page applications are fairly common these days. But to make them work, you need a framework that understands how to render based on components, which wasn’t nearly as common back then.


Kris: Yeah, some of the like, I think back then it was largely like Dojo had a UI component framework. jQuery wasn’t really even taken off. And there wasn’t a whole lot of component options. There was things that you would buy and and set up in your framework and you have to have a license key for something so powerful.


Josh: So Salesforce is centering around ExtJS is because of good support in a very rich, highly interactive interface. But a key component, you know, no pun intended, of web application design is a quick loading interface. Ext is is offering a lot of power, but at a price.


Kris: So yeah core is all it’s like 50K or something and it loads quickly and it gives you the basic stuff. It’s essentially another version of jQuery. Right? And you see all it has all the components in it. So if you need to have a list with a dropdown, you need to pull in ext all and that was at all like megs of JavaScript or something like that. And as you can tell the performance of loading every page was quite extensive. We were hoping four pages in 500 millisecond 300 millisecond range, and any page with the see all on it was basically awesome. Especially back at IE7 days where we’re still kind of even supporting it six at this point. And at some point, we’re like, okay, we have the ext. And now they come with a new version with some great features. So we need to upgrade to the next version. And in doing that we had to go through, find the incompatibilities between the previous version and the new version, change those, if possible, usually with the change them, and then we had to just check it in. And then everyone who use the had to retest all of their features.


Josh: Long story short difficulty with versioning of library beats out support, and the desire for a less bulky framework wins out over a highly complex interface, and turns into Lumen, an internal project at Salesforce to have its own framework for building out user interfaces.


Kris: So my first role was actually a team for help activities calendar and activities and events. So the good old tasks and stuff like that, and so on. When I started, they said, hey, you’re going to do this new thing. It’s a proposed a meeting button. And when you click it, you’re going to get this dialogue kind of same thing you get calendar. It’s a mix of Google and just kind of the general calendar activities now, right. But they said you’re going to do it in, in Meridian, which was the precursor movement. And so I had a very early on interaction with the the JavaScript frameworks and Salesforce, trying to build on these new what eventually became Lumen.


Josh: So if meridians not familiar to you – don’t be surprised it was never externally facing. Neither was Accent, which is a JavaScript library Chris wrote, which was also just an internal tool, but Meridian would have an evolution in both form and name that would eventually turn into the lightning component framework, but it took a while to get there.


Kris: Um, so there was a there was a point where we had the the code like, Meridian was the code word or the working name for a long time, but we knew that we weren’t going to go public with that, especially considering there was already another framework. It’s trademarked and they have that. And so we said, okay, we put a poll out on our internal chatter. We said, what should be the new name? And the poll chose Bloom? And Bloom, so it was okay. And then a guy went through and renamed the entire framework like 1000 files and had a good time. And then when Benioff it’s like, No, that’s not it.


And so, we had to go through the process again, get in higher levels of marketing.

Josh: Brief moment of silence for every developer out there who’s ever had to refactor thousands of files, thanks to somebody in marketing. Oh, and I want to point out that clearly between lumen and aura and lightning, somebody marketing really wanted this framework to be named after something light based. But speaking about making things light, there’s a bit of a side story here, we keep talking about making JavaScript more efficient, making the pages more efficient. But of course, JavaScript is only one of the aspects that is used in rendering your your web interface. Another really important one is CSS.


Kris: We hire this other evangelist, Nicole Sullivan, who at this point is writing CSS. And she’s kind of selling these concepts that we need to be writing CSS this way to tag these class names that are utilities. We should have classes that mean something it was a lot more dependent on the mixture of markup, and CSS, but before which is you just describe what you’re doing with CSS and then CSS file, change it. And that’s particularly important for us because we found once we’ve optimized a lot of features, classic or Lightning, Salesforce, most of the performance penalty on these pages ends up being CSS. As people once quoted to me – CSS never gets smaller, it only grows.


Josh: But hey, this is an episode about JavaScript. So let’s bring it back to some JavaScript.


Kris: We knew that with this problem by we couldn’t grow and scale by adding more and more CSS to the page, regardless of how many JavaScript optimizations we do. So she comes in, and she’s got this framework of CSS, which is pretty much solving this problem. And she writes something called zZen, which realistically is a precursor to SLDS. It’s kind of a slimmed down version of that. And the CSS framework in allows us to start ripping out stuff with the pages and using this base framework CSS, but then we’re in the meeting and she looks to me and goes, Chris, when are the components ready? And I am wondering what she’s talking about because no one at this point has talked to me like I am the component framework component guy. I, I’m pretty like starstruck by Nicole at this point. And so I I’m like, Yeah, okay, I’ll start that immediately. And so I go off, and I write a little framework, a little component framework called Accent. And I start writing some components to match the framework that she’s written. And so at that point, we have a few things like a drop down, maybe some buttons, a bubble hover kind of thing for this framework, and using those like this little Accent framework and a little component framework about CSS or we’re able to like start migrating Salesforce towards standards and light CSS frameworks and really, really performant.


Josh: So this is a phase of trying to get Salesforce on to the standards, it’s really important for what’s happening with JavaScript frameworks at the time, you can kind of see a consistent theme here of less being more. But that less is dependent on the browsers being able to do things for themselves, things like event handling, and understand how the components are actually being rendered. And so as the standards are changing, Salesforce is also still trying to get its own component framework up and running. And so here we have Aura, as kind of this next generation Visualforce replacement, while at the same time we’re trying to keep up with those standards.


Kris: It really, it’s a kind of vision focus was really around maturing Visualforce. Customers at that point have Visualforce as a one single page app with the amazing JavaScript. And that isn’t the concepts that are going to get us to the place where mentioned, which is to be disconnected from frameworks and to even external frameworks. We’re still not, we’re not disconnected from them yet. So as we’re going through, we’re doing this framework, we’re moving all of Salesforce on to lightning and lightning components. And what we’re teaching everyone is actually, here’s how you write at aura, which is, it’s all new to everyone, right? And as the web changes, and as the browsers mature, we have to constantly adapt or working to kind of leverage those features and take advantage of those, which is not really where accent was going and where we ended up going.


Josh: Which brings us to the current iteration of JavaScript with Salesforce in the form of Lightning Web Components. And remember that the goal here is to have the thinnest possible layer of JavaScript talking to the browser than anything specialized that we need to work with Salesforce itself. And this goal is ongoing. And remember, it’s kind of in this conflict zone of trying to work with browser compatibility slash incompatibilities and still changing standards.


Kris: Well, we’re starting to get the benefits from them, and just the framework that we’re developing. And then if we need something particularly important to Salesforce, it’s just security, right? We can’t have you running your component for credit card authorization and having this component there on the page and the same app because then you can just reach over and grab that information. Well, we need that that’s with it without that Salesforce can do its platform, customize it, installed packages and so we we have to support some Lightning Locker to do that. But locker  obviously needs to be watching everything that you do. It’s going to inspect all the API’s and make sure that you don’t have access to the properties that have exposed and the DOM elements. And that was obviously very expensive. But if we can encourage the web standards to this is important for the web, that they should move in this direction, that at some point, it’ll just become a browser feature. And we can just put an attribute on the page, remove lightning locker, and we’re done.


Josh: And that’s our show. In under 15 minutes, Chris, and I have given you a brief history of JavaScript frameworks with Salesforce. Now, I also want to just tack on a quick epilogue here because it occurred to me while talking to Chris, that every chapter in the story is built on good intentions. They were all trying to solve a problem they were having at the time. I also should note I keep saying ext and Kris says EXT – in the Sencha community, there’s a little bit of a disagreement as to which is the appropriate pronunciation of EXT – as a Kris is definitely more of a JavaScript expert than I am, so I will concede his pronunciation. Unfortunately, it’s just sort of an old habit of mine. But getting back to ext – is it was designed to try to solve the problem, the wild west of frameworks, everybody using dojo or jQuery or trying to pick all of these things, to pick a good horse that was going to be robust and interactive for Salesforce users. But then aura is a response to that because it is bulky in terms of download size, and it is also difficult to maintain so or it would give us a framework that we owned that we can maintain the versioning of, and also try to keep as slim as possible. But then in response to aura, we have lightning web components so that Salesforce can start leaning and using the power and the efficiency. Pure web standards. And so all of these solutions are trying to solve the problems that came before them. It’s important to point out this is complex because many of these problems are occurring in parallel, they’re occurring the same time. And so there’s definitely some overlap that’s going on here. And because of that, there are a lot of different events and a lot of different people who have been involved in this journey along the way, and we will definitely try to get those people interviewed for you on the podcast. Now before we go, I do want to point out that a couple weeks ago, you listen to Adam wrote him back and you might have heard Adams very epic journey that took him you know, from from one place to another in order to get his his job at Salesforce. I won’t spoil that for you. But here if you haven’t if you haven’t listened to the episode, but here we have Kris, and Kris is a native of Alaska, and he was working for his father who an ISP and so Chris kind of turned into his de facto web developer. And in order to get into the next chapter of his story, Chris decided that he was going to move to Seattle, which he decided he was going to do by car. And it did not really go smoothly.


Kris: That was, it was, it was one of the best trips I’ve ever had. It was just me cruising through Canada. Playing the four CDs that I had, were on loop with almost no money, right? You don’t want to burn all your money on your road trip. And then about halfway through my engine started making this clicking sound. And I’m like, I don’t know what this is. And my parents freaked me out, like, careful, don’t get stuck, you’re gonna die out there. And so I’m like, all I’m doing is like, okay, I’ll just give them more oil. So I just started there. And eventually it kind of works. The sound stops making such a loud sound. It ended up dying about three days after I got to Seattle. timing chain broke. And I found that’s not nearly as bad. That’s much worse than the timing belt. It’s like, a couple of thousand dollars or something. So I got lucky because otherwise I was stuck.


Josh: Well, thank you, Kris for making it safely across the border all those years ago. And thank you very much for the conversation and the information about JavaScript frameworks. Thanks for listening, everybody. If you want to know more about this podcast, go to, and please subscribe on your service of choice. We’ll talk to you next week.

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