11 ms·

Micro-front ends in Webpack 5

92 points by pastelsky 6y ago

KayL 6y ago
what software used to create the diagrams in the article?
- baxrob 6y ago
  looks like https://excalidraw.com https://excalidraw.com
tobr 6y ago
Of all the possible ways to write it, “Micro-front ends” definitely isn’t the right one. I thought it was about Webpack 5 dropping support for something.
- dindresto 6y ago
  I found the linked docs about Module Federation in Webpack 5 to give me a better insight to what this is about: https://webpack.js.org/concepts/module-federation/ https://webpack.js.org/concepts/module-federation/
- BossingAround 6y ago
  Well, a lot of style guides prefer "front end" and "back end" instead of one word (similarly to a web server, and not a "webserver"). If that's given, "micro" creates a compound noun that comes with a dash. Hence, micro-front end. Whether it's correct, that, I strongly suspect, depends more on your style guide than anything else. As far as I'm concerned, whatever makes the technical writer happy is good for me...
logicalmonster 6y ago
Maybe this is good and useful for some people: but to me it feels like a continuation of the dark slide that frontend tooling is going on. Way overcomplicated, likely brittle and buggy, significant barriers to just sitting down and building stuff.
- denster 6y ago
  I can't help but agree! Where's the Visual Basic 6 of our era? :) Sure, apps weren't pretty, but you could bang one out in a few days and start getting use from it. That's why I've devoted my career to tooling, hoping to improve the situation [1] [1] {cough, cough} https://mintdata.com https://mintdata.com is where we put our blood, sweat 'n tears as a result :)
- irrational 6y ago
  You are my spirit animal. Where did these people come from that decided that front end development needed to be such a house of cards that it takes a masters degree to get a build system successfully set up and working and know how to fix it when it breaks every few days.
  - Kaze404 6y ago
    I personally don't think it's that hard to run `parcel` on the command-line. Front-end tooling is as complicated as any other tooling: as much as you need it to be.
    - Nullabillity 6y ago
      Parcel is easy to use (as long as you stay on the golden path), but I have a hard time calling it simple. Automagically installing dependencies that it fails to `require()` seems way out of scope for a bundler. Or managing Rust toolchains. Or a bunch of hard-coded rules that hard-exclude compiling stuff in `node_modules`. Unless they're in symlinks (presumably for Yarn workspaces?). And so on.
    - markdown 6y ago
      There's a new one called parcel? WTF? I started with Grunt. Then came Gulp, webpack, and a couple of others. They all do pretty much the same thing, and yet apparently someone has come up with a new one called parcel. Do they do this shit to make nice CV's so they can land FAANG jobs? Everything was easier back when we used to use FTP to upload CSS and JS files to sit alongside index.html or index.php. EDIT: I just googled and the first result is parceljs.org, but that one is blank with a BLM logo on it. Is there another site?
denysonique 6y ago
Does it finally work magically out of the box like Parcel does?
- capableweb 6y ago
  Webpack, just like Parcel, has always "worked" out of the box without installing anything extra. You do still have to write a tiny webpack.config.js. Bundles code just fine by just including `webpack` and `webpack-cli` in my project.
  - fenwick67 6y ago
    IME parcel has been much easier to use than webpack for medium-complexity projects.
  - Benjamin_Dobell 6y ago
    In addition to needing to write a config, you also need to find and install plugins (loaders) for various file types, and those plugins need to be configured as well. The idea is that parcel handles that for you automatically. For Webpack, there's often competing plugins, and beyond that competing workflows e.g. TypeScript via tsc, or transpilation via Babel and typechecking via tsc. Still, parcel is not 100% seamless in the sense that whilst parcel doesn't (generally) require plugins, you do still need to add/install regular file type dependencies. "typescript" for .ts files, and "sass" for .scss files and so on.
    - giantDinosaur 6y ago
      I actually still have zero idea how webpack configs and plugins really work. I just end up in a nested soup of config options where nothing really seems to be the same if it's defined at a different level. It eventually just randomly works. Every new plugin results in the order of things being randomly changed until it works again. It's bizarre. Truly unpleasant from an epistemological point of view - I want to understand but cannot.
    - capableweb 6y ago
bauerd 6y ago
So this is like Server Side Includes (SSI) but with shared state and built on top of JS modules?
- iso-8859-1 6y ago
  Yes, but please, can you avoid going around saying that? My children depend on the money I earn by selling support for this. Complexity is a virtue of our industry, and by embracing it, we will all be richer and happier.
BossingAround 6y ago
Honestly, that looks like the most horrifying piece of tech that I really wanna learn and try... In my org, most teams that need it have like one front end dev that's shared among three other teams, and like one or two people who can hammer out some React and don't hate JS to help out with most of the stuff. I suspect this would be an utter madness for that kind of a team. And yet I feel like I wanna try that for our next project.
- JMTQp8lwXL 6y ago
  Good luck coordinating. A result of acquisitions, my product has a combination of Angular, React, Vue and server-rendered pages. And each front-end is deployed as it's own node app, so no shared CDN, which complicates module federation further. Certainly not Webpack's fault.
  - postalrat 6y ago
    Is coordination worth the effort?
    - JMTQp8lwXL 6y ago
      I question it. Inarguably, every microfrontend shipping its own copy of React DOM, Angular Core, etc is wasting bandwidth. Do our customers perceive page slowness due to this lack of optimization? No. Is conversion harmed? No, because we're a B2B SaaS company. This is not to diminish the work of the Webpack contributors. I still think it's a wonderful feature, and folks with less messy situations (e.g., for organizations still doing micro-frontends, but everyone's using a single UI framework-- their adoption of module federation would likely have less friction) and thus be worth the effort.
  - echopom 6y ago
    > my product has a combination of Angular, React, Vue and server-rendered pages. This is intended by Micro Front. Most Billions Dollars SaaS are based on this Frankenstein type of architecture, the goal is simple : - Support legacy code with Zero Effort The result for the end user is absolutely horrendous , it create slow and bloated web pages with Megabytes of JavaScript with UI of various style and behavior similar to Confluence/ Jira etc... This architecture fits perfectly fit the state of the current market : - Push lots of stuff out "as fast as possible" - Turn over in software in +20%, people who build Jira 5 years ago aren't there anymore , they cashed in their stocks and went somewhere else to get a bigger paycheck - The people who build those apps , most of the time , don't use them... Leaders of Atlassian use Gmail and GDrive , I'm pretty confident that they don't even use Jira or any of their own software... Those apps are so slow and bloated it's astonishing...Yet when something is the "norm" in the industry , it's definitely not an issue.
ryanmarsh 6y ago
Nice. Now all the clients pretending to develop microfrontends (by breaking up the repos) but shipping one big js bundle can stop fucking lying now.
liminal 6y ago
This seems like something useful that I hope to never have to debug
Vinnl 6y ago
The goal of micro-frontends (different teams being able to deploy "their" parts of an application) is nice and all, but I still don't see how this is going to work when the shared modules release breaking changes. So now all those different teams that work on different parts of the same applications will still need to do one massively coordinated release in which they all migrate to the newer version at the same time, and a single team delaying things can put the work of all other teams on hold.
- prerok 6y ago
  Exactly this. But... from my limited experience: one team will just break things and then everyone just needs to correct their stuff as soon as they can because it's just not working anymore. Coordination takes time but has no place in the world of "move fast and break things". Could be just my limited experience, though.
- gdsdfe 6y ago
  I think some people are using feature flags for this
- lhnz 6y ago
  > I still don't see how this is going to work > when the shared modules release breaking changes The team I'm working on is currently working on such an application, and that problem is the one I've been worried about most. What do we do when there is a major version breaking-change upgrade of the shared design system? If you are working within a singular repository (monorepo), you can make a singular commit that fixes all parts of your application at once, and since it is deployed in one go there will be no breakage in production. On the other hand, if you have a shared library that affects multiple repositories, somehow everybody needs to do the PR at the same time, and somehow every deploy needs to be synchronised in order that all micro frontends are updated at the same time. How can that be done in a way which doesn't cause breakages? What if one team is slower to update than every other team? What crazy piece of infrastructure might we require for this kind of gradual distributed upgrade? This almost certainly sounds crazy to most engineers, but at the organisation I work they build quite a lot of App Store style applications which amalgamate 100s of other applications into one gigantic application. Additionally, for some legacy reason, we are tied into using separate repositories for each line-of-business micro frontend.
JMTQp8lwXL 6y ago
I opened a PR to upgrade my project to webpack 5 in 2019. Still haven't merged it since Webpack 5 still isn't released. If they have no further breaking changes, they ought to release and do a 5.1 with further non-breaking new functionality.
neals 6y ago
Like <Frame/> but better!
ironmagma 6y ago
The Webpack dev team's time would be much better spent on making their code strongly typed, with configuration especially having a strong type definition. We need less Webpack to deal with, not more.
bob1029 6y ago
This is basically micro-services ideology but applied to the front-end. To me, all of this reads as: "We couldn't agree on a programming language, framework, or set of common development practices, so everyone gets their own individual silo and never has to worry about what everyone else is doing." Does anyone pay attention to the organizational problem that underlies all of this? You have to agree as a team on this stuff. Microservices is not a way to solve a technical problem, but a way to bandaid an organizational/people problem. You simply couldn't get 2 different front-end or back-end teams to agree on some policy or framework, so now you put an explicit rift between them with this microservice bs. We did monolith->micro-services->monolith. I will rewrite a system from scratch before i put it into a leaky box and try to wrap an API around it ever again. You can try to sell this as some sort of way to migrate away from legacy without rewriting code but that is a bullshit siren song that is never true in any reality. You will likely save more time over the long haul building 1 coherent system (both frontend and backend). Keeping legacy around and pushing it further and further into container inception is not a rational technical solution if you actually want to pay down your technical debt at any point.
mmmeff 6y ago
We already kind of solved this problem at IMDb using Webpack 3 and 4 (with tons of hackery). It was, all things considered, a terrible idea. We ended up with a web page with 10 nearly identical sections implemented 10 different ways by 10 different developers across 10 different git repositories. Micro-frontends are cancer, please don't fall for it. You can get much more done for less with a single webserver and a graphQL service, not matter your project's scope. No front-end on earth needs multiple teams to build it - if it does, your product is convoluted and needs to be split up and/or simplified.
- throwaway888abc 6y ago
  I don't understand anything here about the microfronted. Why would you do that ? You can already share and resuse components, modules, stores, functions ? What I don't see here ?
  - smessina 6y ago
    The use case I've seen is for iteratively moving away from a legacy system. Say you have monolithic front end and you want to move to a new framework/version/etc. Instead of rewriting the whole app, you can approach it feature-by-feature and slowly replace the legacy app, Ship of Theseus style[0]. [0]: https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus
    - throwaway888abc 6y ago
      Thank you
    - adamredwoods 6y ago
      This is exactly what we're doing now. Some of the problems we've seen thus far is how to maintain packages but allow for high-iteration development. It is cumbersome using a packaging service, so at best it's being able to decide what to keep in a shared rep, versus things that are being rapidly developed in it's own rep. Any component that needs specific tweak then becomes duplicated and sadly, code-reuse and maintainability suffers. Another problem is tracking down inter-component bugs, especially if the code is behind a repository. How am I to make small tweaks? Bleh! I haven't digested what Webpack 5 is doing, but I'm skeptical, mostly because I don't like Webpack's plugin implementation.
rado 6y ago
A poorly organised company will always be a poorly organised company regardless of the tools it uses.
i_like_robots 6y ago
I'm hoping that module federation will enable multiple, separately deployed services to reuse assets so that users moving between those services may do so without redownloading the same things over and over. We've been able to achieve this to good effect using Webpack 4 with some hackery (https://www.matthinchliffe.dev/2020/06/03/taming-webpacks-content-hashes.html https://www.matthinchliffe.dev/2020/06/03/taming-webpacks-co...) but I'd love to be able to point to something documented and official instead... this sort of looks like it might meet this need. Fingers crossed.
globular-toast 6y ago
This title was quite hard for me to parse. I was thinking, what is Micro-front and why is it ending?
mrsharpoblunto 6y ago
Can we please stop overcomplicating the terminology around frontend architecture? The whole Isomorphism craze was bad enough - lets not make this stuff more complex than it needs to be and create confusion by over-loading existing terms like containers. Whats being proposed here are dynamically linked shared libraries, they expose some functionality & also consume dependencies (that may be shared). Theres no need to be talking about containers, federation, orchestration etc...
greenie_beans 6y ago
Micro-front ends sound like a bad idea, and exactly like the sort of thing our architects would think is a good idea. Does anybody know of any horror story blog posts so I can show my manager, just in case?
kentaadc 6y ago
Please change my mind: I think that sharing modules on the run is not related on microfrontends. Actually what you can achieve with module federation it's achievable with npm modules. The main difference is that are accessible at run time and that them are sharing common dependencies. But it would be a hell to handle deployment and breaking changes.

92 points by pastelsky 6y ago

KayL 6y ago

what software used to create the diagrams in the article?

baxrob 6y ago
looks like https://excalidraw.com https://excalidraw.com

tobr 6y ago

Of all the possible ways to write it, “Micro-front ends” definitely isn’t the right one. I thought it was about Webpack 5 dropping support for something.

dindresto 6y ago
I found the linked docs about Module Federation in Webpack 5 to give me a better insight to what this is about: https://webpack.js.org/concepts/module-federation/ https://webpack.js.org/concepts/module-federation/
BossingAround 6y ago
Well, a lot of style guides prefer "front end" and "back end" instead of one word (similarly to a web server, and not a "webserver"). If that's given, "micro" creates a compound noun that comes with a dash. Hence, micro-front end. Whether it's correct, that, I strongly suspect, depends more on your style guide than anything else. As far as I'm concerned, whatever makes the technical writer happy is good for me...

logicalmonster 6y ago

Maybe this is good and useful for some people: but to me it feels like a continuation of the dark slide that frontend tooling is going on. Way overcomplicated, likely brittle and buggy, significant barriers to just sitting down and building stuff.

denster 6y ago
I can't help but agree! Where's the Visual Basic 6 of our era? :) Sure, apps weren't pretty, but you could bang one out in a few days and start getting use from it. That's why I've devoted my career to tooling, hoping to improve the situation [1] [1] {cough, cough} https://mintdata.com https://mintdata.com is where we put our blood, sweat 'n tears as a result :)
irrational 6y ago
You are my spirit animal. Where did these people come from that decided that front end development needed to be such a house of cards that it takes a masters degree to get a build system successfully set up and working and know how to fix it when it breaks every few days.
- Kaze404 6y ago
  I personally don't think it's that hard to run `parcel` on the command-line. Front-end tooling is as complicated as any other tooling: as much as you need it to be.
  - Nullabillity 6y ago
    Parcel is easy to use (as long as you stay on the golden path), but I have a hard time calling it simple. Automagically installing dependencies that it fails to `require()` seems way out of scope for a bundler. Or managing Rust toolchains. Or a bunch of hard-coded rules that hard-exclude compiling stuff in `node_modules`. Unless they're in symlinks (presumably for Yarn workspaces?). And so on.
  - markdown 6y ago
    There's a new one called parcel? WTF? I started with Grunt. Then came Gulp, webpack, and a couple of others. They all do pretty much the same thing, and yet apparently someone has come up with a new one called parcel. Do they do this shit to make nice CV's so they can land FAANG jobs? Everything was easier back when we used to use FTP to upload CSS and JS files to sit alongside index.html or index.php. EDIT: I just googled and the first result is parceljs.org, but that one is blank with a BLM logo on it. Is there another site?

denysonique 6y ago

Does it finally work magically out of the box like Parcel does?

capableweb 6y ago
Webpack, just like Parcel, has always "worked" out of the box without installing anything extra. You do still have to write a tiny webpack.config.js. Bundles code just fine by just including `webpack` and `webpack-cli` in my project.
- fenwick67 6y ago
  IME parcel has been much easier to use than webpack for medium-complexity projects.
- Benjamin_Dobell 6y ago
  In addition to needing to write a config, you also need to find and install plugins (loaders) for various file types, and those plugins need to be configured as well. The idea is that parcel handles that for you automatically. For Webpack, there's often competing plugins, and beyond that competing workflows e.g. TypeScript via tsc, or transpilation via Babel and typechecking via tsc. Still, parcel is not 100% seamless in the sense that whilst parcel doesn't (generally) require plugins, you do still need to add/install regular file type dependencies. "typescript" for .ts files, and "sass" for .scss files and so on.
  - giantDinosaur 6y ago
    I actually still have zero idea how webpack configs and plugins really work. I just end up in a nested soup of config options where nothing really seems to be the same if it's defined at a different level. It eventually just randomly works. Every new plugin results in the order of things being randomly changed until it works again. It's bizarre. Truly unpleasant from an epistemological point of view - I want to understand but cannot.
  - capableweb 6y ago

bauerd 6y ago

So this is like Server Side Includes (SSI) but with shared state and built on top of JS modules?

iso-8859-1 6y ago
Yes, but please, can you avoid going around saying that? My children depend on the money I earn by selling support for this. Complexity is a virtue of our industry, and by embracing it, we will all be richer and happier.

BossingAround 6y ago

Honestly, that looks like the most horrifying piece of tech that I really wanna learn and try... In my org, most teams that need it have like one front end dev that's shared among three other teams, and like one or two people who can hammer out some React and don't hate JS to help out with most of the stuff. I suspect this would be an utter madness for that kind of a team. And yet I feel like I wanna try that for our next project.

JMTQp8lwXL 6y ago
Good luck coordinating. A result of acquisitions, my product has a combination of Angular, React, Vue and server-rendered pages. And each front-end is deployed as it's own node app, so no shared CDN, which complicates module federation further. Certainly not Webpack's fault.
- postalrat 6y ago
  Is coordination worth the effort?
  - JMTQp8lwXL 6y ago
    I question it. Inarguably, every microfrontend shipping its own copy of React DOM, Angular Core, etc is wasting bandwidth. Do our customers perceive page slowness due to this lack of optimization? No. Is conversion harmed? No, because we're a B2B SaaS company. This is not to diminish the work of the Webpack contributors. I still think it's a wonderful feature, and folks with less messy situations (e.g., for organizations still doing micro-frontends, but everyone's using a single UI framework-- their adoption of module federation would likely have less friction) and thus be worth the effort.
- echopom 6y ago
  > my product has a combination of Angular, React, Vue and server-rendered pages. This is intended by Micro Front. Most Billions Dollars SaaS are based on this Frankenstein type of architecture, the goal is simple : - Support legacy code with Zero Effort The result for the end user is absolutely horrendous , it create slow and bloated web pages with Megabytes of JavaScript with UI of various style and behavior similar to Confluence/ Jira etc... This architecture fits perfectly fit the state of the current market : - Push lots of stuff out "as fast as possible" - Turn over in software in +20%, people who build Jira 5 years ago aren't there anymore , they cashed in their stocks and went somewhere else to get a bigger paycheck - The people who build those apps , most of the time , don't use them... Leaders of Atlassian use Gmail and GDrive , I'm pretty confident that they don't even use Jira or any of their own software... Those apps are so slow and bloated it's astonishing...Yet when something is the "norm" in the industry , it's definitely not an issue.

ryanmarsh 6y ago

Nice. Now all the clients pretending to develop microfrontends (by breaking up the repos) but shipping one big js bundle can stop fucking lying now.

liminal 6y ago

This seems like something useful that I hope to never have to debug

Vinnl 6y ago

The goal of micro-frontends (different teams being able to deploy "their" parts of an application) is nice and all, but I still don't see how this is going to work when the shared modules release breaking changes. So now all those different teams that work on different parts of the same applications will still need to do one massively coordinated release in which they all migrate to the newer version at the same time, and a single team delaying things can put the work of all other teams on hold.

prerok 6y ago
Exactly this. But... from my limited experience: one team will just break things and then everyone just needs to correct their stuff as soon as they can because it's just not working anymore. Coordination takes time but has no place in the world of "move fast and break things". Could be just my limited experience, though.
gdsdfe 6y ago
I think some people are using feature flags for this
lhnz 6y ago
> I still don't see how this is going to work > when the shared modules release breaking changes The team I'm working on is currently working on such an application, and that problem is the one I've been worried about most. What do we do when there is a major version breaking-change upgrade of the shared design system? If you are working within a singular repository (monorepo), you can make a singular commit that fixes all parts of your application at once, and since it is deployed in one go there will be no breakage in production. On the other hand, if you have a shared library that affects multiple repositories, somehow everybody needs to do the PR at the same time, and somehow every deploy needs to be synchronised in order that all micro frontends are updated at the same time. How can that be done in a way which doesn't cause breakages? What if one team is slower to update than every other team? What crazy piece of infrastructure might we require for this kind of gradual distributed upgrade? This almost certainly sounds crazy to most engineers, but at the organisation I work they build quite a lot of App Store style applications which amalgamate 100s of other applications into one gigantic application. Additionally, for some legacy reason, we are tied into using separate repositories for each line-of-business micro frontend.

JMTQp8lwXL 6y ago

I opened a PR to upgrade my project to webpack 5 in 2019. Still haven't merged it since Webpack 5 still isn't released. If they have no further breaking changes, they ought to release and do a 5.1 with further non-breaking new functionality.

neals 6y ago

Like <Frame/> but better!

ironmagma 6y ago

The Webpack dev team's time would be much better spent on making their code strongly typed, with configuration especially having a strong type definition. We need less Webpack to deal with, not more.

bob1029 6y ago

This is basically micro-services ideology but applied to the front-end. To me, all of this reads as: "We couldn't agree on a programming language, framework, or set of common development practices, so everyone gets their own individual silo and never has to worry about what everyone else is doing." Does anyone pay attention to the organizational problem that underlies all of this? You have to agree as a team on this stuff. Microservices is not a way to solve a technical problem, but a way to bandaid an organizational/people problem. You simply couldn't get 2 different front-end or back-end teams to agree on some policy or framework, so now you put an explicit rift between them with this microservice bs. We did monolith->micro-services->monolith. I will rewrite a system from scratch before i put it into a leaky box and try to wrap an API around it ever again. You can try to sell this as some sort of way to migrate away from legacy without rewriting code but that is a bullshit siren song that is never true in any reality. You will likely save more time over the long haul building 1 coherent system (both frontend and backend). Keeping legacy around and pushing it further and further into container inception is not a rational technical solution if you actually want to pay down your technical debt at any point.

mmmeff 6y ago

We already kind of solved this problem at IMDb using Webpack 3 and 4 (with tons of hackery). It was, all things considered, a terrible idea. We ended up with a web page with 10 nearly identical sections implemented 10 different ways by 10 different developers across 10 different git repositories. Micro-frontends are cancer, please don't fall for it. You can get much more done for less with a single webserver and a graphQL service, not matter your project's scope. No front-end on earth needs multiple teams to build it - if it does, your product is convoluted and needs to be split up and/or simplified.

throwaway888abc 6y ago
I don't understand anything here about the microfronted. Why would you do that ? You can already share and resuse components, modules, stores, functions ? What I don't see here ?
- smessina 6y ago
  The use case I've seen is for iteratively moving away from a legacy system. Say you have monolithic front end and you want to move to a new framework/version/etc. Instead of rewriting the whole app, you can approach it feature-by-feature and slowly replace the legacy app, Ship of Theseus style[0]. [0]: https://en.wikipedia.org/wiki/Ship_of_Theseus https://en.wikipedia.org/wiki/Ship_of_Theseus
  - throwaway888abc 6y ago
    Thank you
  - adamredwoods 6y ago
    This is exactly what we're doing now. Some of the problems we've seen thus far is how to maintain packages but allow for high-iteration development. It is cumbersome using a packaging service, so at best it's being able to decide what to keep in a shared rep, versus things that are being rapidly developed in it's own rep. Any component that needs specific tweak then becomes duplicated and sadly, code-reuse and maintainability suffers. Another problem is tracking down inter-component bugs, especially if the code is behind a repository. How am I to make small tweaks? Bleh! I haven't digested what Webpack 5 is doing, but I'm skeptical, mostly because I don't like Webpack's plugin implementation.

rado 6y ago

A poorly organised company will always be a poorly organised company regardless of the tools it uses.

i_like_robots 6y ago

I'm hoping that module federation will enable multiple, separately deployed services to reuse assets so that users moving between those services may do so without redownloading the same things over and over. We've been able to achieve this to good effect using Webpack 4 with some hackery (https://www.matthinchliffe.dev/2020/06/03/taming-webpacks-content-hashes.html https://www.matthinchliffe.dev/2020/06/03/taming-webpacks-co...) but I'd love to be able to point to something documented and official instead... this sort of looks like it might meet this need. Fingers crossed.

globular-toast 6y ago

This title was quite hard for me to parse. I was thinking, what is Micro-front and why is it ending?

mrsharpoblunto 6y ago

Can we please stop overcomplicating the terminology around frontend architecture? The whole Isomorphism craze was bad enough - lets not make this stuff more complex than it needs to be and create confusion by over-loading existing terms like containers. Whats being proposed here are dynamically linked shared libraries, they expose some functionality & also consume dependencies (that may be shared). Theres no need to be talking about containers, federation, orchestration etc...

greenie_beans 6y ago

Micro-front ends sound like a bad idea, and exactly like the sort of thing our architects would think is a good idea. Does anybody know of any horror story blog posts so I can show my manager, just in case?

kentaadc 6y ago

Please change my mind: I think that sharing modules on the run is not related on microfrontends. Actually what you can achieve with module federation it's achievable with npm modules. The main difference is that are accessible at run time and that them are sharing common dependencies. But it would be a hell to handle deployment and breaking changes.