Oleksander Skachkov gskachkov

In all the discussions about ES6 one thing is bugging me. I'm picking one random comment here from this io.js issue but it's something that comes up over and over again:

There's sentiment from one group that Node should have full support for Promises. While at the same time another group wants generator syntax support (e.g. var f = yield fs.stat(...)).

People keep putting generators, callbacks, co, thunks, control flow libraries, and promises into one bucket. If you read that list and you think "well, they are all kind of doing the same thing", then this is to you.

Re: http://blog.chromium.org/2015/03/new-javascript-techniques-for-rapid.html

V8 Optimisations to enable fast page startup

As mentioned in our Chromium blog post, Chrome 41 introduces support for streaming parsing of JavaScript files using the async or defer attributes. This is where the V8 parser will parse any incoming JavaScript piece-by-piece so the compiler can immediately begin compiling the AST when script loading has completed. This lets us do something useful while waiting for the page to load. Compare:

This means parsing can be removed from the critical path when loading up the page. In these cases such scripts are parsed on a separate thread as soon as the download begins, allowing parsing to complete very soon after the download has completed (milliseconds), leading to pages (potentially) loading much faster.

Parallel JS Strawman

Yes, this is a very significant departure from web workers, the current browser concurrency model. But I feel the lower level, more tightly integrated nature of it will make it far faster and lighter in practice, while still avoiding some significant footguns and working with the traditional single-threaded nature of JavaScript. Additionally, raw objects are much easier to deal with than pure message passing with workers.

Creating new threads

So here's my idea:

// parent.js

Overview

Cancellation follows a source -> sink model and consists of three components: Source, Sink, and Signal.

Source - Created by the caller of an asynchronous operation, a Source is a Signal producer.
- Represented in this proposal as CancellationSource.
Sink - Provided by the caller to an asynchronous operation, a Sink is a Signal consumer.
- A Source and its Sink are entangled.
- A Sink can only be used to consume or observe a cancellation Signal.
Represented in this proposal as a CancellationToken.

	/* This is the original elf.h file from the GNU C Library; I only removed
	the inclusion of feature.h and added definitions of __BEGIN_DECLS and
	__END_DECLS as documented in
	https://cmd.inp.nsk.su/old/cmd2/manuals/gnudocs/gnudocs/libtool/libtool_36.html

	On macOS, simply copy the file to /usr/local/include/.

	Mathias Lafeldt <[email protected]> */

	/* This file defines standard ELF types, structures, and macros.

	# -- mode: ruby --
	# vi: set ft=ruby :

	Vagrant.configure("2") do \|config\|
	config.vm.define "vagrant-windows"
	config.vm.box = "windows2008r2"

	# You should be using the vagrant-windows Vagrant Plugin!
	# Admin user name and password
	config.winrm.username = "Administrator"

	const CANCEL = Symbol();

	class CancellationToken {

	constructor() {
	this.cancelled = false;
	}

	throwIfCancelled() {
	if (this.isCancelled()) {

	import React, { Component } from 'react';
	import storeDecorator from './store-decorator';
	import someStore, { SOME_STORE_SYMBOL } from './some-reflux-store';

	@storeDecorator(someStore)
	class SomeComponent extends Component {
	render() {
	return (
	<div>
	{this.state[SOME_STORE_SYMBOL].someProperty}

	#!/usr/bin/env python

	import rospy
	import mavros
	from geometry_msgs.msg import PoseStamped
	from mavros.msg import State
	from mavros.srv import CommandBool, SetMode

	# callback method for state sub
	current_state = State()

	(module
	(func $addTwo (param i32 i32) (result i32)
	(i32.add
	(get_local 0)
	(get_local 1)))
	(export "addTwo" (func $addTwo)))