Micro Front end done right
github.com
github.com
Personally, I don't understand what kind of business or product team would fail to standardize on a single application framework. There are so many benefits to having shared solutions to UI and application behavior.
If you set a minimum bar for "we all use React" or "we all use Vue" then you can achieve much nicer integrations between products owned by different teams.
It's a method useful for startups only.
Businesses who have moved on from startup status need to switch to a quality first approach.
Deprecation should only be on the table if your original design was flawed. And then only if you are certain you are fixing that particular design flaw completely. So many times have I seen rewrites due to a poor design just create the same design flaw in the new system as a compromise because changing the database would be too hard.
And even then, I strongly question the need for isolation/deprecation like this. It says a lot about your company and creates a broken windows atmosphere where it's ok to push shit because it will eventually be replaced anyway.
"Wanting typescript" is a shitty excuse for putting a business critical system up for adoption.
Literally nobody will want to deal with it within a year. After that, your business critical function, likely one that makes money, is no longer maintained and impossible to change.
Enjoy your growth stagnation.
1) web technologies change frequently, junk is accumulated over time if new tooling and updated dependencies aren't adopted- this is more effective in deprecation 2) iteration speed is faster
ultimately code that makes up infrastructure or the foundation of micro*s should be quality first (e.g. auth, kubernetes, microfrontend compositor) but other things should focus on shipping and iteration.
> It's a method useful for startups only.
this is a start up. So yes it's useful.
> Deprecation should only be on the table if your original design was flawed.
It was.
> It says a lot about your company and creates a broken windows atmosphere
It says a lot about what kind of person you are to come at me with a statement like this. The entire reason this approach is being done is to deal with broken windows genius.
> "Wanting typescript" is a shitty excuse for putting a business critical system up for adoption
TS is one of many changes we are adding to deal with the "broken windows" you so snidely commented right before delivering this one. Isolating the part that makes this shift impossible without a lengthy and expensive re-write is absolute the right approach as we can continue delivering features, address tech debt, and leverage this critical piece of software until we can migrate it to the new infrastructure.
> Enjoy your growth stagnation.
Enjoy being a smug asshole.
Have worked in organisations where they would rather build something from the ground up every 1-2 years because the organisation has shifted so heavily on what it wants to do/achieve with the same product, and engineering wasn't given the time to properly architect the solution to be adaptable. But the business would insist on having X feature from before and often the easiest way to achieve that was to build micro front ends.
The solution to that wasn't "building them right", it was making them as bad and horrible as possible to point out that the business, their culture and organisation was the problem, not the technology. And when that didn't work, resigning.
Disclaimer: I am one of the people behind Piral (https://piral.io) which is a microfrontend solution based on React.