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.
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 am developing a JavaScript/HTML5 game and obviously anyone is going to be able to read the code, which I would rather not have happen.
I appreciate I can't stop people reading the JavaScript; I can make it more difficult by obscuring it, but not stop it.
I could convert it to a Java applet (I suspect reverse engineering these is still possible, but I think it would be harder) with just a thin JavaScript wrapper (if necessary).
Someone also mentioned it might be possible to use jQuery and JSON, but I suspect that the client/server interactions may be a bit to slow to make this practical.
Does anyone know of other ways of deterring people from ripping off my work?
If it is javascript, it can be read by other people, whether you use JQuery or AJAX, because it will have to processed by the client's computer and for that, it needs to be transferred to it.
Your best bet is to obfuscate your code, if you are sticking to JavaScript. That way, it is much harder for people to steal your code.
IF you are converting it to a Java Applet, it is only slightly better, as the client can retrieve your Applet and there are Java Decompilers like JD which can help him get atleast a partial look into sources. You will have to run it through a something like ProGuard, to obfuscate that code.
If it has to run at the client-end, no matter which language you pick, there will be atleast a tiny possibility of your code sources being looked at. All you can do is to make it harder to read, understand, and reverse engineer your code using obfuscation.
I apreciate I can't stop people reading the javascript, I can make it more difficult by obsucring it, but not stop it.
True, although the Closure compiler in advanced mode makes the code almost entirely unreadable to human beings. (It also optimizes it, inlining where appropriate [in case the JavaScript engine running it later doesn't], removes dead code, and makes identifiers as short as possible, and a bunch of other things.)
I could convert it to a Java applet (I suspect reverse engineering these is still possible, but I think it would be harder)...
Yes, it's entirely possible. There are tools to turn Java bytecode (what would be delivered to the client) back into readable source. Variable names and several other things are lost, and the code may look a bit odd, but the tools are there. I'm not at all sure it would be harder than dealing with the Closure compiler's advanced-optimized version, though, frankly.
Someone also mentioned it might be possible to use JQuery and JSON...
They must not have understood, those are also entirely readable by the client.
Does anyone know of other ways of detering people from ripping off my work?
My best advice is the Closure compiler. Failing that, if you're willing to go the proprietary route, use Flash — but Flash apps, like Java applets, can be reverse-engineered. I have the impression it's harder than reverse-engineering Java applets, but I don't know a lot about Flash.
I'd say your best bet is not to even try. If you're delivering source code over the wire, people will be able to read it. Obfuscation might make it more difficult, but will not stop someone determined. And it's those determined people that you probaby would most want to stop. I'd suggest you simply live with it: write your code cleanly and clearly, use a minifier for download size, and accept the fact that others will be able to read it if they like.
And if you really want to port it to another language, that's fine. But Java applets are almost as easy to decode, so you'll have to do it server-side or deliver it in some other manner than in the browser. If that trade-off is worth it to you, there are plenty of compiled languages available.
Obfuscation is your best bet. The goal is not to stop them being able to read your source code, it's to make it easier / cheaper for them to recreate it by hand, thus deterring them from ripping off your work.
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've always been dabbling in javascript, but never really got hugely into writing a lot of javascript until last year or so. One thing I noticed is that my javascript started to grow so complex, that parts of it were more complex than the server's application code (minus all the framework code of course, such as Spring or Hibernate).
This caused me to realize that if you want to write a complex javascript application, in the same way you've been writing complex web applications on the server, you have to start thinking about best practices, architecture, how you structure your files, how you test your code, what abstractions do you use to create smaller, more reusable components, what is the best way to pass parameters and send messages, should i pass parameters or object literals, and just best practices all around. None of this provided or encouraged by Javascript itself, and everyone seems to have its own way of going about everything.
And of course, because Javascript offers such very poor api out of the box, I often spend a countless amount of time researching what the best tools for the job are. Facilities like importing files and dependencies, or even a basic collection library, are things NOT handled by the language. Let's not forget that IDE support, even in something like Idea 10.5, is actually pretty bad and nowhere near as rich as say Java due to its dynamic nature and the lack of these hard-bindings for packages and imports.
Outside of jquery, which I really like and feel comfortable with, I still haven't made any decisions as to the "right" way to do things either. This is odd to me.
Everyone seems to have their own coding idioms too - they either write in a pure functional style, or they try and create a whole classical programming model and then use that. People's coding standards and idioms vary from library to library and person to person. All of this makes knowing what the "right" thing to do an incredible task.
Even worse, there doesn't seem to be books on this sort of thing. It's like nobody has bothered to tackle it - which is totally contrary to what we have in the Java space, or many other spaces for that matter.
What is the right/successful path to having a refined way to successfully write nice-looking and robust javascript for complex web applications?
I feel like my knowledge of Javascript expanded and became more complete after reading Douglas Crockford's Javascript: The Good Parts. He really clarifies the most difficult and important parts of the language.
Reading it made clear the different types of inheritance: neoclassical, functional, prototypal. And the different ways to invoke a function: constructor invocation, apply invocation, function invocation, and method invocation.
I would start there.
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.
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.