scomea
commented
2 months ago FAST SSR stays? Are there plans to improve/document that one?
Open janechu opened 2 months ago
scomea
commented
2 months ago FAST SSR stays? Are there plans to improve/document that one?
janechu
commented
2 months ago 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.
Patrickroelofs
commented
2 months ago 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.
janechu
commented
2 months ago @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.
Patrickroelofs
commented
2 months ago 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.
chrisdholt
commented
2 months ago 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.
scomea
commented
2 months ago 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.
janechu
commented
2 months ago 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
r1m
commented
1 month ago 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.
janechu
commented
1 month ago @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.
ontoneio
commented
1 month ago 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.
macel94
commented
1 week ago janechu
commented
1 week ago 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.
FAST Project Re-alignment
The FAST project currently has a number of stated goals and packages that have grown over the course of development. Many of these packages are either unrelated or only slightly related to the core goals of the FAST project and as such are no longer actively maintained.
These packages may still provide value to the open source community, as such we are opening the conversation to determine if anyone is willing to take on and maintain the packages outside of the FAST project.
FAST Project Core Goals
The stated goals of FAST are as follows:
List of Packages
The packages that the FAST maintainers has deemed as non-essential to the project are listed below, please follow the links for the individual package issues to provide feedback:
fast-tagged-templates@microsoft/fast-benchmarks@microsoft/fast-colors@microsoft/eslint-config-fast-dna@microsoft/fast-react-wrapper@microsoft/fast-web-utilities@microsoft/fast-foundationTimeline
We will give the community what we consider a reasonable timeframe of 2 weeks to start discussion on maintaining packages, with a flexible end date depending on how conversations resolve.
Resolution
Once a resolution has been reached for each package, we will deprecate the package and remove the package from the repository.
We will also provide a link in the upcoming documentation update that refers to the package and links to the RFC for that particular package.
Future
The core focus of the FAST project will be on the
@microsoft/fast-elementpackage. We will be making changes to the documentation to reflect this re-alignment and we ask the community to be patient with us as we make these changes to the project.