Microfrontends are a technical solution to an organizational problem, if you can get away with not doing them, you might do yourself, your coworkers and your company a big favor.

Having said that, do you deploy this app, that you want to split into microfrontends, as a SaaS or is it more enterprisy and installed on-prem and access mainly via Desktop? If the latter, the venerable iframe might be your friend.

Also, if you really cannot help it, you should consider building an abstraction where you consider iframes, web-components, or lazily-loaded scripts as an implementation detail.

Source: I’m maintaining something that you’d in microfrontend term would describe as an application shell in Angular 2 since 2017. It hosts > 1000 different screens provided by > 60 dev teams ( > 450 devs) into a single user facing view. And I justified at least one years’ salary by talking my boss in 2019 out of using the approach again on a second product line (where the scope was narrower).

In a larger project we came up with the following solution, to keep the UI parts independent changeable and composable. For every bounded context there is an independent UI which could be used standalone and is versioned and exported as a Web Components. The main application provides the overall context and imports a certain major version (eg. “latest”) of a of each component. All communication between the components is done by exchanging events and callbacks. It was in a vue-based project, but I think this should work in general as well.

There are several ways to achieve this. Also, “microfrontend” can mean many things. It’s usually referred to the architecture in which you can deploy an app shell, and other people or teams (or even companies) deploy their own, and you can include parts of their remote-deployed things into your live app. Look into Webpack 5 and Federated Modules for this. Look also into things like Single SPA. OR maybe Piral. There are other ways out there as well, but I haven’t tried them or they would not mix easily with Angular.

Then perhaps you mean deploy-time or build-time integration. From simple monorepos like nx.dev or workspace-like things, to even straight-forward publishing every module on npm. You can pack Angular Standalone Components into a package without issues. But even if you have older Angular versions like you mention, you can export web-component-like components and push them into a (private) npm namespace, and assemble on build time. And the same on react.

Then there are things like Astro, mentioned bellow, which kind of mix both of these ideas, and many more.

Your question is quite broad. If you have specific requirements, e.g. “I have a repo with two components, an angular app, two react apps in these versions, and I want to achieve X”, you may get specific recommendations, so fire away, ask questions.

What you are describing loosely sounds like the islands archetecture that Astro uses (however I have no idea if it lets you mix angular versions; that sounds cursed)

Astro is a meta-framework like Next.js. Unlike Next.js, however, you could do exactly what you are describing. You can use both React and Angular (and even Vue and Svelte) components all in the same meta-framework.

Additionally, you opt-in to all and any client-side interactivity. If you have components that don’t do anything after the page loads, you don’t have to client side render them.

With that all being said, this might be totally unhelpful to you, but this is just what reading your post made me think of. I wish you luck in your breaking down of a large angular frontend.