[Community Feedback]: Styled Component's A double edged sword ⚔️.

[Mr-Sunglasses]

🌱 Over the last few weeks, I've been actively taking feedback from the contributors on how we can improve the Bloom ecosystem to be more contributor-friendly and easy for everyone to get started with the codebase and get the contributors onboard as fast as we can.

📢 In all these feedback, one common issue that most of the people pointed out is the use of Styled components. We are using Styled components for styling. The main issue with Styled components is that you need to write all the CSS by yourself as there are not any pre-written CSS classes, and most people do not like to write all the CSS. This will be a very big barrier in the faster development of the project as we need to write all the CSS by ourselves, and most of the contributors are also not very comfortable with it. As my personal view, I also suggest migrating to a CSS Library rather than using styled-components. We understand that Styled components provide us with a better and cleaner way to do styling, but they slow down the developer productivity and contributions extensively as a developer is spending more time in styling as compared to giving more time to the product business logic and enhancing the performance, which also reduces the development speed of the project.

🗣️ We are open to discussions on this feedback. All the community members and contributors are invited to give your suggestions on this discussion.

[A91y]

Absolutely, transitioning to a CSS library is a fantastic idea! 🚀 It can speed up development, maintain a consistent look, and simplify onboarding 🌟.
Leveraging the broader community support and pre-built components in CSS libraries can boost productivity and reduce styling time, aligning perfectly with our goal of faster project development 🏁.
Encouraging contributors to join the discussion is a smart move 🗣️.
On a personal note, I've spent the past week grappling with CSS and achieved minimal progress, so shifting to CSS libraries is a very wise decision! It will undoubtedly accelerate our development process 🙌.

[ShreyaPrasad1209]

@Mr-Sunglasses thank you for starting this discussion! I'd like to put out few points:

The main issue with Styled components is that you need to write all the CSS by yourself as there are not any pre-written CSS classes, and most people do not like to write all the CSS.

CSS is one of the foundation for frontend development. Even if we move to a UI Library, we'll still need to have good understanding of CSS to work with that UI Library in case we encounter any bugs or want to customise our features. So with or without UI Library, we'll still need to write CSS.

• Styled components provide reusability because you need to write the CSS code only once and then we can simply extend it to other components. It also helps with theming.
• I do understand that writing CSS entirely from scratch is a headache especially if someone is new to CSS. For that, we can use a UI Library in conjunction with styled components so that we get the best of both worlds.

Let me know your thoughts 💭

[jatinkrmalik]

Yes! I was also thinking the same thing. Is there a hybrid solution possible? Where we can get best of both worlds?

[A91y]

Yes! I was also thinking the same thing. Is there a hybrid solution possible? Where we can get best of both worlds?

@jatinkrmalik Hybrid solution might be good but not in long run as it may cause confusion.

[A91y]

@ShreyaPrasad1209
The concern lies in the potential for contributors to grapple with the choice between Styled components and a UI library. While hybrid solutions can work well, they require meticulous management and clarity. To address this concern, we must emphasize the following:

📜 Clear Documentation: We must provide clear and detailed documentation that outlines the distinct use cases for Styled components and the UI library. 📚 This reference should be readily available for contributors, both new and experienced.

📏 Coding Standards: Defining and adhering to consistent coding standards is crucial. 📝 These standards should not only lay out best practices but also specify the conditions under which each styling approach should be employed.

👁️ Regular Code Reviews: Incorporating regular code reviews into our development process is a proactive way to ensure that contributors are adhering to the established guidelines, particularly in terms of styling.

🤝 Consistency: Maintaining consistency across our project is of paramount importance. Any inconsistencies in styling between components or pages could create confusion. Therefore, we need to periodically review and update our styling guidelines to adapt to the project's evolving needs.

While a hybrid approach can be promising, it's crucial that we mitigate potential confusion by taking these steps to provide clarity and guidance for our contributors. Our aim is to make the choice between styling approaches as clear and straightforward as possible for the benefit of the project's long-term success. 🌟

[ShreyaPrasad1209]

@A91y it's very common to use Styled components along with any UI library. In-fact this is the standard approach used in most enterprise companies ( at-least at Intuit and Atlassian) so that answers your concern about coding standards. If a component is available in UI library then we directly use it, else we use styled components. This can be easily documented. @jatinkrmalik can confirm this as he also has a fair share of experience working with big tech companies so we're actually sticking to the industry standards of frontend engineering and not just what one knows about.

Also, even if we stick to only a UI library, tomorrow if we want to use a component that does not exist in the UI library, we will anyways need to build it from scratch right? Styled components actually helps in that area as it makes that custom component reusable across the entire codebase.

Tbh, your response looks like it's generated from ChatGPT. I am more interested in understanding your actual concerns rather than what AI generates. If you can write that down, that'll be great.

[A91y]

@ShreyaPrasad1209 I totally understand now. So, looking for the industry standards and validation, I vote for the hybrid approach.

Actually, the reply was not AI generated, my thoughts were rephrased by GPT for better text styling and structure.

[jatinkrmalik]

Tbh, your response looks like it's generated from ChatGPT. I am more interested in understanding your actual concerns rather than what AI generates. If you can write that down, that'll be great.

• 💯

@A91y write less but clear!
GPT answers are just going to add a lot of filler text which is really not required here.

---

@ShreyaPrasad1209 Looks like we are good to go ahead with this?

[ShreyaPrasad1209]

@jatinkrmalik yes. We can move ahead with deciding which UI library we can use in conjunction with styled-components. Here's a list of libraries from which we can choose. @A91y please go through the list and let me know your preferences?

[vivekpal1]

As a new member joining this discussion, I've been following the conversation, would like to share my thoughts.

I strongly advocate for the creation of custom UI components using Tailwind CSS.

In the initial stages of our project, to expedite the development and ensure a consistent UI, I suggest we consider integrating a components library like shadcn/ui or NextUI. That I have already begun integrating shadcn/ui. These libraries offer a range of pre-built components that align well with Tailwind's philosophy and can serve as a solid foundation for our UI.

Also using CSS Variables can get more scalability in our code. Shadcn/UI is already handy for doing that.

Looking ahead, I'd suggest developing our custom UI library with Tailwind. This will allow us greater control over our UI design and ensure that our components are perfectly tailored to the specific needs and aesthetics of the Bloom.