Echo JS 0.11.0


mscdex comments

mscdex 9 days ago. link 1 point
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.
mscdex 10 days ago. link 1 point
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 `` since the latter can be slow(er) due to calls to gettimeofday() IIRC.
mscdex 48 days ago. link 4 points
No tests and no benchmarks to back up the "blazing fast" claim. :-\
mscdex 111 days ago. link 1 point
There's a typo: 'Ingnition' should read 'Ignition'
mscdex 147 days ago. link 1 point
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"
mscdex 169 days ago. link 1 point
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`).
mscdex 209 days ago. link 4 points
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.
mscdex 211 days ago. link 4 points
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 ( 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*.
mscdex 221 days ago. link 4 points
Saying "without loops" is a misnomer. This should've been titled something like "JavaScript functional array iteration" or similar.
mscdex 225 days ago. link 1 point
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.