Convert Figma logo to code with AI

webcomponents logocustom-elements-everywhere

Custom Element + Framework Interoperability Tests.

1,173
102
1,173
46

Top Related Projects

LEGACY REPO. This repository is for maintenance of the legacy LitElement library. The LitElement base class is now part of the Lit library, which is developed in the lit monorepo.

12,489

A toolchain for building scalable, enterprise-ready component systems on top of TypeScript and Web Component standards. Stencil components can be distributed natively to React, Angular, Vue, and traditional web developers from a single, framework-agnostic codebase.

78,194

Cybernetically enhanced web apps

207,677

This is the repo for Vue 2. For Vue 3, go to https://github.com/vuejs/core

227,213

The library for web and native user interfaces.

95,657

Deliver web apps with confidence 🚀

Quick Overview

Custom Elements Everywhere is a project that tests how well different JavaScript frameworks work with Custom Elements, a key part of the Web Components standard. It provides a suite of tests and benchmarks to evaluate framework compatibility and performance with custom elements, helping developers make informed decisions about using Web Components in their projects.

Pros

  • Offers comprehensive testing across multiple popular JavaScript frameworks
  • Provides clear, up-to-date compatibility information for each framework
  • Helps identify areas where frameworks need improvement in custom element support
  • Encourages better integration between frameworks and Web Components

Cons

  • May not cover all edge cases or specific use scenarios
  • Test results can become outdated as frameworks evolve
  • Focuses primarily on custom elements, not all aspects of Web Components
  • May not reflect real-world performance in complex applications

Code Examples

This project is not a code library, but rather a testing suite and documentation resource. Therefore, code examples are not applicable in this context.

Getting Started

As this is not a code library, there are no specific getting started instructions. However, developers can visit the project's website at https://custom-elements-everywhere.com/ to view the latest test results and compatibility information for various frameworks.

Competitor Comparisons

LEGACY REPO. This repository is for maintenance of the legacy LitElement library. The LitElement base class is now part of the Lit library, which is developed in the lit monorepo.

Pros of lit-element

  • Lightweight and efficient library for building web components
  • Provides a simple and intuitive API for creating custom elements
  • Offers reactive properties and efficient rendering system

Cons of lit-element

  • More opinionated approach compared to custom-elements-everywhere
  • Steeper learning curve for developers new to web components
  • Limited to LitElement-based components, less flexibility

Code Comparison

lit-element:

import { LitElement, html } from 'lit-element';

class MyElement extends LitElement {
  render() {
    return html`<p>Hello, World!</p>`;
  }
}
customElements.define('my-element', MyElement);

custom-elements-everywhere:

class MyElement extends HTMLElement {
  connectedCallback() {
    this.innerHTML = '<p>Hello, World!</p>';
  }
}
customElements.define('my-element', MyElement);

Summary

lit-element is a powerful library for building web components with a focus on performance and developer experience. It provides a more structured approach to creating custom elements compared to the vanilla JavaScript approach demonstrated in custom-elements-everywhere. While lit-element offers convenience and efficiency, it may be less flexible for developers who prefer a framework-agnostic approach or need to integrate with various libraries and frameworks. custom-elements-everywhere, on the other hand, showcases how different frameworks can work with custom elements, providing a broader perspective on web component compatibility across the ecosystem.

12,489

A toolchain for building scalable, enterprise-ready component systems on top of TypeScript and Web Component standards. Stencil components can be distributed natively to React, Angular, Vue, and traditional web developers from a single, framework-agnostic codebase.

Pros of Stencil

  • Provides a complete toolchain for building web components
  • Offers automatic optimizations and code splitting
  • Includes a virtual DOM for improved performance

Cons of Stencil

  • Steeper learning curve due to its comprehensive nature
  • May be overkill for simple web component projects
  • Requires compilation step, unlike vanilla custom elements

Code Comparison

Stencil component:

@Component({
  tag: 'my-component',
  styleUrl: 'my-component.css',
  shadow: true
})
export class MyComponent {
  @Prop() name: string;
  render() {
    return <div>Hello, {this.name}</div>;
  }
}

Custom Elements Everywhere example:

class MyComponent extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({mode: 'open'});
  }
  connectedCallback() {
    this.shadowRoot.innerHTML = `<div>Hello, ${this.getAttribute('name')}</div>`;
  }
}
customElements.define('my-component', MyComponent);

Custom Elements Everywhere is a project that tests and documents how well different frameworks work with custom elements. It doesn't provide tools for creating web components itself. Stencil, on the other hand, is a complete toolchain for building web components with additional features like TypeScript support, JSX, and automatic optimizations. While Stencil offers more functionality, it also introduces complexity that may not be necessary for all projects.

78,194

Cybernetically enhanced web apps

Pros of Svelte

  • Smaller bundle size and better performance due to compile-time optimization
  • Simpler, more intuitive syntax with less boilerplate code
  • Built-in state management and reactivity without additional libraries

Cons of Svelte

  • Smaller ecosystem and community compared to Web Components
  • Less flexibility for integration with other frameworks or vanilla JavaScript
  • Requires a build step, which may not be suitable for all projects

Code Comparison

Svelte component:

<script>
  export let name = 'World';
</script>

<h1>Hello {name}!</h1>

Custom Element:

class HelloWorld extends HTMLElement {
  connectedCallback() {
    this.innerHTML = `<h1>Hello ${this.getAttribute('name') || 'World'}!</h1>`;
  }
}
customElements.define('hello-world', HelloWorld);

Summary

Svelte offers a more streamlined development experience with better performance, while Custom Elements Everywhere focuses on interoperability and standards-based web development. Svelte is ideal for building complete applications, whereas Custom Elements are better suited for creating reusable, framework-agnostic components.

207,677

This is the repo for Vue 2. For Vue 3, go to https://github.com/vuejs/core

Pros of Vue

  • Comprehensive framework with built-in state management and routing
  • Easier learning curve and more intuitive syntax
  • Larger ecosystem and community support

Cons of Vue

  • Heavier bundle size compared to native Web Components
  • Less flexibility in terms of framework-agnostic development
  • Potential for vendor lock-in

Code Comparison

Vue component:

<template>
  <div>{{ message }}</div>
</template>

<script>
export default {
  data() {
    return { message: 'Hello, Vue!' }
  }
}
</script>

Custom Element:

class HelloElement extends HTMLElement {
  connectedCallback() {
    this.innerHTML = 'Hello, Custom Elements!'
  }
}
customElements.define('hello-element', HelloElement)

Summary

Vue offers a more comprehensive solution for building web applications, with a gentler learning curve and robust ecosystem. However, custom-elements-everywhere focuses on native Web Components, providing better interoperability and lighter weight. Vue is ideal for larger applications with complex state management needs, while custom-elements-everywhere is better suited for creating reusable, framework-agnostic components.

227,213

The library for web and native user interfaces.

Pros of React

  • Larger ecosystem and community support
  • More comprehensive tooling and libraries
  • Better performance for complex, dynamic UIs

Cons of React

  • Steeper learning curve for beginners
  • Requires additional setup and build tools
  • Less native browser support compared to Web Components

Code Comparison

React component:

function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
}

Custom Elements Everywhere example:

class Greeting extends HTMLElement {
  connectedCallback() {
    this.innerHTML = `<h1>Hello, ${this.getAttribute('name')}!</h1>`;
  }
}
customElements.define('x-greeting', Greeting);

Summary

React offers a more robust ecosystem and better performance for complex applications, while Custom Elements Everywhere focuses on native browser support and simplicity. React requires additional tooling and has a steeper learning curve, whereas Custom Elements can be used with minimal setup. The choice between the two depends on project requirements, team expertise, and desired browser compatibility.

95,657

Deliver web apps with confidence 🚀

Pros of Angular

  • Comprehensive framework with built-in features for large-scale applications
  • Strong TypeScript support and tooling ecosystem
  • Robust dependency injection system for better modularity

Cons of Angular

  • Steeper learning curve compared to Custom Elements Everywhere
  • Heavier bundle size and potentially slower initial load times
  • Less flexibility in integrating with other libraries or frameworks

Code Comparison

Custom Elements Everywhere:

<custom-element attribute="value"></custom-element>

Angular:

@Component({
  selector: 'app-component',
  template: '<div>{{ data }}</div>'
})
export class AppComponent {
  data: string = 'Hello, Angular!';
}

Summary

Custom Elements Everywhere focuses on testing and showcasing Web Components compatibility across various frameworks, while Angular is a full-featured framework for building complex web applications. Custom Elements Everywhere promotes interoperability and framework-agnostic development, whereas Angular provides a more opinionated and structured approach to application development. The choice between them depends on project requirements, team expertise, and desired flexibility in integrating with other technologies.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Custom Elements Everywhere 🍻

What is this?

Karma tests for each of the major frameworks to see how they handle working with Custom Elements.

Build Status Renovate enabled

Installation

To install all dependencies and build the site:

# Install all the things!
npm ci

# Test all the things!
npm run build

# Preview the site.
npm start

Current List of Libraries/Frameworks

How do I add a library/framework to the project?

Step 1. Copy an existing example

Tests for each library/framework live in the libraries/ directory. The easiest way to start is by copying the test directory from a project that is similar to your own. For example, if the library you use is similar to React/Preact, you might start by copying and renaming the libraries/preact directory.

Your library structure should look like this:

├── .babelrc
├── karma.conf.js
├── meta
│   ├── issues.json
│   └── summary.md
├── package-lock.json
├── package.json
├── src
│   ├── advanced-tests.js
|   ├── basic-tests.js
│   └── components.js
└── tests.webpack.js

package.json

Your package.json should contain build and test npm scripts. The test script is in charge of actually running karma. The test script should set a variable, LIBRARY_NAME, that corresponds to your library's npm package name. This is used during the build process to grab the library's semver and publish it on the site.

Example:

"scripts": {
  "test": "cross-env LIBRARY_NAME=@angular/core karma start",
  "build": "npm run test"
},

karma.conf.js

Your Karma configuration. Ideally you shouldn't need to change much in here. The config file uses karma-webpack, so there is a webpack property where you can essentially write your webpack.config.js. You'll need to change this property to tell it how to bundle your library.

meta/

This directory contains issues.json where you list any open GitHub issues related to custom element support in your library. There is also a summary.md where you write a short description of how the library interacts with custom elements and any known quirks or gotchas.

src/

This directory contains components.js where you create library/framework components which try to communicate with custom elements. You then test these components in basic-tests.js and advanced-tests.js. You'll want to use all of the assertions in the test files but update the actual test implementations to use your library's components.

Note that all frameworks use the custom elements in the /libraries/__shared__/webcomponents/ directory for tests.

tests.webpack.js

This file is consumed by the test runner and tells it to import any files ending in -test. You probably won't need to change this file.

Step 2. Add npm scripts

In the root of the project you'll need to add a couple of npm scripts to make sure your library builds with the rest of the site. You should be able to copy an example from one of the other libraries.

  • In the root of the project, Add an install-* script to package.json and run it during the install script.
  • In the libraries/[your library]/ director, update the build script in package.json to include your library's name.

There's a test runner called index.js that lives in the root of the project. It will detect when you've added a new folder to libraries/ and attempt to run that folder's build command.

Step 3. Run update-goldens

In the root of the project, run npm run update-goldens. This will generate an expectedResults.json file for your library's tests.

This way any change that results in a different summary score for any library shows up in code review, and any change that would accidentally change the summary score will make the tests fail.

What kind of behavior do the tests assume?

  • The library/framework should be able to display elements that use shadow DOM, insert children in them, and handle hiding and showing them.
  • The library/framework should be able to pass primitive data (strings, numbers, booleans) to a custom element as either attributes or properties.
  • The library/framework should be able to pass rich data (objects, arrays) to a custom element using properties.
  • The library/framework should be able to listen to DOM events from a custom element. These DOM events could use any casing style.

How does the site get deployed/maintained?

Any PR landed to the main branch will trigger an automatic publish to GitHub pages.

License

Copyright 2017 Google, Inc.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.