RFC: FAST Project Re-alignment about fast HOT 13 CLOSED

In general, I think this goes against what is written down on #5901. While it does include a disclaimer that everything in the future is speculative, I didn't expect it to get completely flipped upside down and go against the speculation there. (It should probably be unpinned)

I would like to indicate that our team decided to use FAST simply because Foundation existed which allowed us to start our development faster, we have not outgrown foundation as it is still relevant for us. Where we did start developing our own components we we're able to learn from foundation and solve common implementations.

I am interested in what the future holds for fast-element and how it will differentiate itself from its "competitors", as in my opinion Foundation was that differentiator.

from fast.

I understand the idea of making Foundation a community effort, and would gladly pitch in but I have no experience with contributing to open source projects so I would not take a leading role.

I do wonder what the plan is with the Design Tokens system which is defined in Foundation, I find this to be an integral part of FAST and it should probably stay with the team if this is possible and the team agrees.

I also hope the documentation will be improved as currently I find it very difficult to learn everything I need from the documentation and this is where foundation filled the gaps.

from fast.

FAST SSR stays? Are there plans to improve/document that one?

FAST SSR stays, still in pre-release, it needs some love and we'll have to determine what next steps are. As for documentation, right now it will just be @microsoft/fast-element that has documentation, going forward we may have 1 docusaurus site per package. Attempting to have multiple in one doesn't make sense for versioning as the packages version independently.

from fast.

I understand the idea of making Foundation a community effort, and would gladly pitch in but I have no experience with contributing to open source projects so I would not take a leading role.

I do wonder what the plan is with the Design Tokens system which is defined in Foundation, I find this to be an integral part of FAST and it should probably stay with the team if this is possible and the team agrees.

I also hope the documentation will be improved as currently I find it very difficult to learn everything I need from the documentation and this is where foundation filled the gaps.

I believe that there are a few folks who are interested in continuing supporting the foundation package, including the design token implementation, specifically the Adaptive Web project (@bheston) and I believe @radium-v (current code owner). Ultimately, I think that both of those packages work well together and I don't think it makes sense to break out the design tokens at this point in time. Of course, there is also the opportunity for other folks to pick up variations or improvements of the package, etc. In terms of Microsoft's investment in the token implementation itself, it's not currently something that is being actively investigated as there is an alternative approach for tokens for Fluent UI, Microsoft's design system. That specifically makes it difficult to prioritize the work and keep things rolling and evolving in a direction that supports the community. I think that were it to be retained within the FAST project, it would likely receive less attention than it would from a community invested in its evolution. I'd also expect that documentation would likely improve for FAST Foundation for the same reason.

I know that @radium-v is interested in making some changes to leverage ElementInternals for native form association and @bheston has pretty much finalized the approach for a consistent structure of the components, etc.

In terms of FAST Element documentation, @janechu is working on improving that now, evolving the homepage and getting up docs for both FAST Element v2 while maintaining the current v1 release docs.

from fast.

That is quite a vision change from a Design System framework to a web-component library.
I suppose that fast-cli, that never took of, will also be removed.

from fast.

FAST SSR stays? Are there plans to improve/document that one?

from fast.

@Patrickroelofs I think this has been the struggle of the last couple years with priorities for the project (hence the reason our prerelease has been delayed by a few years), also sorry about the conflicting messages there, I have unpinned the issue but left it open and pinned this one.

You're right that we originally wanted foundation to be an accelerator for teams and considered it a core priority for a long time, and we still believe in the concept and the problems it solves, having the solution be part of this project is not what we believe the answer to be going forward. This is why we are looking for outside contributors to take on the goals of package and build on it, potentially creating multiple projects. We would also love to showcase the work of other projects that build on @microsoft/fast-element as well, instead of being the arbiters of everything "FAST".

The @microsoft/fast-element package remains an extremely lightweight and performant web component library.

from fast.

I know that @radium-v is interested in making some changes to leverage ElementInternals for native form association

Where would this be happening? I'm interested in the latest/greatest in terms of implementing form elements.

from fast.

I know that @radium-v is interested in making some changes to leverage ElementInternals for native form association

Where would this be happening? I'm interested in the latest/greatest in terms of implementing form elements.

You can check out some of the recent commits to the web components package in fluent ui: https://github.com/microsoft/fluentui/tree/master/packages/web-components

from fast.

@r1m it can't be removed if it never was added 🥲. Original intentions aside, we're hopeful that the community will see the value in the underlying architecture that due to the layer of abstraction on top for design systems, was never able to shine. We still get asked "what is the value of @microsoft/fast-element" regularly, which I don't intend to address anymore as the updated documentation will showcase the value in a thorough manner.

If someone wants to create a CLI as part of tooling around developer experience, we welcome the effort, and should it become something we would recommend to the community it will become part of our showcase.

from fast.

It's hard to read that you all want to abandon @microsoft/fast-foundation when people are still actively using it. We chose fast-foundation specifically because of it's proposal of being able to maintain a design system on top of standard component API and ability to integrate tokens, which fit our use case perfectly. It definitely lacks documentation and some of the use cases are bit confusing at times, but I agree with whoever said above that this was one of the biggest value propositions of the FAST eco-system. I hope to see what migrating if at all to the new FAST versions will look like.

from fast.

#6881 should not be closed as it was never solved, or did I miss something?

from fast.

#6881 should not be closed as it was never solved, or did I miss something?

Yes, we have removed the package this issue was filed against, see previous discussion and description of this issue.

from fast.