List of Piral v2 Presets

[FlorianRappl]

This is a WIP on presets that will be available either directly when we release Piral v2 or that are planned / available after some time.

A preset is a combination of packages that come together in form of a template or description to directly support a use case. For instance, right now (Piral v1) we can say that we have 1 preset: SPA.

We have planned:

• spa, pretty much what we have today, but independent of React
• ssr, could be used to also form a modulith service - otherwise just a plain SSR-only solution for micro frontends
• islands, this is essentially a combination of spa and ssr giving you the power of islands architecture with micro frontends, i.e., zero performance impact, fully scalability
• electron, makes client applications also composable
• tauri, similar to electron
• react-native, makes mobile applications composable
• blazor-wasm, like spa but tailored for .NET dev experience
• blazor-server, like blazor-wasm but with even more parts running in pure C#/.NET like the orchestrator
• astro quite like ssr but tailored for Astro
• nextjs quite like ssr but tailored for Next.js
• nuxt quite like ssr but tailored for Vue / Nuxt

A preset defines (among other things):

• What to do about tooling (e.g., bundler plugin)
• How the orchestration flows (e.g., using the browser orchestration, server orchestration, .NET ...)
• What format of the pilets is allowed (client JS, server JS, DLLs, ...)
• How the debugging tools are integrated
• What extra features are added (e.g., client-side routing)

Anything else to consider? We are also actively thinking about qwik or other popular (meta) frontend frameworks that could be touched by this.

[meimosor]

Well done, are you considering supporting Vue and Vite?

[FlorianRappl]

Well done, are you considering supporting Vue and Vite?

Vite is a bundler - it is already supported and for v2 there is nothing in addition to do. It will just work. Vue also is implicitly supported in v2, like piral-base already supports any framework.

The big difference from v1 to v2 is that v1 is mostly thought of as a framework - in this sense having layouting / a component model defined on top of React, v2 is a library where the component model is based on a generic approach, which is mostly just a web component model. So it will work in pretty much all frameworks out of the box.

[meimosor]

Well done, are you considering supporting Vue and Vite?

Vite is a bundler - it is already supported and for v2 there is nothing in addition to do. It will just work. Vue also is implicitly supported in v2, like piral-base already supports any framework.

The big difference from v1 to v2 is that v1 is mostly thought of as a framework - in this sense having layouting / a component model defined on top of React, v2 is a library where the component model is based on a generic approach, which is mostly just a web component model. So it will work in pretty much all frameworks out of the box.

Perfect, I can't wait to convince my team to use Piral! By the way, I would like to know when the V2 version is expected to be released.

[FlorianRappl]

Part of it (regarding the islands-composition / based on our demo with SSR and islands) is already in private preview, but its unclear when we'll have a public preview - especially with all of the presets.

I'd say in Q2 / 2024 we'll enter that stage.

Of course we can also give you guys early access, which can be done rather early. If you have a specific target (e.g., a Vue app) in mind then we surely could also actively work to get this done supported as well as possible.

So I'd say if the team is willing to look into it then come back to us - we can arrange a call (me and some other devs working behind the scenes) and see what you guys need and how we best support you.

[r1m]

I would be interrested to see a Tauri integration

[FlorianRappl]

I would be interrested to see a Tauri integration

Great point. I've added it to the list. The general principle would be the same as with electron, however, part of the preset is some seamless integration with the tooling, so it definitely needs to be tested / refined for it as well. But the client-side / orchestration part will be the same.