Stacker, to me, will always be the DOS hard drive compression software that Microsoft stole. [1] 1. https://en.wikipedia.org/wiki/Stac_Electronics
I was about to write exactly that! I think it dates me.
Micro frontends with Stacker
11–20 of 24 posts
Re: Micro frontends with Stacker
#12This looks like a copy of an idea we built a few years ago ( https://github.com/tes/compoxure ) - still in heavy use at my previous company, along with lots of other folks like Zalando ( https://github.com/zalando/tailor ). 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…
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...
Re: Micro frontends with Stacker
#13Stacker, to me, will always be the DOS hard drive compression software that Microsoft stole. [1] 1. https://en.wikipedia.org/wiki/Stac_Electronics
I was about to write exactly that! I think it dates me.
I remember installing it on a 20 megabyte hard drive, which I thought was enormous, and then seeing so much free space the next time I typed "dir".
It truly was a magical time in my life, before I had the opportunity to work with unix-like systems.
Re: Micro frontends with Stacker
#14Micro 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…
Got a link to the "webpack 5 and micro-fe" stuff? Thanks!
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.
Super popular currently.
Best is to start here I think: https://medium.com/@ScriptedAlchemy/webpack-5-module-federat...
And the “official” doc: https://webpack.js.org/concepts/module-federation/
Re: Micro frontends with Stacker
#15It 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?
Re: Micro frontends with Stacker
#16I 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?
https://medium.com/ringcentral-developers/web-apps-micro-fro...
Re: Micro frontends with Stacker
#17Micro 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…
Got a link to the "webpack 5 and micro-fe" stuff? Thanks!
Pretty sure they're referring to isolated modules, this is a great video about it:
Re: Micro frontends with Stacker
#18This looks like a copy of an idea we built a few years ago ( https://github.com/tes/compoxure ) - still in heavy use at my previous company, along with lots of other folks like Zalando ( https://github.com/zalando/tailor ). 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…
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.
https://en.wikipedia.org/wiki/Java_Portlet_Specification
https://www.infoworld.com/article/2073645/introducing-the-po...
Edit: Actually, given the timing, I was probably using JSR 286 Portlets 2.0 (2008).
Re: Micro frontends with Stacker
#19This looks like a copy of an idea we built a few years ago ( https://github.com/tes/compoxure ) - still in heavy use at my previous company, along with lots of other folks like Zalando ( https://github.com/zalando/tailor ). 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…
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 :)
Re: Micro frontends with Stacker
#20This looks like a copy of an idea we built a few years ago ( https://github.com/tes/compoxure ) - still in heavy use at my previous company, along with lots of other folks like Zalando ( https://github.com/zalando/tailor ). 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…
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. https://en.wikipedia.org/wiki/Java_Portlet_Specification https://www.infoworld.com/article/2073645/introducing-the-po... Edit: Actually, given the timing, I was probably using JSR 286 Portlets 2.0 (2008).
:) 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...