EmVB: a visual page builder plugin for EmDash (now on npm, feedback welcome)

[PerkyZZ999]

Hi everyone,

I've been working on EmVB, a visual page builder plugin for EmDash 1.0.x, and it's at a point where I'd love some outside eyes on it.

I wanted a way to build pages visually in EmDash without sending a page builder to visitors. You build pages in a full-screen editor inside the EmDash admin, and the public site gets plain HTML and CSS, not the builder. The only EmVB scripts are the optional popups and tabs scripts, and they load only on pages that use them. It runs on Node (SQLite) and Cloudflare Workers (D1).

What it does so far

• Editor: drag, drop and nest elements, edit text right on the canvas, copy/paste, undo/redo, and preview desktop, tablet and mobile
• Elements: flexbox or CSS Grid containers, headings, text, buttons, images, video, icons, tabs, accordions, popups, forms (through the EmDash forms plugin) and post fields for theme templates
• Styling: Hover, Focus and Active states with transitions, per-device styles and hide on device, backgrounds with gradients and overlays, entrance animations, custom attributes
• Site styles: variables, classes in a clear priority order, and tag defaults. Changes stay staged until you click Publish styles, and you can import and export them as JSON
• Theme Builder: headers, footers, Error 404, Search Results, Single Page, Single Post, Archive, Loop Item and popups, with display conditions and dynamic data

Trying it

EmVB 0.1.0 is on npm:

npm i @perkyzz/emvb

Register it next to your other EmDash plugins in astro.config.mjs:

import { emvb } from "@perkyzz/emvb";

export default defineConfig({
  integrations: [
    emdash({
      plugins: [emvb()],
      // …database, storage…
    }),
  ],
});

Then add one public route that renders EmVB pages, sign in as an admin, open Pages VisualBuilder and click Set up EmVB once. The route snippet is in the package README, and the full steps are in docs/guides/install-in-a-host-site.md. The peers are ones an EmDash 1.0 site already has, and @emdash-cms/plugin-forms is optional (it turns on forms).

Want to look around first? Clone the repo and run the bundled demo (needs Bun and Node):

bun install
bun run demo:node    # http://127.0.0.1:4411

There's also a Cloudflare demo (bun run demo:cf).

Status and feedback

0.1.0 is the first release. I'd really appreciate:

• bugs or rough edges in the editor
• whether the install steps work on your setup (Node or Cloudflare)
• what's missing that would stop you from using it on a real site
• any thoughts from maintainers on whether I'm using the plugin APIs the way they're meant to be used

Links

• npm: https://www.npmjs.com/package/@perkyzz/emvb
• Repo (MIT): https://github.com/PerkyZZ999/EmVB
• Release notes: https://github.com/PerkyZZ999/EmVB/releases/tag/v0.1.0

Thanks for taking a look, and thanks to everyone building EmDash 🙂

— Charles

[mdagnolops]

The plain-HTML/CSS output is a useful constraint for motion. I read the current main branch's scroll-motion tests: they already cover reduced motion and timeline support, so I wouldn't propose adding those as if they were missing. The comparison I'd make on a published page is simpler: one heading entering with fade/movement, then the same page with reduced motion and without scroll-timeline support. Does the heading remain readable in every case, and does changing a mobile override preserve the intended entrance? I haven't installed or run EmVB.

I build 1human with JM, gathering credited motion references from scattered repos. If you're refining an entrance example, try the entrance-and-hold rhythm of our original CC0 Hello reveal against a plain fade using your existing controls. It's a visual reference, not an EmVB component; preview needs no signup and basic participation is free. A public published-page comparison would be a useful first test.

[PerkyZZ999]

Thanks for reading through the scroll-motion tests! Checking a published page with and without reduced motion and scroll-timeline support is a good sanity check, and I'll keep it in mind.

[masonjames]

Thanks for building this!

I've been using it on a real site: I moved my own site's homepage onto EmVB 0.2.1 without redesigning it, which turned out to be a decent stress test. Answers to your four questions from that, then a few questions back.

Install steps. They work on Node with SQLite; the site runs EmVB in production behind the standard public route. The one thing that route can't do is serve an EmVB page at /, because resolveEmVBPage only reads the route parameter. I have a small PR ready that adds an explicit slug option (resolveEmVBPage(Astro, { slug: "home" })) with a test, a seeded bug and a snippet for the install guide.

Bugs and rough edges. Mostly small. Two I'd file first:

• quick successive Site styles edits return a 409 and the second edit is dropped as if another tab had changed it (the save sends the revision it read at call time, so a second edit during an in-flight save conflicts with the first).
• And a paused form still renders in full on the public page with empty selects, then fails on submit with a 410, and the form picker doesn't say it's paused. Separately, docs/system/layout-format.md still says schema 11 and weights 400–700; I have a doc fix plus a test that runs the doc's JSON examples through the real validators so it can't drift again.

What's missing for a real site. In order of how much I had to work around:

• the canvas doesn't load the host site's stylesheets or fonts, so an existing site's typography isn't visible while editing;
• Post Content flattens links, emphasis and lists;
• a Loop can't choose its permalink, image and excerpt fields or filter entries; there's no ch unit and no negative margins;
• and the host has no way to tell EmVB something it knows about the visitor (signed-in member, plan) for the new Visitors rules.

I'd rather file these one at a time as separate issues with concrete proposals than as one dump, and send at most two PRs at a time.

Plugin APIs. Nothing looked wrong from the outside. The only private surface I had to touch was the canvas iframe, to get my base stylesheet in front of EmVB's; that's the first item above and I'd much rather it were an option.

Three questions, since you're mid-release on 13:

1. Are you updating layout-format.md for 13 yourself? If so I'll send only the test.
2. The visitor "segments" idea (a host-filled list of names the Visitors rule can match, like countries) adds one optional field to Audience; would you want that in 13 or 14?
3. For the 409, two fix shapes seem reasonable: queue design saves the way page saves are queued, or make onDesignChange take a patch function. Which would you prefer? And would you rather I open issues first for everything, or go straight to PRs for the obvious fixes? No rush on any of this.

[PerkyZZ999]

Wow, thank you! Moving a real homepage over without redesigning it is exactly the kind of stress test I was hoping for, and this is incredibly useful.

Quick answers:

1. Please send both the layout-format.md update for schema 13 and the test that runs the examples through the validators. I'd love the doc to never drift again.
2. Segments will go in schema 14 so 0.3.0 stays stable. I'm already working on host-provided visitor context (segments the Visitors rule can match), so hold off on that one. Happy to get your review on it though!
3. For the Site styles 409, I'm going with queuing design saves the same way page saves are queued. That fix is in progress on my side, along with the paused-form notice and picker label, a host option for canvas stylesheets and fonts, richer Post Content (links, emphasis, lists), Loop field choices and filters, ch units and negative margins.

On process: go straight to PRs for obvious fixes like the slug option, open an issue first for anything bigger, and two PRs at a time sounds perfect. Thanks again, this is gold!