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*.
Never say "fastest" because at some point it may not be (or possibly for specific situations) and someone else may end up having the "fastest" of that kind of module instead.
Just call it "fast" and point to legitimate benchmarks (containing module versions and current date/time) that show that it's faster compared to similar modules.
I wrote this for fun in a couple of hours this past weekend and without incorporating any exceptional optimizations, it actually outperformed other "raw HTML"-capable engines like ejs and doT (which claims to be the "fastest"): https://github.com/mscdex/zup/wiki/Benchmarks