use assign helper, to avoid compatibility headaches

[Rich-Harris]

This fixes #431. It adds ~100 bytes to an app (presumably less after gzip), so there's an argument against doing it, but it does mean that people stuck supporting IE11 and old Android phones don't need to do anything extra to get their Svelte apps running.

Thoughts? Should it be behind a legacy option, or is that unwanted complexity?

[Conduitry]

My initial thought was that this should be behind some sort of option, but that was when I thought this only affected older Android browsers. I had no idea (or I had completely forgotten) that even IE11 didn't support Object.assign!

Hm. I guess the 100 bytes aren't terrible, but do we know what the performance difference is between native Object.assign and this helper on browsers that do support it? On top of the extra bytes, I'd hate to also slow down modern browsers. There's not anything in theory stopping us from using Object.assign when it's present, it just seems like it's not quite straightforward with the existing mechanism for helpers.

[Rich-Harris]

I'd naively expect it to be slightly faster, at least once it warms up, because it's not handling any of the funky edge cases that Object.assign needs to (bad arguments, hasOwnProperty nonsense, etc). But I haven't tried it on jsperf.com or anything

[Conduitry]

Oh, that's true. Eh, I don't feel a great need to run those performance tests. My vote is that this can go as-is 👍

[Rich-Harris]

I was curious so I put together a benchmark: https://jsperf.com/object-assign-vs-naive-assign/1

tl;dr, the helper blows away native Object.assign:

Chrome — 2.6x faster

Firefox — 16.2x faster

We're talking about fractions of milliseconds either way, but I'd say that speedup is worth 100 bytes.