When using a javascript framework such as jquery, is there a realy chance of overusing the library for things that can be done simple using plain old javascript.
If so, then does this type of thing:
A: Slow code down
B: Make code less portable
C: Make the programmer less knwoledgeable about what is actually going on underneath everything
Im thinking of things like using jquery .each instead of a simple for loop. Sure this adds a bit of code but then its 'real' javascript if you get what i mean.
Maybe im just being naive.
Well, I suppose there's a chance, but in general the advantages far outweight the disadvantages.
In general
a) it may slow code down slightly if you're doing something that wopuld be simple in pure JS, but in most cases that';s been optimized in jQuery anyway. On the other hand, the naive way you'd do much of anything complicated is probably not as fast as Reisig et al will have done it.
b) It certainly makes code less portable in the sense that it's going to depend on the jQuery libraries. On the other hand, it will be more portable across browsers and versions, which is the more important consideration.
c) yes, it may conceal some of the javascript magic. My experience, however, is that you eventually have to learn it anyway; in the mean time jQuery makes you much more productive, much faster.
(Note, also, that these points actually apply to most libraries. jQuery is my favorite, but I write a lot with dojo, and have used prototype, scriptaculous, and YUI happily.)
B) it makes code more portable, not less, because differences between browsers are handled by the framework implementation.
AS for slowness, I would think that the initial load of jQuery would tackle most of your functionality. If you are loading 20 plugins then you may run into some issues.
jQuery is no less protable than any other JS file. Even less so if you are using a CDN.
I do tend to agree with the third point. I tend to not fuss with much actual JS anymore I just use jQuery to do everything, within reason.
Overall, I think jQuery and other JS lib's are one of the best things to happen to web development in the last bit.
The really great thing about jquery is they have already come up with some quick, smooth code that helps to protect you from cross-browser hazards. So, I am sure anything can be abused, but the benefits of knowing that my code is more likely to keep up with future browser changes simply by updating jquery's API without worrying about your my outdated javascript code gives me a little more peace-of-mind. Is it perfect? Noooooo. But right now, it makes my life sooooo much easier both now and in the foreseable future. If you write "raw" javascript-only code, then if one single browser changes the way they handle your situation, then that is one less segment of users that can efficiently view your site.
I figure if I'm going to load a library on a page, I may as well use it as much as I can. I try to get the bang for my buck (so to speak).
Of course, like any "new" technology, it is overused.
It's the same for things like Linq or CSS adapters for .NET.
The rule is if you can make it simple and efficient, do it!
Related
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
When should I use a javascript framework library?
All,
I'm fairly new to web app development.
Recently, I've built a few HTML5 apps specifically targeted at iPads and iPhones.
I've noticed that very few people seem to use straight JavaScript - virtually everyone uses jQuery (Prototype, YUI, Mootools, etc. seems somewhat less popular).
If I'm starting out - SHOULD I use jQuery? Or, would I be better off writing my own JavaScript?
In general - I prefer using as much of "my own" code as possible. I'm uncomfortable using a framework if I can avoid it - I feel like it prevents me from understanding what's going on "underneath the hood."
(Sure - even if I'm using straight JavaScript - there are many levels "underneath the hood" (e.g., browser's JavaScript enging, the OS, kernel, etc.), that I don't understand, but the lower the level I do understand, the better.)
The only concrete advantage I can think of for not using jQuery... loading the ENTIRE jQuery framework, when I only need a handful of it's functions - seems unnecessary and wasteful.
So - in general - would I be better off creating my own, highly-tailored, application-specific JavaScript for each project?
Or - should I bite the bullet, get over my reluctance to use someone else's code, and use jQuery? Are there advantages to it besides just not having to create my own versions of functions that have already been written by someone else?
E.g., are it's functions somehow optimized or more efficient than what I could produce on my own?
[UPDATE]
One of the common themes in the answers so far... jQuery eliminates the need to worry about browser differences. Good point.
By in my case, I'm writing apps specifically for the iPhone, iPad, and Android. As far as I know - the browsers are pretty consistent. The vagaries and idiosyncrasies of IE6, 7, and 8 really don't seem to apply. Is that true? If so, does it eliminate a major reason for using jQuery?
Another key issue... jQuery is so popular, that there's a good chance that it's already in the user's cache, thus eliminating the need to load it. True... but is that the only performance hit? In other words... does the existence of the hundreds of functions that are part of jQuery impact the performance of my page? (I don't know how JavaScript engines work, so I have no idea if this is the case...).
Many thanks in advance for your advice and guidance.
I do understand you. I had the same thoughts for quite a while. However, in this particular instance it has a good reason why so many people are using a framework (jQuery as the most popular nowadays). The reason is, not to care about browser-differences + a nice toolkit of methods and functions.
But the first thing (browser differences) is by far more important. If you're going to write everything on your own, you just have to care about SO SO many things for all those browsers and versions out there, it's just disgusting. So some smart clever people came up with the idea, why not creating a library which abstracts all those differences and we can use the same set of methods on almost any browser platform. Boohja, that is how a Javascript library is born.
Another point you mentiond: loading the ENTIRE jQuery framework (...)
Well, as you also correctly mentioned, jQuery is so popular it's so likely that an user already has a jQuery-version cached in his browser. So it's always a good idea to first try to load a library like jQuery from a common CDN like Google. The chances that the browser don't even need to download it are pretty good.
Now I'm not gonna argue about the code quality and stuff like that. But jQuery is a pretty solid lib. It offers a very nice browser abstraction along with a convinient syntax (jAndys opinion). But there are lots of other very nice librarys out there. In general I would always recommend to use one, especially for large scaled web applications.
At some point, you'll start anyway to write your own methods to abstract browser differences and behaviors on your own, because it is just annoying to write so much more code every time. Therefore no need to invent the wheel here (only for learning purposes probably).
This is more a question of philosophy than anything else. jQuery is highly optimized for performance, lightweight and there's a lot of things that are just tedious to do by hand every time. If you have a project, that only needs 4-5 functions, there's probably no need to use a library.
But if there's an application that uses class/id/attribute selectors, animations, listens to events, etc., then you should "bite the bullet".
There's no reason not to go with both approaches imo, just choose according to the project.
My opinion is that if you think that you can bend javascript to your will and not need a framework, then go for it.
I'd go for jQuery if I were you, simply because of the cross-browser quirks JavaScript has. jQuery handles this for you.
E.g., are it's functions somehow optimized or more efficient than what
I could produce on my own?
Probably, although there might be a few exceptions.
JavaScript (web browsers) should be standardized, but they not (yet). jQuery do that!
You might be interested in list of tiny JS frameworks, if you think jQuery is too large.
Yes, jQuery hides a lot from you. Yes, a page with jQuery will be slower than an optimized page without jQuery. But computers are so powerful these days that, unless you are using jQuery in a very inefficient way in huge applications, nobody will notice.
About the download issue: it is only 31KiB. Even with GPRS this will only take a couple of seconds to load.
My advice: learn jQuery, and then use it when appropriate.
Thanks to your experience, could you say it's better to use the DOM object XHR or ajax method with jquery ?
Or maybe it depends on points like performance, reliability, or usability ?
I'd like to have some views
I would always recommend using a library such as JQuery rather than writing your own ajax system using httpxmlrequest.
Firstly, JQuery's ajax code already exists, and has been thoroughly tested. It is known to work well, work in all browsers, and to be secure.
If you writing your own ajax code, you'd never be quite sure on either of those points. You'd never be able to do as much testing as JQuery.
JQuery's ajax code is also extremely easy to use. And there are excellent examples and tutorials all over the web. If you write your own, you'll need to consider writing documentation for it (consider the guy who has to take over maintenance of your code in a few years! ;-))
Plus, if there are any security bugs found in JQuery, you can be sure that there will be a patch released for it pretty quickly. If your code has a security bug, you probably wouldn't know about it until after you realised your site was being hacked.
The only time you should consider not using a library for this sort of thing is if you're in an environment where resources are extremely tight. For example, you know your site will need to work with extremely low-memory computers, or those with very low bandwidth, which would make the overhead of downloading a library like JQuery prohibitive. But in that case, you're unlikely to be writing Ajax-capable code anyway.
I should point out that JQuery isn't the only library out there which can do this sort of thing. JQuery is great, but if you want to try something else, there are a number of others with similar capabilities. There are also a number of smaller Ajax-specific libraries, if you don't need the overhead of a full blown framework like JQuery.
It's better to use jquery ajax method, because of the following advantages:
It's cross browser
You don't need to care about internal details, (that also vary from browser to browser)
If there's a bug (rarely) there's a big community that fixes it quickly
Very understandable code (you and anyone can mantain it without problems)
You should use plain xhr only when you can't do something specific with jquery ajax, for example long polling (very rare cases)
Those were my 2 cents.
Hope this helps. Cheers
In terms of usability, using $.ajax can't be beat. So many people are comfortable with jQuery that you and your colleagues will be much more prepared to handle modifying and updating code.
Using a library simplifies your code, reducing the chances of making a mistake, and irons out differences between browsers.
I wouldn't recommend jQuery in particular, but I would recommend using a library.
This is more of a question of style and preference than anything, though it's possible that there might be performance considerations as well.
If you're using a framework (say jQuery for the sake of argument, though it could be any framework) and you need to write a new function. It's a simple function, and you could easily accomplish it without using the framework.
Is there an advantage to using the framework anyway, because it's already loaded in the browser's memory, has a readily-accessible map of the DOM, etc.? Or will plain-vanilla js always parse faster because it's "raw" and doesn't depend on the framework?
Or is it simply a matter of taste?
The answer is going to depend greatly on what you're working to accomplish. In general, you're guaranteed at least a minor performance penalty for function overhead if you use a framework to achieve something that can be accomplished using "vanilla" JavaScript. This performance penalty is typically nominal and can be disregarded when taking other advantages of your framework into mind (speed of development, cleaner code, ease of maintenance, reusable code, etc).
If you absolutely have to have the most efficient code possible then you should try to write pure JavaScript that's highly optimized. If, like in most real world scenarios, you're not concerned about a handful of milliseconds in performance difference, stick with your Framework to maintain consistency.
There's always something to learn when you're solving problems with pure JS as opposed to having external code do it for you. In the long run, it's more maintainable because it's your code. It's not going to change. You know what it does. That's where the value of solving your own problems really comes into play. If you do your research on MDC, MSDN, and the ECMAScript spec, cross-browser scripting becomes a lot easier to process. Sure, Microsoft has their own ideas and their own DOM, but that's where the fun (read: challenge) is.
Cross-browser scripting in pure JS really heightens your problem-solving ability along with your understanding of the language. If there still are things that confound you, then jQuery can come into the mix and bridge the mental gap, so to speak. It's great to drive around in a luxury vehicle, but what use is it if you don't know how to change a tire when it goes flat? The best jQuery devs are the ones that know JavaScript well and know when to use jQuery, and when to use plain JS.
Sometimes, you just have to roll up your sleeves and do some hard work. There isn't a jQuery plugin for everything, and jQuery can't hide you from all the quirks that various browsers have to offer. Getting the job done with your own code is very rewarding, even if you had to sweat it out to make it work.
It's perfectly acceptable to use many different tools to complete a singular task. You just need to know when and where to use them.
From my understanding of jQuery it doesn't actually maintain a map of the dom in Memory and just has cross browser methods for walking the dom. Somethings will natually be faster in some browsers over others (such as a class based selector in Firefox will be faster than in IE because IE doesn't have a built in function for getElementsByClassName and Firefox does). If you don't need the frameworks methods for doing things I would say go ahead and use the native JS as that is generally what you chosen framework will use.
I would say do it with the framework, just because it will bring consistency inside the project. If you are using the framework everywhere even in small function, it will be easier to maintain.
As for the other factor it really depends on what you are trying to do.
I've been working on a javascript-heavy project. I've found that almost every time I had a cross-browser bug in my code, it was in a place where I had code like this:
var element = $(selector);
// lots of code ...
element[0].someVanillaOperation();
and that vanilla wasn't exactly the same across all browsers. What I love about jQuery is that (most of the time) it hides the browser differences and its functions work the same across them all.
If you're selecting elements by ID then plain Javascript is faster. It doesn't, however, provide any of the selection niceties that you get with jQuery - selecting multiple elements by class in a single call, for example.
Take a look at this link: http://www.webkit.org/perf/slickspeed/ which runs a speed test. It's an older version of jQuery, but the results in terms of raw speed speak for themselves.
Personally, I tend to use jQuery for everything - it keeps the code cleaner and the fact it pretty much dispenses with cross-browser JS support issues is worth any performance overhead in my book.
With the availability of JQuery, is there any need to learn direct DOM manipulation with Javascript in order to be a professional web developer/site builder/etc.?
This probably could be asked with Prototype, MooTools, etc. too, but I'm not familiar with them apart from their names.
Note: This question was rephrased so
my answer reflects the initial
question but I kept on adding.
Absolutely. Jquery IS Javascript and while it does abstract a lot of the cross-browser DOM discrepancies, one is still prone to the same exact parsing errors, scope misunderstandings, and so forth.
Using jQuery without knowing basic DOM knowledge or necessary Javascript knowledge is what I would consider dangerous, somewhat like giving a very powerful gun to a child who just may accidentally shoot himself in the foot without knowledge of how to use such a powerful tool the proper way.
A person that's taught straight with jQuery would have absolutely no idea how to debug issues if the error being thrown refers to anything in the DOM. For something as simple as comparing to see if an element is another element ( for things like current state ), they would try something maybe like:
if ( $('a.current') == $('a.current') ) { }
Which would return false since two unique jQuery objects are created. If they had known how to grab the reference to the DOM nodes they could have just done $('#el')[0] == $('#el')[0].
Anytime you use a jQuery plugin and run into some mysterious behaviour, without DOM knowledge you pretty much have to rely on someone else to help you out. Developers with DOM knowledge would be more able to debug and know the root of the problem, so you're only setting yourself up to lose more time scratching you head puzzled in jQuery land.
Furthermore, if one wishes to ever get to a high knowledge level and not just be an ordinary joe jQuery developer then he would greatly need a vast knowledge of the DOM discrepancies and Javascript in general otherwise you're limiting your skill level by a huge margin.
If you stick around Stackoverflow for awhile you'll see this in day to day questions, in which people who took the easy shortcut lack the basic JS/DOM knowledge necessary to solve their issues.
In some circumstances, you could conceivably not want the overhead of a DOM manipulation library.
E.g. for mobile development, mobile internet connections are still a bit slow at the moment, so you might want to save bandwidth by forsaking a library and going with native DOM code. (And possibly save a bit of execution time, as mobile devices are currently a bit slower at running JavaScript than desktop computers.)
But the devices, libraries and internet connections should all get faster as time goes on, so I reckon it’s unlikely you’ll do a lot of direct DOM scripting in mainstream day-to-day web development.
If you don't want to learn the underlying basics, sure it is :)
If you're not interested in how stuff works, sure it is....
If you want to cry for help each time you hit the limits of jQuery, sure it is!
If you want to depend on people here answering you simple questions, sure it is :D (reps for us...)
"The fool wonders the wise man asks."
In other words, know how the tools you use work, otherwise you'll end up with a horrible dependency.
You can use a library like jQuery with little knowledge of Javascript and almost no knowledge of the DOM, but that will only get you as far as the library lets you. You will only be able to do things that others have done before you.
Knowing how the underlying system works will also let you use the library more efficiently. Knowing what the library has to deal with lets you know why there is a big performance difference for certain ways of using the library, and why some things doesn't work at all.
There's a great many things that jQuery simplifies for you, but knowledge of the underlying JavaScript that jQuery calls can make things a little faster:
$('<div />').appendTo($('body'));
and
$(document.createElement('div')).appendTo($('body'));
are both equivalent, but the latter is a shade faster (albeit only in the order of milliseconds), since you're using JavaScript directly, rather than having jQuery calling document.createElement() on your behalf. Again, this is definitely a ridiculous micro-optimisation.
Other examples are working with Date, Math and string objects/functions. jQuery doesn't implement replacements for these (wisely so, since they're fairly easy to work with already).
I'm new to javascript (functional programming is okay for me, though) and I am wondering how jQuery got away with some of the design decisions they made. Is it just too much work to fix now or what? For instance, there seems use of strange symbols in strings when accessing elements in the DOM or weird function definitions for $, that are forcing me to check references every other time I want to get some basic data.
Can someone point me to a learning source where I can learn all of these nuances of jQuery (jQuery's examples just don't cut it, they're too spread out)? Maybe someone has a super good reference site/pdf for jQuery?
Thanks
EDIT:
And as a side point, in regards for learning, why the heck is the entire jquery.js file collapsed onto a single line? It is unreadable.
Try reading jQuery in Action, it's a really good book to get started with jQuery. Next to that you can also watch examples on jquery.com, but I did prefer the book to get started.
For JavaScript basics you can try w3schools.
In the beginning I had the same problem with the $ functions etc, but after I read the book it became all clear to me, and to be honest, I wouldn't use plain JavaScript without jQuery anymore for DOM manipulation.
For your edit: you have a compressed (or minified) version, which has all code on 1 line, most spaces removed etc to keep it small and a readable version. Both files can be found on the download page from jQuery.
The strange symbols you refer to are mostly CSS selectors, the standard way to address elements on the web. jQuery could've come up with its own conventions, but decided to go with what was standard and best known.
jQuery itself is surprisingly consistent. Once you wrap your head around the jQuery style you barely have to consult the documentation; things just work as you'd think they should.
The jQuery documentation is actually quite good and includes an example with every command. It also has a large user base, so a quick search will generally answer any questions you have. Google is your friend.
I'm guessing the issue is not jQuery, but a difference in javascript style compared to languages you're more familiar with. Watch Crockford's "Javascript: The Good Parts" for a reasonable introduction to good javascript style.
http://video.yahoo.com/watch/630959/2974197
Also check out Dustin Diaz's posts, I found his early screencasts where he'd build an app and talk about what he was doing very educational:
http://www.dustindiaz.com/
I think jqapi.com is a more useful jQuery API documentation resource than jquery.com
Compressed javascript uses less bandwidth to load up, and decreases load times. Use js beautifier to expand it.
jQuery is the greatest thing to happen to the DOM API, which is just awful to deal with. It also handles cross-browser issues and older versions, giving them functionality they otherwise wouldn't have.
The strange symbols in selectors are from CSS, not the fault of jQuery. The selectors API is now being built into browsers, so it's worth it to understand what they mean.
As for a functional programmer every imperative language is probably a failure in your eyes and mindbending to capture, with javascript and jquery probably on top of that list. They both have side effects all over. Jquery is really about manipulating the DOM so the side effects are the means and the goal, as opposed to proper functional programming.
If you're young enough you can still make the mind switch though :-)
start on jQuery Docs Main page...
You could try some other JavaScript frameworks to find out which one suits you best.
Although jQuery is pretty cool for most people, it's not the holy grail for everyone.
Maybe it's just not "your thing".