# GoogleChromeLabs/ui-element-samples: 25 vanilla-JS UI prototypes you open in a browser > A folder-per-component collection of UI element samples built on plain web platform features, aimed at engineers who want to read the technique rather than install a library. The README is explicit that these are prototypes, not production code. **GoogleChromeLabs/ui-element-samples** — A collection of prototyped UI elements - Repository: https://github.com/GoogleChromeLabs/ui-element-samples - Website: https://googlechromelabs.github.io/ui-element-samples - Stars: 4,119 · Forks: 723 - Language: JavaScript - License: Apache-2.0 - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/googlechromelabs-ui-element-samples ## What ui-element-samples actually is, and who should read it This repository is a set of UI element samples written with vanilla web platform features. That single sentence from the README sets the scope: each sample demonstrates an approach to building a performant UI element, and the README states plainly that these are prototypes and not production-ready. The audience is therefore narrow and specific. It is for front-end engineers who want to see how a swipeable card deck, a parallax layer or a custom scrollbar can be assembled from platform primitives without pulling in a framework. It is not for teams looking for a component library to install, version and depend on. The repository layout supports the reading-first intent: the top level is a flat list of directories, one per element, alongside a shared index.html, a CONTRIBUTING.md, an .eslintrc and an .editorconfig. There is no package.json in the top-level entries listed, which is consistent with a collection of standalone pages rather than a published package. If your goal is to evaluate an API surface or read release notes, there are none here. If your goal is to understand a technique, the organisation is exactly right. ## One directory per element, and the data flow inside each The architecture is deliberately flat. Each element lives in its own subfolder, and the README's getting-started steps are to clone the repository, open an element's subfolder, and run index.html. That means the unit of delivery is a static page, not a module. The samples are written in ES2015, and the README points at a browser compatibility table for direct ES2015 support rather than shipping a build step. The mechanism inside a sample is therefore whatever the browser gives you: the element's own DOM, its stylesheet, and a JavaScript file such as cards.js in swipeable-cards or side-nav.js in side-nav. The README's transpilation example names exactly those two files, which tells you the file naming convention is consistent across the collection. Data flow is likewise plain: the page loads, the script queries and manipulates DOM nodes, and the browser handles rendering. There is no shared runtime, no central registry and no cross-element imports visible in the layout. That is a strength for reading and a constraint for reuse, because nothing here is packaged for consumption by another project. ## Cloning ui-element-samples and opening your first sample The README gives three steps and no package manager. Clone the repository, change into an element's subfolder, and open its index.html. There is no install command, no dev server and no build step required to see a sample running. ```bash git clone https://github.com/GoogleChromeLabs/ui-element-samples.git cd ui-element-samples ``` After cloning you have the full set of folders. Pick one by name, for example side-nav or swipeable-cards, and open the index.html inside it in a browser. The README describes this as running index.html, and because the samples use vanilla web platform features the page should render without a bundler. ```bash cd swipeable-cards ``` From there, open index.html in your browser and read cards.js alongside it. What you should see is the element behaving as a self-contained demo, with the JavaScript file in the same folder as the markup it drives. If you need to support browsers without direct ES2015 support, the README offers a Babel command instead of a project-level build configuration. ```bash babel --presets=es2015 swipeable-cards/cards.js --out-file swipeable-cards/cards-es5.js babel --presets=es2015 side-nav/side-nav.js --out-file side-nav/side-nav-es5.js ``` The README notes that keeping transpilation in scope would add complexity, and states that it is out of scope for this set of samples. Treat those two commands as a sketch of an approach, not as a supported build pipeline. ## Where the prototype label bites: support, packaging and reuse The clearest limitation is stated by the project itself. The README says these are prototypes and not production-ready, and the stated aim is to demonstrate a solid approach rather than to supply shippable code. That has practical consequences. First, ES2015 is a requirement for direct browser support, and the README defers to an external compatibility table rather than declaring a support matrix. Second, transpilation is explicitly out of scope, so there is no maintained ES5 output to consume. Third, the samples are standalone pages, so there is no import path, no versioned artifact and no changelog to pin against. If your project needs a component with a stable API, a documented browser baseline and a release process, this repository is the wrong tool. It is also the wrong tool if you want to drop a sample into an existing application unchanged: the files assume they own the page they are loaded into. The right use is to read the technique, understand the trade-off the author made, and write your own implementation against your own support requirements. ## How this differs from adopting a component library The obvious alternative is a component library or framework that ships the same widgets as installable packages, with versioning, tests and documented browser support. The difference is not quality, it is the delivery model. A library gives you a dependency you upgrade and a contract you can rely on; ui-element-samples gives you a directory of pages you read and copy from. With a library, the swipeable-card behaviour arrives as an import and you inherit its maintenance. With this repository, the behaviour arrives as a file such as cards.js that you read, and you inherit the maintenance yourself. That trade can be the right one when the widget is small, when you want to avoid a dependency, or when the point is to learn how the platform feature works. It is the wrong trade when the widget is load-bearing and you have no capacity to own it. A second alternative is a web-components catalogue with a defined custom-element interface; that gives you a reusable boundary, whereas the samples here are page-level demonstrations without a published element contract. ## Maintenance, licensing and the cost of copying a sample The repository is not archived, and the last push was on 2026-09-15. That is recent, but recency of the last push is not the same as a maintenance commitment, and there are no releases listed for this project. The README also carries a note that this is not a Google product, which matters when you are deciding how much weight to give the GoogleChromeLabs name. Licensing is Apache-2.0, and the README reproduces the Apache License, Version 2.0 text with the copyright line Copyright 2015 Google, Inc. and a pointer to the NOTICE file for additional attribution information. In practice that means the code is permissively licensed and the main obligation to be aware of is preserving notices and attribution when you reuse files. This is not legal advice, and if you are copying sample code into a distributed product you should read the LICENSE and NOTICE files in the repository yourself. The upgrade cost is unusual: because there is no package, there is nothing to upgrade. Your cost is the time to re-read a sample when browser behaviour changes, plus the work of writing and testing your own implementation. ## Conclusion Adopt ui-element-samples as a reading and reference source: clone it, open the specific element folder you care about, and treat each index.html as a worked example of one web platform technique. Do not adopt it as a dependency or ship the sample files into a product, because the README states these are prototypes and not production-ready. Before you copy anything, verify browser support for the ES2015 features in the file you are reading and decide whether you will run the Babel command shown in the README or write your own ES5 path. The most useful first check is the subfolder for the element closest to your problem, since the repository is organised as one directory per sample rather than as a single bundle. ## FAQ ### What are some good UI design samples I can look at in ui-element-samples? The repository is organised as one subfolder per element, including swipeable-cards, side-nav, parallax, custom-scrollbar, image-zoomer, infinite-scroller, lazy-image, flip-switch, accordion, animated-blur, animated-clip, code-splitting, expand-collapse, firebase-firestore-comments, router, router-advanced, server-side-rendering, service-worker, stream-progress, streaming-service-worker, template, web-workers, webgl-image-processing, 3d-card-flip and a shared index.html. Each folder contains an index.html you can open directly. ### What are some examples of UI elements in ui-element-samples? The samples cover interactive widgets and platform techniques, from swipeable cards and a side navigation to a custom scrollbar, an image zoomer, an infinite scroller, lazy image loading, a flip switch, an accordion and WebGL image processing. The README describes them as UI element samples written with vanilla web platform features. ### Do I need to install anything to run a ui-element-samples element? No. The README's getting-started steps are to clone the repository, open an element's subfolder, and run index.html. There is no package manager step documented. ### Can I use ui-element-samples code in production? The README states that these are prototypes and not production-ready, and that the aim is to demonstrate an approach for building performant UI elements. The code is Apache-2.0 licensed, but the project does not present itself as a production dependency. ### Does ui-element-samples work in browsers without ES2015 support? The README says the samples are written in ES2015 and require direct browser support, linking to a compatibility table. It shows Babel commands for transpiling cards.js and side-nav.js but states that transpilation is out of scope for the sample set. ## Sources - [GoogleChromeLabs/ui-element-samples on GitHub](https://github.com/GoogleChromeLabs/ui-element-samples) - [Issues](https://github.com/GoogleChromeLabs/ui-element-samples/issues) - [License: Apache-2.0](https://github.com/GoogleChromeLabs/ui-element-samples/blob/gh-pages/LICENSE) - [Project website](https://googlechromelabs.github.io/ui-element-samples) - [README](https://github.com/GoogleChromeLabs/ui-element-samples/blob/gh-pages/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/googlechromelabs-ui-element-samples