The author's example inserts 4M elements.
> and the user experience (and the API design) really benefitted from not having a bunch of extra round-trips to the server.
Possibly, but unless you benchmarked both scenarios, this might not be the case.
Performance over networked devices often has trade offs, sometimes those trade offs are directly contradictory, eg sorting/filtering/mapping/etc data on client side versus server side via api call - sometimes one is better than the other but you wont wont know unless you benchmark.
I get the impression that your company did not go through that exercise, considering you guys are building an IDE with scripting language.[1]
[1] https://nickjanetakis.com/blog/switching-to-vscode-from-subl....
The only reason the example inserts 4M elements was because Set and Object start to become prohibitively slow at some point and crash the process with too many allocations, not to mention the stress on the GC which now has to follow so many pointers.
HashTable performance is a fundamental component of any language.
Agreed, but why use Node if performance was so critical to your use case? Could this 400M insert logic exist in a separate service that lives outside your Node code base?
This is very incorrect. At my last company we had a React interface (a specialized IDE, really) that needed to juggle (sort, filter, process) and work with sometimes hundreds of thousands of entities at once, all in-memory. JavaScript did this just fine, and the user experience (and the API design) really benefitted from not having a bunch of extra round-trips to the server.
Even in this extreme use-case, the bottleneck was always the few-hundred items that were actually rendered in the DOM at a time. We virtually never had performance problems from sheer volume of underlying data.