Hacker News new | ask | show | jobs
by StevenWaterman 1691 days ago
You only see the finished product, not the 100 failures and incremental improvements over time. You could certainly write something yourself from scratch, but I doubt it would be competitive against this.
3 comments

> not the 100 failures and incremental improvements over time

This code has 3 actual code commits over 6 days, none of which changed anything fundamental. What are you talking about?

It's quite possible to compete against this on multiple levels. One would be correctness. The other a bit less wasteful interface. Another would be handling arrays in a more useful way (or at all). And yet another would be safety. Another would be speed and memory use. Yet another would be non-recursive implementation. Another would be documentation (what's this diffing? enumerable/non-enumerable properties? how it deals with getters? how about inherited properties? - I can't know any of this without looking long and hard at the code)... etc. etc.

Note on only the first part: the author might have tested bunch of stuff on their local without commiting until they've found something worth, perhaps? That would result in very few commits.
Nah, this just really isn’t a very complex or noteworthy library. There’s not that many edge cases to test. Just look at the test file.
Mmm, agree with parent; can get faster. Unfortunately lots of perf critical code is created out of necessity and defaults to proprietary.

You could profile this lib and figure out where it’s spending most of its time and figure out if there any ways to improve (starts getting into implications of JS <-> system), but as you get more idiosyncratic you lose flexibility and ease of use.

Eg type checks, heap additions, recursion, etc can get “slow”

>Microdiff aims for working for 99% of use cases, instead of making every edge case work.[1]

That's fine, of course, but probably should be in the README.

[1] https://github.com/AsyncBanana/microdiff/issues/2#issuecomme...