Hacker News Reader

Comment by claytongulick | Hacker News Reader

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/

View on HN

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.

Reply on news.ycombinator.com