Some HTML, CSS and ES2015 Best Practices

https://github.com/bendc/frontend-guidelines

by benjamindc • 11 years ago

18 10 11 years ago

github.com

mattchamb• 11 years ago

Lots of "whats", not many "whys"

Is there any explanation for the reason for a lot of these things?

benjamindc4• 11 years ago

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.

bjornsteffanson• 11 years ago

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..

benjamindc4• 11 years ago

You're wrong, the HTML is valid.

tomelders2• 11 years ago

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.

benjamindc4• 11 years ago

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).

tomelders2• 11 years ago

Oh, in that case I vehemently agree

malft• 11 years ago

Several of the examples have an extra lambda like this. What does it do?

const toArray = (() => Array.from ? Array.from : obj => [].slice.call(obj) )();

benjamindc4• 11 years ago

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.

beernutz• 11 years ago

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.

Some HTML, CSS and ES2015 Best Practices

Related Stories