As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I started using Javascript for HTML5 mobile development but noticed I can use the jQuery library as well. My question is, does jQuery do anything besides require you to write less code? Is Javascript faster in performance? Sorry for the newbie question but I couldn't find an answer and really interested in the difference. Thanks in advance
jQuery is a library built in JavaScript. The more you abstract the less performance you'll get. For example, just selecting an element with the native DOM methods is going to be way faster than doing the same with jQuery.
So the question is not quite "find out which one is faster", you already know jQuery is going to be slower. The question is more like "is the performance hit worth it?". And yes, most of the time it is because the time you save in writing code is much more valuable than the performance hit you get, which most of time is simply negligible.
Another factor is the quality of your vanilla JavaScript code. jQuery has been tested and maintained for years, and it shows.
Your question should not be "should I use jQuery or plain JavaScript" but rather "which library should I use?". No one should be starting a substantial project with zero code, they should have at least a good collection of robust, tested code that can easily be collated into a library or tool kit.
The problem with a general library is that it must provide general solutions, hence why jQuery has 4,000 lines of code that any one project might only really need a few hundred lines of. Some libraries have very many more lines of code. If you use someone else's library, you are often bound to their update schedule and may well end up using plugins that require different versions of the library.
If you have your own library, or one developed and maintained in your work area, you get the same reuse of code and can cut your cloth to suit the project. jQuery (and most general libraries) are monolithic: it's all or nothing, you can't include just one part or another (e.g. you might just want a good addListener function). Your own library can be modular, so you only include the code you need and can avoid many of the cross–browser issues that general libraries must deal with. David Mark's "MyLibrary" is one of the very few modular libraries.
Also, cross–browser differences are becoming less and less of an issue and the DOM API is becoming richer so there is less and less need to use a general library. E.g. no one accounts for document.all anymore, or bothers with browsers that don't support either addEventListener or attachEvent. Once support for IE 6 and 7 can be dropped (a few years yet) there will be very little reason to use a monolithic third party library, modularity will be the key. Everything will be a plugin, there will be no need for a base library, or the base library will be very small to provide a generic API for basic DOM functions.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I know that coding in native JavaScript means that your code will execute faster than if you were to code it in jQuery, but how much faster?
In particular, I want to know if the speed increase would make it worth while spending the longer time coding in native JavaScript than jQuery if it was for a very large webapp?
Or is the difference in speed not that great at all?
For instance, to setup an AJAX request in jQuery all you have to do is call $.ajax or $.post and pass a few parameters, but with native JavaScript you have to create XMLHttpRequest or ActiveXObject objects depending on the users browser etc etc.
The difference in speed is in milliseconds - which can add up with thousands of jQuery calls.
The reason is that with jQuery, it tests different scenarios by the information you feed it, so it can function in many ways - even in ways that you will never use. For the functions you DO use, jQuery still performs tests on possible variables and scenarios that you will never feed it for your particular app.
That is what makes it slower. It really depends on how many calls to jQuery you will be making.
Although, it is also very cross-browser compatible, which is a big plus.
I would recommend jQuery personally, for many reasons. But again, it depends on how heavy you will need to use it, and what you define as a "great" difference.
If the only thing you want to do is an AJAX request you can create your own mini-framework that wraps creating XMLHttpRequest and doing the browser dependent stuff.
The same way you could do for any other feature you need.
However: things are getting complex quite fast. Think about animations. jQuery or any other framework will do it better and faster. And cross browser tested.
Do yourself a favor and use an existing Framework.
One more thing: premature optimization is the root of all evil. First find the bottleneck in your application, then optimize that part.
Test it.
Pick a part of your web app and write it in JavaScript and then do the equivalent using jQuery. Test the performance.
Developing JavaScript that outperforms jQuery is dependent on your, or the team's skill. jQuery is battle hardened code that abstracts lots of browser quirks for you. It does add some overhead to cater for lots of development use cases but that is a price that many developers are willing to pay.
It takes skill and knowledge to to re-create the same functionality in JavaScript while eliminating the overhead that is not needed for your web app.
I recommend you use jQuery. However, once jQuery is part of your web app it becomes your code so you must make efforts to understand what it is doing and why.
From my experience I think the best way is to use jQuery instead of native JS. Especially if your app need support in IE6-IE8. Most of the time you'll spend on fixing crossbrowser issues instead of focusing on development.
Even if you'll make your own "mini-framework" for your needs I don't think this won't be with such quality and fast as jQuery. But if you'll use jQuery - follow best practices, and you won't have performance problems and your code will smaller and easy to read.
I think you should only use native JS in highly specialized web apps.
On the app I'm building we are using a combination of JQuery with our own prototypes. The time difference from a user's perspective is negligible from using just straight JS. Plus the CBS(cross browser support) is super important.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been doing HTML layout as well as programming for many years and I'm seeing a growing issue recently. Folks who primarily do HTML layout are becoming increasingly more comfortable using JavaScript to solve basic page layout problems. Rather than consider what HTML is capable of doing (to hit their target browsers), they're slapping on bloated JS frameworks that "fix" fairly basic problems.
Let's get this out of the way right here: I find this practice annoying and often inconsiderate of those with special accessibility needs.
Unfortunately, when you try to tell these folks that what they're doing isn't semantic, ideal, or possibly even a good idea, they always counter with the same old arguments: "JavaScript has a market saturation of 98%, we don't care about the other 2%." or "Who doesn't have JavaScript enabled these days?" or simply "We don't care about those users." I find that remarkably short-sighted.
I would like the opinion of the community at large. What do you think, am I holding too fast to a dying ideal? Is JavaScript's prevalence a good excuse to use a programmatic language to do basic layout, thus mucking up your behavior and layout? jQuery and similar "behavior" based frameworks are blurring the lines, especially for those who don't realize the difference.
Most importantly, I would like some "argument ammo" to use against these folks when the "it's the right way to do it" argument is unacceptable. Can you cite sources outlining your stance, please?
Thanks everybody, please be civil :)
I consider myself also "old-school" and intend to use javascript in a way that increases user experience, but it is not necessary. So for example (not layout, just easier to understand) i would alert you with js if you haven't filled a required field in the form, but if you have js turned off I'd still "catch" you on the server side.
And yes, wherever I can I try to use static html+css. A good example is: many people use jquery animations, but in some circumstances it is easier / faster / smoother to use css transitions.
I agree with you, but because of the 2% but because of the inconsistent page load. As soon as you use client side functions to change the layout you have a short delay between the fully loaded page and the whole functionality. I usually try to do as much as possible with html/css.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm trying to learn JavaScript, but seem to be going around in circles regarding primitives, objects, functions, etc. I can code fairly well in Python, so the JavaScript part is now mostly about syntax and idioms.
I am overwhelmed by the choices and I'm not sure how to choose: Prototype, jQuery, Dojo, Node.js, Backbone.js, etc.
What would be good JavaScript framework/s to pick up after mastering the basics? At the risk of betraying my JavaScript naivete, I'd like one (or a combination of) framework wherein I can do asynchronous requests, data visualization, and UI implementation.
I can do asynchronous requests, data visualization, and UI implementation.
async requests means XHR2
data visualization and UI means HTML, DOM4 or <canvas>
If you want to learn and really learn stick with the low level basics and don't use bloated abstractions.
Sure when you use jQuery you might finish it faster, but you won't learn anything other then how to hack together spaghetti code using jQuery. Your code wouldn't be anywhere near as maintainable, stable or performant if you had just learned how to do it right with plain old javascript.
I wouldn't be right to not first say to make sure you understand JavaScript itself first. It's a rather unique language with both good parts and bad parts. If you take the time to understand closure, prototypal inheritance, this keyword, constructor functions, etc, you will thank yourself. JavaScript, The Good Parts is an excellent place to start. Anyways...
For basic DOM manipulation, event handling, ajax, etc jQuery is the clear winner. In the past, Prototype/Scriptaculous was a common alternative.
For more advanced browser-based applications, Backbone.js, Angular.js, and Ember.js are the winners.
Dojo, Mootools, ExtJS, and Knockout.js are some alternatives to Angular and friends... all with varying strengths and focuses.
There are countless libraries for charting. HighCharts is a popular one. For more advanced visualizations, check out D3.js and Raphael.
Node.js is different beast. It's a server-side, network IO platform. It's competitors are things like Python's Twisted and Ruby's EventMachine.
Of course this topic has been covered in great length here:
https://stackoverflow.com/questions/394601/which-javascript-framework-jquery-vs-dojo-vs
For the first steps I'll recommend jQuery, with it's intuitive syntax and ability to be extended with bunch of plugins, and for it's strong community and huge amount of articles, tutorials, etc. on the internet.
jQuery is a cross-browser JavaScript library that provides
abstractions for DOM traversal, event handling, animation, and AJAX
Try it at first, then you can go with other frameworks based on the task requirements like Raphaël JS for vector graphics,Processing.js for animations, etc.
I would suggest 3 main/major frameworks to consider. The reason I choose the following 3 is because they are fairly well supported, document and used, but more importantly - they all suggest a different coding style/convention.
Dojo
ExtJS (Sencha)
jQuery (UI/core)
Should be noted that any one of them can be fit to almost any coding style/preference, but if I were to create the perfect (from working with it standpoint) framework, I would do a hybrid:
Dojo's widget creation and styling + ExtJS layouting capabilities and stores-based data managemenet + jQuery DOM manipulation and AJAX support.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have started a new web application and have decided to use jquery as my primary javascript library... But still i want to get some pros and cons tips from SO users who used jquery ...
Pro's
Eliminates a lot of cross browser javascript issues
Can perform complicated Javascript operations in little code
Can easily add Ajax functionality to app
Has built in UI and effects libraries
Con's
Overhead of adding extra javascript to page
Learning curve may not be short for some developers
All pros, no cons.
The only thing will be the execution time overhead that jQuery adds to load its files and execute its functions, but compared to the Pro of coding cross browser compatible JavaScript it is nothing.
Also compared to other JavaScript libraries jQuery is one of the fastest and smallest out there. Their community is huge and you can easily find support and good documentation.
Pros:
Large community
Useful for selecting and iterating over sets of DOM nodes
Eliminates some inconsistencies between browsers
Makes it easy for inexperienced JavaScript developers to do relatively complex scripting tasks
Cons:
Regular updates that change existing behaviour
Some confusing fundamental API methods (e.g. attr() method: what exactly does it do? It certainly blurs the line between attributes and properties)
Encourages "chaining", which leads to code that is difficult to debug: in a long chain of jQuery method calls, there's nowhere to put logging statements, so you need a full-on debugger
Short list of supported browsers
A general point about general purpose libraries: they encourage developers not to attempt to understand the underlying problems that the libraries try to solve, leading to a tendency to think of the library as being magical and to use it for absolutely everything
Adds 70K of JavaScript to every page where it's used when often a few bytes of non-jQuery code would do
Performance is generally much slower than the equivalent (well thought-through) non-jQuery code
Quality of plug-ins is very variable
You've made a good choice, don't worry. jQuery is a very well designed library - it is powerful, clean, well documented, and extremely popular. Learn it well, and it will be a powerful tool in your arsenal.
That said, I think that to be really aware of its pros and cons versus other frameworks, you should first learn it well. Only a deeper understanding of a tool enables you real comparison with other tools.
The only con I can think of is the occasional memory leaks. It is a great framework on top of javascript and is not restrictive.
That said, jQuery UI is terrible to my taste and if your application requires highly interactive UI try Ext JS.
The pros and cons are really relative to what your new web application will be doing. If it is going to be JavaScript/Ajax-rich and requires cross-browser support then jQuery is the way to go - no doubt. However, if you are only going to use JavaScript very sparingly, then it may be over-kill to include a large-ish framework, and it would be more efficient (in terms of performance and page size) to code the JavaScript directly.
Pros: Lightweight, easy to use, good documentation, gets rid of nearly all cross-browser issues and normalizes the event model.
Cons: jQuery UI doesn't have much to offer, and the plugins are hit or miss.
If you're doing a very JavaScript-heavy Rich Internet Application, go with YUI or ExtJS. jQuery is an excellent DOM manipulation library, and is the best for highly custom UI work. But if you need lots of stock UI and a robust data management system behind it, you need a bigger framework to tie it all together.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I noticed most questions related to client-side script on SO are jQuery related and that got me thinking. I'm wondering what the ease of these libraries is doing to actual KNOWLEDGE of JavaScript and the DOM.
So much is done for you that my fear is there is a growing number of web developers that actually know very little about JavaScript besides how to include the jQuery library and use the plug-ins they download. It's the "fast food" approach to software development and, based on nothing more than anecdotal evidence, I think a lot of web "developers" would be in the dark when it comes to client script if they were suddenly unable to use the jQuery library.
My question: are these libraries helping or hurting REAL knowledge of client-side scripting?
In my opinion jQuery is to DOM as the .NET Framework is to the Win32 API, or GTK+ is to X11 programming. It's another layer on top of the "raw" API. It makes things a lot easier to work with, at the "cost" of abstracting the lower level details. Usually this is OK, but sometimes these details are important. It can help at times to be familiar with the underlying API (I think moreso in the jQuery/DOM case than .NET/Win32), but I wouldn't worry overmuch if someone has to hit a reference site or two before coding a pure DOM solution.
It's also important to recognize the difference between "JavaScript" and "the DOM". The DOM is not part of the JavaScript language; it is merely an API exposed by to the JavaScript engines in the major browsers. So while using jQuery might hinder one's knowledge of the DOM, it won't hurt their knowledge of the JavaScript language itself.
This is common question in programming.
Libraries and high levels of abstractions, in general, make things that were once difficult, much simpler. This tends to make the number of people who understand low-level internals smaller, but also increases the overall productivity of the industry.
jQuery have hurt my knowledge of DOM: I forget this **** DOM as a nightmare.
jQuery will never hurt my knowledge of JavaScript. You can't forget JavaScript after Crockford's texts
I started by learning Javascript as a child - HTML + Javascript was the easiest thing to deploy without having to actually know much about how computers worked. Since then, I feel that I know more about Javascript than I ever would have to.
However, there are very few projects now for which I use Javascript without jQuery. In fact, before I knew about jQuery, I made my own libraries. They weren't great, but they worked, and saved me loads of time and repeated code.
I guess my point is that the Javascript pros would have produced great libraries for themselves, no matter how many n00bs ended up grabbing onto them. Even if we're hurting beginners' knowledge of Javascript (an assertion which I'm not even going to make), jQuery is still definitely a good thing. What it does to beginners is a question of the learning process we offer beginners, rather than the tool itself.
I think that jQuery and its peers are probably greatly increasing general knowledge of Javascript. When I discovered jQuery I went from disliking Javascript and using it as little as possible to thinking it was a wonderful and beautiful language. Indeed, it might now be my favourite language in which to program, and I've learned an awful lot by reading the source code of the jQuery library. I can't believe that my experience is in any way unusual.
Why do you care about the "real" knowledge? The end result is all that matters.
If a developer can make a website that loads really fast with a great interface and layout, then he or she is a successful developer. How (s)he did it is irrelevant.