RFC: Removal of `@microsoft/fast-foundation`
janechu opened this issue · 14 comments
Removal of @microsoft/fast-foundation
Reason for removal
This package does not fill what FAST considers a core goal of the project. The FAST project seeks to provide useful tools for creating components as a platform gap filler, and not creating the components themselves. Refer to the core goals in the project re-alignment issue.
It is noted that the package has proved to be useful and popular among consumers, so we're open to the adoption of the package by other interested parties.
Is "community maintains foundation package on the FAST repo" a possible outcome of discussion, or is that out from the start?
Is "community maintains foundation package on the FAST repo" a possible outcome of discussion, or is that out from the start?
It is, we considered it as an option but ultimately we believe:
- There is better contributing when a package has direct control by a person/group that is invested in maintaining that specific package.
- Generally we observe that smaller mono-repositories have a better track record keeping on top of issues/PRs/etc.
- A project such as FAST benefits from having a set of core goals and if packages do not meet those goals or are tertiary, they should not be part of that repository (but if they are related and useful to the community, can be included in the documentation for awareness).
That said I'll reiterate that this package has been found to be extremely useful for certain groups of developers looking to quickly leverage some component logic, it's just hard to pinpoint an un-opinionated view on how that logic should work so we'd rather recuse ourselves and instead encourage others to pick up similar types of work, I think the concept has proved to be valuable and there is the potential for several projects to spring up from it.
I was just about to start embedding the web components I think are being removed in a large new web application/hybrid-native project I'm building. I'm glad I came across this issue before I started.
Understanding
The naming conventions and documentation however has left me confused as there seem to be references to (FAST) Foundation, Element, and Components.
FAST Element is I think is alternative to options like Lit from Google or Stencil.js.
Foundation I believe at this point is another name for the FAST web component library that uses FAST Element as building block. The web documentation is found at: https://www.fast.design/. There the web components seem to just be referred to as FAST Components, but the code and comments suggest that they are in fact, the FAST Foundation (web components).
Mind the Gaps
I don't see how the library of components is not still a gap filler. They either provide functionality that is otherwise missing or often error-prone to build in an accessible way, and/or provide a consistency to a UX that is often missing in the native web browser.
Having component/widget libraries from established respected companies is an important contribution to the greater good of the web. I've tried a number of component libraries (too many to count), and I'm disappointed how many: a) fail to provide a consistent dev platform, b) fail to create an accessible solution, and c) are used in major projects, d) allow customization/personalization, ... and bonus e) are for React only, rather than embracing an open web. There are only a small handful of options that solve all of these problems well. In fact, the number may be fewer than 5, especially those that have gained traction enough to be dependable.
There seems to be a resurgence of interest (thankfully!) in providing core level components, rather than designs where "everything looks like Bootstrap" that was common for many years. It's disappointing that Microsoft seems to be stepping away from embracing providing these foundational components. Providing these components and a design system is something I'd expect Microsoft to do well (since I can trace my development back to VB3, 4, 5, 6, .NET, Avalon/WPF/Silverlight, XAML, ASP.NET, ...).
Confusingly, the Microsoft Fluent UI components use FAST components, so this decision to drop the Foundation directly impacts the success of that project.
Summary
I can only guess why this project may not be gaining the traction you'd imagined when it was started. I suspect much of it due to the existing pitch and documentation. The documentation is out of date as it references @microsoft/fast-components which is a deprecated library. As a former developer at a large software company (and I was responsible for approving 3rd party component libraries for 2000+ devs), that alone would have been enough to decline the request. 😀
To wrap up -- it feels more like this project needs a reboot to re-energize it rather than being dumped/graveyarded.
As Microsoft creates the browser (Edge) I use 99% of the time on desktops and laptops, I'd argue the existence of this project (or rebooted as mentioned) is an important part of building for web and supporting the web ecosystem.
Off to find another library. It's dang difficult to build a modern accessible web application still in 2024. I thought this would be a solved problem by now.
As someone who is building/maintaining a design system built on top of FAST, this is a shocking decision to me. The reason FAST was picked as the foundation for our design system is the existence of the foundation library. It had all the controls one would need for a component library, we only had to re-style them, which allowed us to get up and running extremely quickly which was very valuable, so valuable that it made it worth it to go with fast-element, which compared to lit has very little adaption, resources to learn etc. The entire value proposition of the FAST ecosystem for us was the Foundation library, I doubt that we are alone with this.
Now the original RFC states that this is the core goal of the project now:
Where the platform has gaps we intend to create solutions to fill those gaps, this primarily concerns the creation of performant rich web experiences.
If we have created a solution for a platform gap and that gap is filled for all modern browsers, we will deprecate and remove that solution.
I consider it a huge gap in the platform that it does not have simple controls that all performant rich web experiences use, like tooltips, switches, stylable select, combobox etc. Is there somewhere where I can find the reasoning that explains why this is not a gap worth filling anymore? If not could you please tell me? I'm genuinely curious about this.
Another thing I'm curious about, and I say this absolutely respectfully, curious about what the team's opinion is, why is having fast-element necessary? What gap does it fill, that is not filled by lit? What's the value proposition of fast-element (current or future planned versions) that makes it worth using despite lit providing seemingly the same functionality, with much bigger adaption and ecosystem? To me this seems like a gap filled, not by the "platform" of course, but filled, so according to the stated goals, I currently don't see how fast-element is necessary, apart from having a ton of adaption inside microsoft and moving that to another solution would take up way too much resources.
I tried to say everything above in a respectful way, if it sounded any other way I did not mean that, I'm truly just looking for answers to these questions. Thanks for any answers you can provide!
As someone who is building/maintaining a design system built on top of FAST, this is a shocking decision to me. The reason FAST was picked as the foundation for our design system is the existence of the foundation library. It had all the controls one would need for a component library, we only had to re-style them, which allowed us to get up and running extremely quickly which was very valuable, so valuable that it made it worth it to go with
fast-element, which compared tolithas very little adaption, resources to learn etc. The entire value proposition of the FAST ecosystem for us was the Foundation library, I doubt that we are alone with this.
I think you've partially hit on what we're trying to solve, we are in dire need of good resources and external projects built on fast-element. We've decided to spend our time on fast-element improvements and adoption. This will allow the community to take up maintenance of fast-foundation or packages similar to fast-foundation, we already have interest coming from some members in doing this and we will be updating the documentation site to include community projects.
In order to facilitate these goals, based on feedback, we will be merging in any relevant PRs into fast-foundation and then we will create a repository with the latest code that anyone interested in the community can fork or otherwise use as a starting point to publish their own package and take ownership.
@janechu @chrisdholt are y'all willing to address the second question asked by @simonxabris reproduced as follows:
Another thing I'm curious about, and I say this absolutely respectfully, curious about what the team's opinion is, why is having fast-element necessary? What gap does it fill, that is not filled by lit? What's the value proposition of fast-element (current or future planned versions) that makes it worth using despite lit providing seemingly the same functionality, with much bigger adaption and ecosystem? To me this seems like a gap filled, not by the "platform" of course, but filled, so according to the stated goals, I currently don't see how fast-element is necessary, apart from having a ton of adaption inside microsoft and moving that to another solution would take up way too much resources.
Having used fast-element extensively and lit only in passing, I would like to understand the differences more clearly as well. Also if there is a goal to grow the FAST community around fast-element, I expect that to be a common question worth having a clear message for.
@janechu @chrisdholt are y'all willing to address the second question asked by @simonxabris reproduced as follows:
Another thing I'm curious about, and I say this absolutely respectfully, curious about what the team's opinion is, why is having fast-element necessary? What gap does it fill, that is not filled by lit? What's the value proposition of fast-element (current or future planned versions) that makes it worth using despite lit providing seemingly the same functionality, with much bigger adaption and ecosystem? To me this seems like a gap filled, not by the "platform" of course, but filled, so according to the stated goals, I currently don't see how fast-element is necessary, apart from having a ton of adaption inside microsoft and moving that to another solution would take up way too much resources.
Having used fast-element extensively and lit only in passing, I would like to understand the differences more clearly as well. Also if there is a goal to grow the FAST community around fast-element, I expect that to be a common question worth having a clear message for.
Short response for now (I’ve injured my hand so typing takes quite a bit of time currently. Without a doubt, this is a question which has been around since the beginning. I’m not sure it’s ever been shared but we did investigate Lit specifically before creating FAST. We also did a listening tour across Microsoft to identify needs. Ultimately, at that time, the core team felt the volume of asks and the changes required (some potentially fundamental) were too significant. This wasn’t about issues with Lit but the unique requirements of certain teams at Microsoft.
One specific thing we needed and still have many teams relying on is support for MVVM, which is one reason for some of the API deltas. FE 2 has some added support here in directives, but they aren’t well documented. @janechu is working on documentation and we’ll get deeper as we go.
There’s several emerging things we’d like to pursue and improve, and improvements coming from the web platform we’re advocating for so we can implement.
I’ll echo what Jane has said around focusing the project, but I also will add that I’m hopeful folks from the community will take up the foundation work. As someone who initially advocated for its creation and being intimately involved in it over the years, there is a large part of myself struggling with releasing “control”. My day job has focused more around Fluent UI and the implementation there and development/contribution to Foundation has suffered. Ultimately, Foundation was/is a huge part of my OSS journey and I’m hopeful folks will improve it and take it beyond where we could. For various reasons, having folks outside the Microsoft organization own it from within isn’t a great path forward, which is why we’re making a call to interested folks.
Much more than I intended to write, but I appreciate all the feedback and we are discussing it as it comes in. Forgive slow responses, typing with one hand, which I’m off to ice. :)
@janechu @chrisdholt Thanks for providing some answers, much appreciated! Sadly we're a team of 3 engineers supporting 100+ frontend engineers with our design system, so the lack of resources on our side prevent us from picking up foundation officially, if there's traction for a community maintained version, we'll try to contribute as best we can.
@janechu @chrisdholt Thanks for providing some answers, much appreciated! Sadly we're a team of 3 engineers supporting 100+ frontend engineers with our design system, so the lack of resources on our side prevent us from picking up foundation officially, if there's traction for a community maintained version, we'll try to contribute as best we can.
Totally understandable - I'm following up with some folks who have showed interest and we'll keep the community up to date on how things are tracking.
I am definitely interested in taking on some derivative of fast-foundation myself, possibly as part of my regular job, but it'll be some time before I'm done with my current slate of large projects and can refocus on the design system. That said, it would probably be very different and redesigned from the ground up to split apart the template and design system tooling. It's likely that the adaptive-ui project will cover most of the design system portion so I would focus on the templates. In order to drive adoption and other contributors I think a framework agnostic approach would be beneficial, allowing the templates to be used in fast-element, lit, and maybe others.
The templates and design system pieces are the most important to my team and I, fast-element itself is just an ergonomic mean to that end. I'm not sure that it will have any staying power after these pieces are removed, time will tell.
@janechu @chrisdholt are y'all willing to address the second question asked by @simonxabris reproduced as follows:
Another thing I'm curious about, and I say this absolutely respectfully, curious about what the team's opinion is, why is having fast-element necessary? What gap does it fill, that is not filled by lit? What's the value proposition of fast-element (current or future planned versions) that makes it worth using despite lit providing seemingly the same functionality, with much bigger adaption and ecosystem? To me this seems like a gap filled, not by the "platform" of course, but filled, so according to the stated goals, I currently don't see how fast-element is necessary, apart from having a ton of adaption inside microsoft and moving that to another solution would take up way too much resources.
Having used fast-element extensively and lit only in passing, I would like to understand the differences more clearly as well. Also if there is a goal to grow the FAST community around fast-element, I expect that to be a common question worth having a clear message for.
Short response for now (I’ve injured my hand so typing takes quite a bit of time currently. Without a doubt, this is a question which has been around since the beginning. I’m not sure it’s ever been shared but we did investigate Lit specifically before creating FAST. We also did a listening tour across Microsoft to identify needs. Ultimately, at that time, the core team felt the volume of asks and the changes required (some potentially fundamental) were too significant. This wasn’t about issues with Lit but the unique requirements of certain teams at Microsoft.
One specific thing we needed and still have many teams relying on is support for MVVM, which is one reason for some of the API deltas. FE 2 has some added support here in directives, but they aren’t well documented. @janechu is working on documentation and we’ll get deeper as we go.
There’s several emerging things we’d like to pursue and improve, and improvements coming from the web platform we’re advocating for so we can implement.
I’ll echo what Jane has said around focusing the project, but I also will add that I’m hopeful folks from the community will take up the foundation work. As someone who initially advocated for its creation and being intimately involved in it over the years, there is a large part of myself struggling with releasing “control”. My day job has focused more around Fluent UI and the implementation there and development/contribution to Foundation has suffered. Ultimately, Foundation was/is a huge part of my OSS journey and I’m hopeful folks will improve it and take it beyond where we could. For various reasons, having folks outside the Microsoft organization own it from within isn’t a great path forward, which is why we’re making a call to interested folks.
Much more than I intended to write, but I appreciate all the feedback and we are discussing it as it comes in. Forgive slow responses, typing with one hand, which I’m off to ice. :)
Sorry for joining this discussion so late but it somehow went under my radar. I decided to use FAST as the underlying framework for building an enterprise level design system in the company I work in (https://explore.matrix42.design). I knew that it was a risky decision but ultimately I chose FAST over Lit because of the fast-foundation package which includes a lot of base functionality for more sophisticated controls and their accessibility. Now with the decision to remove this advantage to the competition I have to say there isn't really any reason to stay with FAST... Especially since even fast-element has some fundamental flaws (code splitting, template merging/inheritance) which just makes it compare bad to its competitors... I guess you guys made this a well discussed decision internally in MS but for me this feels like doomsday for this framework :/
@DavidVollmers appreciate your feedback, we have some folks in the Discord and in this thread who are interested in picking up where we're leaving off for @microsoft/fast-foundation so there may be a migration strategy, and we will work with them on that front. Meanwhile we aim to improve @microsoft/fast-element which we have not been able to focus on due to our small cohort of developers that can dedicate time to the project. As you've stated there are some issues with it that we simply haven't had the time to address.
Ultimately, we view this as a win for the project, it has been stagnating for some time and this re-structuring is intended to invigorate it. I would ask our community to have some faith in where this is all going, we're working the most efficient way we can to achieve all of our goals (and hopefully yours).
@janechu What would be really helpful to make the decision which my team will have to do now (stay with FAST or move to something else), is to publish a roadmap or something similar so we can better understand what issues will be addressed when and especially what features are upcoming. In terms of fast-foundation we already maintain our own fork because of some updates we thought make sense. But in general the question is more why not use Lit and rebuild the features from foundation based on it...
@janechu What would be really helpful to make the decision which my team will have to do now (stay with FAST or move to something else), is to publish a roadmap or something similar so we can better understand what issues will be addressed when and especially what features are upcoming. In terms of
fast-foundationwe already maintain our own fork because of some updates we thought make sense. But in general the question is more why not use Lit and rebuild the features from foundation based on it...
We are currently in the middle of a big push to get v2 of @microsoft/fast-element out, which includes a significant update to the docs. I think a roadmap is a great idea, one we can certainly add after the launch when we have time to assess and prioritize current open issues and take a holistic look over our current feature set.