Piral is an open-source framework for microfrontends based on React. It brings everything to create amazing frontends using a scalable development approach.

This is the third blog post about our progress on Piral. We will continue to describe our progress and future plans here on dev.to.

The agenda should be almost identical in each post. We'll use

• Current progress to explain what has been done since the last post
• Future plans to explain what we are currently working on or have in our direct pipe
• Other thoughts to list some of the thoughts for future development

Please reach out to us in case of any feedback, ideas, or criticism. We'd love to improve!

Current Progress

We just released version 0.11! That's a big step forwards, especially for our goal to reach 1.0. We will now wait between 2 and 3 months before releasing 1.0.0.

There are two points why you should upgrade (or try) 0.11:

1. With the new pilet schema we can explicitly run also on IE11, Safari, ... - no effort needed
2. By introducing import maps for pilets you can create applications that are even more decoupled from the app shell - even dependencies can be shared without sharing

The first point we already discussed in the last what's new in Piral. If you want to leverage this new mechanism you'll need three things:

1. Your app shell must be referencing piral-base / pira-core in 0.11 or later
2. Your pilets must have been built using piral-cli 0.11 or later
3. Your feed service must support the pilet schema v1 (if you use feed.piral.cloud then this works out of the box)

If any of these three conditions fail we'll fall back to the standard mode before 0.11 - so there is no risk of, e.g., building the pilets using v1 as target schema.

The second point is super interesting and discussed in some detail on the documentation. We'll also create a video for this, soon. To keep this one short and practical: Import maps allow you to specify dependencies that are lazy loaded and can be shared with other pilets. The sharing of a dependency (A) is implicit and demands two things:

• The other pilet also declares import maps with the same dependency (A)
• The dependency (A) is used with exactly the same version

The mechanism works because the dependencies are always included in the pilet. So if pilet 1 and pilet 2 both use import maps with the same dependencies it will not matter if both, one (which one?), or none is loaded. The mechanism always works, because it does not assume anything about other pilets.

As a key indicator we use the hash of the dependency. Thus, version updates of dependencies that do not change any line of code will still yield the same dependency. Such an update, however, is unlikely. While some people want to have a behavior that - in case of only patch-level updates - treats two versions of the same dependency as equal, we cannot offer it.

One of the reasons why we don't want to use the version as indicator is that it will cause more harm than good. While most packages work with semver, some don't. Some work with it, however, do underestimate the propagation of changes in their dependencies. Thus in general we don't want to rely on the version.

Future Plans

As already pointed out we are now in the waiting and refinement game for 1.0.0. In particular, this means:

• Improving the documentation
• Adding more tutorials (or videos, see next section)
• Improving the Piral Inspector

Additionally, we are also adding some new stuff.

1. Adding an extension for VS Code
2. Bringing in advanced support for Blazor
3. Playing around with things: full server-side Piral
4. Playing around with things: support for React Native
5. Playing around with things: pluggable build/debug mode

Let's dive into these five new things in order.

VS Code Extension

We want to make it easier to control Piral from VS Code. Sure, you can do everything today using the command line and VS Code tasks. But we want to make it even simpler. Our vision is that you have a tooling that integrates well and does all that for you.

The tooling detects what (and if) Piral instances or pilets are available in the currently opened folder. If there are any then we'd show additional options incl. building, debugging, validating, and publishing.

For instance, debugging a pilet would already start the VS Code debugging process, too. That way source maps would be correctly referenced allowing breakpoints and full inspection without requiring any custom configuration.

Blazor Support

We've been experimenting with Blazor (WebAssembly, or short WASM) for a while now. While there are parts that are quite hard to get correctly aligned in general we feel that we can offer a really cool and useful Blazor integration. Not only would that allow including pages rendered from Blazor in a full Piral / React app shell, but also using components from React (or any other framework for that matter) in Blazor.

Since this can be lazy loaded we see a lot of immediate benefits as compared to isolated, stand-alone Blazor WASM applications.

What we want to do here is to bring a Piral plugin that brings sharing of core Blazor resources (the core dlls and loader JavaScript) to an app shell. Additionally, we want to have a Visual Studio Template for creating Blazor pilets.

Under the hood, a Blazor pilet would be a standard pilet, but having a WASM file, a DLL, and a JSON as manifest. The pilet just calls the WASM using the JSON with the DLL.

One thing to add here is that the full setup (e.g., registration of pages) should be doable in C#.

Full SSR Piral

At this point we "only" have a small tooling / utility library for SSR available. We actually want to have a full Piral SSR server solution out there, too, which should be capable of running (i.e., pre-rendering) a full Piral solution without much trouble.

We did not spend much time pursuing this right now, but its definitely something we want to have for v1. The idea would be that - given the right circumstances - JavaScript could be disabled altogether. This way one could have server-side microfrontends, too - in addition to client-side and mixed ones that are possible right now.

React Native

Not much to write here. Piral is quite agnostic and only uses react and things like the react-router. Therefore, in theory it should be possible to use Piral in React Native, too. Right now this is all guesswork, but our intention is to play around with this a bit and see where we are going.

We don't know yet if we can officially support React Native. As a first step we'll try to build successfully in the React Native ecosystem. As a next step we would love to showcase what Piral could mean in React Native applications (e.g., a super nice way of allowing plugins).

Right now we don't have any plans to check out a cross-platform scenario where a Piral instance can be used on React Native out of the box. This is still fully left to the development team of the specific application.

Pluggable Build Tools

Finally, we want to look more into alternative build systems. We already released a Piral CLI plugin to allow building pilets using Webpack. In the future we want to make the whole approach pluggable such that

• scaffolding does no longer require any build tooling and can be used / installed much faster
• any build tooling (e.g., via piral-cli-webpack or piral-cli-parcel) can be installed
• if no build tooling is installed then piral-cli-parcel will be added

When the first build / debug is demanded we'll therefore need to install piral-cli-parcel (or nothing, if that has been done already explicitly, e.g., via the devDependencies).

Other Thoughts

With 0.11 we've also released the tutorials as videos on YouTube. The feedback so far has been great!

You can start watching our videos here:

We've also started publishing other Piral related videos. For instance, here is the video for the Piral Inspector, which is our free browser extension available for all major browsers.

More videos are planned for the future!

Conclusion

Piral is marching forward in a great way. We've some very passionate and great users and our desire to create the best microfrontend architecture, framework, and ecosystem is as strong as ever.

With the up and coming 1.0.0 we are quite sure to offer a full package - especially concerning documentation, tutorials, ecosystem extensions, and available plugins.