Menu
In anticipation of Manfred Steyer's session, Micro-Frontends With Module Federation: Beyond the Basics, Richard Wallintin (WPS - Workplace Solutions) had a number of questions for Manfred about his enthusiasm for module federation, the future with micro-frontends and what challenges teams can face with frontend frameworks.
You expressed a lot of excitement around module federation and the massive advances that have happened in the last year. Are you still excited, or does the rush start to fade?
For me, Module Federation is really a game changer. It not only gives us an implementation for loading separately compiled and deployed code like Micro Frontends or plugins but also a mental model that makes it easy to reason about such systems.
Micro-Frontends are becoming more feasible now. Will we soon see enterprise user interfaces seamlessly mixing Angular, React, Vue and You-Name-It? Follow-Up: Are there standards around to mediate between frameworks?
Well, Micro Frontends make such “Frankenstein-Solutions”, as I call them, possible. However, it should never be the upfront goal to mix and match all the possible technologies. Just because we can do it does not mean we should. I see it more as an insurance for the mid- and long-term: If we need to switch over to another stack little by little, Micro Frontends make this possible. Hence, Micro Frontends are especially interesting for enterprise-scale applications that are actively developed by several teams for several years. If you only have one team that works on a piece of software for some months or a tiny number of years, Micro Frontends are very likely an overkill. As everything in this world, they come with several consequences – obviously, not all of them are beneficial. I would not go that far to say that there are standards for the mediation between Micro Frontends. But there are for sure standards that make it easier to deal with them. Examples are Web Components – including Custom Elements, Shadow DOM, and Custom Events – but also Import Maps and EcmaScript Modules in general. Also, Module Federation with its mental model can be seen as a de facto standard that help here.
One more prediction question: Another long-anticipated recent innovation are standalone components. Will Angular modules disappear in consequence?
I would not say „disappear”, because this would be a breaking change. The Angular team’s goal is to prevent breaking changes. But – and I’m really excited about this – they became optional with Angular 14. Beginning with this version, you can use so called Standalone Components that are – more or less – self-sufficient. I say “more ore less” because each piece of software can depend on other pieces like services. With Version 14 they are in developer preview, but they give a nice outlook to (one aspect of) the future of the framework.
Rich frontends running in browsers (using Angular or other frameworks) are well established and popular. What are the hard problems teams face today compared to 3 or 4 years ago? Or is it all recurring issues?
These frontend frameworks are quite powerful. However, this also means, we have to learn to work with them. I remember, I learned jquery back then during a flight from Graz to Munich - a flight that takes about on hour. This was enough to understand the “DNA” of jQuery and it allowed me to do something productive while looking up further details in the docs. This is not possible with modern frameworks, because they are more powerful and provide more a complex mental model to deal with complexity on a higher abstraction level. A real hard problem for the current generation of SPA frameworks is the start performance we need for public website. While start performance is not the utmost goal for enterprise solutions, for public website every millisecond counts. For this, and also because of SEO, most SPA frameworks allow to be used with server-side rendering. In this case, the downloaded html code already contains meaningful information the user can see before the browser downloads all the JavaScript bundles. However, there are several challenges to this and there is a new generation of frameworks coming up that better deals with them. For instance, they allow to lazily load parts of the website and hence to postpone loading JavaScript until it’s actually needed. The big three, Angular, React, and Vue, will eventually incorporate these fresh new ideas. We already have some of them in React and the Angular team currently also puts some focus on this.
The SPA (single-page application) approach faces regular criticism – concerning load time/bundle size, render time, the heavy reliance on Javascript, client-side resource consumption and not leveraging some of the basic strengths of the web architecture. This criticism is then combined with promoting server-side rendering approaches. Do you see chances for convergence of these two programming models for web apps to maybe get the best of both worlds?
This one more time shows that in Software Architecture (and very likely also in life) everything has consequences. Sometimes we don’t see these consequences anymore because we that used to them. SPAs are no exception here. SPAs are a good solution for enterprise applications. But, as you say, for public web sites where conversion and hence start times is a topic, there is some room for improvement. When looking at the mentioned new generation of frameworks, we see indeed a comeback of Multi Page Applications and server-side rendering. However, not in a classical sense, but more in a way where the server-side and the client-side grow together. If they know about each other, we can better combine the benefits of both worlds. Currently, these frameworks are in early stages and primarily focus public content-rich websites.
Which other talks are you curious about?
There will be several sessions about DDD-related topics. For me, this is quite an important topic because it gives us a methodology for bridging the gap between the user’s requirements and our software architecture/ design. Technologies come and go, but Domain-thinking sticks. Hence it can guide us in the long-term.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
