Plasmic vs. other tools

What sets Plasmic apart

Plasmic is a platform containing:

  • Visual page builder that can drag and drop your code components—this is the “heart” of Plasmic.
  • Headless content management system.
  • Growth optimization suite.

What sets it apart from other tools like website builders and pure headless CMSes:

  • Focus on cross-functional collaboration. Empower marketers, designers, content teams to directly edit the website, and free up developers from content/pixel-pushing.
  • Deep integration into website and app codebases. You can use components from your codebase. You can publish to any tech stack. And you can easily augment your designs with code.
  • True no-code tool. You can create production-grade experiences in Plasmic without depending entirely on developers.
  • Unparalleled visual control and power. While it’s easy to start with, Plasmic gives you tools never before been seen in any design tool or page builder to let you create maintainable frontends at scale.
  • Total ownership. You truly own your code and have the freedom to host or deploy it anywhere.

Plasmic vs. drag-and-drop site/page builders

Examples: Wix, Webflow, Squarespace, Shopify, Shogun, PageFly, Unbounce, Instapage, Hubspot.

Plasmic includes a free-form visual builder. You can create components, pages, or entire websites within Plasmic.

All other website builders are end-to-end platforms. If your needs fit within their “walled garden” for the foreseeable future, they are a great solution.

However, many organizations have requirements preventing them from committing to such platforms for their website or app, or they want a more open-architecture solution. Plasmic focuses on flexible integration into arbitrary codebases and complex environments.

Concretely, this flexibility lets you:

  • Use any custom components from your codebase or from npm.
  • Restrict editors to using specific components for your page sections and design system.
  • Integrate flexibly and incrementally with existing codebases and development teams.
  • Maintain freedom over choice of hosting, CMS, SEO, analytics, frameworks, CI/CD, and your general tech stack.
  • Build arbitrarily complex applications and websites (such as Plasmic itself, which is built in Plasmic). Plasmic is designed to work seamlessly with custom code.

Beyond integrations, Plasmic as a page builder and design tool has a very rich set of features not found in most other tools, such as:

  • Multiplayer.
  • Components, with variants and slots.
  • Best-in-class layout system (that doesn’t just throw all of CSS layout at you).
  • Style tokens (reusable style values) and mixins (bundles of styles).
  • Design simultaneously across multiple screen sizes and variants.
  • Build apps as well as websites (advanced use case).

Plasmic vs. vector drawing tools

Examples: Figma, XD, Sketch.

These are great vector drawing tools for exploratory design and mock-ups. You can use them together with Plasmic—when your designs are settled and you would normally hand things off to developers, you can instead build them in Plasmic. For Figma specifically, Plasmic provides a Figma importer.

That said, you can absolutely use Plasmic starting in the design phase. Plasmic’s UI is designed to be familiar to users coming from vector design tools. You can even start all the way from simply drawing wireframes without worrying about layout—Plasmic gives you a smooth path to refining these into production-ready assets.

Plasmic is not as polished as dedicated vector drawing tools for creating pure design mock-ups. The main reason is that Plasmic is not yet as fast at raw editing speed. For instance, it is missing features such as multi-select, and its free-form drawing capabilities are more limited.

However, Plasmic does have powerful abstractions (how it represents components, slots, variants, tokens, mixins) that can let you work as fast or even faster than relying on direct manipulation. Plasmic as a design tool has a number of other advantages as well:

  • With code components, use your real design system from your codebase, use production data, or add arbitrary interactive effects.
  • Take designs all the way from mock-ups to production. Publish directly and eliminate handoffs.
  • What you see is guaranteed to be what you get in production. Design within the real constraints and capabilities of the final medium.
  • Build rich, responsive designs with a full set of layout features. Vector drawing tools often have a small subset of the layout that production assets need.
  • Plasmic’s abstractions (how it represents components, slots, variants, tokens, mixins) are significantly more maintainable and scalable. Vector drawing tools are optimized for quickly “faking things” and place less emphasis on structure.

Plasmic vs. headless structured content management systems (CMSes)

Examples: Contentful, Sanity.io, Strapi, GraphCMS, Prismic, Storyblok.

Plasmic includes a (headless) CMS for structured content/data, like a set of blog posts, testimonials, products, etc.

Whether you use the built-in CMS or another CMS, Plasmic’s visual page builder complements CMSes, rather than replaces them. You can manage your blog posts in a CMS, while designing your landing pages in Plasmic. With code components, you can drop in a section that renders those blog posts or other data from your CMS (or any other data source, such as a Shopify product catalog). You can even design your blog page template in Plasmic.

(Plasmic provides integrations with headless CMSes including Contentstack, Contentful, Sanity, Strapi, and GraphCMS.)

Sometimes, headless CMSes are used to also build pages. Some CMSes, such as Prismic and Storyblok, market “visual editors” that let you preview the page you are building.

Regardless, these ultimately work the same way fundamentally:

  • Developers must create a schema representing the different possible configurable sections of a landing page.
  • Developers must code up the template sections that these will render as.
  • Content editors must build the pages using this schema of nested forms. (Sometimes this is from a sidebar next to the main pane where a preview of the page is shown.)

Plasmic can be used in this way as well—it lets you drag and drop code components/sections authored in your codebase, so you can use it as a “section configurer” as well (including restricting editors to this). However, Plasmic provides a superset of this functionality, since unlike CMSes, it is a true no-code platform.

Some of the implications of the headless CMS approach to page-building:

  • Your pages must be 100% authored in code by developers, as template-ized building blocks. This means more code to write, maintain, and update. Plus the need to understand page performance best practices, animations/interactive effects, and more. For things like landing pages, this tends to be highly rote and undifferentiated work.
  • Developers must design a schema that balances giving the marketer enough flexibility to express the page they want, while managing the complexity/usability of the page builder. And then developers must write an interpreter for this structured data to render it into markup. (For instance, how to design a schema that lets you build a page that contains a section that contains an accordion that contains a paragraph with an inline CTA button that opens up a modal.) Developers are effectively implementing a page builder—one where users are filling out nested abstract forms to build the page.
  • Content editors must be trained to think and work in this way—filling out nested abstract forms to compose the sections of a page, and learning about the quirks of any particular schema.
  • If you want to make even simple changes like introducing an extra call-to-action or tweaking some layout—let alone bigger changes, like a new style of landing page—this all lands at developers’ feet and must wait for development cycles to ship.
  • Sometimes dev teams invest in building extensions for the CMS platform to make it easier to build pages for their specific site on top of the provided built-in abstractions.

On the other hand, Plasmic is a true no-code platform, meaning non-developers can make free-form content changes without code (while guardrails can still be provided). Add a Plasmic API call from your site’s codebase, and from then on, content teams can directly publish pages or parts of pages. The editing experience is visual and intuitive, and requires no schemas, templates, or developer involvement. This fits especially well with designing pages that have responsiveness, flexible layouts, interactions/effects, and so on.

If you do want to give content editors a simplified and more restricted editing experience, you can use Plasmic’s “content creator mode,” which offers a simplified visual editor and restricts page-building to using the existing components (whether code components or Plasmic components!). Plasmic has a sliding scale that lets you offer a spectrum between this “locked-down, CMS-ish page editor” and “full-power no-code tool.” It furthermore lets you mix-and-match—for instance, maybe for certain pages on your site, you want to enforce more stringent design consistency, but for net-new landing pages you want to enable free-form design.

Plasmic vs. design-to-code tools

Examples: Anima, Supernova.io, BuilderX

There exist various open and closed source tools that try to convert designs from design tools (such as Figma/XD/Sketch) into code.

These are one-shot tools that let you copy/paste the generated code into your codebase. As soon as you add your own logic, you diverge from the original generated code. You cannot iterate further on the design, which highly limits their applicability for most real-world products.

While Plasmic can also produce plain React code to let you eject, Plasmic’s primary codegen scheme lets you continuously make changes both to the design and to the code.

Beyond this key difference, Plasmic also prioritizes clean, production-grade code generation and render performance (core vitals). We do not (for instance) render large sections of your design as images!

Furthermore, Plasmic’s Figma importer lets you import from Figma into Plasmic with extremely high fidelity, supporting all layout/constraints, transforms, blend modes, filter effects, and more.

Plasmic vs. prototyping tools

Examples: Framer, ProtoPie.

Prototyping tools have significant overlap with vector design tools, but are focused on mocking up what an interaction looks like. For instance, if you are exploring or communicating what a microinteraction animation should look like, or if you are creating a click-through sequence of screens for user testing or communicating a design, prototyping tools are great.

The distinction is that prototyping tools:

  • are not built to ship to production (for instance, does not use real layout, does not use normal HTML elements, etc.).
  • are not designed to integrate deeply and naturally with production code or developer workflows.
  • do not focus on design tool features that enable a design to be quickly and maintainably built at scale (tokens, mixins, etc.).
  • do not let you seamlessly tap into your real production code components for the design system, production data, or arbitrary interactive effects.

See for instance Framer’s own elaboration on why not production.

Plasmic vs. internal tool builders

Examples: Retool, Budibase, Appsmith, internal.io.

These are useful for quickly slapping together the frontends for internal dashboards and tools. Unlike Plasmic, these tools typically don’t have deep support in customizing the visual design. They provide a fixed set of rich components (for example, editable data grids), which you can link together through logic specified within the visual editor.

What these have in common with Plasmic is that these also typically focus on just creating a frontend, and on connecting to existing backend data sources.

Plasmic does not yet focus on internal tool building, or on specifying behavior within the visual editor. Plasmic technically already supports the app-building use case in the form of code components, but you have to bring your own components and data integrations.

Plasmic vs. visual editors in IDEs

Examples: XCode SwiftUI design tools, Utopia

These are highly technical tools that are exclusively for developers, presenting code and design side-by-side. These tools also need to limit themselves to subsets of editing. Modern declarative UI frameworks encourage arbitrary code-as-UI, and so at most, these tools position themselves as an optional convenience/supplement to writing code. The user invariably must be able to edit the code to make any significant changes, particularly when dynamic state or parameterization is involved.

These tools also tend to focus exclusively on a single platform or language.

Plasmic instead is designed to be usable by non-developers as well as developers. Its main use case is to empower non-developers to create designs and content that ship into a web application that would otherwise require handwritten code. These designs can use custom components from codebases, and can be published into codebases, but Plasmic users don’t need familiarity with code or be highly technical in order to create content. Plasmic doesn’t try to mix logic and presentation; it actively segregates these concerns.

That said, many developers do use Plasmic as a UI builder for applications. This includes Plasmic’s own team—Plasmic is built in Plasmic! Developers can use simplified CSS layout, enjoy instantaneous feedback, design across screen sizes and states, build with rich abstractions, allow designers to make changes, and much more.

Give feedback on this page