VvvebJs: A Drag and Drop Page Builder With No Build Step

What VvvebJs solves and who ends up using it

Most page builders arrive as a framework, a bundler config and a plugin ecosystem. VvvebJs goes the other way. The README describes it as a drag and drop page builder library built with vanilla JavaScript, with no dependencies or build tools, plus Bootstrap 5. The repository layout backs that up: editor.html sits at the top level, the builder code lives under libs/builder/, and the only runtime dependency in package.json is express, which exists for the Node save path rather than for the editor itself.

The audience is therefore narrow and specific. It fits a developer who already has a site or a CMS and wants to drop an editing surface on top of existing HTML pages. It does not fit someone who wants to sign up for a hosted builder. The live demo at vvveb.com/vvvebjs/editor.html is the fastest way to see the interaction model before reading any code, and the README points to the separate Vvveb CMS repository for a full application built on the same library.

How the editor loads a page and writes changes back

The mechanism is an iframe plus a set of cooperating objects. Vvveb.Builder.init takes a page URL and a callback that runs after the page loads. From there the README's initialization example wires up Vvveb.Gui, Vvveb.FileManager, Vvveb.SectionList and Vvveb.Breadcrumb. Pages are registered as plain objects with name, title, url and file fields, and FileManager.addPages feeds that list into the file manager panel.

Because the edited page lives in an iframe, the browser's same-origin rules apply. That is why the README insists on serving the files over a webserver rather than opening editor.html from disk. The save path is deliberately outside the library: save.php handles saving when PHP is available, and save.js does the same under Node. The library itself does not define a storage backend, which is a design choice rather than an oversight, but it does mean you own persistence.

Components are split into separate scripts. components-bootstrap5.js and components-widgets.js are loaded alongside builder.js, undo.js and inputs.js. Extending the editor means adding to that component layer, not patching the core.

Installing VvvebJs and opening the editor for the first time

The README gives two clone forms depending on your git version, because the project uses submodules. Use the recursive form on git 2.13 or newer:

git clone --recurse-submodules https://github.com/givanz/VvvebJs

Older git versions use the recursive flag instead. Once cloned, the README says to open editor.html through a webserver, for example Apache or XAMPP, at http://localhost/editor.html. Opening the file directly from the filesystem will not work because of iframe security.

If you would rather not install a webserver, the README offers a Docker route. From the VvvebJs folder:

docker-compose up

Or run the published image directly, which maps port 8080 to the container's port 80:

docker run -p 8080:80 vvveb/vvvebjs

After that, the README says to open http://localhost:8080/editor.php or http://localhost:8080/editor.html. The first of those is the PHP entry point, so it is the one to use if you want the image upload and save features to work out of the box.

To enable saving under Node instead of PHP, the README's steps are to install express in the VvvebJs folder and start the save script:

npm install express
node save.js

Then open http://localhost:8080/editor.html. Saving is handled by save.js in that setup. There is no documented build step for the editor itself; gulp exists for the landing template and for compiling the scss/editor.scss and scss/_builder.scss stylesheets.

Where VvvebJs stops being the right tool

The save feature is the clearest boundary. The README states plainly that saving a page needs either PHP or Node, and that image upload or page save requires PHP installed. If your deployment target is a static host with no server-side runtime, the editor can still be embedded, but you will have to write your own persistence layer, and the README does not document one.

The second boundary is the component model. The editor ships with Bootstrap 5 and Widgets components, and the README says it can be extended with any kind of components and inputs. That flexibility is real, but it is code-level extension: you are editing JavaScript component definitions, not installing plugins from a registry. There is no package index described in the README.

Third, the README does not document rollback, versioning of saved pages, or conflict handling when two people edit the same page. Undo and redo exist as an in-editor operation via undo.js, which is a different thing from server-side history. If you need an audit trail of page revisions, that is on you. The wiki is where the project points for documentation, so treat the README as a starting point rather than a complete manual.

VvvebJs against GrapesJS: what actually differs

GrapesJS is the comparison most people reach for, and the difference is architectural rather than cosmetic. GrapesJS is typically consumed as a package with a plugin ecosystem and a framework-agnostic core that you initialize from a bundler. VvvebJs is consumed by cloning a repository and loading script tags. The README's own initialization example is a sequence of script elements followed by calls to Vvveb.Builder.init and the panel initializers, with no import statement anywhere.

That has consequences in both directions. With VvvebJs you get a working editor by serving static files, which is genuinely simpler for a legacy PHP site. You also inherit a fixed coupling to Bootstrap 5 as the default component set, and a save path that is written in PHP and Node rather than exposed as an API. With GrapesJS you would more likely write a storage adapter against a documented API. Neither approach is universally better; the choice depends on whether your existing stack is already a served directory of HTML files.

The README also notes a React wrapper at github.com/VvvebJs/react, so a React application is not automatically excluded, but the wrapper is a separate repository rather than part of this one.

Licence, maintenance and what an upgrade actually costs

The project is Apache-2.0, stated both in the README and in package.json. Apache-2.0 includes an explicit patent grant and requires that you preserve notices and state changes you make. That matters here because the normal way to use VvvebJs is to copy the repository into your own project and modify the component files. If you fork and edit, keep the licence file and note your modifications. This is a description of the licence text, not legal advice; check the terms against your own distribution model.

The repository is not archived, and the last push was on 2026-07-01, which is under three months before today's date. Releases are tagged: 2.0.9 on 2026-07-01, 2.0.6 on 2026-05-18 and 2.0.5 on 2026-03-09. Note the mismatch between the release tags and package.json, which still declares version 0.0.1. If your tooling reads the version from package.json rather than from git tags, expect it to disagree with the release you downloaded.

Upgrade cost depends on how far you have diverged. Because there is no build step for the editor, an upgrade is largely a matter of replacing libs/builder/ files and re-checking your component definitions and any scss you compiled. The submodules are the part most likely to bite: the README's clone instructions use --recurse-submodules, so a plain git pull without that flag can leave the demo and template files stale.

Editorial conclusion

Adopt VvvebJs if you want a Bootstrap 5 editor embedded in your own page and you already run PHP or Node for saving. Skip it if you need a hosted builder or a serverless save path, because save.php and save.js are the only save mechanisms the README describes. Before committing, clone with --recurse-submodules and confirm that demo/landing and the components scripts load in your target browser, since the library depends on those submodules being present.

Frequently asked questions

Official sources

1. givanz/VvvebJs on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases