
Show HN: Introducing Q.js, a library for modern web apps - EGreg
https://github.com/EGreg/Q.js
======
enobrev
This looks like a very interesting library. Thank you for sharing it. In case
you didn't already know, there is already a very well known javascript async
library called Q.

[https://github.com/kriskowal/q](https://github.com/kriskowal/q)

~~~
cowbertvonmoo
I published Q in 2009. I based it on another project by the same name and API
that was published by Tyler Close in 2007.
[https://waterken.svn.sourceforge.net/svnroot/waterken/server...](https://waterken.svn.sourceforge.net/svnroot/waterken/server/trunk/waterken/config/file/site/ref_send.js)
His work was based on the E programming language and the name is a reference
to the underlying event "queue".

Q is around the 20th most depended-upon package in the Node.js package
manager, NPM and is downloaded about 100,000 times a month.
[https://npmjs.org/package/q](https://npmjs.org/package/q)

I would recommend calling your library Qbix.js with the Qbix name space.

~~~
EGreg
That's a good recommendation. Maybe we'll call it the Qbix library. It's just
that our entire large framework (which primarily runs on PHP and Node.js) is
called Q, and what I published is just one file from the front-end SDK..

------
dlsym
"Q.md5 - to one-way-encode passwords etc. in insecure websites before sending
to the server"

This is a very bad advice which leads to a false sense of security:

1\. A fast hash function is not desired for hashing passwords. (Bruteforce)

2\. There are TBs of rainbowtables for unsalted md5.

3\. If you use a salt, you would have to expose it clientsided.

~~~
EGreg
You are most likely right. I should explain instead that the md5 should be
used to verify HMACs sent by a service. However, when sending passwords over
the wire, the client should ideally hash it and the username/email + id of the
provider should be used as the salt. That way different providers can't
impersonate a user on each other's servers. This salt SHOULD be applied on the
client side even if you are using https, or you are actually trusting the
provider to not misuse or leak your password, e.g. in logs. See for example
[http://blog.cloudflare.com/cloudflare-prism-secure-
ciphers](http://blog.cloudflare.com/cloudflare-prism-secure-ciphers)

------
EGreg
I've open-sourced one part of our company's Q framework -- the library we use
on the front end.

It contains a lot of stuff that took us a while to design and write and test
on all browsers. If you wind up using it, I would love to hear your feedback.
Ask me any questions if you get stuck. You can also contact me here:
[http://qbix.com/about](http://qbix.com/about)

~~~
nicksergeant
There's a very well-known JS library already named "Q", here:
[https://github.com/kriskowal/q](https://github.com/kriskowal/q)

I'd suggest a name change.

~~~
EGreg
Well, we started about 2 years ago and our company's been calling it Q
internally. This is just the front end SDK for what we built (Q spans PHP,
Node.js and front end css/js.) I think we're going to keep the name.

~~~
alanh
This is the biggest piece of feedback you have gotten yet. Q isn’t nearly as
famous as e.g. Backbone or Ember or Modernizr, but it _is_ established and
well-known. Your name is actually a barrier to this catching on, I think.

~~~
EGreg
What if ours becomes better known? As I said we've started 2 years ago.

~~~
jjsz
This is where you ask yourself "would I like if someone releases a product
with the exact same name as my company's and moved us to the second page of
Google?".

------
blutack
I agree, it's a neat looking library.

    
    
      Q.md5 - to one-way-encode passwords etc. in insecure websites before sending to the server
    

However, I'm not sure promoting unsalted MD5 as a password hashing algorithm
and a replacement for https is a good idea.

There are a multitude of alternatives which would be more suitable.
Alternatively, don't promote the md5 module as being for passwords.

------
j_baker
What does Q do? Apart from providing a "library for modern web apps" (whatever
that means).

~~~
EGreg
It has some minor overlap with jQuery but literally it is built to provide a
unified solution to all the "other" challenges that an WEB/MOBILE WEB APP
developer faces. Such as:

Reusable tools - Q comes with a lot of reusable tools you can just drop onto a
page, many with their own back end and they "just work" when you Q.activate
the page

Not refreshing the whole page - Q has virtual pages loaded with AJAX and slots
(content areas) to fill on the page. Q.handle(url) simply loads the url for
example and activates all the tools for you.

Event system - you nee to be able to remove event handlers when the page is
unloaded or a tool is removed

Integration with PhoneGap, jQuery, touch vs non touch environments, etc.

But the coolest stuff is the middleware. You can literally write apps that get
objects like this:

    
    
        Users.byId(uid, function(err, user) { ... } );
    

and not care how it gets the user object. If it already cached it then it uses
the cached version. If it already requested it, it puts your callback on a
waitlist instead of sending again. When response comes back it calls all
callbacks on the list. It also can do throttling, and batching of requests.
And all the while you just have to use the construction above to get objects.

Oh and Q supports socket.io so if you have node running you can update caches
via a push so they are almost NEVER out of date!

Furthermore a lot of the time your JS code has a functional programming
character, such as "wait until these objects are fetched, then do this". So
just use this:

    
    
        var p = new Q.Pipe(["user", "stream"], callback);
        Users.byId(uid, p.fill("user"));
        Streams.get(publisherId, streamName, p.fill("stream"))
    

You can even use it with any unsuspecting library since it produces callbacks
you pass to this library.

So basically:

Virtual pages and tools you drop on them, set and forget

Model done via caching and realtime updates, query and no worries. Use Q.pipe
to wait for some objects then do what you wanted to do

Connect everything together with event handlers

Boom your app coming together quickly. Other libraries (like jQuery) are for
manipulating DOM and other stuff. This library helps you build rich web APPS.

~~~
ndnichols
Is there a cohesive idea or approach here? This just feels like a bunch of
unrelated utility functions. And there's basically no documentation, right?
The readme description of Q.getter is just "Q.getter - wrapper which makes any
getter function smarter, using caching, waiting, throttling, without worrying
about ", while the docstring for the method is 30 lines long and I still have
no idea what it does or how to use it. It seems like you're doing some really
heavy, serious work in this library with a ton of library-specific options,
etc. If that's the route you're taking, I think you're going to need real
documentation, tutorials, etc. if you expect this to get any uptake.

~~~
EGreg
I completely agree. I just wanted to put out one file from our framework and
get some early feedback.

But Q.getter for example is just that easy. Try this:

1) Include Q.js

2) Take any function that gets stuff from any web server and calls one or more
callbacks, let's say function X

3) Do this: X = Q.getter(X)

Now use your function :))))

See how it improves efficiency? It caches the result, it prevents multiple
requests to the same thing, etc. Next you can tell it what to use for the
cache, by another parameter to Q.getter. And finally you can hook up socket.io
to update the cache on a push!

------
ricardobeat
Releasing useful tools/libs as open-source is always a good thing, so
congratulations and thank you.

However, I believe monolithic libraries are on the way out. Having small,
composable libraries is a much better model: well-defined boundaries, easier
to test, understand, maintain and contribute to. The shared knowledge that
results can also lead to more stable/standardized APIs.

From a quick look, this library covers the same surface as jquery, backbone,
underscore, a cookie-handling lib, async, a caching middleware, crypto, and
more, added together. Adopting it for a project is a _huge_ commitment, and
means that every little piece of it has to fit your project well, or pieces of
your project will have to be hammered to conform. I imagine it would spark
more interest if it was broken down into smaller libraries.

------
nawitus
>Q.mixin - a way to do class inheritance the Javascript way

Note that the next major JavaScript version will have classes and inheritance,
and the specification will probably be finalized this year. (Not a critique
really).

------
joshontheweb
Holy 8 space indentation, Batman!

------
robodale
Another one?

------
aconz2
The internet does not need another 5000 sloc JS library attempting to solve
every problem in one file. Please put your effort towards improving upon
other, focused libs.

~~~
pearjuice
Don't you enjoy your daily dose of obscure Javascript libraries?

------
maxsavin
Nice work Greg!

------
camus
Change the name, there is already a well known lib named q which deals with
promises and and async .

~~~
codereflection
I was just going to say that

