It shocks me to see how many programmers think such framework decisions are one-size-fits-all and jump to conclusion that such framework adoption decisions are is due to lack of skillset and experience.

There are many factors at play. You have time to build and maintain your own utility framework, please go ahead.

Two years ago, I led a team which developed a web app that generated 600 million impressions per year. We used Tailwind because we were a small team and I’d rather have my developers work on high value tasks and not maintain a style framework.

If you are an aspiring developer, know this: There are always trade-offs. Not writing pure CSS does not make you a bad developer. Not knowing system design does.

This is awesome. I have been downloading everything manually on Soulseek since the dawn of time. Now I can effortlessly have a local copy of my entire saved music library. Thanks!

Yes, firmware running on bare metal requires good resource management. My current development board processor contains 512KB SRAM. That’s equivalent to half of the size of an average PDF.

Inventors of this flavour are brilliant and surprisingly innovative. Here’s a video that explains the creative process behind it.

I elaborated on it below. Your team will grow and shrink. No guarantee that each developer will bring the same IDE. This is especially true for open source projects.

If it works your team, no need to be dogmatic about it. Just be careful about what you put there and agree on a set of sane defaults with your team. Your project should build and run tasks without needing a specific IDE.

Linting rules and scripts should never live in an IDE-specific directory. I should not need to know your IDE configuration to run scripts and lint my files.

I have yet to come across a language that requires configuration to be stored that way. All modern languages have separate configuration and metadata files for use cases you have defined.

As for workspace defaults, whatever IDE configuration works for you is not guaranteed to work for others. Shoving extension suggestions down their throat each time IDE is booted should not be a part of your source code, as IDE extensions should not be needed to run your code.

I personally strongly advise against committing IDE junk to version control. Assuming your IDE workspace defaults are “sane” for the rest of the contributors is not a good practice.

Shared this with my team just recently. Guess there is a lot more of these brilliant edits.