Group-income-simple: Progressively remove Bulma from the project (Ongoing)

[taoeffect]

Problem

PR #537 introduced a concern related to massive changes to bulma, where entire files were copy/pasted and modified, possibly violating our CSS style guidelines for overriding bulma.

However, the rest of the PR looked good and so to move things along I decided to merge it and deal with this issue later.

Solution

Discuss and figure out a solution to the concerns linked above, and copied here:

---

I have two concerns with this approach:

1. It's not clear what changes you're making to bulma with this approach
2. If bulma updates itself, and diverges from your changes here, then it's possible that there could be a conflict between bulma and our changes, in which case it would be better to simply fork bulma completely and avoid having to merge back changes

Thoughts? Also would like to hear @sandrina-p's thoughts if she's around.

[pieer]

CSS framework help for fews things:

• Quick prototyping
• Give developers some help when they have no notion of UX and design
• Help developers to learn about good practice
• Fix differences between browsers
• Give some guidelines to structure css code and maintain multiple projects

In our case, we would probably better off any framework for few reasons:

• We're looking for clean code easy to maintain more than prototyping quickly
• We have an excellent UX designer in the team
• We have experienced frontend developers in the team (wink wink) that knows best practices
• We're working on evergreen browsers and those fixes are not very useful anymore (but still with graceful degradation) and now thanks to flexbox, it's super easy to style anything
• We have only one project here and we don't need to keep track of multiple components in many projects
• Bulma structure is not perfect for our code as the components included in bulma are different than the one we develop in term of design and also functionality.
  Vue (and modern javascript framework) tend to embed the css of the component inside the component. Only very few elements like fonts definitions, icons, spacing, colors and in general everything that is defined in CSS variables should be outside of the components.
  But at the moment we have the component CSS split in 3 files (the component css, bulma components css and the override of bulma component). This is not really easy to maintain..
  And in some cases, impossible without using this ugly !important hack...

But I don't think it's a good idea either to scratch all the code that we have already done.
We can use what we have and slowly integrate all of the bulma base into a clean css.

And this is what I'm doing here. I like to keep bulma CSS files that are not touched yet, so it's easier to see what is coming from Bulma and what is not at the moment.
This way we might be able to remove completely unused components like breadcrumb, menu, navbar, pagination, tabs etc..

[pieer]

Concerning the updates of Bulma:
Never in my carrier I ever upgraded a css framework in any project, and that for few reasons:

• Unlike javascript frameworks, CSS frameworks don't change very often
• Bugs that are fixed in minor versions of bulma are most of the time fixed in the project already
• It would generate a lot of work to test everything that the new framework could break
• It would cost time to fix all the new bugs for probably almost no benefices

[sandrina-p]

Hi guys 👋

Personally, I _never_ use CSS frameworks on personal projects because of all the reasons @pieer said above.

Still, I did the effort of keeping Bulma when I joined Group Income and tried to find the easiest way of overriding Bulma per file for better readability (thinking on developers without much frontend experience). Also because redesigns were happening all the time and we didn't have a Design System. At the end of the day, this project is still a prototype and a lot can still change.

On the other side... one of our goals was (and still is) to get rid of external dependencies as much as possible. That includes Bulma. So, sooner or later we won't have the "Bulma" concept in this project anymore.
Now that we have a rock start Designer and experienced CSS developers (wink wink) I believe we are ready to take the leap and start the migration. However, I suggest a slightly different approach:

Instead of blind "fork" a Bulma's CSS file and override what we need, we should go a step further that can only be done in this exactly moment (in the beginning of a migration): When it comes to "fork" a CSS file, we must review all the code of that file and delete/change what doesn't make sense for us. That's how we have a "clean code easy to maintain". For example, we forked button and form and I'm sure we still have there code we don't use at all. (for example .is-inverted modifer , .radio, . file, etc..)

If we don't delete it now, the probability of deleting it in the future is very low because "everyone will be afraid of breaking stuff". Since this is still a prototype, the sooner we break, the faster we recover. 🚀

[pieer]

So if I understand, you agree with me on this but you also want to remove the bulma elements that we don't use at the moment.
This is actually what I'm doing at the exception of the modifiers like the one you mention because it could be useful in the following months (I will definitely use .is-inverted for the new dark theme)

[pieer]

On the side note, I have to add that few times on this project I've been asked to not use "advanced" concept, to allow a better integration of developer without much frontend experience.
Even though this is a good intention originally, in reality there is few caveats to this concept:

• Experienced developer can't use the tools they have to write the best code
• It slow down the process
• New developer don't learn
• Encourage bad frontend technics

[sandrina-p]

So if I understand, you agree with me on this but you also want to remove the bulma elements that we don't use at the moment.

Exactly that. Also, change the syntax to SCSS to keep consistency between all the files, because now that file is "ours", not Bulma's anymore.

This is actually what I'm doing at the exception of the modifiers like the one you mention because it could be useful in the following months (I will definitely use .is-inverted for the new dark theme)

When we get there, if you are not the one to do it, the probability of adding .is-dark and .is-inverted being forgotten might be higher than directly using .is-inverted. (I could start arguing now why I don't like .is-inverted but that's not the topic now hahah). What I want to say is, if you don't need it now, clean it. Once we need it the future, we add it. Or, at the very least, leave a comment on the code explaining why it wasn't deleted, even if it isn't being used. I do like to leave comments when we make "not straightforward" decisions in the code. It always help someone in the future (sometimes even ourselves!)

Even though this is a good intention originally, in reality there is few caveats to this concept: (...)

I agree with you. I believe that's where good documentation and code comments come into place and everyone can learn.

[sandrina-p]

Just to complement... I thought more about it in the way back to home... And actually maybe I think is better to keep as we have for a little longer. At least until we are close to finish the MVP, so we have a more "solid CSS project" and a better vision of what we need and what we don't. After that, I believe it's the right time to extract Bulma.

But one thing is for sure: once we decide to remove Bulma from GI, the approach @pieer is doing with the tweaks I mentioned before, is the best approach to take.

I think at the end, @taoeffect, you are the best person to decide if you feel it's time to start removing Bulma from GI or not.

[pieer]

Well I disagree, as adding more hacks to override the CSS framework is not good, but I'll let Greg decide.
If we rollback I'll need to change the previous commits alsoe, since I've already started to migrate bulma css component a month ago (and we already had a discussion about that at the time...)

[sandrina-p]

Maybe I was not clear. To me is totally okay to do the migration right now.

My only concern of doing it now, is to do it well: Delete the useless code. Keep everything consistent and organized. Document the migrations and decisions along the way. If we do all of that, I think it's a safe route to go.

[pieer]

Ok. So to clarify for @taoeffect, the decision now is between:

• Spending time now to remove all the modifiers that we don't use from Bulma
• Keep modifiers a little longer and clean the CSS later once we know what elements we should keep or not

NB: Components that we don't use are anyway not included atm. So it's just a question of modifier like ".is-inverted"

[taoeffect]

Thank you folks for a very informative thread, I've read through it all now and have added reaction emojis to many of your comments, so some progress has already been made! 😄 (joke)

the decision now is between:

From what I've read above, it seems like both of you are basically on the same page, with @sandrina-p favoring a more active effort in removing things we aren't using (and more quickly getting rid of Bulma), but other than the pace of things, both of you agree with one another, is that about right?

If so, let's just do like this: feel free to continue to "fork Bulma progressively", at a pace that suits either of you. Whenever Sandrina submits PRs, she can remove unused selectors as rapidly as she likes, and same to you Pierre. Eventually, Bulma will be gone, and we'll be left with very beautiful CSS, that is specific to our needs. Sound OK?

[sandrina-p]

It sounds great to me!

[taoeffect]

Closed in #573