yaku: Something strange (Slow resolve on pageload)

Hello hello

First things first, i like your library ❤️ 🙉 , it provides huge benefits compared to other promraries (promise-libraries 😄)! Mainly its size is a really killer feature! But the longStackTraces are a good thing too.

But now I found a very strange problem: As soon as I use Yaku with rollup or brunch (yes I tried both), I notice a very long wait time from resolve to then. It is loading and loading, while a bluebird promise which was started in the same time as yaku, already has resolved.

dec 25 2016 10-14 pm - edited

(When I try yaku promises after the page is fully loaded, it works without problems, this slow resolve only happens on pageload)

Do you have an idea?

This is the code:

Yaku.resolve().then(function() {
  console.log('yaku1')
})

Yaku.resolve().then(function() {
  console.log('yaku2')
})

bluebird.resolve().then(function() {
  console.log('bluebird')
})

One thing I noticed too is, that when I console.log(Yaku) this log takes the same time to complete as the Yaku resolves! It is very strange: first the log just outputs function, and then it magical changes the function to:

function Promise(executor) {
        var self = this,
            err;

        // "this._s" is the internal state of: pending, resolved or rejected
        // "this._v" is the internal value

       …

This is the rollup config I used:

var flow = require('rollup-plugin-flow');
import babel from 'rollup-plugin-babel';
var serve = require('rollup-plugin-serve')
var path = require('path')
import nodeResolve from 'rollup-plugin-node-resolve';
import commonjs from 'rollup-plugin-commonjs';

export default {
  entry: 'app/main.js',
  dest: 'app/assets/bundle.js',
  plugins: [ flow(), nodeResolve({
        jsnext: true, main: true
      }), commonjs(), serve({
    contentBase: path.join(__dirname, 'app', 'assets')
      }) ],
  format: 'umd'
};

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 23 (13 by maintainers)

Most upvoted comments

Thanks for the idea with the webpack configuration, i finally switched to rollup though 😃.

Now it works like a charm, and my lib is at 67 kb thanks to your lite approach 💃

katywings on Jan 4, 2017

By the way, Yaku had fast nextTick one year before, checkout the old version: https://github.com/ysmood/yaku/blob/59bb6511c27c8a262981685bed8ead4dc3569923/src/yaku.coffee#L350

I removed it a year ago to keep myself focused, but now I may revert it back.

ysmood on Dec 27, 2016

Great work! And it did remind me the weird behavior of webpack.

You can use this http://webpack.github.io/docs/configuration.html#node to disable webpack’s process shim, it’s enabled by default. In my experience, most times it only causes confusing.

ysmood on Dec 27, 2016

Good news! I found the problem, it was in my build process, complicated to give you a short description, but basically next-tick was packaged by webpack in a way like this:

function(process, setImmediate....) {
   ...nextTick...
}.call(shim, shim, shim, holy moly

Therefore nextTick just used webpacks setImmediate shim, which currently seems to be slow: https://github.com/webpack/webpack/issues/947

This only happend on the parts of the application, which were built by webpack. Yaku/nextTick, directly imported in rollup didn’t had the problem.

I will probably remove all of the webpack stuff from my build process and just go to rollup 😉

Behind the scenes: I use yaku in a state management library Alo, and that is currently built by webpack. And this issue #41 first occured only when I worked on a example for alo (separate repository), which was built using brunch. Thus it was very tricky to find the real root reason for the slow pageload 😦.

Thx for your help 🍰 !

If its okay for you, I will give you a closing-comment when I migrated/fixed the build process, and did a last test.

katywings on Dec 27, 2016

Thank you for your fast feedback! And that even in christmas time! 🍻

setimmediate speeded it up greatly, but its interestingly still slower than bluebird.

Here is the testing-environment 👩‍💻 bug.zip

Okay I tried it with an other nexttick library (https://github.com/medikoo/next-tick). This library had a better performance than setImmediate and the yaku logs showed up in the correct order (yaku before bluebird)

import bluebird from 'bluebird'
import Yaku from 'yaku'

//import setImmediate from 'setimmediate'
//
import nextTick from 'next-tick'
Yaku.nextTick = fn => nextTick(fn);

console.log(Yaku)

Yaku.resolve().then(function() {
  console.log('yaku1')
})

Yaku.resolve().then(function() {
  console.log('yaku2')
})

bluebird.resolve().then(function() {
  console.log('bluebird')
})

I think it would be very important to atleast show the nextTick info in the README at a more noticable position! What were your reasons to not include a nextTick in yaku? Size? Trust? 😃 next-tick is 1.86 KB-ish unminified 😄

katywings on Dec 26, 2016