Ever get annoyed by people who tell you the web will never compare to native apps and wish you could send them a comprehensive slap in website form? If so, this is pretty awesome. Not only does it list a lot of things there are modern web APIs for, it also displays whether your current browser supports each one.
The box alignment specification details how items are aligned in the various layout methods. As different layout methods pose different constraints in terms of alignment, some of the behaviour of Box Alignment is layout method dependent. This cheatsheet compares alignment in CSS Grid Layout and Flexbox.
Want to know which ECMAScript features are supported by which transpilers, browsers, and other environments? This seems like an excellent resource for that.
If you ever wanted a mini-cheat sheet for what every part of a CSS rule is called, here it is:
- The whole thing is a ruleset.
- The curly braces and everything inside is a declaration block.
- The bit before the opening curly brace is a selector.
- Each key/value pair, as separated by a colon and ending in a semicolon, is a declaration.
- In those key/value pairs, the key is a property (or property name), and the value is a value (or property value).
This is excellent and you should read it all.
Software engineering principles, from Robert C. Martin’s book Clean Code, adapted for JavaScript. This is not a style guide. It’s a guide to producing readable, reusable, and refactorable software in JavaScript.
Not every principle herein has to be strictly followed, and even fewer will be universally agreed upon. These are guidelines and nothing more, but they are ones codified over many years of collective experience by the authors of Clean Code.
Our craft of software engineering is just a bit over 50 years old, and we are still learning a lot. When software architecture is as old as architecture itself, maybe then we will have harder rules to follow. For now, let these guidelines serve as a touchstone by which to assess the quality of the JavaScript code that you and your team produce.
One more thing: knowing these won’t immediately make you a better software developer, and working with them for many years doesn’t mean you won’t make mistakes. Every piece of code starts as a first draft, like wet clay getting shaped into its final form. Finally, we chisel away the imperfections when we review it with our peers. Don’t beat yourself up for first drafts that need improvement. Beat up the code instead!
