Why don't you use jQuery as a blueprint from an interface perspective? For example, instead having getStyles and setStyles you provide css() for reading and writing. I know that it should not be a replacement but that only means that you do not have to provide all functionality like animations. A second thought: Is prototyping on native element like document and html element really a good idea? Maybe offering a function based ES 6 library where you pass in the element would be a better option? Third and last one: In my opion the most comfortable feature of jQuery is its flexibility in its selector engine. Means, one selector function for all. Any plans on this?
Hi Paul! I definitely considered mimicking the implementation of jQuery in terms of naming, but ultimately decided that I wanted to emulate vanilla JavaScript calls instead (such as getElement() instead of getElementById). In Imbue the getElement() and getElements() calls take the same standard selectors as jQuery, as they both use querySelector(), so you can still use things like select .mySelect or #example for selectors.
In regards to prototyping native elements, I haven't found major reasoning against doing so, especially when given Imbue won't override any calls/properties already present in the prototype. By extending upon the native elements it makes using Imbue feel more natural & reflects the fact that the calls Imbue makes are just simple native calls. In essence, my push is just making shorthand calls & useful helper methods that utilize the poorly named or longer implementations native JS has under the hood.
I think the last point is addressed a bit earlier, but the getElement() call is fairly robust, as querySelector() is also fairly robust. An added benefit is that you can specify calling one element vs. a list by using the plural form getElements().
I am admittedly not extremely knowledgeable on the pros/cons of extending things like HTMLElement & HTMLDocument, but from my usage in production (alongside jQuery at the same time) Imbue hasn't resulted in unexpected behavior, but if you have more insight I'd be really excited to hear it!
Thank you for your comments
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Why don't you use jQuery as a blueprint from an interface perspective? For example, instead having getStyles and setStyles you provide css() for reading and writing. I know that it should not be a replacement but that only means that you do not have to provide all functionality like animations. A second thought: Is prototyping on native element like document and html element really a good idea? Maybe offering a function based ES 6 library where you pass in the element would be a better option? Third and last one: In my opion the most comfortable feature of jQuery is its flexibility in its selector engine. Means, one selector function for all. Any plans on this?
Hi Paul! I definitely considered mimicking the implementation of jQuery in terms of naming, but ultimately decided that I wanted to emulate vanilla JavaScript calls instead (such as
getElement()instead ofgetElementById). In Imbue thegetElement()andgetElements()calls take the same standard selectors as jQuery, as they both usequerySelector(), so you can still use things likeselect .mySelector#examplefor selectors.In regards to prototyping native elements, I haven't found major reasoning against doing so, especially when given Imbue won't override any calls/properties already present in the prototype. By extending upon the native elements it makes using Imbue feel more natural & reflects the fact that the calls Imbue makes are just simple native calls. In essence, my push is just making shorthand calls & useful helper methods that utilize the poorly named or longer implementations native JS has under the hood.
I think the last point is addressed a bit earlier, but the
getElement()call is fairly robust, asquerySelector()is also fairly robust. An added benefit is that you can specify calling one element vs. a list by using the plural formgetElements().I am admittedly not extremely knowledgeable on the pros/cons of extending things like HTMLElement & HTMLDocument, but from my usage in production (alongside jQuery at the same time) Imbue hasn't resulted in unexpected behavior, but if you have more insight I'd be really excited to hear it!
Thank you for your comments