Wrap jQuery dojo with custom library?

Question

Starting with Java, I am wondering if the Java practice is applicable to JavaScript.

In Java, there is a separation of interface and implementation, and mixing them is considered bad practice. Likewise, it is recommended that you hide the details of your library implementation from end developers.

For example, log4J is one of the most popular log libraries, but it is recommended that you write code in the slf4j library or the Commons log library, which wraps log4j. Thus, if you decide to switch to another logging structure, such as a log, you can do this without changing your code. Another reason is that you, as a user of the logging library, like logging, do not worry if you know what the log does.

So back to JavaScript, most non-trivial web applications have their own JavaScript libraries, many of which use open source libraries such as jQuery and dojo. If the user library depends on, say, jQuery, and not as an extension, but as an implementation, do you see the need to add another layer that wraps jQuery and makes it transparent to the rest of the JavaScript code?

For example, if you have a foo library that contains all of your customizable interface logic, you would enter a bar library that simply wraps jQuery. Thus, your foo library will use the bar library for jQuery functions, but it does not access jQuery completely. Theoretically, you can switch to other libraries, such as dojo and google web toolkit, without having much impact on the foo library.

Do you see the practical significance in this? Overkill?

Answer 1

There are many good answers here, but one thing that I haven't mentioned is the feature set. If you try to write a library to wrap the functionality provided by, say, jQuery, but you want to be able to easily switch to something like a prototype, you have a problem. The jQuery library does not provide all the function prototypes, and the prototype does not provide all the functions provided by jQuery. In addition, they both provide their capabilities in radically different ways (the prototype expands the base objects, which are almost impossible to wrap).

In the end, if you tried to combine these libraries into some code that adds “abstraction” to try to make them more flexible, you will lose 80% of what the frameworks provided. You will lose the bizarre interfaces they provide (jQuery provides the awesome $ ('selector') function, the prototype extends the base objects), and you also have to decide if you want to leave your functions. If this function is not provided for both structures, you need to either align it or redefine it for another structure. This is a big can of worms.

The whole problem is that Java is a very inflexible language. The library provides functionality and what it is. In JavaScript, the language itself is incredibly flexible and allows you to do many crazy things (for example, write a library and assign it to the $ variable). Being able to do crazy things allows javascript library developers to provide some really creative features, but that means you can't just find common features in libraries and write an abstraction. I think writing javascript well requires a significant change in perspective for the Java developer.

Answer 2

Although this makes sense from a theoretical point of view, in practice, I would say that this is unnecessary. If nothing else for two reasons:

• Anything that adds request size (or adds more requests) is bad - in the web world, less.
• If you use say jQuery, the chances of switching to something like Mootools (imho) are negligible. From what I saw, the best libraries of each of them are aimed at solving various problems (at least in the case of Mootools and jQuery - see this excellent document for more information about this). I assume that you would face a huge headache if you tried to implement a middleware library that could easily switch between them.

Answer 3

In my experience, the Java developer himself, sometimes we tend to take the whole picture of “abstraction” too far, I saw implementations when someone decided to completely abstract a certain structure just for the sake of “flexibility”, but this ultimately makes things more complicated and creates more code to support.

In the bottom line, you should look at it in each case, for example, you would not try to create an abstraction layer on top of struts or on top of the JPA, just in case you go to another (which I rarely saw).

My suggestion is that regardless of the structure used, create objects and components that use the internal structure, they should model your problem and be able to interact between them without the need for any specific structure.

Hope this helps.

Answer 4

Someone wise once said: "premature optimization is the root of all evil." I believe that this applies in this case.

As others have put it, you don’t want to abstract for the sake of flexibility until you get the actual need for abstraction. Otherwise, you do more work than necessary and introduce unnecessary complexity before you need it. It costs money and actually makes your code more fragile.

In addition, if your code is well organized and well tested, you should not be afraid of major changes. The code is always changing, and trying to anticipate and optimize changes that may or may not happen will almost always lead to more problems than this will save you.

Confirmation: I have to pay tribute to Agile programming and my practice and readings on this topic. What I said comes directly from my understanding of Agile, and I found that it is a very good razor to cut out the excess fat of my work and do a lot. Also, none of what I said is specific to JavaScript ... I would apply these principles in any language.

Answer 5

There are good arguments calling for this developmental practice - wrapping up to switch later - to a question in any language.

Good quote by Oren Eini from his writeup on ORM wrapper :

Trying to encapsulate to make things easier to work is excellent. Trying to encapsulate so that you can switch OR / Ms? It will not work, it will be expensive and painful.

Answer 6

This is definitely what has been done in corporate environments.

Take, for example, a company that has its own javascript structure, which is used in all of its projects. Each of the projects decides to use its own framework (jQuery, Dojo, Prototype) to add functionality to the basic modules of the company structure. Employees who move between projects can now easily do this because their API with working on the project code base is still the same, although the base implementation may differ for each project. Abstraction is useful in these situations.

Answer 7

This is an excess. Javascript is not Java and is in no way associated with Java. This is a completely different language, which got Java in the name for marketing reasons.

If you are concerned about the availability of additional libraries, choose a scheme with a large ecosystem. In a corporate environment, you will move forward by standardizing a custom vanilla web infrastructure that you can update every year or so, keeping an eye on the rest of the world. And then add this with the optional SMALL library, which of course you will have to support yourself, not to mention training new programmers that you hire.

Since you are talking about Javascript in a client (web browser), it is more important that you limit the complexity of what people do with it. Do not create a huge amount of client code or make it so fragile that another programmer cannot support it. The web framework helps you maintain linear access and keep your own code simple enough.

This is not a matter of Javascript best practice, because it will be different for server-side JS like Rhino or node.js.

Answer 8

In this case, the adapter template is not a general solution. The only example I know for using this template is extjs . Javascript projects are usually too small, and they are not worth the effort you could make by creating such an abstraction layer. A common solution to this problem is that you are trying to use several frameworks together, for example with jquery.noConflict .

Answer 9

I have done this before and can talk a little about the experience of writing covers for the library / toolkit.

The plan was to switch from Prototype to another library. Dojo was the first choice, but at that time I was not sure that the library would move everything to (and all I mean ~ 5 MB Prototype-happy JS). Therefore, based on the world of clean interfaces, I was set to record one of Prototype and Dojo; an amazing interface that would disconnect from the Dojo a breeze, if it was really necessary.

It was a mistake that cost a lot of time and effort for several reasons. The first is that although two libraries can provide the same functionality, (a) their API will almost always be different, and most importantly (b) how you program in the same library will be different.

To demonstrate, let's take something in common, like adding a class name:

 // Prototype $("target").addClassName('highlighted'); // Dojo dojo.addClass("target", "highlighted"); // jQuery $("target").addClass("highlighted"); // MooTools $('target').set('class', 'highlighted'); 

Still pretty straightforward. Let's complicate a bit:

 // Prototype Element.addClassName('target', 'highlighted selected'); // Dojo dojo.addClass("target", ["highlighted", "selected"]); // jQuery $("target").addClass(function() { return 'highlighted selected'; }); // MooTools $("target").set({ "class": "highlighted selected" }); 

Now, after choosing the interface for your addClass version, you have two options: (1) code for the lowest common denominator or (2) implement all disjoint library functions.

If you go 1st, you will lose the “personality” / best qualities of each library. If you go from No. 2, your addClass code will be 4 times larger than the one provided by any of the libraries, because, for example, when Dojo is enabled, you will need to write code for the function as the first parameter (jQuery) and Object as the first parameter (MooTools).

Therefore, although it is theoretically possible, it is impractical, but it is a very good way to understand the intricacies of libraries there.