To your first issue, it might be because of the component is created, but it is not inserted into the DOM yet by the directive that created it yet. However I'm not sure if that's really the cause - would help if you can reproduce the bug in a fiddle.

To your nextTick question: because raf and setTimeout are not triggered by strictly counting the time, rather, they both simply put the task function into a queue, and the queue is guaranteed to be executed in order, even if it takes longer than 16ms/4ms to exhaust the queue.

I'll try to make a fiddle at work. The component is either created by a custom v-view or manually so in both cases, there is first the instantiation of the component, then a call to $appendTo. That might be it.

I understand now, it's actually basic DOM rendering! So it's in fact our job to minimize the job queue so the browser takes less than 16ms to render, and have a smooth experience.

Alright so, it was indeed coming from the fact that when a component is created procedurally, the ready hook is called before the VM is added to the DOM. I find this behavior odd because I was expecting ready to fire when the component $el is is compiled and attached to the DOM, not when the VM's fragment is compiled (and not inserted). Anyway I used a custom hook like this:

// Use the $appendTo callback to send the event
someComp.$appendTo($wrapper, function() {
    someComp.$emit('hook:added');
});

...

(in the component)
this.$on('hook:added', someAwesomeMethod);

And I don't need some weird double nested nextTick anymore. I should probably watch for both ready and added event before doing any DOM logic, but I'm feeling lazy.

You can also try this.$once('attached', cb) in created hook, although the attached hook is kinda unreliable sometimes.

Ah! Didn't think of this one, I thought attached was only called by v-if. Will try :)