# Object Oriented vs Not jQuery & JS

I have taken a widget/ plugin that I wrote yesterday and just now it has been re-written in an object oriented format. It is certainly more code to write it the OO way, so please let me know also how to analyze the performance of each example of the same widget below:

Please keep in mind that I use data-attr selectors because of their descriptive nature and the fact that it separates style and functionality by not binding its functionality to .class selectors. Yes, I understand ID's are faster. I use a ~ before the = when querying these selectors because I like to leave the data-function or data -widget attr's open to the addition of new functionality (E.G. $('data-function="accordion jsondataset").. in this format javascript will not pick up the jsondataset attribute unless a ~ is added in the selector scripting resembling $('data-function~="jsondataset").

Here is the finished code:

var tabs = function(){
var tabsWidgetEnvoked = $('[data-widget~="tabs"]'); if (tabsWidgetEnvoked){ // if data-attr present in DOM var settings = [ { // widget settings as an object tabs :$('[data-function="tabs"]'),
content: $('[data-function="content"]'), tabShowing : '1', animated: true, } ]$.each(settings, function(){
// event handling
tabs = this.tabs;
content = this.content;
show = this.tabShowing;
animated = this.animated;
});
if (animated === true){
$('body').addClass('animated'); } tabs.children().each(function(i){ i = i + 1;$(this).attr('data-nav-order', i);
});
content.children().each(function(i){
i = i+ 1;
$(this).attr('data-content-order', i); }); tabs.children(':nth-child('+show+')').addClass('active') content.children(':nth-child('+show+')').addClass('active') tabs.children().click(function(e){ e.preventDefault(); tabs.children().removeClass('active')$(this).addClass('active');
requestedView = $(this).attr('data-nav-order'); content.children().removeClass('active'); content.children('[data-content-order="'+requestedView+'"]').addClass('active') }); } } tabs();  I did add animation and a default view to the object oriented one as well but aside from this, the functionality is the same. Here is the code for the standard spaghetti code version. Here is the one I rewrote with an OO approach. • Welcome to Code Review! Nice first post you got here, I hope you enjoy your CR experience and come back often - you now have >15 reputation score and have earned the privilege to spend up to 40 votes every day on this site! Congratulations! Jun 12 '14 at 15:31 • Just noticed it was actually your 2nd... well, welcome back! :) Jun 12 '14 at 15:37 ## 1 Answer First of all, maybe you should give the user a way to configure the selector - this gives most applications the chance to go for an id selector, others might want to have a more global or unobstrusive approach - so they can just use a data-selector. Your object oriented approach is not following the standard principles for jquery plugins - from what I see there you are using jquery so why not use their plugin techniques then. As the jquery docs have a huge documentation of that, here is just a small example: $.fn.tabs= function() {
this.css( "color", "green" );
};

$( "a" ).tabs(); // Makes all the links green.  See http://learn.jquery.com/plugins/basic-plugin-creation/ for a better explanation. This also makes possible what I showed above - let the user decide what selector to use. For this simple tabs script I don't see any other considerations when it comes to performance. • you can configure this script the same way except with less code required. See.. add this:$(function(){ tabs.css('background','black'); } Jun 12 '14 at 15:10
• From your question I assume you want to build a plugin, this means you will ship this piece of code which should be reusable by other users. Your code is not as reusable as if you go for your suggestion, as the user has to rewrite your code - this is not what a plugin is meant for. Just my 2 cents. My example does not directly relate to your tabs plugin, it's just an example of how you an access the selector inside your plugin. Jun 12 '14 at 15:14
• So if my plugin is (more) easily extendable the way it is now and is protected from too global scope... do I really need to rewrite it again to fit jquerys 'template'? I have no issues with change I just like to know why. Jun 12 '14 at 15:20
• It was just recommendation to use the jquery "template" - there is no need to do so. But it's always a good idea to go for standard ways - your users mostly already know how to use a jquery plugin. So why don't ship a "normal" jquery plugin. If anybody wants to extend your plugin he can do so using the methods given by jquery. Also he can use the jquery docs to find answers about extending or using it. But as you said, this is just one way to do it - just like it is always when coding. Jun 12 '14 at 15:38