How come the answer to every javascript question ends up being "jQuery" [closed]
I've been following the javascript questions here for the last few weeks, and I've found a common recurring theme.
Almost any question asked on here that involves JavaScript gets answered with:
- "jQuery can do that"
- "there's a plugin for that"
- "jQuery can make your bed for you."
Even questions referencing other libraries are answered by saying "Use jQuery instead".
Is jQuery replacing JavaScript as a whole?
This is a serious question. Are we really looking at JavaScripts future. Obviously this community has a strong bias towards jQuery (is that because there's alot of .NET developers?), but does the web development community as a whole share this bias?No, jQuery does not replace JavaScript, because it is JavaScript. But it helps you a lot, especially in selecting elements and applying functions on elements.
The probably most important argument for using jQuery: You don't have to think about cross-browser compatibility.
Seriously, the different JavaScript implementations in the browsers are driving me crazy.
But I also don't think jQuery should be used for everything. It depends on where (e.g. which browsers) the JavaScript is used and what you actually do.
And as I already answered on other question, you can only master jQuery if you understand JavaScript. It is very easy to write bad jQuery code if you don't understand how it works.
Update:
In fact in modern browsers you can already do stuff you normally used jQuery for, like using selectors or each(), natively in JavaScript, with document.querySelectorAll() and the array method forEach().
But this is the problem: In modern browsers. jQuery ensures that you can use the same API and don't have to care about the browser version.
I sort of have a bias against jQuery. It's my only ignored tag :)...
In my opinion, it is inappropriate for people to post into other questions saying "Can I haz jQueries?" when the other person is into "plain" JavaScript, though.
I believe that everyone should learn "plain" javascript+dom manipulation BEFORE going into jQuery, sort of like how you shouldn't jump straight into DirectX when you learn c++; you can't work with jQuery without JavaScript know-how...
In the end, though, you should use what you feel more comfortable with.
But in all honesty, I believe that you will have more opportunities if you also become proficient at JavaScript, and let's say jQuery does die out one day... Your experience with JavaScript itself will still be there.
As I see it, JavaScript is ugly, error prone and a pain. I love the flexibility that allows for approaches such as jQuery, prototype.js, etc. However, the emergence of these libraries proves my point. Not all of this is JavaScript's fault. Some of it is due to the web browsers.
To better answer the actual question:
jQuery just makes things easier, like any good library/framework should. This is the reason it gets suggested so much. It's just easier to do it in jQuery than plain JavaScript. Trying to explain all the minutiae to get plain JavaScript to work in a variety of situations can be a serious pain.
That said, I agree. If someone is looking for just a JavaScript solution, that is what they should get. However, they should realize that it could be a difficult process and not everyone has the time/interest to go to that much trouble.
I think jQuery can't replace JavaScript for a very obvious reason. It's because jQuery doesn't solve a single problem in JavaScript - the language. It only solves problems with inconsistent DOM implementations between browsers which is its biggest strength and it comes with some syntactical sugar.
jQuery can't also replace the DOM APIs for another obvious reason. jQuery - the library, is controlled by one organization and primarily one man. DOM, on the other hand, is a spec that is implemented by tons of vendors while jQuery is merely a wrapper around the various implementations of that spec.
If jQuery were to replace these DOM APIs, then it will have to be a spec because different browser vendors can't just take its code and shove it in somewhere and make everything work nicely. The browser engine might be in C, C++, Java, or GolfScript so it becomes absolutely necessary for it to be a spec rather than an implementation.
Once jQuery API's become the de-facto standard and gets laid out in a spec, it will face the same problem that the specs face now. You can't just be a core-committer who fixes a problem overnight and releases a new version say 1.4.3 of the spec. The spec has be discussed, agreed upon, changed, released, and all implementors have to update their codebase to comply which makes the entire process slower. It also loses the ability to fix cross-browser quirks because it doesn't get to control that since its operating at a higher level in the food chain.
Then, because of it being a spec and moving slowly, you can always come up with your own library *Query that simplifies the spec APIs even further, fixes cross-browser issues, and move at a much faster pace.
This is why jQuery can't replace the DOM API because if it does, it will stagnate rather quickly as better, more innovative, and competing abstractions spring up every single day.
Well I can't speak for everyone but jquery just makes javascript tasks easier. Not to mention that they are tested across multiple browsers so less concern with cross-compliant issues.
What you could write in 1 line of jquery could take you 10 or more with writing your own javascript. Also the benefit of using the library is that it has been tested for bugs that you don't have to worry about.
Just my opinion.
Is jQuery replacing JavaScript as a whole?
The only thing I never saw addressed in this thread was this: jQuery cannot replace Javascript,,, it is Javascript. It's nothing more than a collection of pre-written functions in Javascript that takes care of a lot of commonly-used and desired requirements of many developers.
Lets say you've always made your own paper (chop the wood, pulp it, dry it, decorate it, etc) before making your very special paper cut-outs. One day, while making paper cut-outs from your homemade paper, someone points out to you the wonders of pre-made paper (Oh happy day), and says "no need to make your own... get right to the fun of making paper cut-outs." You've never used pre-made paper... to you, paper is the result of a lot of time spent working with wood. So... now that you've discovered Acme Paper, would you ask if Acme Paper has replaced wood? Of course not... it's made from wood. Instead, you would suddenly think of Acme Paper as a time-saver, as a way to get to the final result of making cut-outs without all that wood-working hassle to make the paper itself.
Likewise, jQuery (the 'brand-name' paper) doesn't replace the Javascript (wood) from which it was made, it just saves you the hassle of making your own utility functions (paper) before you get to the fun of making your own custom code (little paper cutouts).
Have I confused the issue yet?
Cheers!
I can't speak for the bias toward a particular framework, but usually using a framework trumps vanilla javascript when it comes to getting things done, and done right. David Walsh said it best here:
http://davidwalsh.name/6-reasons-to-use-javascript-libraries-frameworks
If you're just using JavaScript to manipulate the DOM and do AJAX, why not use a framework to do the heavy lifting and grunt work?
JavaScript does extend beyond web pages and the DOM too. See node.js for some serious awesomeness. For a small peek read this blog post (though it is more impressive with more people on at once).
It's the same thing as asking why there is a preference towards using any framework such as MVC .net, CakePHP etc. Speed, flexibility, reuse etc.
However, although frameworks do a whole bunch of cool stuff, in the end it doesn't replace the need to know and understand underlying language.
To me, jQuery is sort of like Cocoa for the Mac. I have read that the Cocoa framework is composed simply of many "low-level" Unix commands that are the base of the Mac OS. So when you do something as simple as allocating memory, these long-lost simple commands are run.
I would not be surprised if the progression from Unix to Cocoa were to happen to Javascript into jQuery — after all, it would be easier to call a jQuery command that internally did 10 basic Javascript actions (especially if the command was commonly used). Personally, I am against it, because it limits the freedom of the developer. While others might argue it allows more creativity because it's easier/faster to build new/better things, people will rely on it, and eventually become dependent, and forget all about the basic core of Javascript.
What if a specific "handy-dandy, pre-made and ready-to-use" function for what you wanted didn't exist in the merry "simple" world of jQuery? If developers relied on jQuery, they'd be at a total loss. In my opinion, we developers must continue to be independent and create our own code, though using a little pre-made stuff doesn't hurt either.
A following says a lot about an API or Framework. In general, more users will tend to generate better documentation. Documentation can go a long way in the adoption process.
jQuery does have its limitations, at least at the time of the writing of this answer. For example, today I wanted to test functionality with a xhr that stays at readystate 3 most of the time. I decided I might be better off writing my own jQuery plugin instead of using the $.ajax that is commonly used. That wouldn't have been such a bad thing. However, I've come to appreciate that jQuery is tested on many versions of many different browsers. I can hit a target usability audience just by using one framework.
In the end, I could have experimented with $.ajax beforeSend to see if there was a way to attach a handler for readystate 3, but the documentation I was reading led me to believe that it would have been more work for the task I needed to accomplish.
Overall, I have to say that I've enjoyed jQuery more than the other frameworks I've tried. When something else comes along, I'll give it a try also.
I've noticed the same thing lately. That jQuery - but take any other framework - destroys analytical thinking. Developers look at browser scripting as Duplo Lego when it's in fact Technics.
jQuery, while an excellent tool for UI manipulation - doesn't cover every aspect of high level JS programming. What about data, for instance? jQuery is quite poor in that area, but still, when a problem arises that has something to do with sorting or filtering - we go instantly into searching for a jQuery plugin.
jQuery will not, can not replace JS as a whole.
jQuery has become a defacto standard, the way that C or Java is for the desktop programming world - everyone knows it, or should as it provides common language. Typically everyone starts on jQuery and then learns about Javascript from their experiences and can look elsewhere.
Javascript is hard, and jQuery makes it easy to get started. Once people learn jQuery, they will be familiar with Javascript enough to learn the other frameworks or create their own minimilistic ones. But alas you could learn something else instead, but generally the learning curve is bigger.
Some other really popular ones are MooTools and SproutCore - both of which have HUGE backing. jQuery is kinda like training wheels for javascript, MooTools is OO all the way, and SproutCore is for desktop apps in the cloud. Just like any programming language or framework, you learn the easiest one to get started, then as you get better you realise that different languages and frameworks are better for different things - or at least you should realise that ;-) hehe.
加载中,请稍侯......
精彩评论