I loved writing 100 words for 100 days & now want to write 100 days of little HTML, CSS or JS lessons. I'm going to write about methods and techniques that I use often, either
at work or on personal projects. The lessons will be written from a NEWBIE (i.e. my) perspective, and so may not be perfect, but they will offer a valuable insight into the thoughts of a new developer. My goal is to learn/document things for myself, and to show people, particularly other new developers, how someone like me approaches my work and hopefully give them something they can relate to :)
Thanks to Charlotte for the suggestion!
Write about a different pseudo class every day? Or a different HTML element or JS lesson every day? Anything
you want to learn more about? I had hoped to do something similar and never got round to it.
I keep getting tripped up at work by forgetting to write modular CSS classes. There are so many benefits
to a robust CSS architecture that I really want to get it right. BEM is a methodology to achieve this.
Block, Element and Modifier. A Block is a component
or feature than can stand alone and is not dependent on any other code. It can be re-used anywhere. Next,
an Element. This is always part of a Block and has no meaning on its own. Lastly,
there is the Modifier. This changes the behaviour and/or appearance of a Block or Element.
function in the list is written without fat arrows. The last three functions are variations of the first
function, showing how fat arrows can be used to write shorter function expressions, and therefore less
code. You will need a code compiler like Babel to compile fat arrows
There are a _lot_ of resources that try explaining this syntax. Try Wes Bos's introduction for a start. This is complicated subject matter, though, so I suggest searching around for different
posts, reading a few and finding ones that make most sense to you.
I only just found out that ::before (:before) and ::after (:after)
are psuedo elements, which are different from psuedo classes. Both of these are grouped under psuedo
selectors. I like this quote from MDN ~
Even the most skilled web developers are still amazed by what's possible using selectors.
Psuedo selectors are only two types of selectors. The others are: simple selectors, attribute selectors,
multiple selectors and combinators. All of these help us to target and style HTML elements.
So, psuedo selectors include both psuedo elements and psuedo classes. They are added to the end of other
selectors, and don't apply to whole elements, only parts of them.
The psuedo classes (e.g. :hover, :focus, and :nth-of-type() -
plus 38 others) style elements in a certain state.
The psuedo elements (e.g. ::after, ::before, and ::first-letter - plus 3 others, not including experimental ones) apparently need :: rather than :,
although I've used them with only one. These don't depend on the state of an element.
See this MDN page for great examples and to use their awesome active learning playground (I did and it was great
The this keyword is found in various programming languages, and behaves a certain way in
The button below logs to the console.
codepen for the code. It showcases
Liew's great blog post. I really recommend this post
for beginners - you can try the examples in your console! In short, this can be used
globally, in object constructions, object methods, simple functions, arrow functions, and event listeners.
See the MDN docs for more code-heavy examples.
Recently, I began to write React at work and I've been doing okay with presentational components, but much less so with business
logic (I hear ya Brad Frost).
I've heard that improving my ES6 will really help, so you'll see more little lessons on it, but I also
want to touch on how to manage dynamic state. Despite the popularity of Redux, one of my developer friends
recommended covering Flux.
Flux is an application architecture for React (that can also be used elsewhere) utilizing a unidirectional
data flow. In essence, it is an observer pattern that offers one-way data binding. Very useful when
you need to keep lots of components in sync.
action -> dispatcher -> store -> view
The action creator formats messages (what the user does) from the UI
The dispatcher takes the formatted messages and synchronously sends them to different
The store holds all state logic and changes it by deciding what actions it wants
to pay attention to
The view takes changes from the store and updates the UI
Please look at Lin Clark's great cartoon guide for more details. For a more code-heavy example, see here.
I feel like the best way to learn about Flux is to build things in tandem with reading about it (and
finding nice developers who can guide you)!
data on a site, and for it to be shared across sites. I first heard of it at
Beyond Tellerrand in Düsseldorf on May 7th, during a talk about web annotations by Lyza Danger Gardner.
data. It can be thought of as JSON, but with added semantics. And it can be easily implemented into
existing JSON structures. Here's some example JSON:
Above, we see that context can be added to data. foaf stands for "friend
of a friend" (see here), which deals with people-related
terms. id and type, like context, assist in making our
data shareable and semantic.
The concept of JSON-LD is simple, but using it can take getting used to. For more in-depth information,
CSS layout is something that amazes and confuses me at the same time. There seem to be so many approaches (e.g. floats, flexbox, grid), and so many frameworks (way too many to mention). The paradox of choice seems to apply here.
I love hearing from people about CSS layout, and I was lucky to hear Miriam Suzanne talk about it at Beyond Tellerrand (check out the awesome layout on her site). The message she gave was to use CSS grid, and provide fallbacks for browsers that aren't grid-compatible. She reasons that as grid makes layouts so easy (and naturally responsive), that there is time to re-create fallback layouts, which allows more creative control.
Often I allow fallback layouts to be much simpler. CSS Grid has power to create layouts that have no *exact* fallback. Since grid makes many layouts easier, I have extra time to do both. Similar time spent, more creative control.
One thing I really like about CSS layouts is that they aren't designed to be used in isolation. On the contrary, you can mix and match them. A grid item can become a flex container, and a flex item can become a grid. You can even use floats with flexbox and grid.
I am half-way through Wes Bos's CSS grid course and already have ideas I am excited to make come to life using grid. There are looots of great posts and articles out there by people who have had tonnes of fun and learned loads by using grid. I really recommend finding some and making some stuff!
The debugger can do a lot, and it'd take a much longer post to walk through this tool's UI, so I'll mention four of the most commonly used debugging methods here.
Step over code
Steps over a function that doesn't contain a bug and runs its code
Step into code
Steps inside a function and allows you to run each part separately
Step out of code
Steps out of a function you are inside, and runs its code
Resume execution of code
Runs all code up until a specified breakpoint, which can be set at any point
Debugging is something developers have to be really good at. So don't be scared to do it! Or, be scared but do it anyway, you'll get better :)