Echo JS 0.11.0


mscdex comments

mscdex 52 days ago. link 1 point
There's a typo: 'Ingnition' should read 'Ignition'
mscdex 87 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 109 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 150 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 152 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 161 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 165 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.
mscdex 176 days ago. link 3 points
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.
mscdex 192 days ago. link 1 point
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"):