Gr8r Studio: a project management app with no UI framework and no runtime dependencies

What the application contains

Gr8r Studio is described as a calm, structured project management workspace. The feature list in the README's opening paragraph is the whole product in one sentence: a home dashboard, an inbox, my tasks, projects with board, list, table, calendar, timeline and files views, members, teams, activity and settings.

That is a real product surface rather than a demo, and the six project views are the notable part. A board and a list are what most task tools give you. A table, a calendar, a timeline and a files view on the same project means the same data is being read through different lenses, and that is a design decision with cost: the views have to agree about what a task is, and the state model has to support fields that only some views show.

The inbox and my tasks are separate from projects, which suggests the model distinguishes work that belongs to a project from work that does not. Teams and members sit alongside that, and activity is a log rather than a field.

The other thing the opening paragraph does is set the tone. Calm and structured are claims about the interface, and the screenshot is of the home dashboard. Whether a tool feels calm is subjective, but the structure underneath it is not, and that is what the rest of the README documents.

No framework, no runtime dependency

The technical stance is stated in two sentences: built with plain JavaScript ES modules and CSS, bundled by Vite, with no UI framework and no runtime dependency.

The distinction between a build dependency and a runtime dependency is the interesting one here. The package.json devDependencies list shows what the build needs: ESLint with its flat config and the js plugin, globals, the Lucide icon package, Prettier and Vite itself. Every one of those is a development-time tool. Nothing is listed under dependencies, because there is no dependencies key at all, which in npm terms means the published artifact would install with an empty dependency tree.

That is a genuine architectural position rather than a temporary state. A project management interface built this way has no React and no component library to version, and the entire client-side code is what you can read in the repository. The trade is that every interaction, every overlay and every accessible behaviour is written by hand rather than assembled from a library, and there is no ecosystem to draw on when you need a date picker or a combobox with keyboard support.

The Lucide entry is worth reading carefully because it is the one runtime-looking dependency. The icons are not bundled wholesale. The README says to call ic('name') with any Lucide icon name, and that the virtual:icons plugin bundles only the icons the source uses. The plugin is in vite.config.js, so the icons are tree-shaken at build time and nothing from Lucide ends up in the shipped bundle. That is the difference between a dependency and a build-time inclusion, and it is what keeps the no-runtime-dependency claim honest.

The three-layer structure and how a click becomes a state change

The project structure section is the most technical part of the README, and it describes a layering discipline that makes the codebase navigable.

Dependencies point downward in three tiers. First, core/ and data/ depend on nothing else in the app. Second, ui/, shell/, components/, pages/, views/, overlays/ and features/ render HTML from state. Third, actions/ change state and re-render.

The conventions then explain how those layers talk to each other, and the design is unusually direct.

Rendering works by string. Each page or view is a function that returns an HTML string from the store, S, and render() rebuilds the shell while keeping focus and scroll positions. That last detail is the one that tells you this was built with use in mind: a full innerHTML replacement would throw away focus and scroll on every update, and preserving both is a deliberate accommodation.

Interaction works by delegation. Elements declare data-a="actionName", and actions/events.js delegates the click to A.actionName. Inputs use data-in and blur handlers use data-blur. So there is no per-element listener wiring; the document listens once and reads the attribute.

The action table is the mechanism. Each action module registers its handlers on the shared action table, A, when it loads, so main.js imports them after actions/actions.js. The ordering constraint is explicit in the README, which tells you the imports in main.js are load-bearing rather than incidental.

The core/ directory holds utilities, constants, icons, the store with state and lookups, and the theme. The shell/ directory holds the render loop and router, the sidebar and topbar layout, skeletons and the view engine. There is a deliberate separation between the shell and the pages inside it: views/ is for project views such as board, table, calendar, timeline, files and overview, while pages/ is for settings, auth and onboarding. Overlays/ holds the task drawer, modals, popovers, a context menu and a command palette, and features/ covers teams, subtasks and archive.

The layout system and the select element

Two conventions are worth pulling out because they show the kind of discipline that keeps a framework-free project coherent.

The first is the gutter. Every page edge uses var(--gutter), so the breadcrumb, page header, toolbar, list, table and board start on the same line. A single CSS custom property, defined in tokens.css along with colours, spacing, type, radius and the shared --gutter, is what makes six different project views line up with each other and with the chrome around them.

The stylesheets are organised by concern and imported in cascade order, with index.css importing every one of them. There is base.css, components.css, shell.css, panels.css, overlays.css, states.css, motion.css and responsive.css, plus a views/ directory for the view-specific sheets and a pages/ directory for the page-specific ones. Separating states and motion from components means the same component stylesheet works in every state without variant rules multiplying inside it.

The second convention is the select element, and it is the most interesting decision in the codebase. The README says to write a normal select with the select class, and that ui/select.js renders it as the design-system menu while keeping the native element as the source of truth.

That is a specific and clever compromise. A custom dropdown drawn from scratch has to reimplement keyboard navigation, screen reader semantics, form submission and mobile behaviour. By keeping the native select as the source of truth and layering the design on top, the application gets a menu that looks like its design system without giving up the accessibility and form behaviour the platform provides. It is the same argument as the Lucide icon tree-shaking: use the platform, restyle it, do not reimplement it.

Getting it running, and the deployment story

The getting started section requires Node.js 18 or newer, with the .nvmrc file pinning 22, and the package.json engines field requiring node >=18.

The scripts are the standard Vite set:

npm install
npm run dev       # http://localhost:5173 with hot reload
npm run build     # production build in dist/
npm run preview   # serve the production build locally
npm run lint      # ESLint
npm run format    # Prettier

There is also a format:check script that runs Prettier in check mode rather than write mode, which is what the CI uses to verify formatting without changing it.

The index.html is the HTML entry that loads src/main.js, and src/main.js is the entry that imports the styles and modules and then boots the app. The data/seed.js file holds demo workspace data, which is the one thing a user must replace before the application means anything, and it is worth noting that the store reads from it rather than from an API, since there is no back end in this repository at all.

Deployment is a single file. vercel.json builds with Vite and serves dist/. The homepage is gr8r-taskmanagement.vercel.app, and the CI runs lint, the format check and a production build on every push and pull request through .github/workflows/ci.yml.

That CI set is worth a comment. Linting, formatting and a build is the minimum that catches a broken import or a stray style violation before review, and for a project with no tests it is the whole safety net. The absence of a test directory is the notable gap in the repository listing, and for a codebase that renders HTML strings and mutates a shared store, a small set of tests on the action layer would be the obvious place to start.

Limits: an application rather than a library, and no identified licence

The limits are worth stating clearly because the shape of this project invites the wrong comparison.

The first is that Gr8r Studio is an application, not a reusable library. There is no published package to depend on, the package.json marks it private, and the code is organised around one specific workspace rather than around an exported API. If what you want is a task management widget for your own product, this repository is a codebase to read and copy from, not a dependency to install. The npm package name is gr8r-studio and it is private, so it is not on the registry for anyone else.

The second is the licence. GitHub shows the licence as unknown, and there is no LICENSE file in the top level listing. The README does not have a licence section either. So despite the project being presented as open in spirit, there is no stated grant of rights here, and copying code out of it without checking is not a decision you can make from the repository.

The third is that there is no back end. All the state is in the browser and seeded from a demo file. There is no sync, no multi-user collaboration and no persistence beyond whatever the browser holds. The features that imply a shared workspace, teams, members and activity, are all reading from the same local store.

The fourth is the cost of the no-framework choice, which is a design cost rather than a defect but a real one. Every accessibility behaviour of every interactive element is the maintainer's responsibility, and the select component is evidence of how much work that is when done well. Building a command palette, a context menu, drag and drop and per-field behaviour by hand is a lot of surface to maintain.

The fifth is the release state. The repository has no GitHub releases and the version in package.json is 1.0.0, with the last push on 2026-10-07. There is no changelog and no tag history to read, so there is no way to see what changed between versions.

Finally, the deployment is coupled to one provider. The vercel.json file builds with Vite and serves dist/, and the live instance is on Vercel. Nothing about the build is Vercel-specific, but the documented path is.

Gr8r Studio against a framework-based dashboard and against a hosted task tool

Two comparisons make the choice clearer.

The first is against a React or Vue implementation of the same thing. The difference in approach is that a framework version gets its accessibility, its keyboard handling and its form semantics from a component library that has been tested against screen readers by more people than one developer. The framework-free version gets them from the platform, as in the select component, which is a cleverer solution but only available where the platform already provides the primitive.

What the framework-free version gains is legible architecture. The three-layer rule, the action table and the string-returning render functions mean you can open a file, see where it sits in the system and know which direction the dependencies go. There is no build-time abstraction between the state and the DOM, and the whole request path is inspectable in a browser devtools panel without a framework devtools extension.

The second comparison is against a hosted task tool, which is what most people would otherwise use. The hosted tool has multi-user sync, mobile apps, permissions that work, and a support team. Gr8r Studio has none of that and instead has something you can read, host yourself and change, with no vendor and no account.

The practical reading is that Gr8r Studio is best understood as a demonstration and a starting point. As a worked example of how much of a product interface you can build with plain ES modules and CSS and no dependencies, it is genuinely instructive, and the layering and convention sections are the part worth studying. As something to put in front of a team tomorrow, it is not ready, because it has no back end, no sync and no stated licence.

If you want a self-hosted tool you can audit and modify without a vendor relationship, it is a reasonable base to fork. If you want to check tasks off a list with colleagues, use a hosted tool.

Editorial conclusion

Adopt Gr8r Studio as a reference for how far a project management interface can be built without a UI framework, and as a starting point if you want a self-hosted tool with no runtime dependency to audit. Do not adopt it as a product dependency, since it is an application rather than a library and the licence is not identified in the repository. Verify first that the workflows you need, six project views, inbox, teams and archive, are present in the version you clone, and that the seed data in data/seed.js is replaced before anyone relies on it.

Frequently asked questions

Official sources

1. gr8rstudio/gr8r-studio on GitHub
2. Issues
3. Project website
4. README