Echo JS 0.11.0

I don't remember the times offhand.

The article was about using maps/hashes/key-value data structures, so a set wouldn't "work" in that case.

FWIW you can get better results using `Map()` in node. For example with node v8.3.0, using `Map` gives me 16.7 million items before the app crashes due to OOM.

Also for node, you should use the high-resolution timer (`process.hrtime()`) instead of `Date.now()` since the latter can be slow(er) due to calls to gettimeofday() IIRC.

No tests and no benchmarks to back up the "blazing fast" claim. :-\

There's a typo: 'Ingnition' should read 'Ignition'

A couple of comments/issues:

* When zoomed in, (decimal) download counts less than 1 have an 'm' suffix (e.g. '900m', '800m', '700m', etc.) which seems like a bug, since an 'm' suffix typically indicates 'million'

* The "box" styling of the "map" at the bottom of the page looks like it should be reversed such that the portion being viewed up top is enclosed in a box in the bottom "map"

I don't see the benefit of this really, especially considering performance will probably be sub-par compared to strict equality and similar checks (e.g. using `val !== val` to check for `NaN`).

If that is your intention with regard to compatibility (including safety features/limits), you should document that and optionally list what your http implementation does/doesn't cover compared to node's implementation (and perhaps other solutions you have already mentioned, such as nginx and Apache). This way users can be more informed about what to expect if they were to switch to uWebSockets' http implementation.

I agree. I never understood their seemingly consistent bad attitude towards the rest of the community.

Now about the speed increase claims: based on what I've seen in the uWebSockets repo, their http implementation (https://github.com/uWebSockets/uWebSockets/blob/094ee3fcbc7cc1e3adeb81f408374c5f1833363e/nodejs/http.h) is far from complete/compatible with node, so I would expect quite a few applications would break if they were to blindly port over to using this alternative http implementation. Node would be faster too if it didn't have to implement a lot of sanity/safety checks, implement a full EventEmitter interface, properly support node's streams interface, handle special headers appropriately, etc.

What would be more useful is a performance comparison once node compatibility is *all there*.

Saying "without loops" is a misnomer. This should've been titled something like "JavaScript functional array iteration" or similar.

Just wanted to point out that the JavaScript implementation in the project's repository isn't really optimized, so the benchmark results should be taken with a grain of salt IMHO.