The future of Slice Machine

Are there any plans to make Slice Machine usable without a major framework?

Spinning up a shiny new Nuxt site with Slice Machine is all kinds of awesome. But we have a lot of clients who have large existing systems and apps and can't just migrate over to nuxt/next/sveltkit. We integrated with Prismic initially because it was our favorite headless cms. But now that the actual content management is tightly coupled with Slice Machine for previews and Slice Machine requires one of the 3 frameworks we're starting to run into this issue where Prismic isn't "headless" anymore. And this problem is compounded by clients being constantly notified in their management panels that they're missing out on the new super totally awesome preview features - which they are.

What happened to the universal adapter? Are there any plans for a Slice Machine implementation for vuejs? or react? vanilla?

Has any one else cooked up a good solution for your legacy sites that are showing their age via the legacy builder?

1 Like

Thank you for your message regarding the future framework support for Slice Machine.
Currently, the focus of our DevTools team is primarily on enhancing our core product features, and we will not be allocating important resources to add support for additional frameworks until at least the end of this quarter.
However, we do have plans to expand framework support in the future, and we appreciate your interest in this aspect of our product. While we cannot provide specific details at this time, please rest assured that we envision supporting more frameworks as part of our long-term roadmap, including frameworks that have been supported by our legacy builder.

In particular, we are currently studying the possibility to let the developer community contribute and add support of Frameworks themselves through a set of simple API.

Again, thanks for your insights and for your understanding.


Côme, DevTools PM at Prismic.

Hi Jason,

We've got similar issues here. We have a 'traditional' non-client-side site that has no intention of moving to a rich client front end because it offers no benefits (and some serious drawbacks). It currently runs as a typescript expressjs app and works great.

However, because of the new slice machine focus we've been looking at ways we can 'pretend' we have a app so our client can benefit from component previews etc. For us, we're looking at building a translation layer from our existing template language (currently jade) so that we can deploy a slice-machine site alongside the normal site just so we avoid the 'why does it say legacy everywhere' questions that you've also been getting!

In particular, we are currently studying the possibility to let the developer community contribute and add support of Frameworks themselves through a set of simple API.

This would help a bit I think - we'd look forward to finding out more,



API option would be super useful!

*If it helps your team to have feedback regarding the allocation of those important resources, i'd say that having a qualifier for developers that says in order to use Prismic on new projects, they must utilize 1 of only 3 specific frameworks is definitely a deal breaker. Even if they picked 3 really great frameworks.


We've taken a similar approach with a couple of clients as well. We simply spin up one of the frameworks on a protected sub like and configure the urls appropriately. It works a treat for some installations, but for most of them we're doubling (or more) the codebase, introducing a lot of untestable features, and most importantly - creating a head for the headless CMS. The DX for the 3 frameworks is great! But most of our clients rarely fit the "clean install" use case for the modern framework. Especially, when they're at the point that they need a headless CMS.

1 Like