DEV Community

Modern Web Components

Sam Thorogood on June 16, 2019

I'm the lead on Santa Tracker. Yes, I know it's June right now—pretty much as far from the holidays as you can get. 💼 I want to talk about Web Com...

Read full post

Ryan Smith • Jun 16 '19

I love the idea of using built-in components that can be used anywhere but when trying to dive deeper into web components I found there to be a bit of friction in using it to create an app.

There seemed to be a number of different ways to approach using web components:

Vanilla web components
- The issue here seems like there are missing features or difficult to use features in vanilla, which I believe is the reason Lit exists. Vanilla isn't as "batteries included" as I would have liked.
Use a wrapper (LitElement)
- I like LitElement/LitHTML's simplicity and syntax. I think the thing missing here is how to assemble this into an app with modern features such as routing, offline support, bundling, etc. There wasn't a clear direction on the next steps to take. A "Create Lit App" or "Lit CLI" to get up and running quickly with a more minimal working app that has a lot of the setup abstracted away would be ideal.
- I know there are repos like PWA Starter Kit and OpenWC, but I felt that these had too much included. If I were to build a simple site, I would be removing or not using a good portion of either of these.
- Tooling wasn't quite there. I know it is just JavaScript, but in using these you have to hunt for tools that will have proper syntax highlighting, formatting, and linting. Those tools seemed to not exist, had conflicts with other tools, or were difficult to get working properly.
Use a compiler (SkateJS, Stencil)
- While these look like awesome tools, they felt wrong to me. One of my reasons looking into web components was to be framework-agnostic and to future-proof my skills, so while these tools are "not frameworks", they lock you into a specific library. It isn't #UseThePlatform, it is #CompileForThePlatform.

I want to like web components, but there are some things holding me back. I stopped pursuing them for now because it seemed like using a framework such as Vue was easier to be productive with and a better choice for me.

I'm open to any opposing viewpoints. Any suggestions for someone like me?

Sam Thorogood • Jun 17 '19

WCs are just another platform primitive. I don't think they're intended to be part of something called "Create Lit App". I appreciate that this might be what you want. For all of the criticism of say, the thousands of dependencies needed by Create React App, I appreciate that it's an easy way to start.

If anything, WCs lend themselves to the idea of modern ES6 bundling. I'm not necessarily endorsing the Pika package manager, but it has an interesting writeup on its vision. This is effectively the "no-build" system- you just import './element-name.js, and use <element-name> inside your code.

That <element-name> you've created can now be used inside any modern "create foo" or "starter kit". It's just important to remember that WCs aren't really targeting that high level on their own.

I hope that helps.

Ryan Smith • Jun 17 '19

Good point on the dependencies, I was definitely shocked when I npm installed lit-element and saw one folder in node_modules. There is definitely a lot of developer convenience in those types of up-and-running tools, but there is a cost passed on to the user. I have heard of Pika before and I like their vision. It brings me back to the old days before all of the "necessary" tooling.

I think it makes sense from a viewpoint of web components being reusable things and not part of a larger library or ecosystem. I think for me it is deciding really how I want to use them since they are basic building blocks. I could write LitElement components and create a basic router (or pull in an existing library) but there may not be a roadmap to follow and some hurdles to jump over. Or I could use a library I like such as Vue and pull in web components, I'm sure there is some documentation out there but there also may be some things to figure out. Those components are then freed from any one library and can be used in my next Vue app, React app, or [next big library] app, which seems like a good deal.

Sam Thorogood • Jun 18 '19

I think this is sort of the vision, although I don't want to speak for those frameworks (I suspect they're generally on the no-WC-bandwagon). But again, it doesn't matter, because now you've just created a better HTML element that slots in nicely—it's no difference from a complex built-in.

Matias Trujillo • Jun 17 '19

I invite you to try Atomico, it's simpler than the exposed libraries,eg:

Atomico 3kB is based on virtual-dom, HoCs and hooks.

It has a small router and deferred charges(dinamic import), eg:

I hope I have covered the essentials. start simple npm init @atomico

Josef Ježek • Jun 17 '19 • Edited

We love Web Components, not custom apis. ;-)

github.com/w3c/webcomponents

Matias Trujillo • Jun 22 '19

No thanks, WC api is unfriendly and complex, current class-based implementations generate too much repetitive code and tie tightly to this.

instead, with my proposal you can better separate the logic from the view and avoid things like this.

microsoft code.

class /**any libraries based on classes, eg LitElement */{
    anyUpdate(changedProps) {
        if (changedProps.get('_showMenu') === false) {
          // get popup bounds
          const popup = this.renderRoot.querySelector('.popup');
          if (popup && popup.animate) {
            this._popupRect = popup.getBoundingClientRect();

            // invert variables
            const deltaX = this._loginButtonRect.left - this._popupRect.left;
            const deltaY = this._loginButtonRect.top - this._popupRect.top;
            const deltaW = this._loginButtonRect.width / this._popupRect.width;
            const deltaH = this._loginButtonRect.height / this._popupRect.height;

            // play back
            popup.animate(
              [
                {
                  transformOrigin: 'top left',
                  transform: `
                  translate(${deltaX}px, ${deltaY}px)
                  scale(${deltaW}, ${deltaH})
                `,
                  backgroundColor: `#eaeaea`
                },
                {
                  transformOrigin: 'top left',
                  transform: 'none',
                  backgroundColor: `white`
                }
              ],
              {
                duration: 100,
                easing: 'ease-in-out',
                fill: 'both'
              }
            );
          }
        }
      }
}

The right is part of the code that shows how inelegant it can be to solve a state problem using classes.

Indifferent to eg, if I believe that sometimes you need solutions like Atomico if your WC is simple

Abraham Williams • Jun 17 '19

PWA Starter Kit does have multiple templates so you can choose versions with less stuff included by default.

Jordan Austin • Jun 16 '19 • Edited

Thanks for posting this. At my company we've recently migrated away from the all-in nature of Polymer and moved to LitElement where needed. It's amazing and even easier then Polymer because it's even closer to standard Web Components.

I think blog posts like this are really great because it shows people how easy Web Components can be and hopefully gets people thinking about using them more and maybe making their life easier with a small helper library like Skatejs, Lit, or hyperHTML 👏

Abraham Williams • Jun 17 '19

You mention that Polymer is "sticky" and likes to only work with other Polymer elements. Since Polymer 3 is built on LitElement, shouldn't it have the same base level of interoperability as LitElement? Or do you see Polymer 3 elements that somehow have functionality regressions over the base LitElement?

Sam Thorogood • Jun 17 '19

Polymer 3 is a mostly mechanical migration of 2 to use ES modules.
Polymer 2/3 both use the class-based method of inheriting from a base element, but they use Polymer-isms (such as the notify stuff)

There's no real relation to Lit, aside some of the same authors.

Matias Trujillo • Jun 17 '19

I'm a fan of the web components, I would like to know your appreciation of a simpler approach to creation, based on JSX, HoC, virtual-dom and Hooks, 3kB.

Atomico is a personal project made with love

Benny Powers 🇮🇱🇨🇦 • Jun 16 '19

Great examples!

(s/HtmlElement/HTMLElement/g)

Sam Thorogood • Jun 16 '19

whoops. Thanks 😄

Šime Vidas • Jun 16 '19

I’m not sure why anyone would want to write vanilla code. The available standard API just isn’t enough (and probably never will be).

Sam Thorogood • Jun 17 '19

Whether you choose to or not, the option is there because it's part of the platform. It doesn't hurt you, either in bytes or complexity, to do so.

Šime Vidas • Jun 17 '19

But the standard API is more complicated to use, is it not? Just rendering a static template requires you to call a bunch of APIs. I don’t even know if I’m supposed to try to memorize those patterns or just copy-paste the boilerplate code whenever I’m creating a new component.

It’s much more complicated than say writing a template literal inside a render function as with Lit. That’s why I said, I’m not sure why anyone would use (just) the standard API.