We ended up deciding that with the move to component based front end frameworks (react, storybook etc) that the overhead of this wasn't worth the benefits - every developer needs it running, along with lots of services etc.
I'd love to understand what others are thinking about composition on the front end these days. I guess the fact this just got created means that the problem we were trying to solve in 2014 still exists - so perhaps I have my answer?
It sounds like a much older Java thing called JSR 168 Portlets. I remember briefly working with those in 2012, but Wikipedia says the spec is from 2003.
:) see my comment -- yes, portlets are a source of inspiration for some things. As said, we need to share more to enable people to tell us if this makes sense...
Since you mentioned e-commerce: I find it much easier to do a less micro approach and go for medium. Create specific frontends for different domains: my account, cart, checkout, search...
Interesting that you compare Stacker to compoxure. Will need to look deeper into it, but I see a few things Stacker does in a very different way, plus it contains a lot of things compoxure seems to not touch (which, by all means, can be a good thing, please don't misunderstand me).
I only speak for us at betterdoc -- we created Stacker in order to be able to create tools that can be stacked together like containers (the real ones used for shipping things) to form various workplaces. It enables us to mix and match tools without changing code - just by configuration - and we discovered that this is not just a theoretical option, but happens regularly.
The basic idea predates 2014 by far - one of the first things I have worked on back in 2006 was a portlet server (anybody remembering this?), and now we solve many of the problems we tried to solve back then, again, with a different approach and spin.
All I can say is that working on Stacker in the last years was fun, and developing services that serve micro front ends for it gets more fun and efficient with every small step we take.
Cannot wait to share more about the ideas behind it :)
Wow. Brings back memories. I forgot on the fly disk compression used to be a thing. I didn't remember the lawsuit against Microsoft, though it doesn't surprise me.
Micro frontends seems like a technology that's similar to Electron in a way. It gets criticised for its performance characteristics but there one can't ignore the problems it tries to solve for medium-large teams — there is a real need for it.
Once webpack 5 adds support for this, I see a lot more folks using it.
Like electron, the performance characteristics would continue to improve in the long term, but may never be as efficient as hand rolling bundles.
Webpack 5 adds module federation, which to some extend solves our problems with “too many people /teams depend on each other”.
Doesn’t solve component communication, but provides support for shared libs management.
It reminds me of stateful services in .Net and Java. They break tabbed navigation, back and refresh (they often come with explicit warning), freeze and logout when the connection gets flaky, does weird things in case you were logged out.
How will this win over autoscaled stateless web services?
I really like your ideas here, but it makes use of backend for orchestration more than required in some situations.
This nice demonstration of what you can do in frontend with many different approaches could be interesting to compare your ideas against, maybe?
After giving it a first, quick read it really looks like a lot of similar ideas are shared between Stacker and this framework.
Especially interesting for us is the separation between front ends on the client side, which I still, after all these years, find downright hostile if you need proper encapsulation of apps within one page.
I was a bit confused given the recent launch of YC-funded Stacker (https://stacker.app/) - given the sibling comment, it sounds like another Stacker will be unveiled soon!
We ended up deciding that with the move to component based front end frameworks (react, storybook etc) that the overhead of this wasn't worth the benefits - every developer needs it running, along with lots of services etc.
I'd love to understand what others are thinking about composition on the front end these days. I guess the fact this just got created means that the problem we were trying to solve in 2014 still exists - so perhaps I have my answer?