Martín Paredes mrtnpar

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.

A Starting Point for using Emacs & Evil-mode

(I wrote a bit about why Emacs and Vim on my blog and thought it might be nice to give some starting point for people that want to try it.)

If you just want to play around with Emacs & Evil mode do the following:

mkdir ~/.emacs.d/
copy init.el into ~/.emacs.d/
Download Emacs from http://emacsformacosx.com

Essential JavaScript Links

I no longer mantain this list. There are lots of other very comprehensive JavaScript link lists out there. Please see those, instead (Google "awesome JavaScript" for a start).

Algebraic Effects in JavaScript part 4 - Implementing Algebraic Effects and Handlers

This is the final part of a series about Algebraic Effects and Handlers.

Part 1 : continuations and control transfer
Part 2 : Capturing continuations with Generators
Part 3 : Delimited continuations
Part 4 : Implementing Algebraic Effects and handlers

So we've come to the core topic. The reality is that we've already covered most of it in the previous parts. Especially, in the third part, where we saw delimited continuations at work.

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

	const pipe = (...fns) => x => fns.reduce((v, f) => f(v), x);

	const fn1 = s => s.toLowerCase();
	const fn2 = s => s.split('').reverse().join('');
	const fn3 = s => s + '!'

	const newFunc = pipe(fn1, fn2, fn3);
	const result = newFunc('Time'); // emit!

	const curry = fn => (...args) => fn.bind(null, ...args);

	const map = curry((fn, arr) => arr.map(fn));

	const join = curry((str, arr) => arr.join(str));

	const toLowerCase = str => str.toLowerCase();

	const split = curry((splitOn, str) => str.split(splitOn));

	const wait = (
	time,
	cancel = Promise.reject()
	) => new Promise((resolve, reject) => {
	const timer = setTimeout(resolve, time);
	const noop = () => {};

	cancel.then(() => {
	clearTimeout(timer);
	reject(new Error('Cancelled'));

	// npm i web-streams-polyfill
	const streams = require("web-streams-polyfill");
	const {ReadableStream, WritableStream, TransformStream} = streams;

	// (default) object stream
	const rs1 = new ReadableStream({
	async start(controller) {
	// called by constructor
	console.log("[start]");
	controller.enqueue("a");