Simple is best, especially if you get benefit, without loss:

Consider the following examples from the development of the Pagy library.

All Contributor’s List

There was always a long standing requirement (nice-to-have) for users to be listed as contributors.

Consider the solutions available:

1. Use an existing solution off the shelf:

   • e.g. a Github Action
   • copy a script from online or

2. Roll your own

How would you assess the options?

The Github Action seemed easiest: press a button and you’re done. But there’s a lot of complexity behind that button: are you ok with it? I was ok with it: but there was a problem…..it didn’t work. Github actions add complexity: there are more moving pieces. I was looking at the problem the wrong way:

Domizio Demichelis, author of the Pagy library reasoned:

1. Start from first principles: what is it that you want?
2. Do existing solutions give you what you want?
3. And if not, what is the difficulty in rolling your own?

Let me quote it verbatim:

too many time(s) I get caught into trying to use tools already made… forgetting that if you analyze your actual goal, getting it from first principles could be a lot simpler and convenient

He was correct. The final script is a marvel in simplicity:

1. All the information is available in JSON format.
2. The script grabs the JSON format and essentially dumps it in the readme (in mark-down format), in-between two magic comments.

The further benefits, as outlined by the author:

tables are fixed column layout with ugly border and padding, without any feedback for the user, while the contributions are simple markdown img links with titles (tooltip), dynamic columns, no border nor padding and layout reactive.

We got more, with less.

CodeCov

Do we need it? Is it simple?

Codecov … made me waste endless time. Difficult to track it down and fix [bugs]….What was I was thinking when I added it?

And then he rationalised that SimpleCov was better and it had an action - and to simplify it even further: an action was not needed, because:

It’s actually “simplification while getting more benefits” because Codecov might fail the step in upload still being 100% covered, or not failing at all even with 0% coverage, while my little task simply works as intended…

Making the Styles bigger

What if you want to make the style of the “next” caret in pagy bigger? You could:

(i) use a template (over-kill) (ii) use a different caret (perhaps one exists - there are many) (iii) use css to target the relevant html element - possible - but you won’t target the specific node (iv) or use Domizio’s suggestion: edit the locales dictionary, add in custom html, and use that html to hook some css to that element, to change the size.

Again, simple. An innovative solution. Read the complete discussion here.

Complex Stylesheets

In the Pagy library, when I initially saw a PR for tailwind - I was overjoyed. I didn’t vet it too carefully.

• My thought process in accepting: did it work? If yes: accept the PR.

This is not a great value-add as a maintainer: one must exercise some judgment: is this a “simple” way of writing styles? It requires some judgment, and I regret to admit: I didn’t know any better. “If it works - that’s good enough” is not a great attitude. I say this with the utmost respect to any contributor - I do not mean to dminish their contributions, which I greatly appreciate.

Our main contributor Domozio stumbled upon and realised: “hey, we can make this simpler”. And so he did. Here is the commit.

Summary

Simple and beneficial is the best.

Credit

I am not the originator of these ideas: they are due to Domizio Demichelis.

I thought it fitting that they be noted, before they are lost like tears in the rain.