[neg4n]

Thanks! I agree that benefits in web dev are generally low for most of the cases where it would be applicable (only technically). In small/medium products the data volume and the frequency of its transfer is not that high to even consider optimizing it and the runtime gains are quite not important if you're not writing game servers in JavaScript/TypeScript. It can also be cumbersome at DX level, especially for people that haven't worked on the bits level.

The benefits of applying it in cases of enormous data transfer and its volume on disk are also not that big (I did projected benchmarks of bandwidth and disk usage in the article), as things replaced by bit flags are possibly only a drop in the ocean in such application's backends. But still - it is one of an option of the optimization.

And if you decide to go with the bit flags implementation - I must respectfully disagree with changing stack being classified as the low hanging fruit to pick. In my opinion it is the most error-prone event that could happen in development lifecycle of any product. Both from business and technical perspective considering factors such as talent pool availability, team mentoring, migration process, testing the systems on automated/real users level and likely loads more. All these things introduce costs and time complexity. It would be a tough decision to make for the CTO.

I may be wrong but IMHO it would be easier to hire one guy that knows systems from a little lower level perspective, mentoring the team (that have web dev only knowledge) and establishing solid development rules while proceeding with bit flags than migrating whole (or even a part) application to the other stack, changing the team completely or creating a possibly terrible in its results responsibility of one developer to manage it.

Curious to hear different opinions!