Not sure what you mean. What prevents anyone from writing a CLJS module for a JS app? There is of course always that downside of including a separate ClojureScript + GCC build with each such module, unless all those modules are built together. But I don't think single-spa could solve that.

" people can continue to write ClosureScript next to another team's React or Svelte Microfrontend." Who's going to do their code reviews? :thinking_face:

@U2FRKM4TW I'm looking to see if someone has already completed the integration. The end result of a MicroFrontend is a single .JS bundle containing all of the CSS/SVGs/HTML/JS/etc. I'm hoping that someone has proven that concept with the JS is ClosureScript. But I do appreciate your suggestion of a CLJS module. I'm not familiar with that since I am a JS/Typescript developer (actually I'm an Enterprise UI Architect, but sometimes they let me code haha). But based off my (very) limited research, I don't believe that is the normal approach for creating a Reagent website. But it could be a valid direction for the PoC to take. @U0PUGPSFR I'm going to guess that you're joking but I'll give the serious answer anyway: Much like microservices, you try to break up MicroFrontends by deployment boundaries and then to have an autonomous team own that deployable unit (ie the MicroFrontend). So the answer to your question is, the tech lead of the Reagent MicroFrontend would review that MicroFrontend and the tech lead of the React MicroFrontend would code review theirs. The goal of this whole MicroFrontend/polyglot endeavor is to allow teams to continue to write websites in their preferred UI framework and their preferred flavor of JavaScript.

OK, @U03QGHKR9FG, so this is not about a cowboy dev trotting out Prolog in the middle of a C project? :) Am I the only one who views MicroFrontends as an implicit indictment of the ability of software engineers to identify the best tools, such that even getting a single enterprise to agree on one is impossible? I realize MF has other claims to fame, but I saw tech agnosticism listed first here: https://micro-frontends.org/ A CLJS MF does sound like a great idea since it answers one adoption objection. Could be a Trojan Horse, albeit a helpful one, for Clojure.

@U0PUGPSFR no it's certainly not a cowboy effort— it's for a multi million dollar company. And the reason for MicroFrontends is that our company has an acquisition strategy that dictates that we won't be able to force a language upon a company that we recently acquired. So the MicroFrontend pattern allows us to integrate their product as is and then use the Strangler Fig pattern later to migrate the existing product to the established widgets and UI designs. But if you need more than that, I'd encourage us to debate the merits of MicroFrontends and another thread. Your indictment is certainly correct if it was a small company. That's not us. At this point I’m just looking to see if anyone has done it for closure script so I can help give back to the community.

One downside might be a larger set of dependencies, build size, bogging down the front end. If the framework was smart about dependencies that might help. But if your teams have to coordinate tightly on deps, you might wonder why not go all the way? There's def a niche this fills though, especially dashboards with views implemented by different teams throughout an enterprise, where you don't mind waiting a second or two for time to load.

I would def appreciate having the option

Looks like you'd be expected to use the platform version of whatever framework you want to use?

What frameworks get to own the outer shell? Any of them?

Integrating typescript and cljs codebases is a pretty common refrain, would this answer that question? Isolating them from one another?

There are two approaches you can take with MicroFrontends: 1. Each MFE has their own instance of UI framework (ie React) and their own instance of libraries so there isn't any bad interactions from global scope issues etc. 2. Each MFE pulls from the globally required/imported instances of libraries so that page performance is reduced. I suggested to my company that we use #1 and they agreed. Our customers prefer quality/accuracy over performance in the UI. So the outer shell has no framework. It's just raw JS and the single-spa bootstrapper.

Interesting term micro-framework, I like it. Where I work, this is how it's done already, but I never thought of calling it that, and it's not an SPA. But basically, there's the container team, and a bunch of widgets owned by different team. The teams own their own widgets/section/pages, and can use whatever tech they want, and then there's some way to add your own JS deps to the container if needed, but people are expected to use a common design language, so the CSS is standardized, and there's also a default UI toolkit which is suggested to use, because that's ideal if everyone uses the same UI components, but you can deviate if time-to-market and all that benefits from it.

It does mean that teams own front and back of each widget though, unless that itself is too big for one team and they split it further.

@U0K064KQV I'm sensing that your companies are not MicroFrontends at all. That's fine, it's a new term and it can be confusing. The key differentiators between the three (MicroFrontend SPAs, a traditional SPA, and multi-page (non-SPA)) websites are: • if each team can deploy independently • if JS is required on the page to render state transitions So: • MicroFrontend SPAs can be deployed independently. The root app requires JS. • Traditional SPAs can not have pieces of deployer independently. They require JS. • Multi-page applications can be deployed independently and do not have to use JS (and typically try not to use it for speed reasons).

@U1739BP1C since I cited http://blob.tomerweller.com/reagent-import-react-components-from-npm above, I thought maybe you would be willing to weigh in on the best way to produce a JS module from ClojureScript? To be an MicroFrontend, this bundle simply had so to implement single-spa's https://single-spa.js.org/docs/building-applications/ from the index. Also, I noticed in your article that you went with Webpack as the build tool, but shadow-cljs also can pull from NPM so I'm wondering why you elected to use Webpack? > http://cljsjs.github.io/ is a great community effort to package common Javascript libraries in a Clojurescript friendly way. However, it has some shortcomings. [...] 2. Packages are mostly https://docs.google.com/spreadsheets/d/1t61hPgEfb1ukzezb6dn38z8kp07TsEFgkaVwF01-acE/pubhtml compared to their NPM counterparts. But then in the Reagent docs it says: > And provide React using either npm (when using e.g. https://shadow-cljs.github.io/docs/UsersGuide.html) >

npm i react react-dom

Micro front ends are pretty niche. So is CLJS. My guess is most people aren't using the two together

CLJS is a compiled language that produces JS. I'm not sure how to make it abide by whatever rules single-spa wants, I haven't done enough research. You'll probably need to figure that out.

Ya sorry, we don't do something exactly like this, so I can't help you with your research. Also, ours isn't done in Clojurescript at all, though each team can be polyglot in the design, so some teams could be using Clojurescript. Teams can deploy independently, but the page is combined in the backend, I think with iframes. So it's not exactly what you want here.

> micro front ends are pretty niche I don't really agree. I think everyone here would be impressed with the https://npmtrends.com/piral-vs-single-spa. It's now the dominant MicroFrontend tool by far. So it would be nice to see ClojureScript be able to play in this world. I will be conducting my own research into this Reagent adapter but I will simultaneously be keeping this thread alive to make sure that I'm not duplicating someone else’s effort.

single-spa has a couple orders of magnitude less installs than React, which is why i call it a niche. most orgs don't need a microfrontend architecture and don't want one

it only makes sense in big companies where teams need the autonomy to be on different versions of libs or completely different frameworks. for most orgs, it's easier to tell people that they all have to use the same thing

Correct. A monorepo is a perfectly reasonable approach for small to mid-sized companies or companies that do not care about autonomy. But I work for a large company and I'm trying to not tell the ClosureScript devs “too bad, you have to use TypeScript.” I think the devs are most productive when they're happiest and they're typically happiest when they use the tools they know and trust. For me, that happens to be TypeScript + React but for others that might be Svelte or Reagent. And lastly, outside of the autonomy aspects, MicroFrontends allow a company to progressively migrate from one framework to another without having to totally rewrite their entire UI. Having worked during the angular 1 -> angular 2 debacle, this means a lot to me. The MicroFrontend approach has worked well for our company for about 3 years now so far.

Your comparison seems to compare some old MicroFrontend framework with some newer one, but if you say compare against React, which would include all SPA, you can see that SPAs at large are way more popular, and the MicroFrontend approach to them is just a blip.

Nothing against it, just that it is kind of niche in comparison. I think its a nice approach though, I work at a large company as well, so team independence is very important.

Anyways, it seems the requirement is to be able to provide yourself as an ES Module which implements a few convention functions of the "lifecycle"

I'd recommend you check: • https://clojurescript.org/guides/javascript-modules • https://clojureverse.org/t/generating-es-modules-browser-deno/6116

But the truth of the matter is that, ClojureScript is still figuring out how to interact with ES6 modules. It was designed prior to JS modules existing, and ES6 modules make REPL challenging, so it has not found a clean path to it yet. So things are a bit experimental around that. So having to expose itself as an ES module is a bit tricky.

Point being, right, it's unlikely anyone has gone down this path yet

We could definitely use something like this as well though, for a multi team dashboard

:target :esm is no longer "experimental" and works just fine https://shadow-cljs.github.io/docs/UsersGuide.html#target-esm

I know nothing about single-spa or microfrontends but from a quick glance I can't see anything that would stop you from using CLJS to create one

well build size and duplicating dependencies but since that is not a priority it should be fine

Crazy thread necro here, but did you ever get this working, @U03QGHKR9FG? I find myself in need of porting a reagent app to single-spa.