Yup, I guess I should just be a bit less lazy and give a bit more context for each section :)
Some things are just personal preferences and some things are just completely subjective. Overall, though, these advices tend to make front-end code better. The JS part, for example, is largely based on functional programming best practices. Things like immutability, statelessness and the point about JS performance aren't subjective: they'll basically always improve your code's quality.
Some of these examples are valid and should be common knowledge for all web developers (e.g.: treating CSS semicolons as terminators rather than separators; transitions; unitless values; all [+1]), and some of these examples are a bit questionable. The code style seems a bit esoteric, especially some of the ES. Also, not many of these examples would pass an HTML validator without warnings due to the lack of quotes surrounding attributes. Just a caveat..
I vehemently disagree with the recommendation on box models. I'm of the opinion that `border-box` leads to cleaner, terser css. Working around the default box model results in all kinds of CSS gymnastics that some poor person is going to have to figure out in a few months time when they pick up the project.
I also can't agree with the recommendation on using pixel values over relative values. I guess most people are using some sort of CSS preprocessor these days, so a pixel to rem mixin would be my recommendation.
Not to poo-poo the whole thing though. A lot of that stuff I agree with. A small amount I don't, and a couple of things I think are up for debate.
I guess I should clarify this example. I’m mostly fine with a global * { box-sizing: border-box; }, I’m only opposed to changing the box model randomly. The example illustrates a bad usage where changing the box model to get a full-width element is fundamentally wrong (since it’s the default behavior of block elements anyway).
It's an IFFE (Immediately-Invoked Function Expression). The goal is to perform the feature test (the availability of Array.from in this case) just once instead of for every function call.
I like a LOT of these comments, but some just leave me scratching my head:
// bad
void function() { /* IIFE / }();
// good
(function() { / IIFE */ }());
To me, the "bad" one was more readable until I noticed you were invoking the function. Personally, I don't like either notation, but the point is that this example (along with quite a few others) seems to need more explanation to get the point across.
I would maybe think about defining "IIFE" as well as maybe sectioning off the more "functional programming" sections.
Thank you for taking the time to put this together.
10 comments
[ 3.5 ms ] story [ 42.5 ms ] threadIs there any explanation for the reason for a lot of these things?
Some things are just personal preferences and some things are just completely subjective. Overall, though, these advices tend to make front-end code better. The JS part, for example, is largely based on functional programming best practices. Things like immutability, statelessness and the point about JS performance aren't subjective: they'll basically always improve your code's quality.
I also can't agree with the recommendation on using pixel values over relative values. I guess most people are using some sort of CSS preprocessor these days, so a pixel to rem mixin would be my recommendation.
Not to poo-poo the whole thing though. A lot of that stuff I agree with. A small amount I don't, and a couple of things I think are up for debate.
const toArray = (() => Array.from ? Array.from : obj => [].slice.call(obj) )();
// bad void function() { /* IIFE / }();
// good (function() { / IIFE */ }());
To me, the "bad" one was more readable until I noticed you were invoking the function. Personally, I don't like either notation, but the point is that this example (along with quite a few others) seems to need more explanation to get the point across.
I would maybe think about defining "IIFE" as well as maybe sectioning off the more "functional programming" sections.
Thank you for taking the time to put this together.