Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve the section about extend #31
First off, you quoted Bieber and attributed it to Beyoncé. For that, I have this:
This is your guide, and thus you should have the final say. I still disagree with your thesis, but as you state at the beginning, it is an "opinionated styleguide".
As a note, I was just chatting with @elyseholladay who gave me some of the research of @drewwells that supported a suspicion I had about gzip. Although a deeper explanation can be found here, the gzip thesis can only be supported if all non-dynamic code is put together and file sizes are less than 32kb. If either of these are not true, then extra bloat will be added to the codebase. Now, how much and what is worth— I am not sure and would have to do some more practical tests. But I can say that I would still rather use @extend.
The rewritten sections looks great!
For more info... Gzip looks at files in 32kb blocks, so you still get benefits beyond 32kb. However, a 40kb file still benefits from compression. The code to be compressed must be in either the first 32kb or the last 8kb. Code crossing the boundary won't benefit from compression.
I'm with @HugoGiraudel about @extend. It provides some minor code optimizations but introduces a lot of headaches and novice users should be warned. It works well for very simple cases, but scaling @extend is tricky. I find more often that developers hang themselves from using it. @extend feels like a booby trap masquarading as composition/inheritance.