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
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.
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.
Even if that was somehow relevant (it doesn't really matter what you called it internally if you didn't use the name publicly), the existing Q.js is older!
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?".
that is a bit childish. the time you began development is not relevant, and seeing as q.js is already popular, it is safe to say it will stay that way.
changing the name is great advice. consider it.
that is a bit childish. the time you began development is not relevant, and seeing as q.js is already popular, it is safe to say it will stay that way.
changing the name is great advice. consider it.
that is a bit childish. the time you began development is not relevant, and seeing as q.js is already popular, it is safe to say it will stay that way.
changing the name is great advice. consider it.
OK sorry let me put it another way ... the larger library is meant to run on PHP and Node.js, and the Q.js and front end part is just the SDK to use it on a web browser. So when the whole thing is released, it will mostly be a PHP+Node.JS+Web library.
As a long time user of the original Q (which has been around since at least 2009 [1]), I'd also suggest picking a different name for another reason: searchability.
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.
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... 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
I would recommend calling your library Qbix.js with the Qbix name space.
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..
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.
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.
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!
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.
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
>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).
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.
41 comments
[ 3.1 ms ] story [ 89.9 ms ] threadIt 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
https://github.com/kriskowal/q
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.
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:
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:
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.
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!
There are a multitude of alternatives which would be more suitable. Alternatively, don't promote the md5 module as being for passwords.
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.
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).
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.