
Micro Front end done right - alonronin
https://github.com/frontyjs/fronty
======
underwater
Demoing how an web page can ship not just one, but four monolithic frameworks
is going to get the anti-JS folk really worked up.

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.

~~~
vikingcaffiene
It’s seldom that simple in the wild. I just had to build a micro front end.
The original React app had some parts that were business critical but written
quite poorly and required a very specific and weird build chain. The team
collectively wanted to start using typescript and a newer version of React but
couldn’t without rebuilding this piece of the code. So we isolated it into a
microfront end and now have the ability to rebuild it as capacity allows. It’s
obviously not ideal but I consider it a good choice as an interim step in
complex deprecation tasks. Isolate THEN deprecate. :-)

~~~
lugg
This approach is what creates technical debt.

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.

~~~
vikingcaffiene
Why don't you ask a couple follow up questions about the situation before you
slide into the comments and deliver judgement on a something you know nothing
about?

> 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.

------
Hamuko
Am I the only one who didn't understand what it does from the README?

~~~
lelabo_42
No, I also find it confusing.

------
FlorianRappl
People sometimes mix up microfrontend with "running multiple frameworks". Its
not the same. Actually, the main difference between microfrontends and
microservices is that microfrontends _should_ be written with an application
shell and many (development) boundaries in place - otherwise the UX will be
terrible and hard to get consistent.

Disclaimer: I am one of the people behind Piral
([https://piral.io](https://piral.io)) which is a microfrontend solution based
on React.

------
winrid
How do you deal with a consistent look and feel in a product with different
frameworks? What about code reuse?

