ARWES: a sci-fi UI framework that is no longer maintained

What ARWES solves, and for whom

Most component libraries optimise for neutrality: a button, a table, a modal, styled so it can pass in any product. ARWES goes the other way. It is a web framework for interfaces built on futuristic science fiction designs, animations and sound effects, and the README states the concepts are opinionated, with influences from Cyberprep and productions such as Star Citizen, Halo, NIKKE and Mecha Break. That opinion is the product. If you want a dashboard that looks like a ship console, assembling that from a neutral component library means writing every frame, glow and boot animation yourself. ARWES ships those as the default.

The intended audience is narrow and identifiable. The README lists community apps that include ZKN, SoulExtract.com, Archive RPG, a Cyber Movie Database, a stream overlay for a simpit, and several game-adjacent sites. The pattern is clear: game interfaces, role-playing tools, streaming overlays, and personal dashboards where the aesthetic is the point. A banking app is not the audience. A marketing site for a hardware startup could be, if the brand is already leaning that direction.

The framework is split into two layers. The vanilla package is the core, and the README describes vanilla packages as having no major external dependencies but exposing low level APIs that sometimes require elaborated setups. The React package wraps that core for React v18 with SSR support. Choose the React package unless you have a reason not to.

How ARWES is structured: vanilla core, React binding, monorepo

The repository is an npm workspaces monorepo. The root package.json declares workspaces for apps/* and packages/*, pins Node 20 in engines, and sets the package manager to [email protected]. Builds run through turbo, with lerna handling publishing. The TypeScript configuration is split across tsconfig.base.json plus separate CJS and ESM build configs, which tells you the packages ship both module formats.

The React binding is where most users will live. The README states ARWES offers React v18 specific packages with SSR support, and then adds two constraints in the same sentence: ARWES does not work with React strict mode nor React Server Components. Read that as an architectural boundary rather than a bug. Strict mode double-invokes render and effects to surface unsafe patterns; a framework whose value is animation and timed effects is exactly the kind of code that trips it. Server Components assume a boundary between server and client rendering that an animation-driven UI does not fit. The React package also depends on motion, listed at ^10.18.0 in the root dependencies, which is the animation engine underneath.

The vanilla layer is deliberately low level. The README says other implementation packages simplify its use, which is a polite way of saying the core API expects you to wire up your own rendering and lifecycle. If you are not using React and not prepared to manage that wiring, the vanilla package is the wrong entry point.

Installing ARWES and rendering a first React component

ARWES is distributed on npm. The README links both the arwes package and the @arwes/react package to npmjs.org, so installation is a normal npm install. The repository pins Node 20 in its engines field, so match that before you start.

The root package.json pins the toolchain versions the framework is developed against. It declares Node 20 in engines, [email protected] as the package manager, and react and react-dom at ^18.3.1:

"engines": {
  "node": "20"
},
"packageManager": "[email protected]",
"react": "^18.3.1",
"react-dom": "^18.3.1",

Those are the versions to match in your own project. The README states the React packages are React v18 specific, so a React 19 application is outside what the project documents.

Before you write a component, check two settings. The README says ARWES does not work with React strict mode, so if your app is wrapped in React.StrictMode, remove that wrapper or the animations will misbehave. It also does not work with React Server Components, so keep ARWES components on the client side.

The exact component names, props and provider setup are not reproduced in the README, so check the documentation site at arwes.dev for the current API before wiring anything up. That site is where the README points readers, and it is the documented source for the component surface. What you should expect once configured: components that render sci-fi frames and effects, with animation and sound handled by the framework rather than by you.

The maintenance problem is stated by the project itself

This is the part that decides most adoption questions. The README carries a blockquote that says the ARWES project is no longer maintained and currently outdated but still functional and operational, and invites readers to fork it for personal use. That is unusually direct, and it should be taken literally.

The release history backs it up. The most recent release listed is v1.0.0-alpha.23 from 2023-08-13. Before that, v1.0.0-alpha.22 on 2023-07-18 and v1.0.0-alpha.21 on 2023-06-28. The version string still carries alpha after three years of releases, which means the project never declared a stable API. The repository is not archived and the last push was on 2026-07-05, so the code is not frozen, but a recent push is not the same as maintenance, and the README's own statement is the stronger signal.

The practical consequences are concrete. React 19 exists and ARWES targets React 18; nothing in the README suggests an upgrade path. If your application needs to track React releases, ARWES will hold you back. If a dependency in the animation chain (motion is pinned at ^10.18.0) has a security advisory, nobody is going to publish a patch. The README's suggestion to fork is the honest answer: you are adopting a codebase, not a project with a maintainer behind it.

ARWES versus a general-purpose component library

The obvious alternative is a general-purpose React component library such as MUI or Chakra UI, and the difference is not quality but approach. Those libraries give you neutral, themeable primitives (buttons, inputs, dialogs, data grids) and expect you to supply the visual identity through a theme. Their animation support is limited to transitions and micro-interactions; a boot sequence with sound is not in scope. They are also maintained, which matters if you plan to upgrade React.

ARWES inverts the trade. You get the visual identity and the animation and audio layer out of the box, and you get very little in the way of conventional application components. There is no data grid in the README. There is no form validation layer. If your interface is a console with panels, readouts and effects, ARWES saves you the work of building the aesthetic. If your interface is a CRUD app with a sci-fi skin, you will end up importing a neutral library anyway for the tables and forms, and then you are maintaining two systems with different design assumptions.

There is also a middle path worth naming: use a neutral library for structure and write the sci-fi layer yourself with CSS and an animation library. That is more work than ARWES, but the result is code you control and can upgrade. ARWES is the right call when the aesthetic is the product and the project has a bounded lifespan.

Licence and the cost of forking

ARWES is MIT licensed, and the repository includes a LICENSE file at the root. MIT is permissive: you can use it commercially, modify it, and redistribute it, provided the copyright notice and licence text are preserved. The README's invitation to fork for personal use is compatible with that. This is not legal advice, and if you are shipping a commercial product you should have your own counsel review the notice, but the licence itself places no unusual obligations on adopters.

The real cost is not legal, it is operational. A fork means you own the build. The repository uses turbo for builds, lerna for publishing, and a TypeScript setup split across base, CJS and ESM configs. Keeping that toolchain working as Node and TypeScript move forward is ongoing work. The root package.json pins Node 20 and TypeScript 5.3, so a fork starts from a fixed point and drifts from there. Budget for that before you decide a fork is cheap simply because the licence is permissive.

Who should adopt ARWES, and who should not

Adopt it for game interfaces, role-playing tools, stream overlays, sci-fi demos, and personal dashboards where the look is the reason the project exists. The community app list in the README is full of exactly these, and the framework was built for them. A stream overlay that runs for a season does not need a five-year maintenance guarantee.

Do not adopt it for a product with a multi-year roadmap that depends on tracking React releases, or for anything where a security patch to the animation stack needs to arrive quickly. The README states the project is no longer maintained, and the latest release is an alpha from 2023-08-13. That combination is a hard boundary, not a caveat.

Before committing, verify three things: that @arwes/react resolves on npm at a version compatible with your React 18 setup, that your application does not wrap components in React.StrictMode and does not use React Server Components, and that the component API on arwes.dev matches what you intend to build. If the documentation site no longer describes the API you need, the fork path is the only one left, and you should price that work before writing the first component.

Editorial conclusion

Adopt ARWES only for projects where a sci-fi look matters more than a maintained dependency: game UIs, stream overlays, personal dashboards, demos. Do not adopt it for products that need long-term React upgrades, since the README says the project is no longer maintained and the latest release is v1.0.0-alpha.23 from 2023-08-13. Before committing, check the @arwes/react package on npm, confirm your React version is 18, and verify that your build avoids React strict mode and React Server Components.

Frequently asked questions

Official sources

1. arwes/arwes on GitHub
2. Issues
3. License: MIT
4. README
5. Releases