ReeWeb & Reepolee

Introduction

ReeWeb and Reepolee are independent projects built from the same base. They share the template engine, the i18n system, the Tailwind pipeline, and the philosophy of zero runtime dependencies, but they are deployed separately and do not depend on each other as runtime imports. The difference is scope: ReeWeb generates static sites; Reepolee runs full-stack applications.

This page explains how they relate, when to use which, and how a project can move between them as requirements change.

The Ecosystem

Both tools are built on the same shared layer:

That shared foundation does not mean one product imports the other at runtime. It means the underlying conventions, helpers, and template syntax are aligned, so both projects feel the same to work in.

The shared foundation means skills, templates, and translations transfer cleanly between the two when you choose to share them. Learning one is learning most of the other.

When to Use Which

Choose ReeWeb when:

Choose Reepolee when:

Can You Use Both?

Yes. They can coexist on the same domain with a proxy in front, for example by routing /docs to ReeWeb and /app to Reepolee, or by splitting traffic across subdomains. They remain separate deployments, but a front proxy makes them look like one site to the outside world.

ReeWeb and Reepolee project files can coexist in the same repository under different directories, or live in separate repositories that share a common base. The shared foundation files (lib/template_engine.ts plus the lib/template/ engine modules, lib/i18n.ts, etc.) are aligned between the two projects, so you can keep common tooling and templates in a shared library if you want to.

Reepolee can also feed data into ReeWeb during SSG. That lets a ReeWeb site render with data pulled from the Reepolee side during SSG, while still shipping as a static site afterward.

The practical model: start with ReeWeb, scale into Reepolee, and share data or templates only where it is intentionally useful. Launch a marketing site as a ReeWeb project, get traffic, learn what users need, then extend the project into a Reepolee application when the requirements justify it.

Frequently Asked Questions

Can I use ReeWeb for a site that needs a database?

No. ReeWeb has no database connection, no server process, and no write path. If you need to store and retrieve data dynamically, you need Reepolee or a third-party backend. Third-party options (Headless CMS, BaaS) add network latency and external dependencies - Reepolee keeps everything in one process. In practice, Reepolee can also act as the CMS or data source for ReeWeb's SSG script, where ReeWeb pulls content during SSG and still ships as static HTML afterward.

Will moving from ReeWeb to Reepolee require a rewrite?

No. Reepolee is an addition to ReeWeb, acting as a CMS layer. The template engine, component system, and Tailwind configuration are the same, so you can reuse code pieces directly. Templates keep the same props. data access convention in both projects, so the syntax and structure are identical. The main differences are that Reepolee adds server-side context, database storage, and stores translations in the database instead of static translation files.

Is Reepolee harder to learn than ReeWeb?

It has more features, so there's more to learn. But the foundation - templates, i18n, styling - is identical. If you know ReeWeb, you already know the hardest part of Reepolee. The rest (database queries, auth flows, form handlers) follows standard patterns documented in the Reepolee docs.

Can I share templates between a ReeWeb site and a Reepolee app?

Yes, at the source level. The .ree files use the same props. convention in both projects, so the templates themselves can be shared directly when you wire them into each project. Components and stylesheets can be shared the same way. Reepolee translations do not transfer as runtime files, though - Reepolee reads them from the database, so shared translation content needs a DB-backed workflow or seed process rather than a copied file tree. Reepolee can also provide content to ReeWeb during SSG. You can keep a shared component library in a separate repository and use it in both projects.

What reasons would I have to stay on ReeWeb?

ReeWeb is the better choice when you want the simplest possible deployment (copy files to a CDN), zero operational overhead (no server to maintain, no database to back up), and the fastest possible page loads (static files from a global CDN are faster than any server-rendered page). If none of your requirements need a database, authentication, or server-side processing, ReeWeb is the right tool and there is no reason to leave.

Should I start with Reepolee even if I only need static pages?

That depends on your confidence that the project will need dynamic features. If you're certain the project will stay static, ReeWeb is simpler and cheaper to deploy. If you suspect you'll need auth, a database, or forms within the first few months, starting with Reepolee saves the transition later - you can serve static content from Reepolee just as easily as from ReeWeb.

Can I have static pages and dynamic pages in the same Reepolee project?

Yes - this is one of Reepolee's core design goals. A Reepolee route handler that queries no database and returns a static template is indistinguishable from a flat HTML file in terms of the HTTP response. You can have marketing pages rendered server-side alongside admin panels, user profiles, and database-backed content, all from the same route table, same templates, same deployment.

Summary

ReeWeb and Reepolee are not competitors. They are two tiers of the same ecosystem, designed so that a project can start at the tier that fits today and grow into the tier that fits tomorrow.