An Embeddable Drag-and-Drop Page Builder for Your App
If your roadmap has "let users design their own pages" on it, you already know the trap: a visual editor is three to six months of drag handles, undo stacks, responsive controls, image uploads, and serialization — work that has nothing to do with your actual product. BuilderJS is the part you were about to rebuild. It's an embeddable drag-and-drop page builder you mount into any DOM node — React, Vue, Svelte, Angular, Next.js, Laravel, or plain HTML — as a roughly 140KB vanilla-JS bundle. It ships 42 element types, 59 controls, and 31 overlays out of the box, and it's JSON-first: getData() and load() give you a lossless round-trip you store wherever you like. It builds both web/landing-page HTML and Outlook-safe email HTML from the same canvas. You buy it once on CodeCanyon, get the source, and self-host it. No SaaS dependency, no per-seat billing, no usage meter phoning home. The editor lives in your app, on your terms.
Mount it where your app already lives
BuilderJS is framework-agnostic by design: it's a DOM-mount bundle (dist/builder.js + dist/builder.css), not a published npm React or Vue component. You hand it an empty element and it takes over from there. In React you initialize it inside a useEffect; in Vue inside onMounted; in Angular inside ngAfterViewInit; in Svelte inside onMount. It runs client-side only, so in Next.js you load it with a dynamic import using ssr:false and a 'use client' directive. Persisting a design is deliberately boring — and that's the point: call getData() to get the JSON, POST it to your own route or backend, and call load() to bring it back. Because the editor is closure-captured, there's no global state to leak between tenants. BuilderJS is multi-tenant capable, but your application keeps owning tenant isolation, seats, and billing — which is exactly where that logic belongs.
One editor, two outputs: pages and email
Most teams discover they need both a landing-page builder and an email designer, then bolt on a second tool. BuilderJS produces both from one canvas. For web, it emits clean page HTML. For email, the EmailExportPipeline converts your design into Outlook-safe markup: flexbox layouts become tables, SVGs are rasterized to PNG, @media rules stack columns on mobile, and MSO conditional comments plus a CSS inliner handle the rendering quirks that make email HTML notoriously painful. To prove it, the library ships 30+ templates and 200+ samples that have been Litmus-tested across 22 email clients. Worth stating plainly: BuilderJS builds the email markup — it does not send it. You bring your own ESP or SMTP for delivery. Same for pages: BuilderJS produces the HTML; your app handles hosting and publishing.
Extend it without forking
A builder you can't customize becomes a liability the first time a customer asks for something it doesn't do. BuilderJS is built to be extended without touching its source: register your own custom Elements, Widgets, and Controls through Builder.registerElement, drop in custom themes, and localize the UI with i18n across 20+ locales including RTL. If your product has AI features, the builder exposes pluggable, vendor-neutral AI hooks — you wire in whichever model you use, rather than being locked to one. Because you own the source from your CodeCanyon purchase, nothing about this depends on a vendor shipping the feature you need. You can read it, patch it, and ship it on your schedule.
Own the source — no metered SaaS in your critical path
The honest comparison here is with the embeddable-editor market, not with end-user platforms. GrapesJS, the well-known open-source builder framework, is free under the BSD-3-Clause license (per github.com/GrapesJS/grapesjs, as of June 2026) — but free and finished are not the same thing, and assembling a complete, supported, framework-agnostic editor that builds both email and pages from its primitives is the very three-to-six-month effort you're trying to avoid, which is why its own team now offers the commercial Studio SDK. That SDK is session-metered SaaS: a free tier at $0/month capped at 1,000 sessions with Studio branding ($50 per extra 1,000 sessions), then Startup at $200/month (20,000 sessions, $20 per extra 1,000) and Business at $2,000/month (50,000 sessions, $10 per extra 1,000), per grapesjs.com/sdk/pricing as of June 2026. BuilderJS takes the opposite stance: a one-time CodeCanyon license (item 27146783, Regular $52 / Extended $99) for the source, which you self-host. No monthly fee, no per-seat charge, no session metering, no phone-home. The trade-off is honest: author support is time-boxed (roughly 6–12 months), so you're buying source you own and maintain — not an ongoing managed service.
What you actually ship versus what you build
Embedding BuilderJS reframes the work. The editor canvas, drag-and-drop, the 42 elements and 59 controls, undo/redo, responsive editing, the lossless JSON model, and the dual page/email export are done. What stays yours — and should — is the surrounding product: authentication, where designs are stored, how tenants and seats are organized, and how finished output gets used downstream. To make that wiring concrete, BuilderJS includes reference PHP backends (MySQL/SQLite/S3 for save, upload, and auth) that you copy and own outright; if your stack is Node, Go, or Python, they're a clear blueprint to port. You can try the editor itself at the live demo, builder.emotsy.com, before you write a single line of integration code.
Frequently asked questions
-
Is BuilderJS a React or Vue component I can npm install?
No — and that's intentional. BuilderJS is a framework-agnostic DOM-mount bundle (dist/builder.js + dist/builder.css), not a published npm React/Vue/Angular component. You mount it into any DOM node from your framework's lifecycle hook: useEffect in React, onMounted in Vue, ngAfterViewInit in Angular, onMount in Svelte. It runs client-side only, so in Next.js you load it with a dynamic import using ssr:false plus 'use client'. This is why it works the same in React, Laravel, or plain HTML without per-framework packages.
-
Can BuilderJS send the emails or host the pages it builds?
No. BuilderJS is the editor you embed, not a platform. It builds page HTML and Outlook-safe email HTML, and gives you the markup via getData(). Sending email is your ESP or SMTP; hosting and publishing pages is your app. BuilderJS produces the template and markup — delivery and hosting are yours to bring. Keeping that line clear is what lets it stay a lightweight, embeddable library instead of a service you depend on.
-
How do I save and reload what a user designs?
Through a lossless JSON round-trip. Call getData() to serialize the current design to JSON, then POST it to your own route or backend and store it however you prefer. To restore, pass that JSON back into load(). Because the editor state is closure-captured rather than global, there's no shared state leaking between users or tenants — your app controls where data lives and who can see it.
-
Can I add my own elements or translate the UI without forking?
Yes. You register custom Elements, Widgets, and Controls via Builder.registerElement, apply custom themes, and localize the interface using built-in i18n across 20+ locales with RTL support. There are also pluggable, vendor-neutral AI hooks if you want to wire in your own model. Since the CodeCanyon license gives you the source, you can also patch internals directly — but the documented extension points mean most customization never requires touching core.
-
How does the one-time license compare to a metered SDK?
BuilderJS is a one-time CodeCanyon purchase (item 27146783, Regular $52 / Extended $99) for source you self-host — no monthly fee, no per-seat charge, and no session metering. By contrast, the GrapesJS Studio SDK is session-metered SaaS: a $0/month free tier (1,000 sessions, Studio branding) scaling to Startup at $200/month (20,000 sessions) and Business at $2,000/month (50,000 sessions), per grapesjs.com/sdk/pricing, as of June 2026. The honest trade-off with BuilderJS is that author support is time-boxed (roughly 6–12 months): you own and maintain the source rather than paying for an ongoing managed service.