I still don't fully understand the big deal here. Couldn't you already load JS modules dynamically before by using the import statement? And you could already compose the separate modules into an app by using single-spa.js.org/
It seems the main advantage remaining would be using dynamic modules for SSR, but from what I heard Next.JS doesn't support module fedaration. :/
So what is actually the big idea? Looking at the webpack config above I'm concerned this new architecture is just going complicate things and also lock-me-in to webpack.
Hi vonwao. Actually the new thing here is not dynamically loading, as you said you could do this by using import() syntax. The new feature here is that with only a single plugin you have the capability to separate your JS code into different projects and work with them at build time, I don't think there will be much change in your Webpack config if it's only a matter of adding a Plugin pretty much :)
Not entirely sure if single-spa works at build time or runtime, which could be a big difference, but I see they are already experimenting with using Module Federation, the only downside I see for single-spa is that the setup looks heavier
Next supports MF, with some workarounds that I created. Next 10 will support MF as a flagship feature.
Single SPA doesn't make the JS payload smaller, it lets you mount many apps and bus data between them. Module federation is pretty much dynamic imports between separate webpack builds that are deployed independently. Single SPA also relies on system.js to share code. MF can support multiple versions if needed and has intelligent semantic versioning at runtime.
As for support, I've already released partial support for rollup and parcel will be adhering to our API interface. All three bundlers should be compatible with each other since we are working to make this interface universal. No lock-in.
You have mentioned,that the support for rollup and parcel were released. Couldn't find the example which shows the support for parcel anywhere.
Also, how is module federation different from single spa.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I still don't fully understand the big deal here. Couldn't you already load JS modules dynamically before by using the import statement? And you could already compose the separate modules into an app by using single-spa.js.org/
It seems the main advantage remaining would be using dynamic modules for SSR, but from what I heard Next.JS doesn't support module fedaration. :/
So what is actually the big idea? Looking at the webpack config above I'm concerned this new architecture is just going complicate things and also lock-me-in to webpack.
Hi vonwao. Actually the new thing here is not dynamically loading, as you said you could do this by using import() syntax. The new feature here is that with only a single plugin you have the capability to separate your JS code into different projects and work with them at build time, I don't think there will be much change in your Webpack config if it's only a matter of adding a Plugin pretty much :)
Not entirely sure if single-spa works at build time or runtime, which could be a big difference, but I see they are already experimenting with using Module Federation, the only downside I see for single-spa is that the setup looks heavier
People from Webpack are working with Next.JS to bring this feature btw: github.com/module-federation/modul...
Next supports MF, with some workarounds that I created. Next 10 will support MF as a flagship feature.
Single SPA doesn't make the JS payload smaller, it lets you mount many apps and bus data between them. Module federation is pretty much dynamic imports between separate webpack builds that are deployed independently. Single SPA also relies on system.js to share code. MF can support multiple versions if needed and has intelligent semantic versioning at runtime.
As for support, I've already released partial support for rollup and parcel will be adhering to our API interface. All three bundlers should be compatible with each other since we are working to make this interface universal. No lock-in.
You have mentioned,that the support for rollup and parcel were released. Couldn't find the example which shows the support for parcel anywhere.
Also, how is module federation different from single spa.