Kirill Morozov moki

Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.

My 3 developers team has just developed React.js application with 7668 lines of CSS (and just 2 !important). During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.

Here are main principles we use to write CSS for modern (IE11+) browsers:

SUIT CSS naming conventions + SUIT CSS design principles;
PostCSS + CSSNext. Future CSS syntax like variables, nesting, and autoprefixer are good enough;
Flexbox is awesome. No need for grid framework;
Normalize.css, base styles and variables are solid foundation for all components;

Edit — February 2019

This gist had a far larger impact than I imagined it would, and apparently people are still finding it, so a quick update:

TC39 is currently moving forward with a slightly different version of TLA, referred to as 'variant B', in which a module with TLA doesn't block sibling execution. This vastly reduces the danger of parallelizable work happening in serial and thereby delaying startup, which was the concern that motivated me to write this gist
In the wild, we're seeing (async main(){...}()) as a substitute for TLA. This completely eliminates the blocking problem (yay!) but it's less powerful, and harder to statically analyse (boo). In other words the lack of TLA is causing real problems
Therefore, a version of TLA that solves the original issue is a valuable addition to the language, and I'm in full support of the current proposal, which you can read here.

I'll leave the rest of this document unedited, for archaeological

This document has moved!

It's now here, in The Programmer's Compendium. The content is the same as before, but being part of the compendium means that it's actively maintained.

Storing Images and Demos in your Repo

In this quick walkthough you'll learn how to create a separate branch in your repo to house your screenshots and demo gifs for use in your master's readme.

How to

1. Clone a fresh copy of your repo

In order to prevent any loss of work it is best to clone the repo in a separate location to complete this task.

2. Create a new branch

Create a new branch in your repo by using git checkout --orphan assets

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

Learning FP the hard way: Experiences on the Elm language

by Ossi Hanhinen, @ohanhi

with the support of Futurice 💚.

Licensed under CC BY 4.0.

	// Custom promise-based compose
	const composeWithPromise = (...args) =>
	R.composeWith((f, val) => {
	if (val && val.then) {
	return val.then(f);
	}
	if (Array.isArray(val) && val.length && val[0] && val[0].then) {
	return Promise.all(val).then(f);
	}
	return f(val);

	FROM node:6-onbuild
	RUN mkdir -p /usr/src/app
	WORKDIR /usr/src/app
	COPY package.json /usr/src/app/
	RUN npm install
	COPY . /usr/src/app
	#next specific build
	RUN npm run build

	import React, { Component } from 'react'
	import { SubWidgetLink } from './routes'

	export default class MyComponentWithALink extends Component {
	render() {
	const { widget } = this.props

	return (
	<div>
	...

	var smoothScrolling = {
	// add smooth vertical scrolling to internal anchors
	init: function() {
	// if new native support available we don't need any of this
	var isSmoothScrollSupported = 'scrollBehavior' in document.documentElement.style;
	if (isSmoothScrollSupported) {
	return;
	}

	this.bindEvents();