Should we make Bliss a dependency?

[LeaVerou]

Until recently, I used to include helper funcitons separately in projects. Now I’ve released my helpers as Bliss, a 3KB helper library. It has a community around it and very good test coverage.

I was wondering if it would be a good idea to make Bliss (shy) a dependency. It would shave off the following bit of code:

function $(expr, con) {
    return typeof expr === "string"? (con || document).querySelector(expr) : expr || null;
}

function $$(expr, con) {
    return slice.call((con || document).querySelectorAll(expr));
}

$.create = function(tag, o) {
    var element = document.createElement(tag);

    for (var i in o) {
        var val = o[i];

        if (i === "inside") {
            $(val).appendChild(element);
        }
        else if (i === "around") {
            var ref = $(val);
            ref.parentNode.insertBefore(element, ref);
            element.appendChild(ref);
        }
        else if (i in element) {
            element[i] = val;
        }
        else {
            element.setAttribute(i, val);
        }
    }

    return element;
};

$.bind = function(element, o) {
    if (element) {
        for (var event in o) {
            var callback = o[event];

            event.split(/\s+/).forEach(function (event) {
                element.addEventListener(event, callback);
            });
        }
    }
};

$.fire = function(target, type, properties) {
    var evt = document.createEvent("HTMLEvents");

    evt.initEvent(type, true, true );

    for (var j in properties) {
        evt[j] = properties[j];
    }

    target.dispatchEvent(evt);
};

Thoughts?

[TxHawks]

I like Bliss a lot, but I think something like Awesomplete is better left dependency free. The amount of code that will be removed by making bliss a dependency is just too little to be worth the coupling

[vlazar]

We can also look at what a dependency is differently.

One way would be to use full bliss.shy.js as a dependency. And it's bigger than Awesomplete itself.

Another way would be to make Bliss itself modular, so that parts of it can be used to build Awesomplete or any another project with a little build script. We can even have 2 builds of Awesomplete. One can be completely standalone version built from parts of Bliss and Awesomplete code. Another build can be Bliss-free, and user would have to include Bliss.

If Bliss and Awesomplete are rewritten to use ES6 modules some day, builds can be smart enough not to include the code which is not needed.

[fractaledmind]

One +1 of making Bliss a dependency is that the code becomes that much more DRY, which, while a benefit in and of itself, also simplifies the evolution of this project. For example, my PR #16787 made changes to the bit of code that overlaps with Bliss. With redundant code in two projects, if any change is made here that would benefit Bliss, or vice versa, someone has to manually keep things in sync.

However, I can also see why including a dependency that is larger than the project seems perhaps unwanted. I, for one, would vote for making Bliss more modular, allowing Awesomplete to use only the bits that it needs and nothing more.

[LeaVerou]

On the other hand, to play devil's advocate, jQuery is bigger than most jQuery plugins, so the "dependency bigger than the project" is not that unheard of.
I'm all in for making Bliss more modular, though dissecting 3KB into several modules feels a bit like going too far. I mean, yes, it is bigger than the project, but both are pretty tiny.

[LeaVerou]

Also, excellent point by @smargh. I wasn't suggesting making it a dependency to shave off code, but because code in Bliss is tested and much more polished, while still small and using a compatible API.

[fractaledmind]

Having thought on it a bit more, my vote would be to make Bliss a dep. The more I think about it, the more that the "separation of concerns" angle strongly sways me. Bliss is a library for (among other things) sanely working with the DOM; Awesomplete is a library for making autocomplete inputs. Awesomplete need not maintain, test, and evolve code for sanely working with the DOM--it's not one of it's concerns.

Plus, as @LeaVerou says, the size issues aren't really that strong. First, @LeaVerou is being very thoughtful and mindful to not let Bliss get bloated. Second, adding 3KB (minified and gzipped) shouldn't be a showstopper. Third, over time Bliss will naturally become modular anyway and these issues will lessen anyway. As ES6 continues to gain traction in the browsers, I'm certain that Bliss will restructure into ES6 modules. Until that time, however, I say having Bliss as a dep is worth the extra code and size.

[fractaledmind]

I have a branch that uses Bliss (shy) throughout. I'd like to put in a PR, I'm just not 100% certain how to make it a dependency. I would add it as a dependency in package.json, presumably to bower.json as well, but would there be more required?