Show HN: Introducing Q.js, a library for modern web apps
github.com
github.com
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
I would recommend calling your library Qbix.js with the Qbix name space.
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.
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
I'd suggest a name change.
Here is the first public version, from 3 years ago: https://github.com/Gozala/q/tree/v0.1.0
[1] https://github.com/kriskowal/q/commit/9191ce4c803cc3f8a01fb6...
Maybe this http://qbix.com/about#contact
Q.md5 - to one-way-encode passwords etc. in insecure websites before sending to the server
There are a multitude of alternatives which would be more suitable. Alternatively, don't promote the md5 module as being for passwords.
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) { ... } );
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"))
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.
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!
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.
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).