I would rather see articles about "How to do Microfrontends right" rather than all these "X sucks" articles.
There's a million of those. Certainly, having a few dissidents is _expected behaviour_.
Microfrontends should be a last resort
61–70 of 143 posts
Re: Microfrontends should be a last resort
#62If reusable frontend code for your within a single organization or business unit is important, then having separate repos is crazy. A monorepo with separate build pipelines is better, but still unnecessarily complex. A framework like Next.js can do the heavy lifting for you. One build pipeline where components are shareable, and pages/routes ans entry are isolated during development and can be deployed independently…
How is it crazy? I think a lot of big companies have design standards and then some teams create UI libs that follow those standards (and then the UI/UX designers will use the design standards while devs use the ui lib). That’s plenty of reusability, and if you really need to share some components between two MFEs then maybe they should just be 1 MFE. A page footer could easily just be a small react component library built on top of the ui lib, and then everybody can just import it and stick it at the bottom of their MFEs.
Re: Microfrontends should be a last resort
#63Earlier quoted context omitted.
Separate services helps a lot with bigger teams. No matter how much you modularize code -- which will gradually fall apart anyway unless you have custom tooling that enforces API boundaries programmatically -- you're still tying people to the same runtime environment, which means you're tying people to the same libraries and underlying framework/operating system. Which means major library upgrades become nonstarters…
I'm a fan of libraries, not modules, for hard API boundaries. A library, developed and compiled separately and published with versioning, gives you a lot of the clean separation of services without the networking and system overhead. Dependencies should always point from the app to the library as much as possible, so the library should bring it's own dependencies instead of trying to reuse the app's framework/librari…
Libraries sort of help but not really. In the end, if the main app is on Python 3.10, all libraries it uses must be capable of running on Python 3.10. And if you want to upgrade the app to 3.11, first you have to upgrade all libraries to support 3.11 (in addition to 3.10, since you'll likely have to do it piecemeal and not a single big-bang).
This is to say nothing of the classic dependency hell[0] where the main app depends on library X and Y, but library X depends on Z==1.0.0 and library Y depends on Z==2.0.0. At which point you have to do some hacky stuff like JAR shading (which has its own problems, see log4shell) or vendoring the dependency under a new namespace.
For a lot of use cases, specifically at larger orgs and where highly optimized performance isn't a big priority, the networking and operational overhead is a small price to pay for decoupling.
Re: Microfrontends should be a last resort
#64> Microfrontends are very popular on the conference circuit, so I am probably about to make future job interviews awkward by criticisng them. This has been my experience with conferences lately: Way too much emphasis on the next big trend, to the point of being counterproductive for actually getting work done Certain teams and companies live and die by conference trends. If you can't also show interest in those trend…
> knowing about them was his primary signal for someone's overall competence I don't know if it's the primary signal, but I think you need a balanced team. It's a good idea to have at least one person on your team who's staying on top of what's going on in the front-end community. But you have to be careful that person isn't blindly trying to apply every trend in your product, e.g. resume driven development.
> It's a good idea to have at least one person on your team who's staying on top of what's going on in the front-end community.
Keep your friends close and your enemies closer.
Re: Microfrontends should be a last resort
#65> Microfrontends are very popular on the conference circuit, so I am probably about to make future job interviews awkward by criticisng them. This has been my experience with conferences lately: Way too much emphasis on the next big trend, to the point of being counterproductive for actually getting work done Certain teams and companies live and die by conference trends. If you can't also show interest in those trend…
>They hired a lot of "smart" developers, but they also took forever to ship anything.
Oh man does this resonate with me. Some of the "smartest" people we've hired have also been the slowest to deliver as they waffle and perfect and theorize and play with the tasks they have.
Re: Microfrontends should be a last resort
#66Micro-anything tends to cause engineering orgs to spend more time drawing boxes and fantasising about what tech would be 'just-perfect' for that particular box than actually considering their users needs. The killer truth is, the connections between your components start to become more important than the components, and the work to maintain this system is only really justifiable if the components can be worked on in…
Hmm I wouldn't say it never happens we are building a large system (in cybersec space) and there is like a dozen + teams that are delivering their respective frontend functionality as microfrontends. The experience has being fairly reasonable so far. Very likely because each team's app is fairly isolated.
Re: Microfrontends should be a last resort
#67> Microfrontends are very popular on the conference circuit, so I am probably about to make future job interviews awkward by criticisng them. This has been my experience with conferences lately: Way too much emphasis on the next big trend, to the point of being counterproductive for actually getting work done Certain teams and companies live and die by conference trends. If you can't also show interest in those trend…
>They hired a lot of "smart" developers, but they also took forever to ship anything. Oh man does this resonate with me. Some of the "smartest" people we've hired have also been the slowest to deliver as they waffle and perfect and theorize and play with the tasks they have.
But then their playtime projects may turn into your next big product :)
Re: Microfrontends should be a last resort
#68> Microfrontends are very popular on the conference circuit, so I am probably about to make future job interviews awkward by criticisng them. This has been my experience with conferences lately: Way too much emphasis on the next big trend, to the point of being counterproductive for actually getting work done Certain teams and companies live and die by conference trends. If you can't also show interest in those trend…
>They hired a lot of "smart" developers, but they also took forever to ship anything. Oh man does this resonate with me. Some of the "smartest" people we've hired have also been the slowest to deliver as they waffle and perfect and theorize and play with the tasks they have.
That's something I didn't get for a long time
There is a difference between being smart and effective
Re: Microfrontends should be a last resort
#69Earlier quoted context omitted.
> knowing about them was his primary signal for someone's overall competence I don't know if it's the primary signal, but I think you need a balanced team. It's a good idea to have at least one person on your team who's staying on top of what's going on in the front-end community. But you have to be careful that person isn't blindly trying to apply every trend in your product, e.g. resume driven development.
This is a double edged sword unless you plan to allow them room to experiment. If all the work is in older technologies with no short term or middle term plan to upgrade, you will be hiring people who aren't going to be satisfied with the day to day duties and looking to change teams to a team who is using new things or leave. I think teams being honest and self critical about what their actual needs and day to day o…
> you will be hiring people who aren't going to be satisfied with the day to day duties and looking to change teams to a team who is using new things or leave
I don't know about this. I've been able to convince several developers to put down their shiny in favor of trying out some classic options. They seem to enjoy their newly-discovered traction. Progress feels good regardless of how you're achieving it after a while.
I did have to provide starting points & patterns, but it didn't seem to take much. I think they key is proving the value around why the old tools are (likely) better. Just lecturing a young person verbally about this and that is almost certain to send them even deeper into their rabbit hole.
If the mission is vague with uncertain upside associated with completion, you will absolutely find everyone fucking off in different directions as convenient. If you somehow frame the mission more like "ship by Christmas and everyone gets a 50k bonus", you can usually convince even the biggest 'not my job' assholes to adapt to changing realities.
Leadership is at the heart of why some companies are simple and others are running a technological clown show.
Re: Microfrontends should be a last resort
#70Personally I think we should go one step further and introduce an tag to HTML so you can embed an electron instance within webpages