Charles Nelson cfnelson

Frontend Development

Attention: the list was moved to

https://github.com/dypsilon/frontend-dev-bookmarks

This page is not maintained anymore, please update your bookmarks.

The introduction to Reactive Programming you've been missing

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

Table of Contents generated with DocToc

FrontEnd Masters - ES6 notes
Rest Parameters

Use these rapid keyboard shortcuts to control the GitHub Atom text editor on macOS.

Key to the Keys

⌘ : Command key
⌃ : Control key
⌫ : Delete key
← : Left arrow key
→ : Right arrow key
↑ : Up arrow key

Turning Off Github Issues

My friend Michael Jackson turned off github issues on one of his smaller projects. It got me thinking...

Maintainers getting burned out is a problem. Not just for the users of a project but the mental health of the maintainer. It's a big deal for both parties. Consumers want great tools, maintainers want to create them, but maintainers don't want to be L1 tech support, that's why they

"Parens and Performance" – counterpost

Kyle Simpson (@getify) wrote a very thoughtful post decrying optimize-js, which is a tool I wrote that exploits known optimizations in JavaScript engines to make JS bundles parse faster (especially minified bundles, due to what could be reasonably described as a bug in Uglify).

Kyle lays out a good case, but I tend to disagree with nearly all his points. So here's my rebuttal.

Raise Open File Limits in OS X

in OS X 10.4 to macOS sierra 10.12 and maybe higher!

Create Launcher Script:

`/Library/LaunchDaemons/limit.maxfiles.plist`

Copy this entire code block and paste it into your terminal and push Return to create this file for you with correct permissions. It will (probably) ask for your password:

Problem: How can we preprocess JavaScript (at build-time or on the server-side) so engines like V8 don't have to spend as much time in Parse? This is a topic that involves generating either bytecode or a bytecode-like-abstraction that an engine would need to accept. For folks that don't know, modern web apps typically spend a lot longer in Parsing & Compiling JS than you may think.

Yoav: This can particularly be an issue on mobile. Same files getting parsed all the time for users. Theoretically if we moved the parsing work to the server-side, we would have to worry about it less.
One angle to this problem is we all ship too much JavaScript. That's one perspective. We could also look at preprocessing.
We've been talking about this topic over the last few weeks a bit with V8. There were three main options proposed.
1. Similar to what optimize-js does. Identify IIFEs and mark them as such so the browser and VMs heuristics will catch them and do a better job than today. optimize-js only tackles IIFE bu

	#!/bin/bash

	cat $(find app/assets/stylesheets/ -type f) \|
	grep -Eo '\.[a-z]+[a-z0-9_-]*' \| sort \| uniq \| sed s/.// \|

	while read CSS; do
	if ! grep -Erqi "([^(remove\|has)]?class[(:\|=\|[:space:]=>[:space:])][[:space:]\W][(\"\|')][-a-z0-9[:space:]]$CSS\|\\.$CSS\b)" app/views/ vendor/assets/ app/assets/javascripts/; then
	echo $CSS >> unused.scss;
	fi
	done

	// See https://blog.isquaredsoftware.com/presentations/react-redux-ts-intro-2020-12/#/36 for slides
	// My basic render function structure:
	function RenderLogicExample({
	someBoolean, // 1) Destructure values from `props` object
	someList,
	}) {
	// 2) Declare state values
	const [a, setA] = useState(0);
	const [b, setB] = useState(0);