Philip Roberts latentflip

Keybase proof

I hereby claim:

I am latentflip on github.
I am latentflip (https://keybase.io/latentflip) on keybase.
I have a public key ASBI6Z-jWtGaqeuOQNOJzfjfMbDQQVl26r7h8JHSTm3_2wo

To claim this, I am signing this object:

Install windows somehow. If you have a 16gb usb stick, you can do it with bootcamp assistant and an iso from: https://www.microsoft.com/en-gb/software-download/windows10ISO
- I think I chose pro but shouldn't really matter
Get visual studio installing cos it takes forever, use the community edition here: https://www.visualstudio.com/en-us/products/visual-studio-community-vs.aspx
The easiest way to get going with git on windows seems to be https://desktop.github.com/ that sets up keys etc for you
Install node and npm: https://nodejs.org/en/

Philip, I recently watched your youtube video on the event loop and found it to be very informative. In one of your examples it has a setTimout(...,0) and is followed by two console logs. Being that the setTimeout is a web API it is sent to the callback queue and finally to the call stack (once it has been cleared of the two console.logs). My confusion lies with the fact that console is a web API as show here(https://developer.mozilla.org/en-US/docs/Web/API) in the MDN. If console is a web API then doesn't it go to the task/callback queue just like setTimeout?

Thank you,

So the confusion is probably just because I glossed over the difference between an asynchronous web api, and a synchronous one.

The distinction between calling a "normal" JavaScript function (say Math.floor(5.5)) and one provided by a web api (like console.log('foo') or setTimeout(..., 0)) isn't solely about whether it's async (and so appears on the callback queue) or not.

Really the difference is whether it's a part of th

Run-time Debugger

This week I've been hacking around with some ideas about a runtime debugger for node (and probably browser JS too). These build upon some of the ideas loupe.

Run-time debugger is probably the wrong phrase, but I can't yet think of a better one - essentially what I mean is that all the code for building instrumenting/visualisating/debugging would be written in "userland" JS, rather than embedded in the JS engine itself.

This would obviously not be as powerful as a native engine debugger, with full access to the internals of v8 (or whichever engine), but I think the potential for hackability, and building things on top of it, is kinda interesting.

	<head>
	<!-- this will run -->
	<style nonce='1234'>
	.a {
	color: red;
	}
	</style>

	<!-- this won't run -->
	<style>

	module.exports = function transformer(file, api) {
	const j = api.jscodeshift;

	const update = path => {
	if (path.node.expression) {
	const body = j.blockStatement([j.expressionStatement(path.node.body)]);
	return j.functionExpression(path.node.id, path.node.params, body, true, false)
	}
	return j.functionExpression(path.node.id, path.node.params, path.node.body, true, false)
	};

	'use strict';

	const util = require('util');
	const execSync = require('child_process').execSync;

	const ignoreModules = [
	'react-heatpack-script-alias',
	'babel-runtime'
	];

	setTimeout(function () {
	console.log('DELAYED');
	}, 1000);

	var x = 10;
	var y = 100;

	function foo(y) {
	console.log(x,y);
	}

	'use strict';
	var State = require('ampersand-state');

	var ChildState = State.extend({
	props: {
	name: 'string'
	}
	});

	var ParentState = State.extend({

	var exec = require('child_process').exec;
	var config = require('./src/browser.webpack.config.js');
	var compiler = require('webpack')(config);
	var path = require('path');

	compiler.run(function (err, stats) {
	if (err) {
	throw err
	}

Philip Roberts latentflip

Keybase proof

Run-time Debugger

Loupe