I have been using Plasmic for the last 3 months as part of a contract app where the goal was to get the technical, but not frontend experienced client able to do a lot of the design. I did a lot of custom work on components (like integrating the Supabase API and custom Auth for RLS support) as well as integrating some other endpoints/libraries.
In short, I have gone pretty deep with it as a proper "app" builder compared to maybe a more CMS/design use case. By far, for front-end low code UI tools it is my favorite. However, it isn't without the typical pains of that when the abstraction breaks it can be quite a hassle and requires some real knowledge (or support help) to figure things out. The real thing that keeps me on it though is that it really can have hand written react and Plasmic generated react live by side, which drastically lowers the risk compared to a lot of other app builders.
I do genuinely think it can speed up development for certain teams on app use cases, but I think the structure of those teams is a bit particular, because you do need someone who really knows react/next ecosystem to manage the underlying integration.
> you do need someone who really knows react/next ecosystem to manage the underlying integration.
So this is react specific? It doesn't say so in the home page. It vaguely hints at it with a "Bring your data sources, React components, deployment environments, design system, and more.".
While Plasmic does offer the flexibility to export designs to other frameworks like Angular, Vue or even plain HTML, it is mainly targeting React. Some features, such as the ability to register custom components from the user's codebase, are React-specific.
Is the project open to contributions for supporting other frameworks? I'm interested in Blazor specifically, which is based on HTML. Do you see this becoming a pan-framework "design mode" tool? Do you think it's architected for that? A related question is, is it easy to use it for client-side-only stuff and leave the backend alone?
> is it easy to use it for client-side-only stuff and leave the backend alone?
Yes - using Plasmic to manage landing pages design and content is our main use case!
We still need to improve the experience for open source contributions, but we are open to that! That being said, React is still our main priority at the moment.
I'm not familiar with Blazor, but you may also explore our render API (https://docs.plasmic.app/learn/render-api/). It allows fetching rendered HTML from Plasmic servers, then you would just render it in the DOM.
That omission jumped out at me too. I immediately googled "django plasmic" and had to find out from the Github repo title: "plasmicapp/plasmic: Visual builder for React. Build apps, ..."
I don't understand why tools like this "pick a winner" with a specific framework instead of rendering to Web Components with a framework wrapper, or using something like Stencil[1] that can render to any framework.
It really depends on how well you want the design to integrate with your codebase, which is where most of Plasmic power lies on, such as: leveraging your existing custom components as building blocks within the design tool; or adding heavier instrumentation to props and rendered contents on the code side.
It is possible to use Plasmic's render API (https://docs.plasmic.app/learn/render-api/) to fetch the rendered HTML and just render your designs using any framework, but that means it's a more limited experience.
We wanted to support tight integration with people's existing codebase, so that it is easy to use your React components directly in Plasmic, or to read data from your React contexts provided from outside of Plasmic, or to have your code components communicate with each other via React contexts when they're used within Plasmic, etc. There's power in being in "one React tree" with your existing app.
I imagine it's possible to achieve this with other frameworks too, though the integrations would be deep and bespoke for each framework. We've just decided to focus on React first.
Sure, though if you had selected Web Components as the base implementation, you could have achieved that goal while also being compatible with almost every other framework. See Ionic for a great example of this.
There are several lightweight wrapper libraries to "reactify" web components.
Going the other direction is not as easy. While it's possible, it involves loading all of react into another framework.
The generated react living alongside custom react sounds similar to MUI's low-code drag-n-drop editor that they're working on (https://mui.com/toolpad/).
Looking at the demo, does Plasmic have any killer features that MUI's offering doesn't? At the moment, MUI's main limitation is that it can't connect directly to a database: you have to go through an API, or write an API route for each app that proxies the SQL queries.
MUI's Toolpad looks pretty cool! I'm going to try it out today.
One big difference is that Plasmic is a platform and can be used by non-developers to make changes that go straight to production. Think marketers, content managers, and other non-devs that are on your team who want to ship new designs and content without bugging the dev.
I also started using Plasmic exactly 3 months ago and accomplished now one client project with all the backend/auth/frontend integrations entirely using plasmic. I agree with you that this is a great tool, that is far beyond other known builders and low-code solutions.
I'm curious about your approach to integrating APIs with Plasmic. Did you utilize Plasmic's backend integrations, or did you prefer a client-side fetcher?
In my case, I found that using backend integrations through Plasmic's servers resulted in noticeable latency issues, with response times varying between 1 to 3 seconds, which was quite slower compared to direct API calls that took no more than 200ms. Have you encountered similar challenges?
On another note, while the client-side Fetcher was a potential alternative, it fell short in several areas for my needs. Specifically, it lacked options for customizing SWR fetch options, built-in mutation support, and accessible state management. To address some of these issues, I've made a contribution through a pull request: https://github.com/plasmicapp/plasmic/pull/102. I thought it might be of interest to you. I would love to hear your thoughts on this and any insights you might have based on your experience.
I am using custom components for all data fetching which primarily wraps the supabase JS sdk. I have some issues I still need to make a bit more robust around caching and invalidation, but the Supabase JS sdk does help some.
I do think that is another weakness right now is the built in plugins aren't quite sophisticated for a lot of real use cases
It looks very nice for exploring the large design space of what UI an app needs, and actually laying it out. I think in terms of the backend, but the gap to visualize what the frontend needs like can be large; the blank page stares back so much. Hoping something like this can help.
Balanced viewpoint here. Good writeup. Got potential. In my view looks solid in certain use cases e.g. websites, mobile apps and for rapid prototyping. Step in the right direction (open sourcing) for Plasmic i think.
Basically, it's a visual page builder that plugs into your own Next.js/Remix/React/etc. codebase. Your marketing/content/design team can then build and publish pages without filing tickets on eng. This (content management) is the main use case.
The most interesting aspect is that editors can drag and drop React components from your own codebase as building blocks. This is very powerful, esp. with e.g. data fetching React components.
Why open source? Because we love the tool. Plasmic has been in production deployment at companies big and small. But we think it can grow far beyond ourselves as an open source project. We’d love to see a broader community take it in unexplored directions. Community users have even started using it to build emails with React.Email and mobile screens in React Native.
I think another thing interesting about Plasmic is that it is a bit ambitious in trying to combine some seemingly disparate genres:
- Webflow, Wordpress and other page builders
- Retool and other tool builders
- Glide and no-code app builders
- Contentful and other CMSes
Today these are different tools to specialize in, but the line between, say, a website and an application is blurry (consider an ecommerce storefront with user logins, or a customer portal). With the right foundations, we think these can be unified—Plasmic’s UI can adapt to different levels of control for different personas/tasks.
So a newer use case is that you can use it to build applications as well as websites, for both developers and non-developers. This is the more experimental side of the project, beyond the content management use case.
All things considered, they seem pretty similar - visual UI to generate React code that works alongside existing codebase, open-source & self-hostable, etc.
Congrats on going open source! Which components are open sourced specifically? Is there any chance it will be self-hosteable? I don't want to host it myself any time soon but I prefer giving my money to a company where that's an option.
You can think of it like that - GrapesJS ultimately outputs HTML that exists in its own universe, whereas Plasmic focuses more on integrating with existing codebases, where you might want to use your React components, render in your React context, etc.
I talk about the "why" a bit above, but we've talked about how to open source it internally since almost its inception, but there's work involved in open sourcing that we just had to prioritize like any other work item, as well as concerns around whether we were ready to support it (for instance, in light of rapidly changing code and data).
Framer has a great UI builder, but doesn’t connect to backends very well. They have their own CMS but the net result is that you typically use it for marketing sites but not business app interfaces.
Retool can connect to a lot of different data sources but is ugly and wouldn’t help build a customer-facing app that I would feel proud of. They give you easy to use UI primitives to get you up and running fast.
This seems like a UI builder that can hook into backend systems.
Yes, in a way! Plasmic is a general visual React app builder that can be embedded into your existing React app or be deployed standalone. As such, we place a heavy emphasis on _design_, so you can build exactly the thing that you want, and on _integration_, so you're never limited by what Plasmic can do out of the box. A big part of this is being able to use your own React components in your Plasmic designs, which is a major escape hatch that lets you include any amount of data fetching or business logic that can be consumed by your Plasmic designs.
I think they're trying to invent a new market where none exists yet, and when you do that you HAVE to communicate very clearly. Basically I think they're a WYSIWYG editor for a React SPA. For me, this section helped:
For component composition and layout, Plasmic makes it easy to build responsive pages. Our primitives like stacks are all based on flexbox, though you can use absolute positioning if needed.
Plasmic at its core is a general React app builder. You can create components, add interactivity, and connect to other data sources. You can also bring in your own React components, so there's endless possibilities in extending the tool for your needs.
Our users have used Plasmic to build all sorts of things, from websites and e-commerce storefronts, to Retool-like internal tools, to full web apps (major parts of the Plasmic visual editor itself is built with Plasmic!). The most popular use case we have is as a CMS -- once developers set up Plasmic, the marketers are able to design and publish sections of the website without developer involvement. One remarkable thing is that the dynamically-fetched Plasmic-generated design is part of the same React tree as the rest of your React app, so it is able to read from your React contexts, etc., making it possible to have rather deep and interesting integrations into your site.
Ultimately, Plasmic generates React code from your designs. This code can either live in your code base alongside the rest of your code, or be dynamically fetched (like in the CMS use case).
Basically, you set up a "custom app host" -- stand up your server (which has your code components), and you add a route (say `https://yoursite.com/plasmic-host`) that renders a special `<PlasmicCanvasHost/>` component. When you open a Plasmic project that uses your custom app host, it loads your `/plasmic-host`, and the `<PlasmicCanvasHost/>` component bootstraps the Plasmic visual editor into the page. So now Plasmic studio is actually running on your page, and it can access your code components that you have registered to be used with Plasmic. We never see your code; it's a run-time integration.
No, if you use codegen, you should register your component by providing additional necessary metadata, like importPath, importName and others. Then you can use you component in the Studio same way like other builtin components. Check https://docs.plasmic.app/learn/code-components-ref/ for more details.
It's a visual page builder that integrates with React codebases. Content management is our biggest use case - i.e., dev team integrates with Plasmic, and then marketing/content/design teams can create landing pages on the marketing site.
(A newer use case is building applications as well, hence some of the comparisons with Retool etc. There's actually quite a bit of overlap between these use cases, esp. when considering external-facing "customer portal"-style applications.)
I've been using Chakra UI components in Plasmic for around 1 year after trying to do this in Framer and UXPin Merge. Plasmic is what Framer was hyped to be but did not deliver, it's the best I have found.
The downside to Plasmic has been the community size and therefore lake of support so I hope Plasmic going open source will resolve these issues.
These types of tools can be overlooked by traditional siloed Design and Development, and is best suited to hybrid teams were the power of designing with code components can be realised.
Plasmic was like discovering a Gem, a rough diamond that a hybrid open source community get the chance to shape.
I'd add that our current workflow is to complete our webapp designs using code components and deploy via Vercel as a prototype. Later we aim to publish production directly from Plasmic. These little steps are addressing cultural issues mostly, a the idea of a design team publishing the FE touching a lot of cultural issues and fears like reporting lines, processes, job loss - change is scary.
This doesn't quite hit the sweet spot for me, yet, but I really wish something described the exact output of this app. Is it a react app, always? Or can it be just a vanilla js-based web app? Can it make svelte components?
Just a sample of the output would go a very long way in telling me whether or not it can produce anything I can use.
Right now Plasmic mainly target outputting React components. The code it generates can either be consumed as files you check into your codebase (see https://docs.plasmic.app/learn/codegen-guide/) or as data you fetch dynamically across the wire to render content without touching your codebase (the "CMS" use case).
Plasmic is by far the best kept secret in the no-code industry. Having built apps on Bubble, Flutterflow and a few other platforms, Plasmic takes the cake hands down. It is great for complex apps and allows endless custom components, is super scalable, and is also open source.
Best of all, their customer support staff are top tier. Plasmic has a dedicated Slack channel where they respond to questions and solve problems almost immediately. They will literally respond within 5 minutes of a slack and start helping. It's white glove service that is rare.
My question with these WYSIWYG editors is always how maintainable is the code they output?
I have no problem using these on smaller projects that are fairly static, but on more complex things it has always felt to me like the time you save by using a tool like this, you end up losing when you want to do something not supported by the tool and you have to hack through the spaghetti code it outputs.
Can anyone speak to the quality of the code that Plasmic puts out?
Plasmic isn't a one-time codegen tool, where you generate some code and then modify it to suit your needs. Instead, we've designed Plasmic code generation so that you can generate code, add some business logic, iterate on design, generate code again, without blowing anything away. You're never directly editing the code generated by Plasmic.
That's not really the question I was asking. Most WYSIWYG's that I've used in the past are built around the idea that you can use them over and over. I'm thinking of things like Wix and Squarespace or even all the way back to Microsoft Frontpage.
My question is more focused on the idea that at some point there will be something that I need to do that can't be done through the WYSIWYG editor. I'm wondering what happens in that use case. Can I open up VS code and start changing the underlying code myself? If so how does the tool maintain those changes through iterations and how maintainable is the code that Plasmic generates?
My concern comes from the fact that I've used some of these tools in the past and the code they spit out will have things like 8 levels of nested divs for no reason, empty tags, and inlined and !important styles all over the place. I'm not saying Plasmic will do that, but I'm wondering if anyone who has used this can say how good or bad the generated code actually is.
The main way to extend Plasmic is to use your own React code components. So if there's something you can't achieve with our editor, you can make a component that does it, and use it in the design. An alternative way is to use the Plasmic components that we generate, which expose a lot of hooks that lets you instrument the props and rendered content within the component, without having to edit the generated component code itself. It is our explicit goal that you never need to edit the Plasmic-generated code in order to extend it to do what you want.
As for the actually generated code, it basically maps to what you've created yourself in the studio. Plasmic does have a styling / element abstraction, but it's fairly low-level, and everything is pretty close to how you'd write a React component yourself. If you're not creating empty divs in the editor, you shouldn't see empty divs in the generated code :-)
> Instead, we've designed Plasmic code generation so that you can generate code, add some business logic, iterate on design, generate code again, without blowing anything away. You're never directly editing the code generated by Plasmic.
I think that actually amplifies the concern. Basically it's "don't touch the output," but what if we want/need to?
We wanted Plasmic to be the source of truth for certain things (the css, the composition, etc), so that it is possible to re-generate code from Plasmic and continue iterating on your designs (design-to-code is never a one-time thing!). We've designed the generated code to be very instrumentable; you can pass in prop overrides for any part of the component, swap out parts of the component with other content, etc., so you can get the component to do what you need, without having to edit the component code itself.
+1 to Chung's reply. There's also a loader API where you'll generally never need to see the code that is output. Check out the differences between loader API and codegen here: https://docs.plasmic.app/learn/loader-vs-codegen/
In case you still want to see the code from codegen, here's an example. We generate 3 files per page/component:
While 1 and 2 will be overwritten as you update your project in Plasmic (and therefore you should never modify it), the wrapper (3) is yours to customize as needed, like setting props or binding event handlers. In the above example, we computed how much free trial time a customer has. You can read more about the generated code here: https://docs.plasmic.app/learn/codegen-components/
I’ve been using Plasmic for the last 6 months to build rich featured Dapps in the web3 space. It takes some time to import all the React components I need but once you do, it is really incredible how much this speeds up my development. We now have non-developers (like designers and PMs) regularly shipping entire features to production without developer help. Really takes some of the pressure off the engineering team while drastically improving team velocity.
Just for fun during the ETHDenver hackathon, I shipped an LLM-powered NFT generator, with 0 lines of code in 3 hours, and won a cash prize. This tool completely changes the game for me and my team.
An ability to connect a custom UI to managed data source connectors seems interesting. Probably just me, but I find most of the point-and-click intranet builders a bit cumbersome and restrictive.
The pricing vary depending of the use case, for those using the CMS, it is mainly for the usage of our hosted version of the visual builder and the CMS. We already provide ways to connect with other CMSes besides our own, like sanity, stripe, contentful, hygraph... But it’s possible to self host and connect with other CMSes.
No it's another one of those startups looking to cash in on becoming open source. If your open source projects contains a "pricing" page prominently in the top bar, it goes against the open source ethos and you should be ashamed of marketing it as such.
I understand your mention of open source ethos, but open source projects can also have commercial aspects. It is primarily about transparency, collaboration, and free distribution of software. There are many successful open source initiatives that incorporate commercial strategies to support their ongoing development, professional support services, and operational costs. Our pricing page is part of our commercial approach, ensuring we sustain our open source contributions, also for some additional services that we provide.
WYSIWYG web design has been tried since the internet has existed, but people keep coming back to writing UI in code. How does this compare to other tools? What is the best WYSIWYG tool today?
I think, with most WYSIWYG editors in the past, a developer runs into some limitation, forcing them out of the system into uncharted/hacky territory. But for Plasmic, developers are a first-class citizen.
For example, one huge advantage with Plasmic is that Plasmic components run within your React tree. This means you can naturally embed Plasmic components in your React components, and even the other way around!
Whats the difference between this and Builder.io? both no/low code apps with a CMS as its base. Drag and drop for UI, auto-code generation and plug into back end of choice.
We have a lot of respect for the work Builder.io is doing! If you're using Plasmic as a CMS, then there is a lot of overlap there. But Plasmic is a general visual React app builder, and as such, it comes with a lot of the abstractions and power you need to build a full React app. For example, you can craft reusable components in Plasmic that have different variants and have stateful behavior, and you can make use of abstractions like style tokens. Whereas Builder.io's UI is pretty focused on building individual pages, Plasmic is more about building the intermediate, reusable pieces of your app -- components, tokens, etc -- that you can then compose into pages and experiences. Using Plasmic will feel a little more like working on a full React application... for better or worse
It can deeply integrate into your existing app (reuse your React components, and form the same React tree as your React app and read from the same React contexts, etc), and it can be hosted from anywhere. It also places a lot more emphasis on design and customizability.
Eventually someone is going to build a good enough visual app builder with AI assistant, and nobody will ever know except that a mysterious startup with seemingly unlimited resources and agility is taking over every SaaS market.
In short, I have gone pretty deep with it as a proper "app" builder compared to maybe a more CMS/design use case. By far, for front-end low code UI tools it is my favorite. However, it isn't without the typical pains of that when the abstraction breaks it can be quite a hassle and requires some real knowledge (or support help) to figure things out. The real thing that keeps me on it though is that it really can have hand written react and Plasmic generated react live by side, which drastically lowers the risk compared to a lot of other app builders.
I do genuinely think it can speed up development for certain teams on app use cases, but I think the structure of those teams is a bit particular, because you do need someone who really knows react/next ecosystem to manage the underlying integration.
Thanks to the Plasmic team!
Happy to answer questions in thread