Hacker News Reader

Comment by mmmeff | Hacker News Reader

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.

View on HN

In my company, micro-front ends was appreciated by the development teams involved. It seemed to reduce problems with delivery to production, probably because of splitting up our tests (which were too slow). It is worth noting that we introduced micro-front ends along with a change to the philosophy of the product and also a change to the technology. So our front-ends might be better described as separate applications that happen to be presented to users within a seamless shell.

I've had a similar experience. I spent a few weeks hacking with a team to discover what was killing their productivity and it all came down to the early decision to adopt micro-frontends.

The only place I can imagine this working is at the very, very top end of the organizational scale: somewhere like Facebook where they have the engineering discipline and know-how to manage hundreds of front-end engineers working on a single application.

For every other use case if micro-frontends seem like a good idea it's because something else is going wrong in your development process.

The last assertion is problematic. A team of engineers can only produce so many pages -- you could reasonably need multiple teams to work on different parts of the product's UI.

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 ?

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

Thank you

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.

> You can already share and resuse components, modules, stores, functions?

You're absolutely right that we can, but the issue is that most teams are too large or too disorganised to share complex codebases, so they choose to do a hard division: splitting the code itself.

Here's an argument that I love: Microservices and microfrontends are (most of the time) a failure of encapsulation [1].

Of course there are other benefits, such as separate deployment processes and ability to use different frameworks.

[1] https://michaelfeathers.silvrback.com/microservices-and-the-...

To me, microservices were more about scalability than encapsulation.

Maybe that's the reason that I find serverless more promising.

Sometimes it appears that microservices contrarians are just focused on nitpicking while turning a blind eye to the myriad of advantages that justify their existence and widespread adoption. It's similar to how it's fashionable to criticize Java or C++ just for the heck of it. Sure, the architecture style is not a panacea and there are plenty of downsides and some projects made poor decisions and some evangelists try to make a career selling their snake lard. However, one just need to understand that vertical scaling is not a panacea or effective in reducing latency or providing reliability to understand the need for microservices.

I feel like the debate between the microservices evangelists and the contrarians are "Microservices are a best practice you should almost always use" and "Microservices are a tool for primarily splitting up development teams when they get too large to manage, i.e. a technical solution to an organization problem".

The organizational part is just one of the many advantages, and arguably the least relevant of the bunch as it's only relevant for huge projects requiring dozens of developers working concurrently

Is modularity a huge benefit when most languages allow you to compose applications into modules which have keywords to enforce encapsulation?

And scalability seems like an incremental benefit at best. If you're cpu bound you can load balance without microservices. And if you're database bound (and have already cached, optimized, and scaled up your db) you can scale up your db to multiple instances. Even Stackoverflow runs their entire infrastructure on just 4 db machines.

> an argument that I love: Microservices and microfrontends are (most of the time) a failure of encapsulation [1]

There are plenty of problems and challenges with microservices, but that rant makes no sense at all. The blogger does not understand the upside of running separate processes? And then although he presents himself totally oblivious to the problem somehow asserts that "programming languages give us all we need to encapsulate state and environment", claiming that any shortcoming is due to people doing it wrong?

Quite frankly, that article is just a rant devoid of any rational point, and it surprised me how it has been presented as some sort of argument on an entire architecture style.

I see it coming into play with automated UI building systems

Reply on news.ycombinator.com