Page UI: copy-paste landing page components for React and Next.js
📃 Landing page UI components for React & Next.js, built on top of TailwindCSS
At a glance
- What is it?
- Page UI is a Shadcn-style component collection for landing pages, distributed through a CLI rather than an npm runtime package. It is useful if you want to own the markup, and awkward if you want a maintained dependency.
- Who is it for?
- Adopt Page UI if you are building a marketing or landing page in Next.js with Tailwind v3 and you want the component source in your own repository. Do not adopt it if you expect a versioned npm dependency, Tailwind v4 support, or a documented upgrade path.
- 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 75 days ago.
- What is it written in?
- Mainly TypeScript, 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 blank canvas problem Page UI targets
Most React component libraries are built for application surfaces: tables, dialogs, form controls. The README states the motivation plainly, that most UI libraries focus on application UI, so a new starter or boilerplate leaves you looking at an empty page. Landing pages need a different vocabulary. Hero sections, marquee strips, testimonial rows, pricing blocks, screenshot layouts. Page UI is a set of those, written for React and Next.js and styled with Tailwind CSS.
The audience is narrow and specific. You are a developer or a small team shipping a product site, you already work in Next.js, and you would rather paste a section into your repo than install a runtime dependency you do not control. The README describes the components as things you can copy and paste, and the repository name for the CLI package, @page-ui/wizard, reflects that distribution model. You get source files, not an import.
That choice has consequences in both directions. You can edit anything, and nothing breaks when the upstream project changes a prop. You also inherit the maintenance. There is no upgrade command that rewrites your customized sections, because after the paste the code is yours.
How the wizard distributes components instead of shipping them
The mechanism follows Shadcn UI, which the README names as the inspiration. The published package is the CLI, not a component library. Its package.json declares a single binary entry, bin pointing at ./packages/cli/index.mjs, and its dependencies are terminal tooling: chalk for color, commander for argument parsing, enquirer for prompts, ora for spinners. There is no React, no Tailwind, and no component code in the dependency list, because the CLI's job is to write files into your project.
The repository layout matches that split. Top-level directories include components/, templates/, packages/, and website/. The CLI lives under packages/, the copyable components and templates sit alongside it, and website/ holds the documentation site. Node is the only runtime requirement the package states, with engines set to node >=14.17.0.
One constraint is stated in the README as a warning rather than buried in a changelog: Page UI currently works with Tailwind v3, and the project says support for v4 is in progress. If your project is already on Tailwind v4, the components will not drop in cleanly, and the README does not describe a migration path for that case.
Installing Page UI in a Next.js app
The README gives a four-step installation for Next.js. First, scaffold the app. The command below creates a TypeScript project with Tailwind and ESLint already configured, which is the shape the rest of the steps assume.
npx create-next-app@latest my-app --typescript --tailwind --eslintSecond, run the Page UI CLI from inside the project. The README shows it invoked with npx and the @latest tag, and the wizard prompts you for what to add.
npx @page-ui/wizard@latest initThird, install the peer dependencies the components expect. The README lists them as one npm command, covering the Tailwind plugins, the class-merging helpers, and the Radix primitive used by the accordion.
npm install @tailwindcss/forms @tailwindcss/typography tailwindcss-animate class-variance-authority clsx tailwind-merge lucide-react @radix-ui/react-accordionFourth, add the CSS variables and utility layers to global.css. The README's block defines custom properties for light and dark themes, a set of perspective transforms used to angle screenshots, hard shadow variables, and container width utilities. It notes that if you already use Shadcn UI you should already have the color variables, and that the .dark block can be skipped in that case. The perspective and shadow utilities are specific to Page UI and are not part of a standard Shadcn setup, so that part still needs copying.
Templates, demos, and the Tailwind v3 ceiling
The README points to two galleries rather than embedding examples: landing page templates and landing page component examples, both hosted on shipixen.com. The template thumbnails named in the README are Specta, described as a creator platform template with a marquee and a showcase section; Gnomie AI, a B2C AI SaaS template with carousel examples and product tours; Minimum Via, a minimal product or productized-agency layout; and ScreenshotTwo, a developer tool template with inline testimonials and a two-column screenshot layout. Those descriptions come from the README's own image alt text, so they tell you the intended use case of each template without telling you what the code looks like.
The hard limitation is the Tailwind version. The README carries an explicit warning that Page UI works with Tailwind v3 and that v4 support is being worked on. This is not a small caveat. Tailwind v4 changed how configuration and theme variables are declared, so a project that has already migrated will find the global.css block and the utility classes in the components written against the older model. The README does not state a timeline for v4 support, and no releases were retrieved for this review, so there is no way to judge how far along that work is.
A second limitation is the absence of upgrade tooling. Because components are copied rather than imported, there is no diff to apply and no changelog that maps to files in your repo. The CLI version moves independently of the code you pasted. The README does not document rollback or re-sync behaviour for already-installed components.
Page UI against a conventional component library
The natural comparison is a runtime component library in the MUI or Chakra style, where you install a package and import components. The difference is not stylistic, it is about where the code lives and who maintains it. With a runtime library, a bug fix arrives when you bump the version, and a breaking change arrives with it whether you want it or not. With Page UI, the fix exists upstream and does nothing for you until you read the diff and apply it by hand.
Shadcn UI itself is the closer reference point, and Page UI is explicit about the lineage. The practical difference is scope. Shadcn supplies primitives, the buttons and dialogs and inputs that application screens are assembled from. Page UI supplies the assembled sections, the hero and the pricing block and the testimonial row. Using both is the intended combination, which is why the README says to skip the color variables if Shadcn is already present.
If neither the copy-paste model nor the section-level scope fits, the honest alternative is a full landing page template or a site builder, where you configure a page rather than own its source. You trade control for not having to maintain the markup. The README itself points at Shipixen as a way to skip the setup entirely, which is a fair signal about where the project thinks its own boundary is.
Licence, maintenance, and what a paste actually costs
The package declares the MIT licence, and the repository carries a LICENSE.md at the top level. For most teams that is the permissive case: you can use the components in commercial products, modify them, and keep the modifications private, provided you preserve the licence notice. This is a description of what the licence file states, not legal advice, and if the components end up inside a distributed product you should read LICENSE.md yourself rather than take a summary.
The maintenance picture is mixed by design. The repository is not archived, and the last push was on 2026-07-06, which is recent enough that the project is still being touched. But the CLI version and your pasted components are separate artifacts. When you run npx @page-ui/wizard@latest init, you get whatever the current CLI produces; the files it wrote last month do not change. Upgrading a section means diffing the current template against your modified copy and deciding what to take.
The upgrade cost is therefore front-loaded into your own repository rather than into a dependency bump. That is a reasonable trade for a landing page, which tends to be written once and edited occasionally. It is a poor trade for anything you expect to receive security patches for, since there is no patch channel here at all: the code is already yours, and the responsibility for auditing it is too.
Editorial conclusion
Adopt Page UI if you are building a marketing or landing page in Next.js with Tailwind v3 and you want the component source in your own repository. Do not adopt it if you expect a versioned npm dependency, Tailwind v4 support, or a documented upgrade path. Before committing, check the Tailwind version in your project against the README's v3 requirement, confirm the CLI writes the files where you want them, and read the global.css block to see whether your existing Shadcn variables already cover it.
Frequently asked questions
How do I use Page UI in a Next.js project?
The README's installation runs create-next-app with the TypeScript, Tailwind and ESLint flags, then npx @page-ui/wizard@latest init, then installs the peer dependencies such as @tailwindcss/forms, tailwindcss-animate and lucide-react, and finally adds the CSS variables and utility layers to global.css.
What is landing page UI in the context of Page UI?
Page UI describes itself as a collection of free templates, components and examples for building landing pages with React and Next.js, styled with Tailwind CSS and inspired by Shadcn UI. The README's stated motivation is that most UI libraries target application UI, leaving a new project with a blank canvas.
Does Page UI work with Tailwind CSS v4?
No. The README carries a warning that Page UI currently works with Tailwind v3 and that support for v4 is being worked on. No timeline is given, and no releases were retrieved for this review.
Is Page UI a runtime dependency I import from?
No. The published package is the wizard CLI, whose package.json declares a single bin entry and only terminal dependencies such as chalk, commander, enquirer and ora. Components are copied into your project, following the Shadcn UI model the README cites.
What licence does Page UI use?
The package declares the MIT licence, and the repository contains a LICENSE.md at the top level. That permits commercial use and modification provided the licence notice is preserved; read the file itself for the exact terms.
Community notes