
Micro-front ends in Webpack 5 - pastelsky
https://github.com/sokra/slides/blob/master/content/ModuleFederationWebpack5.md
======
mmmeff
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
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
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)

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

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

~~~
RussianCow
I agree with the general sentiment of frontend tooling becoming more complex
over time, but the thing about features like this one is that you don't ever
have to use them or even think about them if you don't need to. But they sure
are nice to have if you _do_ need them.

Personally, I'm looking forward to implementing this at work, but I don't
think I'll ever touch it for my personal projects.

~~~
wcarss
It's a great point that you don't need to use these things if you don't want
to in your projects, but the caveat is that you will often end up working on
projects other people created, and they might have done things like use a
feature just because it seems cool, or create the project from a template that
includes the kitchen sink and eventually rusts through.

In those cases, you have to understand the rusty sink at least well enough to
fix it, and hopefully well enough to assess if it was the right tool for the
job, and how to safely remove it if it really wasn't.

A great example of this is actually create-react-app. Many people who have no
idea what they're doing start off an app using this toolset and end up with a
boatload of things they aren't even aware of, like a half-baked service worker
that by default caches the app's code in localStorage to enable offline app
functionality!

My own experience with that specific issue was of people building a production
system on top of an ejected create-react-app, who ended up with deployment
issues where some users arrived to a blank page after some deploys. It just
seemed to happen randomly.

It turned out that after some deploys, for some users, the default CRA service
worker's cache and the webpack js minify+chunk configuration, and the 404
redirect configuration for firebase, didn't play well together. You could end
up with new code calling cached code which requested chunks that didn't exist
anymore, and getting served html 404s with status 200, so the cache wouldn't
bust properly. Understanding this, debugging it, and solving it safely (in
part by safely deregistering the service worker for all users) took ~days!

The really upsetting part is that no one involved in building this app
(neither founders nor original create-react-app-running devs) ever wanted
service workers, nor a progressive web app offline code cache, nor code
chunking, nor optimistic 200-html pages in place of 404s. But those were all
default options and packages and stackoverflow copypasta that got cargo culted
in, and it produced a bit of a tower of crap.

~~~
cageface
The worst software hairball I've ever had to untangle was a react/redux/saga
monstrosity that was excruciating difficult to debug or improve. I finally got
permission to rip most of that out and the resulting plain react app was
fairly pleasant to work on.

So yeah, software development fads matter whether you personally follow them
or not.

~~~
JamesBarney
I was recently brought onto a project to add a couple of simple screens to an
app. Any other react project it would have taken a couple of days so I was
surprised the previous estimate was for weeks of development effort. Opened up
the hood to find saga, and quickly discovered why it would was weeks of
effort.

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

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

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

~~~
JMTQp8lwXL
Let's not bury the lede here. The problem is with coordinating, not the
colorful selection of technologies used. Most teams use abstractions on top of
Webpack, because they are not interested in how a bundler works, and would
rather focus on product features (from a business perspective: I can somewhat
appreciate this sentiment). Since most teams haven't ever picked up Webpack,
and barely touch facades surrounding it, good luck telling them to add module
federation to their configuration.

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

~~~
esperent
Couldn't you version shared modules to avoid this?

~~~
Vinnl
What do you mean by "versioning" them? If you mean running two different
versions of the same library and putting them in different shared modules,
then: maybe, that depends on the library. I'm quite sure that that's not
possible with React, though, and I've experienced the same problem at a
previous employer that insisted on using Polymer: Web Components have their
own tag name (e.g. <google-maps>), and you can't run multiple versions of them
at the same time because they'll both want to claim that tag.

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

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

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

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

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

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

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

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

~~~
iso-8859-1
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.

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

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

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

~~~
capableweb
> you also need to find and install plugins (loaders) for various file types,
> and those plugins need to be configured as well

No, you don't _need_ to find and install plugins, unless you need it because
you're going further beyond than the core use case of webpack.

You're comparing two tools that have different focuses and compare them on the
axis of "working out of the box" which some specific use case in mind. Parcel
might work out of the box for React, because it was created to provide that
experience. Webpack wasn't created for that, but to provide customizations for
its users. Of course Parcel is gonna be better at providing that experience

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

------
neals
Like <Frame/> but better!

------
i_like_robots
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-
co...](https://www.matthinchliffe.dev/2020/06/03/taming-webpacks-content-
hashes.html)) 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
This title was quite hard for me to parse. I was thinking, what is Micro-front
and why is it ending?

------
greenie_beans
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?

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

------
KayL
what software used to create the diagrams in the article?

~~~
baxrob
looks like [https://excalidraw.com](https://excalidraw.com)

