How does builder.io stack up against plasmic.app?

General
1

Hi Builder team,

I recently came across plasmic.app and it appears to me (as a non-developer) that it is quite similar to Builder.

While they have a detailed page of them vs others, it does not take into account Builder.

Does the team at Builder or anybody else have any thoughts on how these two products are positioned?

Thanks!

2

Hi! I’m not on the Builder team, just another customer.

I hadn’t heard of Plasmic before, but your post inspired me to sign up for a trial and investigate. I wrote up my findings here: Evaluating Builder vs. Plasmic, two no-code tools for building websites | by Ersin Akinci | Oct, 2021 | Medium

tl;dr: Plasmic is more developer-oriented than Builder and has more polish. Publishing with Plasmic requires a few more steps than Builder. Also, Plasmic doesn’t have a built-in CMS.

1 Like
3

Wow, @ersin - Thank you so much for your feedback. While Builder is a push-publish-and-forget-it sort of solution, this can easily be achieved by Plasmic with some initial configuration.
In fact, this is one of their key use cases of empowering marketing (non-development) teams to make content changes.
For 40 bucks a month, Builder does provide heatmaps, which Plasmic does not.

4

Hey @bhaveshdhaka -

So at the end of the day, our products are positioned quite similarly. They are both no-code tools that you can embed directly into your code stack. Builder was one of the first to market in this space and we have learned a ton by being such, but Plasmic seems to be quickly emulating a lot of the things we have been up to the last couple of years.

I think the high-level summary is that with Builder you get a more mature platform. We have tons of integrations and are customizable with plugins, custom data, etc. We focus on the end-to-end experience of being able to create, measure, and optimize content - not just create. This is why we have rich and well-vetted features around A/B testing, analytics, segmentation, scheduling, etc. We also have a large customer base where we’ve proven our technology with customers of all sizes, which has taught us the value of having a very good and extensible custom field system (critical for SEO), roles and permissions, etc, as well as various other features we have that Plasmic doesn’t.

It appears to me that Plasmic is trying to be more of a general-purpose rich design tool, while Builder is trying to be an end-to-end no-code experience building platform. Our focus is on never hitting limits, working elegantly with teams of all sizes, being flexible enough for any use case imaginable, and constantly measuring the impact of what you are creating.

Overall though, I encourage you to check out both platforms and look forward to hearing your feedback. And great to see yours @ersin!

1 Like
5

The more that I look into Builder vs. Plasmic, the more I want to rewrite or possibly take down my article.

I think that a lot of the use cases covered by Plasmic are actually covered by Builder, I just didn’t realize. Plasmic’s docs are on a different level for such a small startup. Builder’s docs are OK but aren’t nearly as systematic, and advanced knowledge seems to be spread across multiple videos, tutorials, etc. That’s probably why I underestimated Builder.

In contrast, I did the Plasmic getting started tutorial and I read the docs section by section, and I came away with a very full understanding of what that tool is capable of within about four hours of messing around. I have been using Builder for a week and I still have a fuzzy understanding of some of its features.

Plasmic seems to be the more flexible platform, and as @steve said, they seem to be catering to a different audience. You could use Plasmic as a no-code tool, but its functionality would be limited. For example, there’s no way baked into Plasmic’s editor a la Builder’s “data tab” to fetch external API’s; you have to write a code component to do it. That’s very normal for web devs to do and it’s the most flexible way, but it kinda defeats the purpose of having a no-code editor.

(Builder also supports custom code components, and I assume that one could write fetching code there, just like Plasmic. So the additional flexibility is there if you need it.)

I still think that the fit and finish of Plasmic is better. Everything feels so crisp and precise…hard to describe and admittedly subjective.

Anyway, having dug more into Builder, I will probably stick with Builder rather than switching to Plasmic.

3 Likes
6

Really appreciate your detailed feedback @ersin. Docs/education, onboarding, and UX are exactly our top priorities right now, so I appreciate you confirming the necessity for our focus there.

Please don’t hesitate to send us feedback anytime - your thoughtful input is incredibly valuable and appreciated

3 Likes
7

The docs are pretty good and glad to hear they will get better. Tagging on to this - I would love to see the React Builder SDK more thoroughly documented. There are some powerful options that we only discovered by reading the code (which is fine, though not obvious from the builder.io/c/docs)

1 Like
8

Much appreciate the feedback @will - what featured in particular did you find useful + undocumented? Would love to prioritize those in fleshing out the docs

9

I’m starting to dig into the SDK and I second @will’s observation. It would be great to have a full-on set of API docs where every method is documented with parameters, types, etc.

For example, I’m really curious right now about queueGetContent. Seems like a way to batch content requests from code, maybe?

1 Like
10

More general feedback on docs.

The more that I use the platform, the more I realize that my initial impression was mistaken. As a new (technical) user, I’ve had difficulty getting a firm grasp of what the platform can do, partly because some of the best info is obscured by the documentation structure.

Here’s the top-level headings from Drag and drop page builder and CMS - Builder.io

General
Builder visual editor
Builder for Shopify
Tutorials
Developer docs
Account

My observations and suggestions:

  • Having a heading called “General” is too general. The first heading should be something like “Introduction” or “Welcome to Builder.” Also, it shouldn’t be a section heading, it should be a single page that explains what Builder is.
  • Case in point, the subheadings under “General” don’t speak to the idea of “here’s where you go to get a sense of what this thing that you’re looking at is.” The subheadings are: “How Builder works,” “Best practices,” “Builder technical overview,” and “Roles and permissions.” Each of these concepts–just going on the headings, not the content–is introduced too early. I don’t need to know how Builder works, what best practices are, a technical overview, and definitely not roles/permissions when I’m just trying to understand what is Builder.
  • Shopify seems to be prioritized in a number of places (“Builder for Shopify” heading, “Tutorials–>Shopify” subheading). I get it, I’m guessing that’s a large part of your target market, but the current implementation in the docs makes it harder to find info for anything other than Shopify.
  • There’s a kind of categorical confusion going on between some of the top-level headings and the subheadings. For example, “Builder visual editor” and “Developer docs” both have the subheading “Guides”–fine. But then why is there a top-level heading called “Tutorials”? Tutorials are similar to guides, so they should be at the same level. Either create a tutorial subsection alongside each guide subsection for every top-level heading, or merge all tutorials into a single top-level heading and merge all guides into a single top-level heading. As it stands, I don’t know what I’ll find under the top-level “Tutorials” section–is it going to be for the visual editor? Dev docs? Something else?
  • Same thing goes for all the subsection headings that refer to specific platforms, for example “Developer docs–>Angular.” Is this going to be a guide to using Builder with Angular? If so, why is it at the same level as “Guides” instead of nested under “Guides”?
  • Subsection headings that open up to reveal more deeply nested points need to have an arrow or some visual indicator that the subsection heading is a branch, not a leaf. It’s not clear at first-glance that “Developer docs–>React,” for instance, is actually a folder rather than a document. You can see the arrow when you hover over the link but it should always be visible.
  • Nit pick: there are some folders that only have one document, e.g. “Developer docs–>Angular.” These should be just leaf nodes.

If I were redoing the docs, I would do something like this:

  • Split off developer docs into a separate sub-site, there’s just too much stuff to cover.
  • Restructure top-level headings on main docs like so:
    • Introduction
    • Quick start
    • Creating content with the visual editor
    • Integrating with external platforms
    • Managing your account
  • Dev docs site should be something like:
    • Introduction
    • Quick start
    • Important concepts
    • Guides
    • Tutorials
    • API reference
  • Dev docs site should make workflows clear early on. There needs to be a clear transition from the general positioning of your product as a no-code tool to low-code tool. That Builder has three main use cases that can be mixed and matched:
    • Building sites only in the visual editor without any coding
    • Building sites in the visual editor with code components that you’ve written (requires integration with your codebase)
    • Building sites in your own code with sections that you’ve created in Builder (requires integration with your codebase)

Just my $0.02.

4 Likes
11

Amazing feedback @ersin! You make some really good points here. Good news is we are actively working on restructuring our docs, and hopefully will be making some of these updates soon.

Seriously, thank you very much for sharing :grinning_face_with_smiling_eyes: . Feedback like this is extremely helpful in our journey to help our customers be successful.

1 Like
12

I want to second what @korey said - amazing feedback @ersin and incredibly valuable and helpful and we will use this to heavily guide our docs efforts that are underway!

1 Like
13

My pleasure, @korey and @steve! I’m glad that it’s being received in the positive spirit in which it’s intended. Working through my frustrations with docs is one of my chief ways of investing in a new platform, so this is very educational for me, as well.

I also left some more documentation comments about page/section models here: Lots and lots of confusion about page/section models - #2 by ersin

Builder looks really great and I want it to succeed! Keep up the great work!

1 Like
14

+1 to @ersin 's feedback

–

More about our specific use case

One of our use cases will rely heavily on custom components, and the docs surrounding platform extensibility are not full or are not clear on the capabilities.

One example: Registering custom components. The only place that some of the options are surfaced are through looking at built-in components. The full options for builder.registerComponent are not defined in any of the top-level docs.

Another example: Creating a custom editor type.

The marketing pages say you can:

Extend the platform
Use our plugins (and/or build your own) to integrate content and capabilities from your favorite platforms, like Shopify and Cloudinary

The developer docs at Extending Builder.io with Plugins - Builder.io explain that you can create a plugin to offer a custom editor type, awesome! There is no mention that you must be on an enterprise plan to integrate a plugin. Nor is there more info on how to create a public plugin.

The only way I found out that I could not create a custom editor type was through building one and getting the error Builder.registerEditor() called in the wrong environment! You cannot load custom editors from your app, they must be loaded through the Builder.io app itself..

I think that the extensibility of builder.io through custom components is amazing. I do think that allowing for custom editor types would make builder.io really shine. Please do update the docs to show that Builder.io can only be extended by Builder controlled plugins, and that you must be on an enterprise plan for private plugins.

I’ll open a separate forum topic to discuss plugins :slight_smile:

Thanks for all the help and awesome platform!

1 Like
15

Hi! I am not a builder team but i want to know about it. i am agree your information is interesting and a good question.

16

Thanks for the feedback @will - and I should’ve gotten back here sooner bc you can absolutely make custom editors on any plan. In order for them to be public you just have to send a pull request for your plugin to us and we will host it for anyone to use. You can see our example plugin here and if your fork our repo and send a pull request for your plugin in the plugins/ directly your plugin can be available to you and everyone on any plan (and of course when developing locally it is accessible to you as well)

17

Personally I found Plasmic powerful but much more complicated.

They don’t seem to have a concept of “editable zones” like Builder does - which is maybe it’s best feature. Plasmic feels almost more like a developer tool. I can’t imagine any other team member feeling comfortable in it.

Too bad, their pricing makes more sense to us

18

Hi friends,

currently, plasmic seems to have quite extensive comparison with buildre.io here Plasmic vs Builder.io: Compare features & benefits and from the comparison they looks like more mature… could someone make a buildre.io constructive reaction to this comparison?

Many thanks :pray: