What JavaScript frameworks conflict with each other? - javascript

There are times when I want to use mootools for certain things and Prototype & script.aculo.us for others but within the same site. I've even considered adding others, but was concerned about conflicts. Anyone have experience, or am I just trying to make things too complicated for myself?

If you really, really want to do this, then you will be able to without too many problems - the main libraries are designed to behave well inside their own namespaces, with a couple of notable exceptions - from Using JQuery with Other Frameworks:
The jQuery library, and virtually all of its plugins are constrained within the jQuery namespace. As a general rule, "global" objects are stored inside the jQuery namespace as well, so you shouldn't get a clash between jQuery and any other library (like Prototype, MooTools, or YUI).
That said, there is one caveat: By default, jQuery uses "$" as a shortcut for "jQuery", which you can over-ride.
So, yes, you can do it, but you'd likely be creating maintenance headaches further down the line for yourself - subtle differences between framework functions may be obvious to you today, but come back in 6 months and it can be a whole other story! So I would recommend keeping it as simple as you can, and having as few different frameworks (preferrably 1!) as you can in your codebase.

AFAIK, all the popular frameworks are designed to be combined with other frameworks. I don't think combining them is that much of a problem. I would however discourage combining them purely from a case of bandwidth needs. A slow site experience is less forgivable than a more complicated development experience.

A recent question: jQuery & Prototype Conflict
Prototype.js library used to be very offensive and conflicted with many other libraries / code. However, to my knowledge, they recently given up with some really hard-core staff, such as replacing Element object etc.

You are better off sticking with a single framework per application. Otherwise your client will spend too much time/bandwidth downloading the javascripts.
That being said, Prototype and JQuery can work together. Information is on the JQuery web site.

My suggestion is to learn one (or more!) framework(s) very well so that you will be able to replicate the features you need without adding the overhead of multiple frameworks.
remember the more code that you push to the client the slower everything becomes.

From my experience I can say that some javascript libraries rather conflict with the browser, than with each other. What I mean is the following: sometime code written against some library will not well co-exist with the code written against browser DOM.

My Framework Scanner tool is useful for finding JS/CSS conflicts between libraries:
http://mankz.com/code/GlobalCheck.htm

Related

Removing jQuery for performance reasons justified?

I am on a new project and our job is to rewrite an e-commerce website that is having performance problems on mobile devices.
We are re-writing the javascript based on a more object-oriented/modular architecture which I think is great! However my team lead said that we should remove all the jQuery calls and replace with javascript like so domElem.querySelectorAll(query) , which has better performance. I understand jQuery does some kind of caching in the background which can create memory issues.
I am a little sceptical of this, firstly because it seems like a case of 'premature optimization', that is, we should find the bottle-necks first before we re-write anything. And secondly I haven't found anything on the internet that says that jQuery has significant performance problems.
The current website does have a lot of overlapping dom branch queries which I think creates a lot of redundancy. That is there is too much querying happening, and on our new architectual approach we are restricting our object/module to fewer dom queries and more targeted dom queries which is great. This does need to be re-written.
But whether or not we use domElem.querySelector(query) or $(domElem).find(query), I can't see there as being much of a difference. Is my thinking right?
Some tests are done here (check other revisions as well). Good detailed discussion is done here over pros and cons of using jquery over javascript.
Also want to point out that jquery doesn't do any caching of selectors.
The thing we often forget because of using Javascript frameworks all the time is that jQuery is not a framework.
Obviously, if you do the exact same one-operator action using the jQuery '$' object and using a direct DOM method like getElementById, the latter will be noticeably faster as jQuery itself is written in Javascript and does a lot of background stuff.
However, nothing (except code readability) prevents you, as a developer, from combining jQuery with plain Javascript: using plain Javascript wherever possible and only using jQuery functions that provide complex functionality and take some time to write and optimize from scratch. There are a lot of those in jQuery: providing browser-independent css, serializing object and doing lots of other cool stuff.
It depends on the application but usually performance troubles are related to badly-designed algorithms, not the use of jQuery.
In any case, if your application does a lot of DOM-manipulation, it may be worthwhile to re-write it using plain Javascript and test. Keep the library, just don't use it for simple operations you can easily write without it.
If your application is heavily-reliant on jQuery functions with complex functionality, removing it is out of the question.
I myself use this combined approach: everything simple written in Javascript with jQuery functions for stuff that is difficult to implement.
Also, a good place to dig around if the app has troubles with performance is the DOM-manipulation. Those operations are very heavy compared to almost everything else in Javascript. You may be able to cut down on time by rolling several operations into one, building finished objects with one constructor, instead of creating empty ones and assigning properties one-by-one, etc.
Sorry, if the answer is a bit vague but it's difficult to be precise in this case without seeing the code and running tests.
Let me quote Uncle Bob about this discussion "Architecture is about intent, we have made it about frameworks and details"
Premature optimizations needs to be considered carefully.
They often result architectural decisions that are not easily revertible.
They introduce code optimizations that are usually specific to the problems they solve, which makes the code less abstract thus hard to
maintain, and more complicated thus prone to more bugs.
They tend to be prejudice and not objective, sometimes without any real comparison to other alternatives.
The problems they are trying to solve tends to be overestimated, to the degree of non-existent.
I'm not a big expert on Web development but if possible, you should always push this kind of decisions to the end by separation of concerns, and good abstraction.
For example over the parts that generate the java-script code you can have an abstraction of JavaScriptWriter, and use different frameworks. This way you can use JQuery at the beginning, test the system and only then replace parts you know to be inefficient.

jquery vs javascript

I have to build a simple app, and I'm not sure if it worth to use the jQuery framework. Besides the complex or fancy applications, When is it recommended to use the jQuery and not the pure javascript.
In addition to complex or fancy applications you could use jquery in applications performing cross browser DOM manipulations and AJAX and which could benefit from the hundreds of available plugins.
using jquery will increase the development speed and you get the benefit of browser compatible code too.
It's more or less an issue of personal preference: jQuery, MooTools, Prototype and other JavaScript frameworks bridge many browser incompatibilities and simplify many of the common tasks for which JS is used, and thus shorten development time.
IMHO, if you are using JS for the usual "effects, AJAX, input widgets, pre-submit validation" tasks, a framework like jQuery is much faster and easier to use than rolling your own implementation. The drawback of loading one more script file and minding its license is negligible when compared to the flexibility and efficiency that it brings.
(also, most frameworks have plugins for various advanced tasks, but that's a bit beyond the scope of the question)
Besides all the facilities for writing code, I think that you should think at what you will put inside your application (i.e. plug-ins): jQuery offers a lot of useful plug-ins, both internal (calendar, tabs...) and external (e.g. jqGrid for displaying grid data). It is very helpful to have all this things in one single and standard framework (e.g. jQuery): otherwise you'll have to look each time to a different javascript plugin.

What is better, One javascript framework, or multiple frameworks

I am an avid user of the YUI framework (http://developer.yahoo.com/yui/). It has its' strengths and weaknesses both performance wise and syntax wise. I have seen a bit of JQuery and I have worked a little with prototype as well but I have stuck mainly to YUI. My question is, is it better to stick with one Javascript library per application, or leverage the abilities of multiple javascript frameworks in your application?
I think it is better to use one framework for at least two reasons:
1. Code is easy to maintain because there is no syntax mix.
2. Application loads a little faster and I think should execute little faster.
My guess is that multiple frameworks is better as long as each has its purpose. If I'm building an ASP.Net web application with AJAX functionality, there may be some built-in ASP.Net AJAX Javascript libraries being used automatically that can be combined with JQuery to handle some situations. Alternatively, one could have third-party controls like Telerik's RAD controls that also bring in more Javascript code possibly. The key is to understand what each framework is adding in terms of rolling your own.
Sure less frameworks in the same website will make your life easier, so try as you can to use one framework, and if you are going to use more than one, take care from conflicts and redundancy.
If i am in your place, i will start searching the framework i have for some plugins and updates, if didn't find will add the new framework.
One more point: don't panic from using more than one framework, the big and famous frameworks such as jquery has its implementations to solve conflicts and work side by side with other javascript libraries
Also... if you use 2 diffrent frameworks at the same time, some functions in one framework could override an function in the other framework, and make ugly conflicts.. e.g the $() could be implemented in diffrent ways, and make something crash, if other functions of the framework is using it. (and they sure do!)
I think its better to use 1 framework in your development, for consistency of API and loading speed. the problem sometime is no framework is comprehensive enough to have all of our development needs.
This is just came into mailbox, their advertisement saying it's a comprehensive framework, with plenty of widget: grid with grouping, charts, forms, tab, fields and so. I haven't play it long, but it seems very promising. check here

Is it worth it to use jQuery for Ajax instead of building your own JavaScript?

Aside from the framework, is jQuery worth using rather than creating your own javascript? I've always debated if the framework was better to use than to create your own calls. Are their disadvantages of using it?
Sorry for beginner question, I'm trying to feel out if it would be better to use this and create some of the ajaxish workings of my site rather than develop it from scratch.
Are there other frameworks out there that would be better to use to create an ajaxish website?
Yes, jQuery is worth it. I speak as someone who resisted using any library for a long time, then finally saw the light.
I do recommend that you build some hand-rolled Ajax interactions before you dive into using jQuery for Ajax, so that you understand exactly what is happening with Ajax. Once that's achieved, though, let the library do the dirty work.
jQuery (and most other framework) are for making difficult things simple. It keeps you from having to write cross-browser compatabile code. It keeps you from having to write recursive methods to update multiple dom-elements. It basically cuts your development time down substantially, and saves you a lot of frustration.
Stackoverflow Archive:
Which Javascript framework (jQuery vs Dojo vs … )?
Great discussion (with lots of involvement) over various javascript frameworks. It will benefit you to browse this in depth, or even at a cursory level.
When should I use a javascript framework library?
Which Javascript Framework is the simplest and most powerful?
What JavaScript library would you choose for a new project and why?
Which Javascript Ajax Framework is most powerful and very lightweight?
Which javascript framework can be used for all browsers?
If you like reinventing the wheel, write your own. For me, I prefer to spend my time focusing on solutions rather than lines and lines of javascript code. I'll use JQuery to save resources and frustration
One thing I want to add is for the past couple of months, I was trying to fill a web developer position for my team, and it proved to be a difficult task.
Lots of folks knew how to use a JS framework (JQuery, ExtJS, YUI...), but once outside of the framework, they found themselves in an unfamiliar ground. I had a self-claimed senior JS developer with over 10 years of experience couldn't tell me how to use function.call() or function.apply() or how to implement simple inheritance in JavaScript.
Framework is great and definitely useful, but you will also want to make sure to know how to implement the basic OO concept and DOM manipulation without the framework.
BTW, we use ExtJS and if you are starting to pick a JS framework, you may want to look around to see which one suits you the most.
jQuery is a big project with many users. By that nature, it will be better tested than anything you write by yourself.
It is a great framework for most uses I've come to need.
Is there anything in particular you are trying to do?
jQuery helps you avoid worrying too much about cross-browser JavaScript issues, and helps you get things done quickly. As far as I'm concerned, the key reason for using it vs your own hand-rolled JavaScript probably is the "don't re-invent the wheel" cliché.
Apart from added productivity, JQuery's main plus is that it takes all (most) of the pain out of cross-browser testing.
There is no reason you cannot write your own code and splash in JQuery where needed. JQuery is incredibly lightweight for what it provides and you will quickly find that you can do most takes easier in JQuery (especially once you start using the plugins for it) than by hand. I am a big believer in not reinventing the wheel. The JQuery code is tested by tons of people and there are so many plugins to chose from I could almost guarantee that what I want to do has already been done before.
If you are starting with a clean site, now is the perfect time to take JQuery for a spin though, because if you do get hooked on it your code will be more consistent if you solve similar tasks using the same technique. Go give it a try :)
I would highly recommend using jQuery (or any comparable framework) over straight JavaScript. It just makes common programming tasks easier, most notably cross-browser development.
jquery makes js related work easier and more important standardised/compliant.
If you need re-assurance as to its use:
MS & Nokia are bundling it in their dev platforms.
Its compatible with many of the newest web technologies.
It has a large developer community supporting it.
There are many plug-ins available to aid RAD.
and more...
Give it a go!!
Definutly! Jquery wil save you a lot of time struggling over code and makes your code easier to read to non-experts.

How to achieve library-agnosticism when building a javascript framework?

I've started looking into architecturing a javascript framework.
I don't want to reinvent the wheel here, especially regarding browser quirks, and know that for that matter, I'll have to rely, at some point, on some commonly-used libraries to handle low-level concerns.
The thing is, I'm not sure how i can depend on an external library for some piece of functionality (say for example dom manipulation), without tying it to my design.
Practical examples would help make a better point, but I'm not at the design stage yet, and I'm merely trying to avoid getting started on the wrong foot.
So I'm looking for some examples, guidelines, best-practices or maybe patterns that could help in this situation.
Any insight ?
EDIT : Bit of a clarification on why I'd want to do this.
My goal is to build something resembling more of an application framework than most traditional libraries like jQuery.
Think layered architecture, where the libraries would fit into the infrastructure layer (as per Evans' definition in Domain Driven Design), and handle things such as events, dom traversing and manipulation etc...
This is a very broad question, but if I were you, I would use jQuery as a base. It is a very easy library to extend and add functionality too.
I'd recommend grabbing a copy of ExtJS and taking a look at how they provide support for replacing the underlying core of their product. You can use their higher level libraries, such as grids, trees, etc, but choose to use YUI or prototype in place of their Ext core.
That should give you a good starting point.
Edit to answer comment:
Once you've downloaded ExtJS, take a look in the "adapter" folder. In there, you'll see the various adapters that exist to make ExtJS work with other libraries. You'll quickly see how they define functions that in turn make use of the appropriate underlying lib.
Segregate your code:
use the external libraries to the fullest possible, within their separate section of code.
Taking jQuery as an example, just designate a section for interfacing with jQuery and then use jQuery within that section of the library like there's no tomorrow, and give it interface functions that the rest of the code uses exclusively.
Frankly, if you integrate a library with your code and try to make it generic enough that you can trivially swap it out with something else, you're probably going to neuter the library to the point where you might as well have not included it at all.
Accept that you may need to rewrite if you end up swapping libraries, but prepare for that by giving the library-interfacing code it's own separate section, and you'll be able to write less generic, more powerful code with those external libraries and save yourself a lot of work.
This doesn't answer your pattern question, but a word about the frameworks. All of the modern JavaScript libraries are pretty good at playing well with each other, but some are better than others. Just make sure that they libraries don't monkey-patch the core objects with arbitrary properties or muck with the global namespace and you should be good to go. JQuery and YUI are both well designed and namespaced libraries. Dojo is also quite good, but a couple years ago when looking at all of the options, it seemed like Dojo encouraged the use of proprietary element attributes in markup as JS hooks. At that time Prototype was the library that mucked with objects like String/Array and didn't play well with others. I haven't looked/used Dojo or Prototype so take that with a grain of salt. I'm actively using YUI and JQuery in the same app; YUI for widgets and event management and JQuery for Selector/DOM manipulation.
I'd suggest you pick a single general purpose library or no library at all, depending on the requirements of the framework you plan to write. It's very difficult to make any kind of recommendation without more information, such as what your framework is aiming to achieve, who will be using it and in what kind of environment.
If you're considering writing a script of reasonable complexity then I would suggest learning the relevant "low level" DOM manipulation techniques for yourself. It's not as difficult as devotees of some of the famous general purpose libraries would have you believe.
Use some kind of interface to link to the library.
Don't do:
$("blah").something();
do
something("blah")
function something(id){
$(id).something();
}
Since you could call something() 20 times, it'll be simpler to update if the actual use of the library is in only 1 place.
It'll add development time and then complexity, but you won't be as dependent on a library.
I don't think this can be achieved very effortlessly. If you really want this behavior, I think you'd have to manually map the features that are covered by all libraries you want to include support for.
So that the implementation would look like:
yourLibrary.coreFramework = 'prototype';
yourLibrary.doStuff();
And your librar would treat it in the following manner:
function doStuff() {
var elem = getElement('id');
// do stuff with 'elem';
}
function getElement(id) {
switch(this.coreFramework) {
case 'prototype': return $(id);
case 'jquery': return $('#'+id);
/* etc */
}
}
Check out the jQuery or prototype frameworks.
If you decide you need to, then extend these.

Categories

Resources