SynchronousAsync.js

Infrastructure.js

let cache = new Map();
let pending = new Map();

function fetchTextSync(url) {
  if (cache.has(url)) {
    return cache.get(url);
  }
  if (pending.has(url)) {
    throw pending.get(url);
  }
  let promise = fetch(url).then(
    response => response.text()
  ).then(
    text => {
      pending.delete(url);
      cache.set(url, text);
    }
  );
  pending.set(url, promise);
  throw promise;
}

async function runPureTask(task) {
  for (;;) {
    try {
      return task();
    } catch (x) {
      if (x instanceof Promise) {
        await x;
      } else {
        throw x;
      }
    }
  }
}

Program.js

function getUserName(id) {
  var user = JSON.parse(fetchTextSync('/users/' + id));
  return user.name;
}

function getGreeting(name) {
  if (name === 'Seb') {
    return 'Hey';
  }
  return fetchTextSync('/greeting');
}

function getMessage() {
  let name = getUserName(123);
  return getGreeting(name) + ', ' + name + '!'; 
}

runPureTask(getMessage).then(message => console.log(message));

This is awesome. Couple of questions:

• Why does runPureTask() on line 18 have .then after it? Isn't the point to be able to call it all synchronously?
• What are perf implications in major browsers on relying on throwing the exception?

@jaredpalmer The point is not for the whole program and event loop to be synchronous. Just a small part of it. At some point you have to have a coordinator that says what happens to the rest of the program while you're blocked.

Note that this is not throwing an Error. Creating an error object can some times be a bit more expensive since that stores the stack trace. Throwing is not necessarily zero cost, but it's minor compared to the I/O that is happening here.

This thing is very much optimizing for most things to not block on I/O and is cached. The major downside is not the throw, it is that you may have to reuse some work if it does. If you're expecting to mostly hit I/O in many places I'd recommend async/await instead.

@jaredpalmer @sebmarkbage

I added promise rejection scenario (see "try this" comment) and composition of fetchTextSync:

https://gist.github.com/idibidiart/69fd5f9df339b5ef1783e6a8fae9fa51

I like how I can compose idiomatically with this, e.g.: let result = fetchSync('/test/1a') + ' ' + fetchSync('/test/1b')

This is brilliant dude, I am intrigued about algebraic effects now 🤩🤩🤩🤩

Huh, pretty cool.

The major downside is not the throw, it is that you may have to reuse some work if it does.

By this, do you mean that the "infinite" for loop will keep executing same code from start after each await, right?

@sebmarkbage
how is this better than writing fetchTextSync as generator function and using npm/co(Generator based control flow) instead of runPureTask. I mean yes, you doesn't bound to using genearor in your example, but still depends on async runPureTask.
I know it's different concepts and so on, but maybe you could explain why is your approach is generally better and what benefits it provides?