Thank you for this awesome post and your insights. I'm currently exploring to use micro-frontends at work as well. My main reason for choosing micro-frontends is actually to be able to use different frameworks simultaneously. Our main framework will be react, but I want the possibility to migrate away from it step by step, without having to re-write the whole application from scratch. Our current monolithic frontend is written in AngularJS and since we are still a very small team, with a huge application, migrating away from AngularJS for us currently would mean no new feature releases in the current frontend, while rewriting everything in the new framework. And we don't want that to happen to us again in the future, so that if for some reason react would be deprecated, we can update each micro-frontend on it's own. That is actually an approach I want to try now with our current monolith. My current plan is to integrate the AngularJS monolith into the micro-frontend architecture and then gradually replace different parts of the application. Do you have any suggestion or tips on achieving that? Or would you generally advice against doing that?
Lead for JavaScript e2e DX at Microsoft Azure. ex-Architect at MongoDB. ex-Principal Architect Adobe Stack at Cognizant. GDE for #Angular and #WebTechnologies Opinions my own.
Education
The Internet
Pronouns
she/her
Work
Principal JavaScript e2e DX/Dev Tools Lead @Microsoft Azure
Thank you for replying, Martin! Actually, avoiding vendor-lock is probably one of the strongest points in favor of micro-frontends.
I can only tell you how I avoid a framework vendor-lock in the projects I lead. ... I promote development in vanilla JS (ES6) and we only use framework for very specific cases (usually in the form of micro apps, as I describe in the article)
But there is also the thing that specifications change too, so no framework will last forever and no vanilla JS frontend will last forever. Always, at some point, you will need to migrate to a newer version.
Strategic modularization, is the key.
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.
Thank you for this awesome post and your insights. I'm currently exploring to use micro-frontends at work as well. My main reason for choosing micro-frontends is actually to be able to use different frameworks simultaneously. Our main framework will be react, but I want the possibility to migrate away from it step by step, without having to re-write the whole application from scratch. Our current monolithic frontend is written in AngularJS and since we are still a very small team, with a huge application, migrating away from AngularJS for us currently would mean no new feature releases in the current frontend, while rewriting everything in the new framework. And we don't want that to happen to us again in the future, so that if for some reason react would be deprecated, we can update each micro-frontend on it's own. That is actually an approach I want to try now with our current monolith. My current plan is to integrate the AngularJS monolith into the micro-frontend architecture and then gradually replace different parts of the application. Do you have any suggestion or tips on achieving that? Or would you generally advice against doing that?
Thank you for replying, Martin! Actually, avoiding vendor-lock is probably one of the strongest points in favor of micro-frontends.
I can only tell you how I avoid a framework vendor-lock in the projects I lead. ... I promote development in vanilla JS (ES6) and we only use framework for very specific cases (usually in the form of micro apps, as I describe in the article)
But there is also the thing that specifications change too, so no framework will last forever and no vanilla JS frontend will last forever. Always, at some point, you will need to migrate to a newer version.
Strategic modularization, is the key.