Add skruv

[SvanteRichter]

This adds the skruv micro-framework.

I read some of the discussions around requestAnimationFrame (like in #430) which I use to schedule a render, but since my framework leaves scheduling of renders up to the user (and it renders the whole tree, not just the deleted row) that's fine, I hope. Let me know otherwise and if I should change the scheduling to setTimeout/requestIdleCallback or similar.

I did not do any build steps as that is my preferred/recommended way to use it, I'm sure some metrics would be better if I did. I might open a PR for such a benchmark in the future if that's fine.

Most of the implementation is copied from the hyperapp one since that is the other framework I've been using recently and the way to structure the views feels similar.

Results from my machine compared to hyperapp, vue, react do not show anything too far out of normal (although they are better for skruv than I thought) to indicate something being totally wrong, but that's just my guess:

It uses one "hack", but that is not really decided on how to deal with it, I have an issue for fixing/documenting in skruv/skruv#2

I'm new to both writing frameworks and contributing benchmarks, so please let me know what I can do better in the future :)

[krausest]

Thanks. Using RAF for just some operations in the benchmark should be regarded as cheating. Using RAF for all operations should be acceptable, but might be considered a code smell. I added a note to the implementation (when I find the time it should be yellow for notes and red for issues. This one would be yellow)
Here are the results on my machine:

[SvanteRichter]

@krausest Thanks! What would be your suggestion to schedule a render for a bunch of different state changes that happen within a short time? I'm looking for something to only schedule one render for a bunch of state changes that happen within short intervals.

Is setTimeout with a low timeout (1-2) better for this or is RAF considered a codesmell mostly because it has potential for cheating? Or would it be better to just do the work on the next tick via setTimeout with timeout 0?

[ryansolid]

It's an interesting area. Some frameworks schedule under the hood by default to do this batching like you described. Most commonly using a microtask (like a Promise resolution). Some use animation frames since in theory why do any updates quicker than the end-user would see.

Animation Frame is actually slower for most of these operations but improves performance on a couple. So in the past people abused this (myself included). So while it might seem overly manual to have that be the question posed to the end-user, if that's the position being taken it's consistent. It's just a unique choice to not have a default batching behavior so when you see it you immediately ask is something specific to this benchmark suite is being done.

[krausest]

@SahAssar Sorry I can't give you good advice on that except that as a user I'd rather prefer the framework to solve that problem for me.