Nijor is a component-based frontend framework for building modern web applications.
Unlike many UI frameworks that rely on separate meta-frameworks for application features, Nijor includes these capabilities by default.
File-based routing, layouts, middleware, and other application-level features are built directly into the framework.
Templates are written in *.nijor files that combine markup, logic, and styles in a single component file.
Nijor avoids the Virtual DOM and instead relies on the browser’s native DOM APIs for rendering.
Server-side rendering (SSR) is currently under development. Once fully implemented, developers will be able to choose between client-side rendering (CSR) and server-side rendering (SSR) for production builds.
Nijor is still evolving and is not a perfect framework yet. Like any growing project, it has some flaws and rough edges that are being improved over time.
Nijor is built around a simple principle: use the browser’s capabilities instead of recreating them in JavaScript.
Modern frameworks often introduce additional abstraction layers such as Virtual DOMs or heavy runtime systems. Nijor aims to reduce this complexity by relying on native browser behavior wherever possible.
Nijor updates the real DOM directly instead of maintaining a virtual representation.
Events are declared using inline attributes instead of generated addEventListener calls.
Routing, layouts, middleware, and plugins are included directly in the framework instead of requiring an additional meta-framework.
Unlike many JavaScript frameworks, Nijor projects do not include a node_modules directory by default.
Instead, the Nijor runtime files are shared across projects. This reduces disk usage and keeps projects lightweight.
You can still install and use external packages via Bun or Node and import them in your project without extra configuration.
Nijor is actively evolving, and some parts of the framework are still being refined. One current limitation is the lack of proper error logging, which can make debugging harder than it should be. This is a known issue and will be improved in the future.
A typical Nijor project follows a simple and organized structure:
my-app/
├── pages/
│ ├── index.nijor
│ ├── about.nijor
│ └── blog/
│ └── index.nijor
├── layouts/
│ └── main.nijor
├── middleware/
│ └── auth.js
├── plugins/
│ └── example.js
├── public/
│ └── assets/
└── nijor.config.js
The pages directory defines routes, layouts contains reusable layout components, middleware handles request-level logic, plugins extend the framework, and public stores static assets.