25. Building Enterprise-Level Applications with Web Components

René: So sure. My name René and I work as a developer evangelist with Salesforce. I do, I would say, a lot of things that span the Lightning platform, which is doing web development, back-end development, all Salesforce related. But at the same time, I have a kind of diverse background in IT. So yeah, anyone who is old enough, and who knows [inaudible 00:01:11], I think that's how I started, and touched a bunch of things from Java to JavaScript to Python to Perl to Go and you name it basically. But as of now I work with Salesforce and focus a lot on our new Lightning Web Component framework.

Jamie: Great. I believe you're based in Germany, is that right?

René: Exactly, remote in Germany. I call it the middle of nowhere, because if you look on the map it just green around, which is kind of cool to live.

Jamie: Oh, that sounds wonderful. How long have you been a remote worker?

René: 10 years, I would say now. Yeah, 10 years plus, business ready to travel, which is I wouldn't say a lot, but I see some places of the world. But the rest of the time I'm spending countryside, which is kind of cool.

Jamie: Yeah, remote work is a big theme for Code[ish] and Heroku in general. Do you have any tips for remote workers?

René: I would say it's the same as if you would work in an office. You need your space, quiet space to work in. You need to focus. But at the same time, you should finish your work at a specific time because that's if you have your MacBook, or Windows machine or whatever with you, you tend to work more. I can just recommend you just behave as you would be in a regular office. The other thing is like try to reach out to colleagues, because you don't want to sit in your office all day long alone.

Jamie: Absolutely, great advice. So the topic for today is Lightning Web Components, and you mentioned the Lightning platform. Perhaps you could just briefly summarize what the Lightning platform is before we dive into the main topic.

René: Sure. So the Lightning platform is what we as Salesforce will specify as our platform. That spans technology from our UI frameworks that you can develop on for our core technologies like Sales Cloud and Service Cloud, or the platform itself, as well as our back-end language which is Apex, as well as all the low code tools that we have, which is Process Builder, Flow. Technically we would need a podcast just to walk through all the things that include the Lightning platform. In short, it's something where you can build with little to no, to a lot, of code for Salesforce.

Jamie: Also, to set the scene for Lightning Web Components then, maybe we could start by talking about web components themselves. Could you define web components for the listeners?

René: So web components have been around for some time, and they are a set of specifications that provide a low level set of APIs that allow you to extend the browser's building set of HTML text, right? So they provide common methods for creating a component using standard DOM APIs, as well as a common way of receiving and sending data using properties and events. But outside of that, well the standards don't say a lot about how a component's actually implemented. When you look at the web itself or the DOM structure itself, you see things like an input on video tech, right? So this is a standalone functionality as part of the DOM, and this is kind of what you can in simple words imagine is a web component. Now they're built for interoperability, right? This is the main purpose. Because of the said interface, you can use them anywhere, just like build element as I mentioned before, like the input of video tech.

René: When you look at the specifications that make up web components, and they're made up of a few specifications, which are custom elements, Shadow DOM, HTML templates, they really provide a kind of different functionality, right? I think we could talk about that a bit more in depth after we should revisit how web components in general fit into the overall landscape of frameworks.

Jamie: Yeah, that sounds like a good segue. So how do they fit into this landscape, particularly thinking about other front-end technologies like React, Vue, Ember, and all of the tool change required for those tools? Where do web components sit within all of that?

René: I think we should go a bit back in time. Let us just go to 2014, right, to understand why web components are there, and how the web stack actually looked like in 2014 right? So back then, the web standards that were there only offered really a limited foundation for the full stack that developers need to build large scale web applications, rendering engines, standard elements events and also call language, ECMAScript 5. In addition to being rudimentary, that foundation had also other shortcomings, right, traceable to its roots as a page rendering platform, and not an application execution platform. There was no React, there was no Angular at the time being. With that, I mean, you look at the technology itself, the browser themselves, rendering wasn't optimized for continuous UI transformation.

René: The call language had no modern constructs to write larger model enterprise plus apps on the client side, like modules, classes, decorators and so forth. Then frameworks emerged over time like React, Ember, Vue, right? They were developed to optimize rendering. There are also different frameworks introduced, different component model, and HTML template approaches and techniques. Other libraries came up that provided different language extensions, just naming modules with AMD and CommonJS. So this is how the web looked like in 2014. When we look now at how many of those frameworks evolved over time, and this is really the thing like you talk to a developer and are they today a JavaScript developer, or are they more a React developer, or a Angular developer, or Vue or Next. You name the framework of their choice, right? So this is really the question, where does it all fit in?

René: As I mentioned before, web components are built for interoperability. They're built for being used in any framework. Even if you develop page with PHP, you can use web components in them because they just run everywhere as they are backed by the core technology, the browsers.

Jamie: So maybe give us some examples of the kind of things you would use a web component to build.

René: So there are a couple of examples where you can use them. Well the biggest benefit in my opinion is building reusable design into UI elements, right? When a company grows, or when your internal application landscape grows, you start building your design. You want to have a coding UI element, or you want to have a button element, or you want to have a data table element that looks and behaves the same, no matter in which web application you're using that.

René: Web components are actually the perfect fit for that because A, you can implement the design within the web component, and it won't change no matter in what order, or whatever correlating CSS, or other things are used in the HTML, or the application where it's used in, right? So it really allows you to build once and to run everywhere, which I think is pretty cool for all of us who have been there and built the component at some point, and it got dropped onto a page, and everyone was wondering why it just looks different than it should be. You find out there that there was a CSS collision, or a factual collision. I think this is really where web components help to grow your landscape. I saw recently a video and someone from Google said that they internally in Google run I think it was around 16,000 web components, right, so really reusable units, which I think is pretty impressive.

Jamie: That is impressive. So you're saying that the web component spec allows you to kind of isolate a web component from the surrounding CSS and other context on the page on which it's used?

René: Yes. So as I mentioned before, web components are made out of several specifications. One specification is custom elements. So you define basically your own HTML DOM tech. This represents your custom element, your component. So when you're looking into the DOM, you'll really see your component. Another part of the spec is a so called Shadow DOM, which encapsulates the web component, so that it means that CSS from an outer parent HTML tech can't bleed into your components. It's really truly encapsulated. The same as actually for any JavaScript functionality that you would bind into the web component.

Jamie: Well now we know the foundational technologies of web components. Maybe we should take a little aside to talk about the kind of current feelings about web components, perhaps controversy about web components on the web. So Rich Harris, the creator of SvelteJS amongst other tools recently posted a fairly controversial blog post entitled Why I Don't Use Web Components. I think other people have come to defend the use cases for web components. What's your take on all of that? Do you think these authors are making reasonable points?

René: Yeah, this is like throwback Thursday for me when I read the things. I think it was like 1995 when I was discussing with friends which is the best server operating system, OS/2, Windows NT 4, or are we going with Linux, right? Not every hammer is the right tool for a nail. So I think that they're perfect reasons to use React. They are perfect reasons to use Angular. There are perfect reasons to use web components, and it just really depends on the use case. When I see those comments like yeah you actually have a great point, but for my specific use case, it's not the right point.

Jamie: Yeah, and I think it probably is in the interest of all of us working on the web to embrace the full toolkit available to us, and especially embrace the platform. So I think it's a good stance to take definitely for all of us. So with all of that context set, tell us about Lightning Web Components.

René: Okay, so Lightning Web Components, and I got asked what is Lightning Web Components? How are they different from web components, and what are they actually made of? I always describe Lightning Web Components as a thin layer on top of the web component primitive APIs with some decorative sugar. When you would write a native web component, you would write a lot of JavaScript. I wouldn't call it boilerplate, but you still have to write some amount of JavaScript. With Lightning Web Components, we took a different approach, right? We wanted to build a foundation which is enterprise grade, which allows you to write standard HTML, standard CSS and modern JavaScript to build your web components to build your UI, and not a mix like you see it in other technologies like JSX with lots of things in one file. No, we want to have a separation of concerns that makes this also really easy from a developer point of view.

Jamie: Okay, so Lightning Web Components then is kind of a toolkit that sits on top of the web component spec to facilitate more declarative components. Would that be fair to say?

René: Yeah, so I frame it that way. We provide a small compiler and runtime engine that actually creates our own internal engine to drive web components. You don't have to bother with how you would build a web component from scratch using the standard browser APIs. It's really like here's a simple model based on ES6. You write your class, you have an HTML file as your template engine, separation of concerns, really clean. You can add optional CSS to write that, and you don't have to learn a framework which I think personally is really important because we see that with all the other frameworks and libraries, and how whether they need themselves as of today, that I just can't, if I don't know React, I just can't jump on a React project and be productive in three days lot right? There's a lot to learn. The same applies to other frameworks. We really tried to minimize, it was Lightning Web Components. We really say you need HTML knowledge, and you need JavaScript knowledge, and then you can build web components.

Jamie: So maybe talk us through, let's say I wanted to create some kind of a web component let's say for picking the ingredients for a meal I want to make. How would I go about generating and then authorizing that Lightning Web COmponent?

René: Okay. First of all, you would need some built tooling, right? That's I think the first really first step which you can get on lwc.dev, which is the open source side for Lightning Web Components. Then you will get a skeleton project where you would have to define which component you want to build, right? There is a scaffolding CLI provided, which is actually built by myself using the Heroku oclif framework, shameless plug here. You get a basic project structure where you would start with an HTML file which uses a template tag, which is also HTML standard specification. You would just add your plain HTML in there. Then you will have an ES6 class where you can define how your web component would behave. That can also be to be fair, an empty JavaScript class because when you don't have any functionality, any logic that you want to execute against your HTML markup, then that's also fine. But these are the only ingredients that you really need.

René: You would need a build set up. We highly recommend the LWC Create App tool, which is also linked on the official website for Lightning Web Components open source, and then you can directly get started.

Jamie: Great, and then so I assume these tools also allow me to compile my source into a web component that then I can use on any page that I like.

René: Yes. You can build that either with Rollup or with Webpack, for example, the scaffolding CLI uses Webpack. We actually built that. But that just depends on where you want to use it at the end of the day. But it creates the needed output for being reusable on any platform, GCP, Heroku, AWS, your own homegrown PHP server, wherever you want to add the Lightning Web Component.

Jamie: Gotcha. Then so and I assume then for CSS it's a similar story, you're authoring your CSS within the component. As we spoke about earlier, it's encapsulated so that when it's compiled out, it comes along for the ride with the web component?

René: Exactly. So when you look at the file structure for Lightning Web Components, you would have a folder, let's call it hello world, and within that folder you would have maximum three files, a hello world JS, a hello world html, and a hello world CSS file. So again with the true separation of concerns, where you can then add your CSS, your JavaScript into your HTML, and that then gets compiled in what the Lightning Web Components engine would generate on as the custom element on the webpage.

Jamie: How about writing tests around these components? What's the best practice? Would you write a test kind from the outside treating the component as a black box and testing its API or test the internal JavaScript class that you've written? Give us a bit of detail on that.

René: The preferred tooling for testing Lightning Web Components is just jest. It's hard to argue that it's not one of the popular testing framework, unit testing framework at the moment. We provide also tooling just to test your Lighting Web Components. If you look at actual unit tests, you would test the functionality of the output, or the expected output of your markup, right? This is what you have to test in the unit test. We can argue about that in another podcast what you should test, but this is what you should test in the unit test. So yes, you would actually just test the generated output. So if you have, for example, a button that sends an event, or changes a display in your component, this is what you would test with jest.

Jamie: If I wanted to compose a Lightning Web Components out of other lightning web components that either I or somebody else had authored, what does that story look like? Do I bring them in as web components, or if they come in as the Lightning Web Components sources, they're more integration that can be provided?

René: Yes, so there are a couple of things which has not yet fully provided. The engineering teams are currently working on having I wouldn't say an integration around it, because there is integration already, but a more documented integration where you just would do an NPM install into your existing project, and then could reuse the other web components at the end because they're our own, they're really encapsulated elements. The only touch point that you would have if you want to reuse other web components, you would just use their custom element markup in your HTML file.

Jamie: So summing up all that we've just spoken about, it sounds like Lightning Web Components really are a general purpose tool for anyone looking to get started using web components in their apps. I wonder now if we could switch gears to talk about Salesforce in particular and why Salesforce decided to create Lightning Web Components. Could you tell us a bit of the history there?

René: I mentioned before that like in 2014 there was not a lot available in the browser stack so, and that also applied to us, right? We developed our own framework, the AURA framework to allow developers to develop actually component based on our platform. Now since then, the technology stack has really changed, right, and we saw an uptick in especially the JavaScript world with lot of new specifications going from ECMAScript 6 to 9. We got classes, modules, promises, decorators and all the other things. We have to say that some of my colleagues actually work in the technical committees to drive the JavaScript specification, and they also joined recently, I think it was in January the W3C Consortium to also drive the general specifications of the web to make them more enterprise ready. Now, the history is also then that we want it to evolve, because a web stack looks really different today than it did five years ago with a weight really heavily tilting to what standards, and the core stack finally got its update and it's needed to become an application development platform in its own right, especially for enterprises.

René: Because many of those features that a couple of years ago required frameworks now come standard with the browsers, no one no longer needs their own proprietary component model, their own language extensions, proprietary modules and so forth. This is the vision that we also had. We wanted to have for us performant, reusable, self-contained component model based on the latest web standards with techniques and tools that are in a dead and simple and fast, more elegant way available. They should also drive adoption productivity by any big developers to take advantage of a greater selection of tools that they already know love. At the very last, we really wanted to deliver a technology that is really compatible with the standards of today and those well into the future.

René: What some people may not know as we at Salesforce, we have a commitment to our customers that we are backwards compatible, and at the same time we don't want that. We want to agree, and we wanted to live in standards. There is in 2019 especially in general no longer than need to be a really propriety right. The open source world, the web world has so much evolved that we are betting on the current standards which are built in the browsers, and one of their promise is we don't break the web, right? This is also another reason why we have chosen web components as a model because this is going forward just built into the browsers. We don't have to maintain that. Every enhancement that gets added will automatically be available for everyone who is using data technology, which is also pretty cool in my opinion.

Jamie: Let me see if I've got this right. Salesforce wanting to build best of breed tools, enterprise grade best of breed tools for developing apps on top of the Lightning platform, and the engineering teams decided to bet on open standards on web components. The results of that was the Lightning Web Component framework, which is now in fact open source, and turns out is a great tool for anyone to use whether you're developing on top of the Lightning platform or not. Have I got that about right?

René: That sounds about right. I mean the important takeaway is that because it's web standard, because it's baked into the browser, we don't maintain our own proprietary model, right? I think this is really my personal takeaway with all of this. Before that, I had to learn my own framework, framework A, B, C, D, right? You name it, no matter if it's for developing on Salesforce or on another platform. Now that it's a technology that's built into the browsers as web standards, as core APIs, everyone really gets the enhancements of the technology, which also is part of the interoperability story of web components because it's in the browsers. It's just there.

Jamie: Great, and so I suppose there's a kind of inbuilt benefits as well for Salesforce, open sourcing Lightning Web Components because we can see adoption elsewhere outside of Lightning platform itself, and see indeed contribution from elsewhere. Is there a community already starting to grow up around LWC?

René: Well we got open source like four weeks ago, so I leave that to others to judge. I think we have a great uptick, and we see a great traction. Just for example the scaffolding CLI that I mentioned before, we had over the last week a thousand NPM downloads, which is I think not bad after four weeks going open source. We should come back in maybe six months to see that.

Jamie: That's great. I notice as well that the VS code extension suite is very sophisticated for such a young project.

René: Yes. We have to differentiate though there that we currently provide the Salesforce extensions for Visual Studio Code, which is exclusively focused when you develop on Salesforce, but there are some efforts underway to also provide a similar tooling experience for Lightning Web Components opensource.

Jamie: Okay. So René, maybe you can describe for me some of the example web components authored with LWC that are out there right now.

René: Sure. Well you go on the Lighting Web Components open source site, lwc.dev, you have the installation section, which points out the two main things you want to get started. You actually don't have to install anything. First of all, it is the playground, which is like account sandbox, right? You can directly play with a Lightning Web Component, create your JavaScript file, HTML file, and see the actual rendering output there, so real time, no installation, just playing around experience. If you want to see how they're actually built, and how you can play with them, there's also the so called recipe section.

René: So when you go on to recipes.lwc.dev, this is a live application, just put Lightning Web Components, shameless plug also built by me, where we showcase how you can build with the different aspects that make Lightning Web Components, be it the event system, be it composition, be it data wiring, or using third party JavaScript libraries like D3, so real world examples, and also real working examples actually running on Heroku where you can directly look into the DOM see how does it behave, and also get linked to a dev repo where you can see all the source of those recipes.

Jamie: So is there much of a community say I'm getting started with LWC, and I want to reach out to some other people to ask questions. Where should I go? Who should I speak to besides yourself of course?

René: So there are a couple of ways. So the community goes to two areas. Either they go to our developer forums on developer.salesforce.com, and there's also a dedicated Salesforce Stack Exchange, which is on salesforce.stackexchange.com. This is mostly focused towards building online platform though, right? I would just say follow those two patterns, and at the same time you can reach out to me or just with the hashtag asksalesforce on Twitter, and see if someone goes on that, because the general Salesforce development community is pretty big. They help as much as they can on any social media. Worse case is if someone doesn't know, but they may know someone else who knows about that specific technology, they will just forward you. Lightning Web Components as we run them also on our platform has also such a broad ecosystem that there's not a lot of difference in between building on platform or off platform with that.

Jamie: Gotcha, and I suppose because they are bringing you to the web component spec, and not trying to hide anything from you about that, you can also go and seek out people who know about web components and get answers there too.

René: Exactly, and you can just go to github.com/salesforce/lwc. There's all the source code of this for us core technology internally as well as externally. You'll just dig around open issues. If you find something or have questions, I mean that's the pure reason why everything is open source.

Jamie: Are there any other players in this space of providing tooling around web components? How does the LWC team view its competitors?

René: You can use for example Polymer with lit-element right? So you can use other frameworks. I think that lit-element is maybe one of the most popular one. You can also build with React of you and have a generated output as web components, which I think is pretty interesting when you have a framework that is doing their thing at the same time as providing an output as web component because you may need that, or your customer demand is actually to use that. I wouldn't call it a competitor because all the frameworks and libraries have their purpose and their reason. What we are really targeting at is to provide an enterprise grade framework, and this is our home base as Salesforce, right? We are in companies from pretty small to pretty big. We really want to push the web forward, and now with Lighting Web Components to fulfill the needs that companies have with web applications, which is sometimes different from when you're running your blog or another not consumer facing application.

Jamie: Yeah, and I'll actually emphasize that point by saying that when we talk about enterprise grade in this context, we're talking about these UI components being used on apps with massive and very broad user bases, people with all sorts of different needs, all sorts of different legal requirements, and actually leads us into a topic that's very close to my heart, which is accessibility on the web. I don't know, maybe could we talk about that for a moment in the context of LWC? It might not be the LWC does anything explicitly to do with accessibility, but I know that the teams within Salesforce work really, really hard to make sure every UI component is as accessible as it can possibly be. I believe LWC plays a role in that too.

René: Yeah, we have internally our own design system like many companies have, which is called the Salesforce Lightning Design System, SLDS. The focus is really strong accessibility, right, because every user of a web application should have the same opportunities and the same chances to actually work with the application. At the same time, we have also to differentiate between the technology Lighting Web Components, and between the design system that we use, right? They are separate at this point of time, which makes sense because at the end, our web component implements just all the different attributes that are relevant for having a component accessible.

Jamie: I think it's fair to say that LWC is very much engineered with that in mind, and by basing itself upon web standards doubly so because web standards are all built with a strong thrust towards accessibility.

René: Exactly. I mean on the recommendation side you will see a section around accessibility, and what you have to do actually to make your components accessible, right, to have the right array attributes for example, and screen readers can identify the component. So web proponents and the accessibility are not exclusive, but they are also not strongly tied together, right? It's just a pattern that you have to follow so that your components are accessible.

Jamie: Well I think we've had a pretty good summary here of Lightning Web Components where they came from, the technologies that they build upon, and how you can get started using them in your own apps today. Renée, thank you so much for joining us. Where can people find out more about you, or follow you on the web?

René: Well, I would say the easiest thing is to Google René Winkelmeyer, because no one can actually pronounce my Twitter handle, maybe on purpose. I don't know. So yeah, if you can do that, if you understand German, find me at muenzpraeger on Twitter, which is also my GitHub name, and on every other system around. If you ever meet me in person, try to find out if you are, I'll tell you the back story about my nickname.

Jamie: We will of course include links to Lightning Web Components and René on the internet in the show notes. That's it for today. Thank you so much. Join us again on the next episode.

René: Thank you for having me.