UIkit: a modular CSS and JS framework from YOOtheme, and how to install it

What UIkit is, and the problem it solves

UIkit is a front-end framework for building web interfaces. The README describes it as "a lightweight and modular front-end framework for developing fast and powerful web interfaces," and the package.json repeats that description verbatim. The repository is owned by the uikit organisation, developed by YOOtheme, and licensed under MIT.

The problem it addresses is the one that appears when a team wants interactive components (dropdowns, modals, sliders, accordions) without adopting a JavaScript framework and rewriting the application around it. UIkit ships CSS and JavaScript that attach behaviour to data attributes and class names in ordinary HTML. A page rendered by a CMS, a static site generator or a server-side template language can use it as-is. Nothing in the README asks the reader to write components in JavaScript.

The audience follows from that. It is for people who control markup but not necessarily a build pipeline: theme developers, teams maintaining server-rendered applications, and anyone who wants a documented set of components with a single stylesheet rather than a dependency tree. The primary language listed for the repository is HTML, which is consistent with that positioning.

How the distribution and build are structured

The repository layout separates source from output. src/ holds the Less and JavaScript sources, dist/ holds the compiled CSS and JavaScript, and build/ holds the Node scripts that produce them. The package.json points main at dist/js/uikit.js and style at dist/css/uikit.css, so a bundler resolving the package by name lands on the compiled files rather than the sources.

The npm scripts show the pipeline. compile runs compile-less and compile-js; compile-less runs the icons script and then build/less; compile-js runs build/build. There are separate scripts for RTL output (compile-rtl), icon generation (icons), selector prefixing (prefix) and scoping (scope). The devDependencies include less, esbuild, rollup, clean-css and rtlcss, which matches the script names: Less for stylesheets, Rollup and esbuild for JavaScript, clean-css for minification, rtlcss for right-to-left variants.

That is a heavier build than the phrase "lightweight framework" might suggest, but the weight sits on the maintainer side. Consumers who install the package get dist/ pre-built. Only someone cloning the repository to modify UIkit itself needs the toolchain, and the README points that person at the clone command rather than at the scripts.

Installing UIkit and rendering a first component

The README lists the installation routes plainly: download the latest release with pre-built CSS and JS, install with npm, yarn or pnpm, load it directly from jsDelivr, or clone the repository for the full source including build scripts. Package managers are the shortest path.

npm install uikit

The same command is given for yarn (`yarn add uikit`) and pnpm (`pnpm add uikit`). After installation, the compiled files sit under the package's dist/ directory.

If you would rather not add a package manager to the project, the README also offers a direct script and stylesheet load from jsDelivr, whose package page is linked as https://www.jsdelivr.com/package/npm/uikit. A static HTML page can pull both files from the CDN and use UIkit classes immediately.

git clone [email protected]:uikit/uikit.git

That clone is what the README recommends for getting "all source files including build scripts." It is the right choice only if you intend to modify UIkit or rebuild the CSS yourself.

Once the files are loaded, components are declared in markup. The README does not include a component example, so the concrete class names and data attributes have to come from the documentation at getuikit.com. What the README does establish is the shape of the workflow: you write HTML, you include the compiled CSS and JS, and the framework supplies the styling and behaviour.

The dev tag, and what pinning a version actually buys you

The README documents a second installation channel for people who want unreleased code. Using npm, `npm install uikit@dev`; using yarn, `yarn add uikit@dev`; using pnpm, `pnpm add uikit@dev`. The same tag is reachable over the CDN at https://cdn.jsdelivr.net/npm/uikit@dev.

This is a deliberate trade. The dev tag tracks the develop branch, which is also the repository's default branch, so it can contain changes that have not been through a release. The README frames it as a way to "always have the latest development version of UIkit, even before a release." For a production site that is a liability, not a feature: you are consuming whatever the branch happened to contain at install time, and a lockfile is the only thing standing between you and the next push.

The project follows Semantic Versioning, as the README states under its Versioning heading. That gives a predictable meaning to version numbers, but it says nothing about how often breaking changes arrive. The release history visible in the repository shows a steady cadence of patch releases, with v3.25.23 published on 2026-09-16, v3.25.22 on 2026-09-09 and v3.25.21 on 2026-08-07. The last push to the repository was on 2026-09-21. A team pinning a version should expect to move the pin periodically rather than once a year.

Browser support, and where the documentation stops

The README's browser support table lists Firefox, Safari, Chrome, Edge and Opera, each marked "Latest" with a check mark, and notes that the project is tested with BrowserStack. That is a narrow and explicit promise: current versions of the five major browsers, with no stated support for older releases. Anyone who has to support a long-lived enterprise browser should treat that table as the answer to their question, and the answer is no.

The README is also thin in places where a prospective adopter would want detail. It does not document a rollback procedure, a migration guide between minor versions, or the component API. It links to the homepage for learning more, and that is where the real documentation lives. The repository does carry a CHANGELOG.md at the top level, and CONTRIBUTING.md for people filing bugs or pull requests, but the README itself is an entry point rather than a manual.

That division is normal for a project of this age, and it is not a defect. It does mean that evaluating UIkit from the repository alone will not tell you what the components do. You have to read getuikit.com.

A limitation worth taking seriously: no first-party JavaScript framework bindings

UIkit is not a component library for React, Vue, Svelte or any other JavaScript framework. The README and package.json describe a CSS and JavaScript framework whose output is dist/css/uikit.css and dist/js/uikit.js, consumed by including those files and writing markup. There is no first-party React package in the repository, and no mention of framework adapters.

In a React or Vue application, that means UIkit sits outside the component model. State that lives in the framework and state that lives in UIkit's DOM behaviour have to be reconciled by hand, and any UIkit component that manipulates the DOM can conflict with a virtual DOM diffing over the same nodes. This is not a reason the project is badly built. It is a reason it is the wrong tool for a single-page application whose screens are all framework components.

The second limitation is the browser table. Five browsers, latest versions only. If your support matrix includes anything older, UIkit's stated support does not cover it, and you would be testing against a promise the project never made.

Alternatives, and the real difference in approach

The closest comparison in the search data is Uikit-react, a separate project that provides React bindings for UIkit. The difference is structural rather than cosmetic: Uikit-react wraps UIkit's components so they can be declared as React components and participate in the React tree, whereas UIkit itself expects you to include a stylesheet and a script and write plain HTML. If your application is React and you want UIkit's look, the binding layer is the relevant choice. If your application renders HTML on the server, the binding layer adds a dependency you do not need.

The other comparison that appears repeatedly in the search data is SwiftUI, and it is a false one. Apple's UIKit is a native iOS interface framework, and SwiftUI is Apple's newer declarative replacement for it. Questions such as "What is UIKit vs SwiftUI?" and "Which is better in 2026, SwiftUI or UIKit?" are about Apple's framework, not this repository. The two share a name and nothing else. YOOtheme's UIkit targets the browser and ships CSS and JavaScript; Apple's UIKit targets iOS and ships as part of the platform SDK. A reader who arrived here looking for the iOS framework should leave.

Editorial conclusion

Adopt UIkit if you want a class-driven framework you can drop into server-rendered HTML or a CMS theme, and if you are willing to read the docs at getuikit.com rather than rely on a large third-party plugin ecosystem. Do not adopt it if your application is written in React or Vue and you expect first-party bindings, or if you are looking for Apple's UIKit, which is a different project entirely. Before committing, check the dist/ directory in the installed package to confirm which components ship pre-built, and read the CHANGELOG.md for the release you pin.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. uikit/uikit on GitHub