Brandon Dail aweary

`constant-locals-loader` for Webpack

This loader optimizes the output of mini-css-extract-plugin and/or css-loader, entirely removing the potentially large CSS classname mappings normally inlined into your bundle when using CSS Modules.

Run npm install constant-locals-loader, then make these changes in your Webpack config:

module.exports = {
 module: {

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

Speaker Rider

by Tatiana Mac

Last updated 14 April 2021

What is a speaker rider?

As speaking comes with immense privilege, I have crafted a speaker rider to set expectations and boundaries around my engagement. I am grateful to all the conference organisers who have brilliantly hosted me. I would love to continue to exercise this privilege to speak at conferences, and use this privilege to make the landscape more accessible and beneficial to tech's most historically excluded and marginalised communities.

Considerations

😫 I provide a lot of explanations for those of you who never had to consider these things. Most thoughtful conferences I've attended check most of these boxes intrinsically, particularly when conference runners are experienced speakers. They get it.

Algebraic Effects in JavaScript part 1 - continuations and control transfer

This is the first post of a series about Algebraic Effects and Handlers.

There are 2 ways to approach this topic:

Denotational: explain Algebraic Effects in terms of their meaning in mathematics/Category theory
Operational: explain the mechanic of Algebraic Effects by showing how they operate under a chosen runtime environment

Both approaches are valuables and give different insights on the topic. However, not everyone (including me), has the prerequisites to grasp the concepts of Category theory and Abstract Algebra. On the other hand, the operational approach is accessible to a much wider audience of programmers even if it doesn't provide the full picture.

Note:

When this guide is more complete, the plan is to move it into Prepack documentation.
For now I put it out as a gist to gather initial feedback.

A Gentle Introduction to Prepack (Part 1)

If you're building JavaScript apps, you might already be familiar with some tools that compile JavaScript code to equivalent JavaScript code:

Babel lets you use newer JavaScript language features, and outputs equivalent code that targets older JavaScript engines.

Demo: Coordinating async React with non-React views

tl;dr I built a demo illustrating what it might look like to add async rendering to Facebook's commenting interface, while ensuring it appears on the screen simultaneous to the server-rendered story.

A key benefit of async rendering is that large updates don't block the main thread; instead, the work is spread out and performed during idle periods using cooperative scheduling.

But once you make something async, you introduce the possibility that things may appear on the screen at separate times. Especially when you're dealing with multiple UI frameworks, as is often the case at Facebook.

How do we solve this with React?

	import * as bcrypt from "bcrypt";
	import { createCookieSessionStorage, redirect } from "remix";

	import { db } from "./db.server";

	export type LoginForm = {
	username: string;
	password: string;
	};

	use crate::type_context::{Element, TypeContext};
	use ::common::unique_name::UniqueName;
	use ::hir::{
	hir, BinOp, Binding, Expr, ExprKind, Lit, LitKind, Local, StatementKind,
	Type as HIRType, UnOp,
	};

	use ::hir::visit::{walk_component, walk_function, Visitor};
	use data_structures::HashMap;
	use diagnostics::ParseResult as Result;

	// This is a minimal UA sniffer, that only cares about the rendering/JS engine
	// name and version, which should be enough to do feature discrimination and
	// differential code loading.
	//
	// This is distinct from things like https://www.npmjs.com/package/ua-parser-js
	// which distinguish between different branded browsers that use the same rendering
	// engine. That sort of distinction is maybe useful for analytics purposes, but
	// for differential code loading it is overcomplicated.
	//
	// This is meant to demonstrate that UA sniffing is not really that hard if you're

	import { autorun, toJS } from 'mobx';
	import { props } from 'skatejs';

	export const withObserver = (Base = HTMLElement) =>
	class extends Base {
	constructor() {
	super();
	const { stores } = this;

	// This dynamically adds props post construction, so this happens for every instance that is created. One way to