Hacker News Reader

> 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.".

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, ..."

It is possible to use Plasmic in other contexts, but to really unlock the power of Plasmic, yes you need to be using React.

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.

This is my main concern too.

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.

[1] https://stenciljs.com/

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.

Plasmic does have support to different data integrations, including databases: https://www.plasmic.app/integrations

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.

Just some of the differences: https://news.ycombinator.com/item?id=38701406

And yes you can connect directly a database - critically, Plasmic lets you define backend operations that work with auth: https://docs.plasmic.app/learn/integrations/#security

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.