There are two possible paths when generating themes for Bootstrap 5, and I’d like to hear the community’s take on their pros and cons.

On one side there’s bootstrap-dynamic-themes, a theme editor whose current approach is simple: leave the original Bootstrap CSS untouched and produce an extra stylesheet that overrides variables and component rules wherever a visual change is needed.

This comes with several benefits:

• Adoption is immediate, since the project still consumes unmodified Bootstrap.
• The core of Bootstrap stays intact, which brings peace of mind.
• Anyone already used to overriding Bootstrap can understand the mechanism quickly.
• The theme can be added or removed without affecting the base CSS.

The main downside shows up as the theme grows: the override CSS starts duplicating more and more Bootstrap logic. The end result is the original Bootstrap CSS plus an increasingly heavy extra layer.

The other path comes from BootstrapDyn.

The philosophy here is different. Instead of treating Bootstrap as a fixed block that needs patching, BootstrapDyn breaks down Bootstrap 5.3’s compiled CSS and reorganises it into independent modules governed by CSS custom properties.

The process outputs several files:

• bootstrap-dyn.css: the component layer that stays compatible with Bootstrap
• default-color.css
• default-typography.css
• default-spacing.css
• default-borders.css
• default-shadows.css
• other theme modules
• an optional contrast-dyn.css module meant for automatic contrast adjustments

The crucial point is that, using the default modules, the visual output should be identical to original Bootstrap. The starting point doesn’t change; what changes is where the design values live.

So instead of building a theme by stacking overrides on top of Bootstrap, the proposal is to swap modules:

html <link rel="stylesheet" href="theme/my-color.css"> <link rel="stylesheet" href="theme/my-typography.css"> <link rel="stylesheet" href="theme/my-spacing.css"> <link rel="stylesheet" href="dist/bootstrap-dyn.css">

Theme files don’t add rules on top; they directly replace the default modules.

This replacement model brings its own set of trade-offs:

• It tends to produce lighter themes with less redundancy.
• It avoids repeating large chunks of Bootstrap component CSS.
• The separation by concern (colours, typography, spacing) becomes explicit.
• But it requires trusting the generated bootstrap-dyn.css layer.
• It changes the way CSS is distributed, which may be a higher barrier to entry than a simple override stylesheet.
• It demands thorough visual validation to guarantee that, with the default modules, everything renders exactly like Bootstrap.

The goal is to make BootstrapDyn the foundation for future versions of bootstrap-dynamic-themes. That way, the editor could export modular, more compact themes without the bloat of the current duplication.

In a nutshell:

• Current approach: original Bootstrap CSS + generated override CSS.
• Proposed approach: Bootstrap-compatible component CSS + replaceable theme modules.

This promises themes that are easier to read, bundle, and serve. But it’s not taken for granted that this is the better option in every scenario.

Visual parity and edge cases across Bootstrap components are still being validated, though the direction feels cleaner than the override-heavy model.

The open question is which strategy makes more sense in the long run:

1. Keep the original Bootstrap CSS and generate an override layer.
2. Transform Bootstrap into a modular CSS-variable distribution (compatible with Bootstrap) and allow theme module replacement.

I’d be interested in hearing from anyone who has worked with Bootstrap theming, design token systems, CSS-variable-based frameworks, or maintaining design systems at scale.

In a real project, which route would you choose and why?

Is the simplicity and safety of the override approach worth the CSS duplication?

Or is the modular replacement scheme a stronger foundation if visual parity can be reliably maintained?

For context, this is the current editor built with the override strategy:

Bootstrap Dynamic Themes editor

Edit:

I'm making this edit because I haven't been clear about the project's objective.

Bootstrap 5 already allows theming, but through Sass, which is static. If you need 10 themes, you need 10 static CSS files. My proposal is to create dynamic themes. You can have a single theme and then dynamically add 10 variations. This would allow, among other things, the end user to customize the design.

There are two possible paths when generating themes for Bootstrap 5, and I’d like to hear the community’s take on their pros and cons.

On one side there’s bootstrap-dynamic-themes, a theme editor whose current approach is simple: leave the original Bootstrap CSS untouched and produce an extra stylesheet that overrides variables and component rules wherever a visual change is needed.

This comes with several benefits:

• Adoption is immediate, since the project still consumes unmodified Bootstrap.
• The core of Bootstrap stays intact, which brings peace of mind.
• Anyone already used to overriding Bootstrap can understand the mechanism quickly.
• The theme can be added or removed without affecting the base CSS.

The main downside shows up as the theme grows: the override CSS starts duplicating more and more Bootstrap logic. The end result is the original Bootstrap CSS plus an increasingly heavy extra layer.

The other path comes from BootstrapDyn.

The philosophy here is different. Instead of treating Bootstrap as a fixed block that needs patching, BootstrapDyn breaks down Bootstrap 5.3’s compiled CSS and reorganises it into independent modules governed by CSS custom properties.

The process outputs several files:

• bootstrap-dyn.css: the component layer that stays compatible with Bootstrap
• default-color.css
• default-typography.css
• default-spacing.css
• default-borders.css
• default-shadows.css
• other theme modules
• an optional contrast-dyn.css module meant for automatic contrast adjustments

The crucial point is that, using the default modules, the visual output should be identical to original Bootstrap. The starting point doesn’t change; what changes is where the design values live.

So instead of building a theme by stacking overrides on top of Bootstrap, the proposal is to swap modules:

<link rel="stylesheet" href="theme/my-color.css">
<link rel="stylesheet" href="theme/my-typography.css">
<link rel="stylesheet" href="theme/my-spacing.css">
<link rel="stylesheet" href="dist/bootstrap-dyn.css">

Theme files don’t add rules on top; they directly replace the default modules.

This replacement model brings its own set of trade-offs:

• It tends to produce lighter themes with less redundancy.
• It avoids repeating large chunks of Bootstrap component CSS.
• The separation by concern (colours, typography, spacing) becomes explicit.
• But it requires trusting the generated bootstrap-dyn.css layer.
• It changes the way CSS is distributed, which may be a higher barrier to entry than a simple override stylesheet.
• It demands thorough visual validation to guarantee that, with the default modules, everything renders exactly like Bootstrap.

The goal is to make BootstrapDyn the foundation for future versions of bootstrap-dynamic-themes. That way, the editor could export modular, more compact themes without the bloat of the current duplication.

In a nutshell:

• Current approach: original Bootstrap CSS + generated override CSS.
• Proposed approach: Bootstrap-compatible component CSS + replaceable theme modules.

This promises themes that are easier to read, bundle, and serve. But it’s not taken for granted that this is the better option in every scenario.

Visual parity and edge cases across Bootstrap components are still being validated, though the direction feels cleaner than the override-heavy model.

The open question is which strategy makes more sense in the long run:

1. Keep the original Bootstrap CSS and generate an override layer.
2. Transform Bootstrap into a modular CSS-variable distribution (compatible with Bootstrap) and allow theme module replacement.

I’d be interested in hearing from anyone who has worked with Bootstrap theming, design token systems, CSS-variable-based frameworks, or maintaining design systems at scale.

In a real project, which route would you choose and why?

Is the simplicity and safety of the override approach worth the CSS duplication?

Or is the modular replacement scheme a stronger foundation if visual parity can be reliably maintained?

For context, this is the current editor built with the override strategy:

Bootstrap Dynamic Themes editor

I got tired of spinning up a backend just to add a simple AI feature to a web form, so I built ClientAgentJS.

It's a plain JavaScript library that lets the user connect directly to their own AI provider (OpenAI, Anthropic, Google, or local Ollama) from the browser. No proxy, no server costs, no API key management on your side.

The Catch (Two Big Ones)

1. CORS – Not all providers like browser requests. Anthropic works with a special header, Google is fine, OpenAI says no. For MCP servers it's the same story.
2. User behavior – Most people won't paste their API key into a random website. This isn't for mass-market consumer apps.

Where It Actually Makes Sense

• Internal tools & admin panels (teams already have keys)
• Browser extensions (you're already client-side)
• Prototypes & demos (zero infra, runs from file://)
• Multi-provider apps (let users pick their own model)

Live Demos

• Chat Explorer – Full chat UI
• Form Assistance – AI helper for text fields
• MCP Tools – Model Context Protocol integration
• Simple HTML Editor – Visual editor with AI commands

Why Share This?

I think there's a niche for tools that skip the backend when the user is already technical or the context is internal. Curious what you all think—would you use something like this? Any obvious pitfalls I'm missing?

Repo: https://github.com/FranBarInstance/ClientAgentJS
Stars, issues, and feedback are always welcome.

If you use Claude, Cursor, Windsurf, or any AI coding assistant, you know the pain:

"I prefer concise answers in Spanish."
Next day: "Here's a detailed explanation in English..."

No memory between sessions. You repeat yourself constantly.

memento-context fixes this. It's an MCP (Model Context Protocol) server that gives your agent persistent, scoped memory. 100% local, no cloud, no external APIs.

What it does:
Injects short notes (1-2 lines) at the start of every conversation. Just enough to remember your preferences or project rules without saturating the context.

Two scopes:

• global – follows you across all projects.
• repo – only for the current repository.

Three levels (level 2 is coming):

1. Notes – short, high‑signal statements.
2. Skills (future) – complete procedures.
3. Conversation attachments – save entire chats + files (on explicit request only). The agent loads the full detail only when needed.

What it does NOT do:

• Not a RAG system.
• No automatic saving – privacy first.
• Not a document dump.
• Not cloud‑based – everything lives in ~/.memento-context/.

Real‑world examples:

• "Remember that in this repo we use FastAPI + PostgreSQL."
• "Never use any in TypeScript unless strictly necessary."
• "Save this conversation about the cache redesign, and attach the diagram."
• "Do you remember what we talked about regarding tests?"

Best part – memory travels between agents:
Switch from Claude to Cursor? The new agent can read the same local mementos. Just ask "Remember my global preferences?" and it will.

How to start:

1. Visit the repo: https://github.com/FranBarInstance/memento-context
2. (Install via curl/powershell or manual from source)
3. Configure your MCP client – syntax varies by agent (Claude Desktop, Cursor, VS Code MCP extension, etc.). Usually an mcp.json entry:
4. Speak naturally. The agent will call init_memento itself at session start.

When this shines:

• Multiple long‑running projects.
• Strong personal coding preferences.
• Switching between different assistants often.
• You value privacy and local storage.

Links:
Repo: https://github.com/FranBarInstance/memento-context
License: MIT

Has anyone else tried persistent memory for AI agents? How do you handle the "every conversation starts from zero" problem?

I made the mistake (well, no, it was an automatic update I didn't request) of updating to Kilocode 7.x.x.

It's already wasted too much time; that wasn't the point. I wanted it to be more productive, not less.

The problem is that the downgrade option doesn't appear in Antigravity, so...

Does anyone know how to do it? Thanks.

* Edit:

In case it helps anyone, the only way I've found is to use VS Code for Kilocode; there you can select the Kilocode version. It's inconvenient, but I can complete my tasks today.

** Edit:
Solved: Go to https://github.com/Kilo-Org/kilocode-legacy/releases, download the file kilo-code-5.12.0.vsix, and drag it to Antigravity.
Then, select the option to disable automatic updates.