Layui: a browser-native UI component library that ships as plain HTML, CSS and JavaScript
一套遵循浏览器原生态开发模式的 Web UI 组件库。
At a glance
- What is it?
- Layui is an MIT-licensed component library built around the original browser development model rather than a build pipeline. It fits server-rendered admin pages and teams without a frontend toolchain, and it is the wrong choice when you want a component model with typed props and a bundler-first workflow.
- Who is it for?
- Adopt Layui if you maintain server-rendered pages, internal admin tools, or template-driven backends and want components that work by loading CSS and JavaScript directly in the browser, without a build step or a framework runtime. Do not adopt it if your project already depends on a component model with typed props, compiled templates, and tree-shaken bundles, because Layui's value proposition is precisely the absence of that layer.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 15 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Layui fills: components without a build pipeline
The README describes Layui as a Web UI component library that follows a pure native HTML, CSS and JavaScript development model, and states that it lowers the barrier for non-frontend developers building complex page interfaces. That sentence is the whole positioning. The target user is not a frontend specialist choosing between component libraries. It is a backend developer, a template author, or a small team shipping an admin console, a CMS backend, or an internal tool where the page is rendered by the server and the interactive parts are a form, a table, a modal, and a date picker.
In that setting, the cost of a modern frontend stack is not the framework itself. It is the toolchain: a package manager, a bundler, a transpiler, a dev server, and the build configuration that has to be maintained by someone who understands it. Layui's claim is that you can skip all of that. You include the stylesheet and the script, you write HTML with the expected class names and attributes, and you call a small JavaScript API to turn a div into a table or a select into a dropdown. The README frames this as letting developers face the browser directly. Whether that is a virtue or a constraint depends entirely on who is maintaining the page six months later.
How the mechanism works: markup first, JavaScript second
Layui's architecture is markup-driven. Components are declared through HTML structure and class or attribute conventions, and then activated by a JavaScript call. The README does not reproduce the API surface, but the pattern is visible in how the project describes itself: the page's elements and interactions are expressed in native HTML, CSS and JavaScript, with the library supplying the styles and behavior.
This has a concrete consequence for data flow. There is no virtual DOM and no reactive state graph. When data changes, you re-render the affected markup or call the component's update method, and the library manipulates the real DOM. For a table bound to a server endpoint, the typical flow is that the component issues the request and renders rows into the existing table element. For a form, the values live in the DOM inputs until you read them. That is the same model the browser already uses, which is why the library can be dropped into a server-rendered page without a hydration step.
The library is also modular. Layui's documentation describes loading individual components rather than the entire bundle, which matters because a page that only needs a date picker should not pay for the table and upload components. The README does not enumerate the module names, so check the v2 documentation for the exact identifiers before wiring your loader configuration.
Getting it running from the documented entry points
The README gives two documentation entry points: Layui 3, which it marks as under development and links to a GitHub issue rather than a release, and Layui 2, linked at layui.dev/docs/2. The current stable line is 2.x, with v2.13.9 published on 2026-08-11, following v2.13.8 on 2026-06-30 and v2.13.7 on 2026-05-29. If you are evaluating the project today, the 2.x documentation is the one that describes shipped behavior.
The README itself does not include an installation command or a configuration snippet, so the exact setup steps have to come from the documentation site rather than this page. What the material does establish is the distribution channel: the project publishes to npm under the package name layui, and the README's own logo is loaded from unpkg, which indicates that CDN delivery of the built assets is a supported path. For a server-rendered page, that means you can either reference the built files from a CDN or copy them into your static directory, and neither route requires a bundler.
What you should confirm in the docs before starting is the module loader's path resolution. Layui's loader is the piece that turns a component name into a script request, and in deployments where assets sit behind a context path or a different origin, the default resolution will need to be adjusted. The documentation describes an extend configuration for aliasing module paths, but the README does not reproduce it, so treat the exact key names as something to verify rather than assume.
Where the browser-native model breaks down
The same design that makes Layui easy to adopt makes it awkward in codebases that have moved past direct DOM manipulation. If your application state lives in a store and your views are derived from it, Layui components sit outside that system. You will end up writing imperative glue: after the store updates, find the element, call the component's render or reload method, and hope the two stay in sync. That glue is where bugs accumulate, and no amount of documentation removes it.
There is a second limitation in the release history. Between May and August 2026 the project shipped three patch releases, v2.13.7, v2.13.8 and v2.13.9. Patch releases are normal for a maintained library, but they mean that if you vendor the built files into your repository, you own a recurring update task. Pinning to a CDN URL moves that task to the CDN but does not remove the need to check what changed.
The third issue is the version split. The README states that Layui 3 is in development and links to an issue for it. Starting a new project on the 2.x line means accepting that the next major version exists on a roadmap you cannot fully evaluate from the README. The README also records that the project recommended users move to mainstream frameworks in a 2021 announcement and continues to describe itself as filling the narrower gaps outside the mainstream. Read that as an honest statement of scope, not as a warning, but do read it.
Layui against a framework component library
The natural comparison is a component library that ships inside a framework runtime, where components are declared in the framework's template syntax and receive props and state through the framework's own mechanism. The difference is not cosmetic. In that model, a table component re-renders when its data prop changes, and the framework reconciles the DOM for you. In Layui, you call the table's reload method and the library updates the DOM directly. The first approach scales better as the number of interacting components grows. The second approach requires no runtime, no compilation, and no understanding of a component lifecycle beyond when to call the update function.
For a page with four interactive elements, the second approach is simpler and the difference is small. For a single-page application with dozens of interdependent views, the first approach wins, and choosing Layui means writing the coordination layer yourself. That is the trade in one sentence: Layui removes the toolchain and hands you the DOM.
Licence and maintenance expectations
Layui is released under the MIT licence, which permits use, modification, and redistribution with the licence notice preserved, and the README points to a separate disclaimer document hosted on Gitee for related terms. This article is not legal advice; if your organisation has restrictions on third-party code, the disclaimer is the document to read, not the licence badge.
Maintenance cost depends on how you consume the library. The npm package and the CDN both give you a versioned artifact, so the upgrade decision is yours to schedule. The repository shows continuous activity, with the most recent push on 2026-09-01 and the v2.13.x series arriving on a roughly monthly cadence through mid-2026. That cadence is the practical number to plan against: if you vendor the files, budget a review per patch release, and if you reference a CDN, pin the version in the URL so a patch cannot change your page without a commit.
Editorial conclusion
Adopt Layui if you maintain server-rendered pages, internal admin tools, or template-driven backends and want components that work by loading CSS and JavaScript directly in the browser, without a build step or a framework runtime. Do not adopt it if your project already depends on a component model with typed props, compiled templates, and tree-shaken bundles, because Layui's value proposition is precisely the absence of that layer. Before committing, verify three things against the v2.13.x documentation: how the module loader resolves paths in your deployment (the docs describe an extend configuration for aliasing), which of the 2.x components you actually need, since Layui 3 is in development and the README links its tracking issue rather than a stable release, and whether your team accepts the upgrade cadence implied by three patch releases between May and August 2026.
Community notes