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 am baffled by the difference in design between jQuery and Yahoo UI APIs. Disclaimer: I have a strong dislike of the jQuery api, but I am also a huge ignorant in web programming and javascript in general, so I could be dead wrong and come back here begging for redemption. so long...
The point of my question is the following. The two designs are different. jQuery puts the DOM at the center, and adorns the DOM by executing a "trigger" enhancer method on it. example
$("#flexigrid").flexigrid()
A requirement of jQuery is that you must, in some cases, follow a very specific conventional structure for your html beforehand. Example:
<div id="accordion">
<h3>First header</h3>
<div>First content</div>
<h3>Second header</h3>
<div>Second content</div>
</div>
and then
$("#accordion").accordion();
Moreover, the returned entity in general does not provide any mechanism to hide the DOM through a convenient programmatic method. To manipulate your jQuery entity you have to access the DOM via selectors, access that in some case is not guaranteed to be easy to know, like in the case of internally generated ids. Suppose that you want to swap the accordion programmatically, what you do is
$('#accordion').accordion('option', 'active', 2);
and not a more intuitive
myAccordion.setActiveTab(2);
On the other hand, yahoo ui focuses on javascript objects, you create them passing the DOM node selector (e.g. myDataTable = new YAHOO.widget.DataTable("container_id")) and then perform all manipulations through the object methods. Want to add a new row ? call myDataTable.addRow(). The DOM is hidden. You are not concerned with what's going on behind the scenes.
Now, my experience with Trolltech QT maps nicely to Yahoo UI. Clear, defined API of the widget objects, eventual freedom to reimplement part of them via inheritance, opaque rendering unless you want to open the box and get your hands dirty. QT is a winning API, works well, it's easy to use, and Yahoo UI is kind of similar in the design style. On the other hand, jQuery works in a counterintuitive (to me), very open box way, with reduced API on its objects.
Enough ranting. The point is that I assume I can be dead wrong on this, but I'd like to know why. What are the design advantages of having a jQuery-like interface (where the DOM is clearly exposed and you potentially have to hunt for stuff that jQuery plugins create automagically, so you can finally $(select) them and attach events or modify their content) instead of hiding everything behind an objects and commodity methods like YUI does ?
I'm not talking about speed, or code size, or amount of typing. I'm talking about design concepts like encapsulation, focus on interfaces, and ease of access. What design is better, in what situations, and why?
I don't think your argument is directed at jQuery, but more the APIs provided by plugin authors.
Unfortunately, no two plugin authors will create a plugin with the same API. The level of programmatic access is not limited by jQuery itself, but rather by the author/s of the plugin.
Also, as you said, jQuery is all about the DOM -- I see this as a benefit because it means jQuery doesn't get all mixed up in the "logic" (eh, "business logic") of the application... It's quite fine on it's own level of abstraction -- it deals with the DOM, and that's all!
You can create an unlimited amount of data structures and additional APIs for your application. jQuery doesn't hinder you in this respect.
You've added more details to your question -- this 'edit' is in response to those details.
I think what you're experiencing is common when you reach a certain stage with jQuery... The API becomes insufficient. You don't want the DOM... You want a nice clean API for your module, whether it's an accordion or a data-grid.
Personally, I don't think that some things should be bundled into a "jQuery plugin" -- doing so normally means sacrificing the API -- or having to resort to jQuery's mechanisms such as psuedo-event triggering through "trigger":
var someModule = $('#contain').someCoolModule();
someModule.trigger('initiate');
I get what you're saying, and I think I agree, but I also think it's important to have jQuery on an entirely separate level -- forget about it -- only utilise it when you need to attack the DOM.
jQuery doesn't require any kind of special markup - you can write a selector for any object. You can also use an existing DOM reference, and turn it into a jQuery object like so: $(domObject). Actually simpler and more capable than Yahoo UIs.
It's not required to know your dom selectors if you already have a DOM reference... That might be the source of your misunderstanding.
Having worked with both Yahoo UI and jQuery, let me tell you they are both great libraries. They're for different roles, but both have great approaches.
jQuery is kind of a wrapper, simplifying everything that has to do with the DOM, Ajax, selecting objects, doing graphics. It has a very concise and brilliantly simple API that abstracts all the browser compat nonsense away.
jQuery uses radically different design concepts than most newbie programmers are used to. It is really the poster child for how Javascript should be used. A few years back, there was a lot of ignorance about the power of Javascript. Mostly, because most of the javascript on the internet was terrible. Now, I think most people have realized that Javascript is one of the most capabable languages. It supports several paradigms: functional, imperative, object-oriented (prototype, not class-based), data literals....
jQuery uses Javascript to its full ability, using each aspect of its design to solve each problem in the most effective way.
I tell all people learning javascript to read the jQuery source over and over until they understand it.... It will be hard, but they will finish by being much better programmers, with a much larger assortment of tools in their toolbox.
It's kind of perpendicular to the Java/.NET brainwashing, which is to give every developer a screwdriver (OOP), and tell them it is the perfect soltion to every problem in programming and life.
Which, it's not. Every problem needs a different tool. OOP is good, but often a bad idea for some problems.
jQuery's mixin-style plugin architecture is really good. Different, but highly effective, fast, and easy to use.
jQuery is #1 for a reason - it's simple to use, and incredibly powerful.
Yahoo UI is a different approach, for a different problem. It's a UI toolkit that has very heavy abstraction from the DOM (vs. jQuery's lightweight approach).
You'll find yourself speding a lot of time modifying it if you intend to something outside the norm. (That's the downside of the heavyweight approach).
It's not a framework for developing apps. It's a bunch of GUI widgets.
I've used both together. There's no reason you can't use both jQuery and Yahoo UI on the same page, they're two different tools for different problems.
I suggest including jQuery site/app-wide, then including jQuery UI plugins as needed. If you need heavyweight stuff, add Yahoo UI. But stick to jQuery for your plumbing code...
Learn from jQuery. Understand the power of array programming, callbacks, data literals, treating code as data, and keeping things concise. And that using the right tool for each problem means much shorter, simpler code.
In my opinion, YUI is weaker in DOM manipulation, but is way ahead in design.
JQuery is designed for those with little or no JavaScript (or general coding) experience. Its very easy to get an application up and running.
YUI is more readable, and any programmer can pick it up and go very quickly because of the wide use of best-practice methodologies.
jQuery is a great library for DOM manipulations, and centering it's API around selectors is one of the reasons why it's so popular today. The thing is, jQuery wouldn't be needed if the browsers DOM APIs were more consistent and easier to use. And I agree with Robert Harvey (commented above) that as an abstract layer over the DOM jQuery does a very capable job.
But as I understand, you dislike jQuery plugin system and the jQuery UI, not the core library itself. Personally, I prefer a YUI style API for components and widgets, because at the higher abstraction level DOM elements become less important. I think the reason why jQuery UI authors chose this design is to make API more consistent with their main product, jQuery library. But I don't agree that this was a good decision.
jQuery is designed to work with the DOM (i.e. it's a language highly optimised around web pages).
you potentially have to hunt for stuff that jQuery plugins create automagically
Presumably if it's appropriate, a plugin returns a jQuery object that you can manipulate, unless it's badly written. In which case that's obviously the plugin's fault.
If you're using a method that autogenerates IDs then jQuery may not be for you. However for example I've used jQuery with Google Maps without too much trouble.
If you wanted to add a row to a table automatically, I'm sure there's a plugin out there. If not, it wouldn't take much to write one.
I agree with Computer Linguist. OOP is not a perfect fit for every possible for problem.
In case of web development one first has to decide upon the kind of solution that one has to design. Is the solution essentially a web page with interactive widgets embedded at places that enhance the interactivity or is it a full fledged RIA. JQuery,I believe is fit for the first case and it is basically targeted towards ease of handling of the DOM.
In case of RIA applications, toolkits working at a higher level of abstraction are prefered because the developer in this case is dealing with widgets and layouts rather than the HTML and css that lies underneath. In such case using Object Oriented Toolkits like YUI, Dojo or ExtJS are more convenient as they bring the desktop application development approach (with its associated advantages) to the web domain.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a student and also new to JQuery. I want to know the difference between JQuery vs JScript. How we decide what to use and when to use those two technology.
Considering
Performance
Technology
jQuery is JavaScript. It is a JavaScript library, so it operates on top of JavaScript. It cannot exist on its own, so you can't use one over the other. You can use just JavaScript or JavaScript and jQuery.
jQuery is designed to make many JavaScript development tasks much easier.
Use jQuery when it will significantly reduce your development time, and you can afford the extra overhead of downloading the library.
A lot of people automatically include jQuery without considering the fact that it might not make the particular development task at hand much easier. This is a bad habit to get into...
Personally my most common uses are:
Complex element selection
Animation
Event handling
There is a humorous Photoshopped screen shot of a "Stack Overflow" post that pokes some fun at the overuse of jQuery. Enjoy:
I was initially against jQuery and, for new programmers, I still am. It is a pure JavaScript framework that has several benefits; here are some of the major ones:
crossbrowser support
easy element selection
customizable plugins
large support community
very popular
Some would argue that it is large, which could affect your web performance... and they would be right. However, because of its popularity, it is likely to have already been used on some site you've visited before. Most browsers these days are good about caching scripts/images, so that download hit is reduced over time.
On the other hand, many new programmers that rely on the framework become very dependent on it, so much so that they lose their ability to evaluate the best tool for the job, and use the most familiar tool that they're used to. These same programmers lose their ability to properly debug and become reliant on an API that has no standard.
What I like using it for is it's cross browser support, which is great for event handling; and whenever you apply dynamic styling to elements on the page (or really anything that requires you needing a more advanced set of elements). Element selection is it's #1 tool, where you can select elements by id, type, attribute, classname, tagname, hierarchical relationship,... all sorts of ways.
I want to know the difference between JQuery vs JScript.
JavaScript is a scripting language for the web. Microsoft refers to their implementation of it as "JScript" but in terms of syntax it's pretty much the same.
jQuery is a software library, written in JavaScript, whose intention is to help JavaScript developers when writing code that is to be run in a web page.
How we decide what to use and when to use those two technology.
JavaScript (including jQuery) can be used to add interactivity to a web page beyond that which is possible merely with HTML and CSS. This allows for a more "application-like" experience for the user. Many see it as a bad idea to make a web page which depends on JavaScript, and won't run without it, and insist that JavaScript should only enhance the user experience. However, websites which won't work without JavaScript do exist and are becoming more common.
jQuery runs in JavaScript, and is written in JavaScript. If you are writing JavaScript for a web page, it is often a good idea to also use a library (or framework) like jQuery to make the task of browser-compatibility that much easier. It is like a pre-packaged set of JavaScript routines that you may have otherwise needed to write yourself, packaged in an easy-to-use way.
A drawback of using jQuery is that it is a relatively large file size, which does matter on the web. Some would argue that if you are not using enough of jQuery to justify its file size on your site, you should consider something else (such as a more modular framework, or not using a library/framework at all).
It's perhaps a little redundant now but 'JScript' was originally the name of the Microsoft implementation of Javascript in old versions of Internet Explorer. Thankfully it's long since disappeared although if you find references to it in older literature just replace with 'Javascript'.
Back to the questions, if you're new to this, I'd strongly recommend going for JQuery (or another Javascript library) instead of raw Javascript. You can do very complex things with one line of JQuery that would take a lot of coding and debugging if you were to use raw Javascript. Ultimately you will need an understanding of the underlying language to take full advantage of JQuery but if you want something you can deploy today, start with JQuery rather than Javascript.
I have been recently struggling with the same question, jQuery or JavaScript. Coming from a coding background that includes several old school programming languages (C, perl, ksh, and more recently Java and C#), I am finding that JavaScript is MUCH easier to quickly understand than jQuery. From a support perspective, the ease of understanding the code is more important than less typing when creating the code. The one answer here, that does have me reconsidering the use of jQuery, is browser compatibility. This one significantly impacts future application support. Based on my experience (over 20 years as a software engineer) the application life cycle spends a lot more time in support than it does in development.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to create a custom UI framework in JavaScript for web applications (like Google Docs ui) (do not confuse with web application that deploy using languages like PHP, Python, etc.). However, after reading several books about web development, I understand that the best website is layered as follows:
Structure in HTML
Presentation in CSS
Behaviour in JavaScript
So there are several approaches to creating my own HTML document and control it in JavaScript. However in this approach HTML and CSS will be mixed, like in case of extJS UI. I am confused now, and I need some answers from experienced developers on how to write this kind of framework.
If HTML, CSS, and JavaScript is mixed.
What was advantages?
What was disadvantages?
Is there are other methods?
What was the usual type of creating UI frameworks?
I apologize that this answer is extremely long and at times may seem somewhat off-topic, but please keep in mind that the question was not very specific. If it is improved, or made less general, then I will gladly remove the superfluous parts, but until then, just bear with me. This is somewhat of a compilation of the other answers here, in addition to my own thoughts and research. Hopefully my ramblings will be at least somewhat helpful for answering this question.
General Tips for Frameworks
Frameworks are a ton of work, so don't spend all of that time for nothing. Work Smarter, Not Harder. In general, you should remember these things when creating a framework:
Don't Reinvent the wheel: There are tons of great frameworks out there, and if you create a framework that does the exact same thing as another framework, you've wasted a ton of your time. Of course, understanding what goes on inside another library is a great way to make your own library better. Quoting #ShadowScripter, "knowledge -> innovation." However, don't try to rewrite jQuery by yourself. :)
Solve a Problem: All good frameworks (and programs) start with a problem they are trying to solve, then design an elegant solution to solve this problem. So don't just start writing code to "create a custom UI framework," but rather come up with a specific problem you want to solve, or something you want to make easier. jQuery makes selecting and manipulating the DOM easier. Modernizr helps developers identify the features supported by a browser. Knowing the purpose of your framework will make it more worthwhile, and may even give it a chance of becoming popular.
Fork, don't rewrite: If the problem you aim to solve is already partially solved by another framework, then fork that framework and modify it to fully fit your needs. There's no shame in building of the work of others.
Optimize and Test: This is kind of a no-brainer, but before publishing version 1.0 on your website, test every single part of the function, under every single possible scenario, to make sure it won't crash and burn in production. Also, another no-brainer, minify your code (after testing) for performance benefits.
DRY and KISS: Don't repeat yourself, and keep it simple, stupid. Pretty self-explanatory.
Stick to Stable: (This is mostly my personal opinion) Unless you're trying to create a framework specifically targetted to HTML5 in Chrome 31, using experimental features and unstable code will make your framework slower, uncompatible with older browsers, and harder to develop with.
Open Source: (Another of my opinions) It takes years for huge companies like Google with thousands of dollars invested to create frameworks (e.g. AngularJS) so it is an excellent idea to make your source openly available. Having a community of developers contributing to your project will make development faster, and will make the end product faster, bug-free, and better all around. Of course, if you're going to sell it, that's another story...
For more information about best practices when making libraries, take a look at these links:
Javascript Library Design
Javascript Module Pattern: In Depth
Best Practices in Javascript Library Design
Building a Javascript Library
Types of Frameworks
The first thing you need to think about, as mentioned above, is what functionality you want your framework to provide. Here are is the list of types of frameworks/libraries (thanks to #prong for the link). For a much more comprehensive list, see jster, which has 1478 libraries, put into 8 categories, each with several subcategories.
DOM (manipulation) related
GUI-related (Widget libraries)
Graphical/Visualization (Canvas or SVG related)
Web-application related (MVC, MVVM, or otherwise)
Pure Javascript/AJAX
Template Systems
Unit Testing
Other
As you can see from the link, there are already dozens of libraries and frameworks in each of these categories, so there's not exactly much room for something new. That being said, I don't want to discourage you- who knows, you could create the next bootstrap or jQuery. So, here are some resources about each type of framework.
Note: you can't say that any type is better than the others, they simply are designed for different goals. It's like comparing apples and oranges.
DOM (manipulation) related
These types of libraries are designed to interact with, modify, and control the DOM of a website. Here are just a few of the things they do:
Select Elements in the DOM ($("div#id .class"))
Add/Remove Elements in the DOM ($("div#id .class").remove())
Edit Attributes of Elements in the DOM ($(div#id .class).height("30px"))
Edit CSS of Elements in the DOM ($(div#id .class).css("property","value"))
Add listeners for various events taking place in the DOM ($(div#id .class).click(callback))
The most notable of these, of course, is jQuery, and it has one of the largest user bases of any Javascript library. However, it is by no means perfect, and if your library wants to compete, the best thing to do would be to make it excel in the areas that jQuery fails- speed, fragmentation, and "spaghetti" code. (The last two aren't completely in your control, but there are certainly things that you can do to make it easier for users to use the most update version, and keep their code maintainable)
GUI-related (Widget libraries)
I think that this may be the type of framework you're looking to create. These types of libraries provide widgets (datepickers, accordians, sliders, tabs, etc.), interactions (drag, drop, sort, etc.) and effects (show, hide, animations, etc.). For these, people are looking for quantity- the best frameworks out there have several useful widgets/effects that work well. This is one case where it's "the more, the merrier," of course, if it works properly.
Graphical/Visualization (Canvas or SVG related)
The purpose of these libraries is to control animations on the page, specifically on an HTML5 Canvas. These feature animations and sprites for games, interactive charts, and other animations. Again, successful graphical libraries have many, many sprites/animations. For example kineticjs has over 20 different sprites available. However, make sure that quantity does not compromise performance and overall quality.
Web-application related (MVC, MVVM, or otherwise)
Basically, the idea is to provide a layout for the users to put their code in, typically separating the model (data) from the view(what the user sees), with a small controller to provide an interface between these two. This is known as MVC. While it is by no means the only software pattern to base a framework off of, it has become quite popular recently, as it makes development much easier (that's why Rails is so popular).
Pure Javascript- AJAX
This should really be two categories. The first, AJAX libraries, are often paired with a server side library and/or database (though not always) and are designed to make connections with a server and get data asynchronously. The second, "Pure Javascript" are designed to make Javascript easier to program in, as a language, provide helpful functions and programming constructs.
Template Systems
This might also be the type of framework you're looking to create. The idea is to provide components that developers can use. There's a thin line between Template Frameworks and Widget Frameworks (which twitter bootstrap, one of the most popular template frameworks, crosses a lot). While widget frameworks just give a bunch of little elements that can be put in a site, template frameworks give structure to a website (e.g. responsive columns), in addition to making it look good.
Unit Testing
This type of framework is designed to let developers test, or systematically ensure the correctness, of their code. Pretty boring, but also really useful.
Other
This type of framework is for really specific purposes that don't really fit into any of these other categories. For example, MathQuill is designed for rendering math interactively in web pages. It doesn't really fit into any other category. However, these types of frameworks aren't bad or useless, they're just unique. A perfect example is Modernizr, a library for detecting a browser's support for features. While it doesn't really have any direct competitors, can't be put into any of the other categories, and does a very small task, it works very well, and is very popular as a result.
More Types
There are a bunch of other types of libraries. Below are the categories (I'm not listing subcategories because that would take half an hour to copy down) that JSter puts their 1478 libraries into:
Essentials
UI
Multimedia
Graphics
Data
Development
Utilities
Applications
It depends on what you really want. The first distinction that needs to be made is between a Javascript UI framework (which provides structure to the app), an HTML UI Framework (Presentation) and Widget Libs.
Javascript Frameworks such as backbone, angular, ember, and knockout provide MVC-like structure to the app.
UI frameworks such as YUI, bootstrap, and Foundation provide a consistent HTML and CSS base.
Widget Libraries such as jQuery UI, Fuel UX, and Kendo UI provide ready made widgets.
There are also fully-fledged frameworks which provide things across the board, such as Google Closure tools, Dojo with Dijit.
This Wikipedia list pretty much sums it up, and here is the comparison.
In order to find the best way to create a framework, first ask this question: Can any of the above frameworks/libraries solve all or some of the problems/requirements I have?
If something solves all the problems, you can use it right away.
If something solves your problem partially, you can start by extending/forking that project/framework.
Follow DRY and KISS rules. Only solve a problem which nobody has solved as of now.
Fortunately, there is already a good solution: Google Closure Library. This is what Google uses. It shows the approach of mixing HTML, CSS and JS. I wouldn't say it's perfect, but I believe it's one of the best ones at this moment. Its architectural principles rely on proven component based and OOP concepts, and it's accompanied with a static compiler for Javascript. It's definitely worth of studying before baking your own solution.
I'd like to say that cloudcoder2000's answer sums it up nicely. I'm just writing this answer because it didn't seem right in the comment section :P
If you are thinking of making another framework, my suggesting is to stop thinking.
First find the thing in current implementations which troubles you the most, and try to find how you can improve it. Contribute to existing projects, nearly all of them are open source anyways. Also, you don't really need to be a JS-ninja to get into their midst. Take a fork, and get started. Once you're done, and feel that you're code is good enough, make it known to the original repo's maintainers that you have done improvements, and are looking for it to be merged into the project.
Keep in mind here that I'm not discouraging you from solving the problem at all.
I'm just pointing out that there are so MANY frameworks out there, wouldn't it be better if you went ahead and contributed to one of them instead of going for complete glory and implementing a full framework yourself? Making a framework is hard, but getting people interested in your framework is HARD. Really Really HARD, even for Google! Only once Angular got a very good documentation (which itself took quite some time, and resources, of Angular evangelists), that it has gathered so much steam. So, I'm just saying that instead of creating your own monument, perhaps lending a hand to others would be a more worthwhile exercise.
Most importantly though, is the fact that since you are just starting out, I presume you wouldn't have much experience designing frameworks, or thinking in those design terms even. It would of immense value if you contribute to existing projects. Then you will be gathering knowledge and experience of how things are built. Then, you'll be more confident. Then, you can go ahead and make your own framework! Then you'll be more equipped to tackle mammoth projects such as designing a framework. And Then, my friend, will you make something which would be worth the time of countless developers.
Short answer
Build a skinny DOM and only focus on JS code to make it more efficient.
Long answer
A good architect always replies with "it depends." You can't have one single framework that enjoys all others' benefits and suffers from no disadvantages, all at once. There's always a trade-off.
In order to create a framework that is really lightweight, you would probably want the lightest DOM (HTML) structure. However, having a skinny DOM might have the cost of more JS code. So you would probably try to write the most efficient code. You can start here.
Needless to say, you should be keeping the open-close principle, and have the stylesheets separated from HTML, using only classes and never inline styling. I would suggest using less. It makes the implementation faster, and the result is pure css so you suffer from no performance issues around it.
I must respectfully disagree with cloudcoder2000,
From a young age I have been being told don't re-invent the wheel, but why?
During the last 3.5 years, I have re-invented almost all of my web controls using javascript/html/css. From the extremely complex; for example a grid, rich text editor, tree view, dialog. To the very simple, like a progress bar, dropdown. What I gained is a better understanding of html/js/css.
No pain, no gain. I'm so happy with what I was doing these years as I learned more than others.
Some of the controls I re-invented, I think, are much better than the popular ones, like telerik, jquery mobile, extJS. For example, my tree view is fully customizable, with it one can build very complex trees.
So, I encourage you re-invent the wheels, and you will definitely get more than you expected. But also, from the beginning, you need to learn the source code of the popular controls, and re-invent them. You will be very happy when you find yourself be able to make the controls better.
Then the tips on creating HTML controls:
1. use jquery;
2. write jquery plugins(jQuery.prototype...) for simple controls, while define classes for complex controls;
3. separate css from html and js files. Define the html template in js, don't use html files, which make using the controls hard.
Regards,
Leo
For best performance in your UI design, you need to use a lightweight JavaScript framework like angular or backbone, Twitter Bootstrap for the UI, AJAX for base script load and use gzip compression in your app to make it lightweight and help the UI render faster.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a student and also new to JQuery. I want to know the difference between JQuery vs JScript. How we decide what to use and when to use those two technology.
Considering
Performance
Technology
jQuery is JavaScript. It is a JavaScript library, so it operates on top of JavaScript. It cannot exist on its own, so you can't use one over the other. You can use just JavaScript or JavaScript and jQuery.
jQuery is designed to make many JavaScript development tasks much easier.
Use jQuery when it will significantly reduce your development time, and you can afford the extra overhead of downloading the library.
A lot of people automatically include jQuery without considering the fact that it might not make the particular development task at hand much easier. This is a bad habit to get into...
Personally my most common uses are:
Complex element selection
Animation
Event handling
There is a humorous Photoshopped screen shot of a "Stack Overflow" post that pokes some fun at the overuse of jQuery. Enjoy:
I was initially against jQuery and, for new programmers, I still am. It is a pure JavaScript framework that has several benefits; here are some of the major ones:
crossbrowser support
easy element selection
customizable plugins
large support community
very popular
Some would argue that it is large, which could affect your web performance... and they would be right. However, because of its popularity, it is likely to have already been used on some site you've visited before. Most browsers these days are good about caching scripts/images, so that download hit is reduced over time.
On the other hand, many new programmers that rely on the framework become very dependent on it, so much so that they lose their ability to evaluate the best tool for the job, and use the most familiar tool that they're used to. These same programmers lose their ability to properly debug and become reliant on an API that has no standard.
What I like using it for is it's cross browser support, which is great for event handling; and whenever you apply dynamic styling to elements on the page (or really anything that requires you needing a more advanced set of elements). Element selection is it's #1 tool, where you can select elements by id, type, attribute, classname, tagname, hierarchical relationship,... all sorts of ways.
I want to know the difference between JQuery vs JScript.
JavaScript is a scripting language for the web. Microsoft refers to their implementation of it as "JScript" but in terms of syntax it's pretty much the same.
jQuery is a software library, written in JavaScript, whose intention is to help JavaScript developers when writing code that is to be run in a web page.
How we decide what to use and when to use those two technology.
JavaScript (including jQuery) can be used to add interactivity to a web page beyond that which is possible merely with HTML and CSS. This allows for a more "application-like" experience for the user. Many see it as a bad idea to make a web page which depends on JavaScript, and won't run without it, and insist that JavaScript should only enhance the user experience. However, websites which won't work without JavaScript do exist and are becoming more common.
jQuery runs in JavaScript, and is written in JavaScript. If you are writing JavaScript for a web page, it is often a good idea to also use a library (or framework) like jQuery to make the task of browser-compatibility that much easier. It is like a pre-packaged set of JavaScript routines that you may have otherwise needed to write yourself, packaged in an easy-to-use way.
A drawback of using jQuery is that it is a relatively large file size, which does matter on the web. Some would argue that if you are not using enough of jQuery to justify its file size on your site, you should consider something else (such as a more modular framework, or not using a library/framework at all).
It's perhaps a little redundant now but 'JScript' was originally the name of the Microsoft implementation of Javascript in old versions of Internet Explorer. Thankfully it's long since disappeared although if you find references to it in older literature just replace with 'Javascript'.
Back to the questions, if you're new to this, I'd strongly recommend going for JQuery (or another Javascript library) instead of raw Javascript. You can do very complex things with one line of JQuery that would take a lot of coding and debugging if you were to use raw Javascript. Ultimately you will need an understanding of the underlying language to take full advantage of JQuery but if you want something you can deploy today, start with JQuery rather than Javascript.
I have been recently struggling with the same question, jQuery or JavaScript. Coming from a coding background that includes several old school programming languages (C, perl, ksh, and more recently Java and C#), I am finding that JavaScript is MUCH easier to quickly understand than jQuery. From a support perspective, the ease of understanding the code is more important than less typing when creating the code. The one answer here, that does have me reconsidering the use of jQuery, is browser compatibility. This one significantly impacts future application support. Based on my experience (over 20 years as a software engineer) the application life cycle spends a lot more time in support than it does in development.
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.
Context:
I am astounded by the number of front end developers that hack at HTML, Javascript and CSS all day long and that ignore tools like jQuery ( or other equivalent helper frameworks ) and refuse to use them. I am not talking about JavaScript gurus, I am talking about in the trenches every day Joe production developers. I get a lot of arguments that are more like excuses or personal opinions that I don't think have any technical merit, I want to make sure I am not missing something.
Question:
What are some empirical technical reasons not to use jQuery?
I am not looking for religious or dogmatic arguments or subjective opinions "like some other framework is better", consider jQuery the straw man for all comparable frameworks in the question.
Update 2015:
In this answer from 2011 I'm talking about libraries like jQuery, YUI
or Prototype. Today in 2015 that reasoning is still applicable to
frameworks like Angular, React or Ember. In those 4 years the
technology progressed tremendously and even though I see considerably
less prejudice against React or Angular than I saw against jQuery or
YUI, the same kind of thinking - though to a lesser extent - is still present
today.
Update 2016:
I highly recommend an article published few days ago:
Why jQuery? by Michael S. Mikowski, author of the Single Page Web Applications book
That article is basically a very detailed answer to this very
question. Had it been available when I was writing the answer below - I would have definitely quoted it.
Original answer:
I'll answer about jQuery but those are the same arguments that I've heard against using YUI, Prototype, Dojo, Ext and few others. Main arguments that I've heard:
file size, which in fact is 84.6 KB in case of jQuery 3.2.1 - probably smaller than the logo on an average website and can be served from Google's CDN which is likely to be already in the cache of most of your visitors. As using jQuery always means smaller file size of your own JavaScript files, it can actually mean smaller download, even if not already in the browser cache.
speed - writing pure JavaScript may be faster, but writing portable JavaScript seems to be impossible for most of the people. A website that is faster but doesn't work on every popular browser is useless in the real world. Besides jQuery uses some pretty heavy optimizations to actually be pretty damn fast and keeps getting even faster with every release, so it's actually not so easy to write faster code by hand for anything other than trivial examples.(*)
"intellectual property" - a company is scared using someone else's code - while in fact jQuery is open source and free software that is used everywhere from your grandma's blog to Amazon, from Twitter to Bank of America, from Google to Microsoft - if they can use it then any company can use it.
I can't remember hearing any other argument being used seriously.
(*) Here's a trivial example: getElementById('someid') vs. jQuery('#someid')
Is using getElementById faster? Yes. And of course everyone always checks the parentNode to catch when Blackberry 4.6 returns nodes that are no longer in the document, right? jQuery does. And everyone handles the case where IE and Opera return items by name instead of ID, right? jQuery does. If you don't do it then your code is not portable and you introduce subtle bugs that can be very difficult to find. And getElementById is the most trivial example that one could possibly find - don't even get me started on events and AJAX and the DOM...
Update:
There is actually a fourth result of asking why someone doesn't want to use jQuery. I forgot to put it on this list because it is not really an answer but rather the lack of any answer. The comment I got yesterday reminded me about it. This is hardly a "technical reason" to be added to the list but may be interesting nonetheless and may actually be the most common reaction.
What I personally suspect to be the main underlying reason to all of those reactions, though, is what I believe to be the biggest obstacle to progress in computer science: "I don't want to use it because I never did, therefore it must not be that important."
It was once the reaction to optimizing assemblers, compilers, structured programming, higher level languages, garbage collection, object oriented programming, closures or pretty much everything that we now take for granted — and today it's AJAX libraries. Maybe some day no one will remember that we once used to manually interact with the raw DOM API on the application level like now no one remembers that we once used to write programs using raw, unadorned, inscrutable hexadecimal numbers.
jQuery expresses everything in a DOM-centric paradigm which can be misleading and doesn't require any need to express things in an application pattern.
Many developers wind up programming themselves into a corner with this DOM-centric pattern and eventually realize they haven't created anything extensible or reusable.
Rebecca Murphey has a great write-up of her own switch to Dojo from jQuery - the blog post is more about why not jQuery versus why Dojo.
One reason not to use a framework - and this is an extreme edge case - is when writing embeddable code for another website, such as a banner. Arbitrarily inserting some complicated library or another will be polluting the namespace and potentially breaking someone else's site. Not that I wouldn't put it past some advertisers to try anyway, the pond-sucking scum, but I digress...
I disapprove of adding a framework when one is already present and equally capable. I see it all too often and it's my pet hate, I see it as unwarranted bloat. That is another question entirely.
Other than that I cannot think of a justified reason not to.
filesize - but really, beyond that, it's an absolute god-send for cross-platform javascript and browser differences. You would have to have some very good reasons not to want it in your toolkit (or be a fundamentalist developer idiot).
They can't justify the filesize (even though it is probably less than script which doesn't utilise the abstractions provided).
They don't want to rely on third party tools.
Their business does not want to run any libraries (for whatever reasons).
Their business does not want to run any JavaScript code not written by their employees.
Learning: To actually code everything, and learn more. (Rather than using pre-coded stuff)
Size: jQuery has TONS of features you might not need, why make the user download so much code if it's not going to be used?
Alternatives: at this point, there are dozens of more powerful, well structured web frameworks out there.
Flexibility: Although jQuery is really flexible, you might need something it doesn't provide.
By all means, I like jQuery, but there are some reasons not to use jQuery:
Download size/bandwidth: jQuery 1.5 is now over 200K uncompressed, for some the size of the library is too much to justify the benefit.
Performance: Writing native JS will always be faster than abstracting it behind a library.
Added complexity: Many people will download the entire jQuery library when really they only need a few neat features from it.
Application Dependencies: Introducing dependencies always has its hang ups. If there is a bug in jQuery, you can debug and edit the file, but upgrading later introduces problems. You could leave the bug, but now you are dependent on jQuery's time table for a fix, not your own.
Because quite often it's just unnecessary.
if all I want to do is validate some input, or hilight some field then it's just as easy to write simple javascript / dom code. And jQuery doesn't really help in such simple cases, so the question should be why use it?
Clearly there are many cases where it is very useful, but sometimes people seem to use it for no real reason too.
I would prefer to use jquery for dom manipulation or traversing the dom , which is really easy with jquery . Moreover, attaching an event or event delegation are so easy using jquery or other framework otherwise you have to write custom event attachment for IE or non IE browsers etc.
But it has some performance penalty when you use $.each instead of vanilla JS for and array.push()...
other issues like if you bind an event and remove that without unbind it will have memory leak....
My conclusion is only use any framework for complex dom manipulation and rest use vanilla JS
Why not use jQuery?
I can't think of a good excuse to use vanilla JavaScript over jQuery (aside from the intimidation factor of learning something new), but some people prefer other JavaScript frameworks (like the excellent MooTools) due to the philosophical differences between them.
Some people simply don't like jQuery's DSL-ish syntax, but they recognize the importance of using a robust JavaScript framework.
Personally, I love jQuery, but I know people who use other frameworks and are no less productive.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Our company builds websites and web applications. We are a small firm and our team of developers are always building the javascript functions from scratch or copying from other websites built by us. Every time I bring to the table the word standardization and using a JS framework like JQuery, Prototype or any other, I am told Frameworks have the three points below as arguments against them:
Mainly for people that don't know enough JS
Frameworks limit Javascript developers
Frameworks bloat the actual development code with a lot of things that are not used.
We don't use enough Javascript in our applications for us to need JS framework
In my mind it seems that Frameworks, give our team a good starting point, documentation, a community and always the option to grow on top of the framework. Could some Framework users elaborate further?
EDIT 1:
Thanks to all of you for your great responses. I really did not think that this was going to be such a hot topic. I am glad I asked the question. I posted another similar question in the following link in case you might think you want to add something. The topic of the new question is CSS related. Thanks.
By your coworkers point of view, .NET and JAVA are for people who don't know enough assembly.
Frameworks exist for a reason. They allow you go focus on the problem instead of dealing with repetitive code. They allow you to be confident (assuming you use well tested frameworks) that certain pieces of your code are reliable and well tested.
If your coworkers are against frameworks, I would seriously consider moving on.
Since no one has mentioned it - a Javascript framework rapidly becomes one more project dependancy, and in general terms, dependencies are bad as they represent points of failure.
As for this:
Mainly for people that don't know
enough JS
Without elaborating, I will say that if one of our team said something like that in my presence, I would try to shrug it off as a joke. If I thought they were being serious, I would probably have to kill them.
And as for this:
Frameworks limit Javascript
developers
That could translate to "Frameworks make it marginally harder to write spaghetti code, and that's what I do best"
Those are not arguments, they are excuses.
Arguments against:
Frameworks prevent you from re-inventing the wheel
Frameworks generally contain well tested code
Frameworks are well supported by the community
Frameworks force you to focus on the business problem you're trying to solve
</sarcasm>
Frameworks may have a license you don't agree/can't work with
A few positives for javascript frameworks (like JQuery).
They provide standardization in ui
elements.
Reduce time to develop complex
interfaces and effects.
Normalize efforts by providing
functions that are already
cross-browser compatible.
Due to efforts in cross
compatibility documentation is more
useful in a framework as you can use
the framework's api as canon
instead of searching for obscure
support for various/proprietary
javascript functions.
Reduced learning curve for new
developers making them productive on
your software quicker.
I completely disagree that a framework limits javascript developers. Quite the opposite actually. Most frameworks provide extensive plug-in mechanisms where the framework can be extended using raw javascript utilizing hooks in the framework itself.
I'll use jQuery as an example, but what I'm saying here could apply to most JavaScript frameworks.
Many frameworks (notably jQuery) are far too monolithic and not modular enough.
While depending on well-tested 3rd party software is often more than justified, "frameworks" tend to give you a lot more functionality than you need at the moment.
In many projects, I very much like the convenience that jQuery gives me for selecting sets of elements (using $(".classname"), for example). But, if I'm not using any significant amount of AJAX, I don't need the AJAX utilities provided by jQuery.
Software should do one thing and do it well, and software written in JavaScript is no exception. Most of the frameworks you refer to try to do everything, resulting in unnecessary complexity.
One place this can bite you is when you're considering upgrading to the next version of the framework. That involves crawling through jQuery's changelogs for backwards-incompatible changes and searching your project for areas where that code is used. This can be quite a nightmare, especially if you don't necessarily have a comprehensive list of which jQuery features you use and which ones you don't.
Also, jQuery (and other frameworks) tends to cause developers to start depending on new features of jQuery without even thinking about it, making it harder to determine which features of jQuery your project uses and which it doesn't.
If you use a utility which does one thing, then you know exactly which features of that utility you're using. There's only one. (If you aren't using that utility at all, it's easy to determine. Such a determination would mean you could safely remove it from your project.)
I'm all for using well-tested 3rd party code. But if it tries to do too much, (that is, if it's a framework rather than a utility), you should probably look for an alternative. If it tries to do too much (like jQuery tries to do too much), then it's got some serious, foundational design flaws that will probably come back to bite you.
I'm surprised no one has already mentioned it:
A lot of web developers default to using JQuery without considering the alternatives
And end up including it on a web page to do a few trivial tasks which could easily be done in pure JavaScript
The result is that users have to wait for the whole library to download and it slows down web browsing
Also:
Some web developers get carried away with the design of web pages, and end up developing unnecessarily complex web pages because of the power of JQuery
Just because JQuery enables you to create scripts with good cross-browser compatibility it doesn't mean that the end result is usable on different devices / interfaces
I'd also argue the cross-browser compatibilty because I've seen instances of webkit not playing well with JQuery
JQuery encourages "fast" scripting - but if you rush it you are likely to have missed something out
Writing in JavaScript from scratch is slower - but I believe that you end up with a more complete solution which more closely matches the users needs
Using JQuery can shift the focus of the web developer to creating web sites which are highly graphical and visually appealing, whereas the focus should be on functionality and usability
JQuery is not a silver bullet for web development
I am biased here because I don't use JQuery, but it is because I haven't found a need for it yet - maybe it's because I focus more on usability and functionality rather than making the user interface look pretty (sorry I know JQuery can do more than that).
An argument against libraries is BROWSER SUPPORT most libraries support only a subset of browsers out there .
Here is an example of BBC rolling out their own instead of using something like jquery .
I liked the answer of pb +
Mainly for people that don't know
enough JS
I believe it is too complicated for them, so they use this excuse. FW allows you to build much more complex applications.
Frameworks limit Javascript developers
bullshit
Frameworks bloat the actual
development code with a lot of things
that are not used.
what is it today extra 100k-200k? especially if you use the CDN versions (at google for instance). And this is assuming you use nothing in the FW.
There are plenty of good reasons to be suspicious of frameworks in general, balanced of course by lots of reasons why they are worthwhile.
I use jquery now, and frankly within an hour of learning it realised that it fits the job so well that if it didn't exist I'd only end up reimplementing something very similar myself, only it wouldn't be as good or as cross platform.
There isn't much bloat there, it's very small and well designed and does nothing at all that stops you writing any javascript you want for specific cases that don't fit your needs.