Looking for more podcasts? Tune in to the Salesforce Developer podcast to hear short and insightful stories for developers, from developers.
25. Building Enterprise-Level Applications with Web Components
Hosted by Jamie White, with guest René Winkelmeyer.
In the past, the ambitions of web developers in building feature-rich applications has run up against the limitations of an Internet that wasn't designed with heavy UI elements in mind. That's all changing with web components, a standardized way to encapsulate and distribute functionality across every browser, regardless of an application framework. René Winkelmeyer from Salesforce is our guest on this episode to talk about the history of web components, as well as the open source tooling which Salesforce is building with enterprise-level applications in mind.
Heroku Front-end Engineer Jamie White sits down with René Winkelmeyer, a developer evangelist at Salesforce, to talk about the company's commitment to advancing web components. Web components are a collection of standardized web and browser APIs designed to overcome some of the limitations with the design of the Internet, particularly when it comes to page rendering. Web components exist outside of web frameworks such as React, Ember, or Vue in that they are built using standard web technologies and can be used in any application, regardless of the framework or language it's architected in. They're built for reusability and consistency across your application's UI.
Lightning Web Components is a toolkit built and open sourced by Salesforce to ease the development of web components. These components are Enterprise-level, in that they provide functionality for many complicated UI scenarios. Although there are other web component frameworks, such as LitElement, a core goal of LWC is to make the process of building web components more declarative.
The conversation turns towards attracted Salesforce to investing time in web components, with the conclusion being that open standards would continue to succeed in the future when compared against closed and proprietary tools. Their focus is also on ensuring that accessibility needs are met for every user of a website.
Links from this episode
Jamie: Hello and welcome to Code[ish]. I'm front-end engineer Jamie White, and today we're talking with René Winkelmeyer from Salesforce about Lightning Web Components. Thanks for joining us, René.
René: Hi, I'm really glad to join you here at your Code[ish] podcast. I'm really happy to talk about Lightning Web Components with you.
Jamie: Wonderful. Well maybe you could give us a little bit of your background. What exactly do you do at Salesforce?
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é: 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?
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.
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?
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é: 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é: 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é: 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.
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.
A podcast brought to you by the developer advocate team at Heroku, exploring code, technology, tools, tips, and the life of the developer.
Front-end Engineer, Heroku
Jamie is a software engineer on the team that takes care of Heroku’s Dashboard, CLI, Data Dashboard, and other UIs.
Principal Developer Evangelist, Salesforce
More episodes from Code[ish]
Robert Blumen and Marcus Blankenship
How can developers learn from catastrophic errors such as airline disasters? Learn how understanding the root causes of failure in complex systems can prevent their recurrence. →
Karan Gupta and Marcus Blankenship
How can applying the right technology choices at the right time impact your coding and business choices? Karan Gupta explains how practicing “pragmatic engineering” can have an oversized impact on business and business efficiency. →
The episode focuses on managing a certificate authority (CA) within an enterprise. The internal CA is compared on many points to PKI on the public internet. →