Nikki Massaro Kauffman is a unique combination of front-end developer, multimedia specialist, and educator. She will bring her experiences from Penn State University and present at the 2019 Technical Academy. It’s a two-day deep-dive, immediately before the HighEdWeb Annual Conference, that helps web developers build better sites.
1. We can use browser-supported standards. No frameworks necessary.
Web components are built based on four modern browser specifications:
- Custom elements allow you to define your own HTML elements.
- Shadow dom allows you to treat your component’s DOM as separate from the document’s DOM so that your can style the component in a controlled way.
- ES modules (replaces HTML imports) allow you to build on other web components by including them into your project.
- HTML templates allow you to create markup that can be reused by your element as needed.
Because custom elements are natively supported by browsers, you can use them just as easily as you would use a <div>.
You can use them with Angular or React. You can use them with a framework or without one. The same component could be used across different frameworks. You can use them in Drupal or WordPress. You can use them on static websites. The same component could be used across different CMSs.
Our HAX project, a web component block editor, uses the same web component across all of its integrations. We only have to update our component itself to have Drupal 6-8 and WordPress use the same block editor.
And because you are defining custom elements as you go, the code you use has more meaning. No more <div> soup. Wish a HTML had <datepicker-calendar> element instead of <input type=“date”>? Build on the semantics of the input tag, and define it yourself.
3. We can share components to provide consistency and scalability.
Your pattern library could be made entirely of web components. With properties and CSS variables can specify exactly what variations in form and function are allowed. Because the shadow DOM is its own DOM, you don’t need to worry about CSS classes conflicting with other parts of the document regardless of where it is used.
Imagine having a header web component. Imagine that component anyone can use that web component without understanding build routines. Imagine having a CDN where you can share the web component with every department, regardless of whether they use WordPress or Drupal, and all they have to do is copy the code on your CDN. Now imagine that the next time you change your logo, re-design your header, or make an accessibility fix, that you just update one component in your institutional CDN and the change instantly applies to your Drupal, departmental WordPress site, and even static site that someone set up without your knowledge. BYU does this with their components demo site.
4. We can use simple web components to make bigger web components.
Web components are like building blocks. You can use them to build progressively more complex things. The ES modules spec allows you to import other custom elements to use in your custom element and to export your custom element for even bigger projects. We reuse components of any complexity: a simple toggle button, an accessible table editor, an interactive timeline, or a WYSIWYG block editor.
You can make a web component for an icon set. You can import that iconset to make a web component button. You can import those buttons to make a video player web component. You can even import the video player, the buttons, and the icons to an entire application, that is also a web component.
We might not have time to build complex things from scratch, but if we build on other components, development time speeds up dramatically. That application and video player I mention isn’t hypothetical. It is the project our small 4-person team built last year by leveraging the efficiency of web components.
Why go it alone and reinvent the wheel? Let’s join forces to make a better, more accessible web one web component at a time! Attend the HighEdWeb 2019 Technical Academy and I’ll get you started.