Feedback

[balupton]

Use this issue to provide general feedback for Chainy.

[balupton]

8:58 AM pomke: ' it's like jQuery but for data. '
8:59 AM pomke: I like the idea but that description doesn't have awesome connotations c_c;
8:59 AM pomke: Looks pretty cool actually
9:14 AM balupton: pomke: because of jQuery’s bloating?
9:50 AM pomke: yea
11:08 AM balupton: pomke: yeah, perhaps I clarify that in the tagline, a lot of people don’t get it, until they ask “so it’s like jQuery”, “yes”, “ahhhh right"

[balupton]

• I can see this benefiting from some more core plugins
• Things that come to mind are array utility functions like what is available in underscore 'unique', 'min', 'sortBy', 'groupBy' - I know you have some
• I'd like to see examples of how this unites task runners, I can see it being a direct competitor

[calebboyd]

What do you feel are the main differences / advantages of chainyjs over something like rxjs or baconjs?

[balupton]

@calebboyd So the thing is that chainy is ridiculously lightweight and is agnostic to what the data is. That means that things like highland.js and bacon.js can actually be built on top of it using the plugin system, and then bundling a bunch of plugins together.

It's a way to provide a chainable API for data, with flow control, error handling, and all the rest. So instead of writing monolithic procedural applications, instead we write plenty of tiny maintable packages using a concise smooth functional style.

I've actually begun to start using it for everything now, and will add to the showcase wiki page as more things I do become public with it.

As a bit more background, Michael Riethmuller sent me an email asking more or less the same, this was my reply:

For the idea of task unification to make sense, it's important to cover my inspiration for chainy, and a bit of my history.

I created History.js in about a weekend many years ago, and it's gone on to become one of the most popular projects in the world, however, it's a bitch to test, as it has to be tested manually. Plus as people's use of it is just to drop it in, and go, it's not something that they find is worthwhile enough to financially support, unfortunately.

That then made me desire to build something that people would use 8 hours a day, so I built DocPad, and a static site generator for Node.js. However, recently I realised that maintaining it has become just too difficult, as it is way too dependent on myself, and the code has become quite monolithic, with everything being docpad context sensitive: docpad/docpad#821

During this time I've always been a fan of substack's work, and the MicroJS movement, which is, if you publish tiny modules, less than say 200 lines of code, and then composite larger applications from them, then you end up with something maintainable, as tiny code is easy to test, and easy to maintain.

However, after trying to use MicroJS for a few things, I've found that you always lose context. And context is very important when dealing with large applications.

Also during this time, I was invited to the node-task working group you could say, https://github.com/node-task where myself and other leading task runners have been trying to figure out a unifying way so that we only need one coffeescript compile plugin, that then works for everybody. Chainy isn't there yet, but maybe in a few versions and after a lot of discussions with the larger community, it certainly could be — or at least move the initiative further.

Chainy is kind of the result of all of this. It's about, how could I now write applications in an easy, accessible, intuitive, and composite way. The Chainy CLI is also implemented using Chainy, and I'm coding an database API server now with it too. It's really amazing, as once you start using this paradigm, you start wanting to use it for everything. Of course, there's a risk here of seeing everything as a nail when I've got a new hammer, but only time will tell I guess, especially as the wider audience uses it.

This issue #14 covers a bit more about what I mean about the unification.