PlasmicLoader vs. Codegen

Turning your designs into production code is Plasmic’s flagship capability. Plasmic has two methods of consuming designs built in Plasmic from your codebase:

Codegen

You use the Plasmic cli (plasmic sync) to pull Plasmic-generated React code directly into your git repo. You treat the generated code just like any React code — it is checked into your git repo, versioned with git history, and deployed by your usual pipelines. As “just code”, you can review, test, deploy, and rollback design changes just as you can any code changes.

However, that means whenever you want to deploy some design changes to production, you’ll need to run plasmic sync to generate new code, create a git commit, possibly go through code reviews, merge the commit into main branch, and deploy as usual. Because the Plasmic-generated code lives in your codebase, deploying changes necessarily involves developers who have access to work through this workflow. Depending on your use case, this may be fine, or too heavyweight.

PlasmicLoader

(Currently for Gatsby/Next.js only)

You use a special PlasmicLoader component for rendering Plasmic designs, like this:

<PlasmicLoader
  // name the component you want to render
  componentName="LandingPagePromotion"
/>

Developers only need to insert the above one-time snippet into the right place. From there on out, PlasmicLoader will just always fetch the latest designs from Plasmic when you build the Gatsby / Next.js site; no Plasmic-generated code is checked into your git repo. That means whenever you want to deploy some design changes to production, you just need to trigger a re-build of the Gatsby / Next.js site, which will pick up the latest changes, without involving developers.

Which scheme should you use?

The main trade-off to consider is whether you want Plasmic-generated code to live in your git repo. If you do, you benefit from the typical tooling and processes that come with working with code, but likely require a developer touch point to deploy design changes. If you don’t, then you lose out on the tooling, but gain the ability for non-developers to deploy design changes directly to production. We consider both PlasmicLoader and codegen to be important but different methods of consuming Plasmic designs in production, and each is best-suited for different workflows and use cases.

In short, PlasmicLoader makes it possible for non-developers to push design changes without ongoing developer involvement. We believe it is a great workflow for projects involving mostly static designs, where designers / marketing / etc want to be able to deploy changes made in Plasmic without involving developers. These are similar workflow benefits to adopting a CMS — PlasmicLoader lets you use Plasmic as a CMS that gives you full visual control and page-building capability.

You should consider using PlasmicLoader if you:

  • Are building mostly static designs that don’t require heavy code instrumentation (static websites, promotional banners, etc.)
  • Want to make design changes in Plasmic without going through the typical code commit workflow, so that non-developers can easily get their changes deployed without involving developers
  • Prefer or don’t mind having generated Plasmic* code living outside of your git history

You should still use codegen if you:

  • Are building a dynamic app with a lot of code instrumentation (via overrides passed to Plasmic* components)
  • Want generated Plasmic* files to be checked into your git repo, as part of your git history
  • Don’t mind having to go through the typically developer-owned workflow of running plasmic sync, creating a git commit, merging into main, etc. when you make design changes in Plasmic
  • Are not using Gatsby / Next.js