HN user

tahu

71 karma
Posts6
Comments18
View on HN

Without a doubt Bluebird, When.js, Q, then/promise and others are faster. The implementation in httpinvoke is optimized for code size.

The other reason for current solution is that the specification for creating and resolving promises [1] is not yet published.

Having a Promise object in global scope, as exported by Q, Bluebird and then/promise, is not enough. There is no uniform way to hack into these implementations and use their promises resolver.

But when resolvers-spec is available, httpinvoke will definitely check for already loaded promises library and reuse it.

[1] https://github.com/promises-aplus/resolvers-spec

httpinvoke and superagent differences:

* superagent has a "fluent" API, httpinvoke is a plain function, with an options object and with Node.js callbacks and/or promises.

* superagent is not easy to use with binary uploads/downloads

* superagent does not give you an abstraction over progress events

* httpinvoke does not build query strings

* httpinvoke gives you raw multipart/form-data responses, does not parse them

Other aspects are comparable (file size, Node.js and browser support, etc).

Hi, thanks for the questions, sorry for the late reply..

httpinvoke fully implements Promises/A+ specification. The spec is very short and easily implementable. The implementation in httpinvoke takes only 568bytes when minified (check it out!).

So the answer is, if you use httpinvoke with a different promise library, it will work, unless the library really is at odds with Promises/A+ specification. Which is unlikely, because all the major promises libraries support it, even if they do not indicate that in their documentation.

httpinvoke only contact with the external promise (which it can only get when onFulfill or onReject returns one) is the .then method here [1].

[1] https://github.com/jakutis/httpinvoke/blob/master/src/common...

a look at the HTTP headers:

  tahu@laptop:~$ curl -I http://hackful.com/about
  HTTP/1.1 200 OK
  Content-Type: text/html; charset=utf-8
  Connection: keep-alive
  Status: 200
  X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.11
  X-UA-Compatible: IE=Edge,chrome=1
  ETag: "6972d16343b1a4d0f2a49c9a3174e977"
  Cache-Control: max-age=0, private, must-revalidate
  Set-Cookie: _hackful_session=BAh7B0kiD3Nlc3Npb25faWQGOgZFRkkiJWQ5NzYzMThlNDFkOWVhYTI1YzJiZGI0YzNjMjlkOWFhBjsAVEkiEF9jc3JmX3Rva2VuBjsARkkiMUVRU1gzZkhvcHRockpaWndWY2NRcGk3SElJczBmOEY3TW50YjJRZ0plSTg9BjsARg%3D%3D--572416e3b12cc85dda3675c22d117839535e636d; path=/; HttpOnly
  X-Runtime: 0.017811
  Date: Fri, 03 Feb 2012 16:26:04 GMT
  X-Rack-Cache: miss
  Server: nginx/1.0.10 + Phusion Passenger 3.0.11 (mod_rails/mod_rack)
JavaScript and URLs 15 years ago

I agree that JavaScript is breaking the traditional web - linked static HTMLs with some forms in it. But I also believe that one day people will start to forget this bumpy ride. I am thinking of http://nodejs.org/ and http://jsdom.org/ - if the user agent has javascript disabled - the client side javascript code could be executed on the server.