Who's using this library in production?

[ABIOLI-COM]

I'm really sorry to sound 'hard', but after a long weekend (Friday included) spent investigating the possibility to bring this library in production code, I have to say that my frustration is too high to go on.
I've been misleaded by the version number: I expected it meaning to be the 4th release of an already production code, but it's really not the case.
I'm not complaining about anything: I perfectly understand the effort gone in this work (and still going on...) but this should be more correctly a version 0.8 or something, so developers can immediately understand the maturity of the project, and take decisions accordingly.
I will keep my branch open on the work I did until now: when all the minor and major bugs are fixed, maybe I will give another try, but for the moment I don't see a real usefulness in all of this, and I will revert to using Radzen Blazor components with Tailwind, that work anyway quite well.
There are many positive sides to go this route, anyway, so that's why I will keep an eye on this library.
Sorry about this negative comment, but keep on with your good work! :-)
AB

[vnbaaij]

You are of course totally free to do what you want and are entitled to your opinion. Let's agree to disagree.

The .NET Team choose this library to build the Aspire Dashboard on and with. I think that speaks enough to the maturity and production readiness of this.

I think you went into parts of using/changing the library in it's most difficult (and most poorly documented) area. I explained in a different issue on the why and how behind that. Clearly, that is not what you expect of a component library and that is totally fine. But I don't think it says anything about being production ready. You just want something or are looking for something that is not aligned to the goals we have with this library.

As for the version, we just follow the semver pattern mostly. Major versions are released when there are (major) breaking changes to the API/Components.

[ABIOLI-COM]

Thank you for your totally polite answer to my rudeness :-)
I take your point, and I respect it. So the problem lies maybe in what is the goal of the library, and what I could understand about it (they are of course two different problems around one... part is surely my fault in understanding).
Let's make some examples, to see if I'm inside the goal of the library, or not.

• I would like to have some 'branding' colors on an application, in a centralized way. Let's suppose my customer has two important colors. I think it's normal to be able to 'spread' these colors in menu items, grid headers, and even normal text (maybe totally traditional div's). Of course I would expect to be able to specify these colors in just one place, so if tomorrow I want to brand the application in a different way, or for a different customer, I just change those two colors. I appreciate all the effort in having 'side' colors generated automatically, but all of this cannot go against that basic need. Is it this in the scope of the library or not? If not, what is the workaround? We don't live in a perfect world, of course, but there must be some common sense solution to this problem.
• Same goes for distances, to make another example. I'm using tailwind, where there are for example 5 levels of padding, p-1, p-2 and so on, and if I use them, I still keep the possibility to change them tomorrow to different values (maybe because I enlarge the font size, for example) and just by 'adapting' them, I can still have a consistent look. Again, I think this is a perfectly normal requirement in a business application, and I don't think I should need to incorporate bootstrap, or tailwind, to have this support. This should be the goal of the library.
• On the other side, I'm pleased to see that the behaviour of the components is very very good. They integrate quite nicely with server side logic and services, so it's really a shame that (probably for lack of time and resources) you couldn't hit all of the goals for a really generic library.
  Happy to be challenged and explained on what I miss. :-)
  AB

[vnbaaij]

Thank you for your totally polite answer to my rudeness :-)

I understood already from your other questions and comments that you are not here to 'burn this thing into the ground' :)

• I would like to have some 'branding' colors on an application, in a centralized way. Let's suppose my customer has two important colors. I think it's normal to be able to 'spread' these colors in menu items, grid headers, and even normal text (maybe totally traditional div's). Of course I would expect to be able to specify these colors in just one place, so if tomorrow I want to brand the application in a different way, or for a different customer, I just change those two colors. I appreciate all the effort in having 'side' colors generated automatically, but all of this cannot go against that basic need. Is it this in the scope of the library or not? If not, what is the workaround? We don't live in a perfect world, of course, but there must be some common sense solution to this problem.

In the current Fluent UI Web Components (v2 of those), there is basically only one branding color. The token system and the rest of the code work together to apply that color everywhere where needed. See the 'Settings' part of the demo site (behind the gear icon in the top right). The number 1 pro of this approach is that it is super dynamic. Just pick another color from the drop down in that setting panel and you'll see it being applied everywhere instantly. Only needs the implementation code. As the demo site is part of the repo, that code is available for everyone to see, re-use and adapt.

For the demo we only offer a list of the standard Office colors but it is possible to define a custom color as well. Downside of using this is that the Web Components v2 always use a 'recipe' to determine a value close to the color that ensures there is enough contrast (one of the design goals of the web components is to have good a11y out of the box). So when you need to have a strict branding which uses an exact color or when you need multiple branding colors, like you, you're going to have a hard time. This is not something we can change/influence at the moment but I expect that will change for the better with the wc v3.

• Same goes for distances, to make another example. I'm using tailwind, where there are for example 5 levels of padding, p-1, p-2 and so on, and if I use them, I still keep the possibility to change them tomorrow to different values (maybe because I enlarge the font size, for example) and just by 'adapting' them, I can still have a consistent look. Again, I think this is a perfectly normal requirement in a business application, and I don't think I should need to incorporate bootstrap, or tailwind, to have this support. This should be the goal of the library.

We have heard that request many times before but kept holding off on doing it because this is typically something that we will probably never do 'right' in the eyes of the beholder (ie someone used to Bootstrap vs someone used to Tailwind). That plus it taking a a lot of time to build, lead to us focusing on the components and less on the site building aspect. I still think that leaving that to a personal choice and preference is the better choice, but due to popular demand , we are making this a goal for v5. As a matter of fact a PR has just been created for this. I really hope that we will nog get a bunch of 'but you're doing it wrong' issues out of doing this. I'm guessing adding this will make using Bootstrap or Tailwind together with the components a bit harder.

• On the other side, I'm pleased to see that the behaviour of the components is very very good. They integrate quite nicely with server side logic and services, so it's really a shame that (probably for lack of time and resources) you couldn't hit all of the goals for a really generic library.
  Happy to be challenged and explained on what I miss. :-)

Hope this clears up some of our choices and explains the challenges we are working with (and around).

[ABIOLI-COM]

All good. All of your points are reasonable, of course (and please, rest assured I totally understand the problems underlying this kind of solution that have to be solved!).
Getting to some important points, then: I already understood that this approach of generating colors 'on the fly' (sorry, I don't find a better way to say it, now) is really interesting, I have to think more about it, to grasp it correctly in the implications: my istinct would say that since we should always start from the concept of the cascading style sheet (that is another important and interesting model) the obvious thing a developer would like to see is to set a color, to be used widely everywhere, then specifying 'but for the grid headers I want this other color), and last, in a specific page, 'this particular grid header should be shown with this last color'.
I understand that ultimately it's just a choice: given that the world is not black or white, there's a decision to be taken, balancing good and less good things. I'm honestly still a little bit puzzled, at the moment, but I will spend some more time thinking about this.
I gave a look at the Aspire web look: if I can joke a little bit on this, I could say that if a developer wants to have just that look, work has been done, it's all ready, and very nice to look at, but it's just the way the library has been built by default, take it or leave it! :-)
I remain, coming back being serious, with the most important question: if a developer has a hard time 'branding' it, as we defined it :-), what is the intended use of the library? Just having the good components, without much possibility of fine-tuning to the needs? I think I have to wait for the next version, to see what you can implement, about this! :-)
I really appreciated your time, your openness, and the quality of your answers!
Thank you again.
AB

[vnbaaij]

my istinct would say that since we should always start from the concept of the cascading style sheet (that is another important and interesting model) the obvious thing a developer would like to see is to set a color, to be used widely everywhere, then specifying 'but for the grid headers I want this other color), and last, in a specific page, 'this particular grid header should be shown with this last color'.

That is precisely what using a design system is not particularly suited for. You don't (or shouldn't) need or want to have that kind of exceptions. Which doesn't say it is impossible, but just harder to achieve.

I could say that if a developer wants to have just that look, work has been done, it's all ready, and very nice to look at, but it's just the way the library has been built by default, take it or leave it! :-)

Yes, exactly.

I remain, coming back being serious, with the most important question: if a developer has a hard time 'branding' it, as we defined it :-), what is the intended use of the library? Just having the good components, without much possibility of fine-tuning to the needs?

The intended use is to have the building blocks to build a site/application that has the 'look and feel' of a modern Microsoft application like Outlook, Teams or basically any other modern MS app. In other words to have an application or site that follows and implements the Fluent Design System. By doing that you will bring instant 'recognition' to an app for the end users. As said earlier, it can be tweaked (quite extremely) but that is not the main goal or concern for us.

I think this will (is/should) primarily be used to build (LOB) applications that need to integrate with or align to something in the Microsoft space of applications (this is for example why the library is also being used in the Visual Studio Teams Toolkit). Would I choose this to build a flashy ecommerce site or my personal blog? Probably not. And that is fine.

[ABIOLI-COM]

And now we are also totally aligned, then! :-)
Thank you again.
AB