Evaluating Builder vs. Plasmic, two no-code tools for building websites
IMPORTANT UPDATE! READ THIS FIRST!
Hello reader from the future!
So here’s the thing. I wrote this review in 2021 when I was evaluating various visual programming tools to help me create a micro-SaaS website. Turns out that I had absolutely no clue what I was talking about, especially when it comes to Builder.
I’m leaving this post up for historical purposes, but you should know that I ended up loving Builder so much once I learned more about it that I started working there.
If you want to know more about my journey from misinformed critic to advocate and employee and what makes Builder so powerful, check out my update over here.
Thanks for reading, and if you like my content, please subscribe! 🙏
Another day, another no-code tool for building websites visually. Seems like the market is flooded with them.
Two that caught my eye are Builder and Plasmic. There’s not a lot out there about them, so I thought that I’d write a mini-comparison. (I recently used Builder to make a landing page from scratch. So far, I’ve only gone through the Plasmic tutorial and read through their docs.)
Builder and Plasmic, like Squarespace or Webflow, are so-called “no-code tools” for building websites without any code. They have visual editors that let you drag and drop HTML elements onto a canvas-like workspace to compose your pages, then you hit “publish” and your creations go live on the web. There are literally dozens of these apps out there as their popularity has exploded in recent years.
All of these tools fall on a spectrum of how much of a walled garden they are. On one end, you have Squarespace and Wix, which don’t allow much customization or integration with custom code. Webflow is a little more open, allowing you to construct fully custom layouts but still locking you into their platform.
Comparing Builder vs. Plasmic
Builder and Plasmic are on the open end of the spectrum. They let you build your pages on their platform as well as edit the code itself. Both use React components behind the scenes to build your webpages. Between the two, Plasmic is more oriented toward developers and technical users.
For example, Builder has a built-in CMS and its own hosting, whereas Plasmic doesn’t. Plasmic’s docs show you how to publish to GitHub Pages, or you can download the code and host anywhere you like (Builder allows you to download your code to self-publish, as well, but it’s optional). Publishing to GitHub Pages is trivial for most web developers, but I could see where it might intimidate a non-technical user. The lack of CMS is actually a good thing for my use case, but that’s a major feature that others would miss.
Workflow
The expected workflow for Builder is design then hit publish and the website goes live. It’s pretty straightforward.
The expected workflow for Plasmic is design then hit publish and it will export your code to however you configure it. It can work like Builder if you set the publish step up to go to GitHub Pages, like the Plasmic docs suggest, but it can also do much more than that. For example, you could export directly into a preexisting code base, which in fact is one of their main use cases.
Publishing only scratches the surface in the ways in which one can customize Plasmic deployments. The platform’s most interesting feature is perhaps “app hosting”
Browser support
I’m not in a position to comment on browser support for websites generated by Builder or Plasmic since I’m still a new user. However, I noticed that Plasmic’s editor only supports Chrome whereas I haven’t seen any such warning with Builder.
Plasmic’s browser limitation is a medium-sized annoyance to me as a Firefox user, and I had to download Chrome just to try it out. To be fair, Builder has a lot of weird UX bugs and periodically drops my work without saving; perhaps Firefox isn’t tested by their developers as rigorously as Chrome? Most devs use Chrome on their personal laptops, so this is more plausible than you’d think.
External API usage
Both Builder and Plasmic support hooking into external API’s for pulling data, which Webflow and others don’t allow. The two tools take different approaches, however.
Consuming JSON API’s is a first-class feature in Builder. You can specify remote API URL’s and what to do with fetched data through each component’s “data” tab. For example, if the API returns an array, you can tell Builder to repeat a component for each item, which is useful for rendering a feed. You can even support advanced use cases by accessing the fetch API directly, all within Builder’s editor (although that requires writing some JS code).
Plasmic doesn’t have any remote API functionality baked-in. Instead, you’re supposed to write custom React components that do the fetching themselves. This approach, which is no different from what you’d do if writing a React app from scratch, is much more flexible than Builder’s. It’s also more suitable for integration within a larger preexisting code base.
Plasmic’s flexibility comes at the cost of added complexity. For simple apps, it’s easier to use Builder’s remote data bindings.
Polish
So far, I’m blown away with the level of polish on Plasmic’s app. They essentially lifted Figma’s UI/UX, which personally I really like. They’ve also introduced some formatting features that aren’t supported in every browser (e.g., flexbox gaps), which are then supported on your site through polyfills that they inject onto your page. From their marketing page:
Plasmic is a page builder and design tool that has a kernel which runs from within your application. We call the Plasmic project “hosted” by your application.
Presumably the kernel supports polyfills.
Which one will I use?
I’m leaning heavily toward Plasmic right now because the fit and finish is much higher than Builder’s and because I don’t need a built-in CMS. They’ve made some smart choices in their visual editor with intuitive layout features like row/column gap in flexbox. I also know that I’ll need to be writing some custom code for my projects and Plasmic seems better-suited for that task.
That said, Builder is probably the better tool for people who want a truly push-publish-and-forget-it solution, or for folks who want a CMS. In terms of fit and finish, it’s still early days for both tools and I’m sure that the Builder team is working hard on catching up.
In truth, though, there isn’t any no-code tool on the market that offers what I really want, which is a platform that handles authentication and authorization properly.
From my perspective as a web developer, the only proper way to handle a logged-in session is to set a session cookie that’s restricted to your webpage’s domain. As of writing, you still have to write custom code to accomplish this.
There are awesome services like Outseta that make login/sign up easy, but there’s no way to set a session cookie for your domain, let alone have a way to check it and conditionally grant access to certain pages and resources without writing code.
If someone could solve the auth/session cookie problem, they’d get my money in a heartbeat!
