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.
Heh, that's something that many plugin authors do without needing help, isn't it? :) Here's the rub -- I'm coding a jQuery plugin which I have the intent to sell. I want to provide a live demo of it; of course, I don't want anyone just using the demo code.
I know it's dumb, and it certainly doesn't bring any good karma, but what are some naughty things I can do in the demo script that would make life reasonably difficult for anyone trying to use it? Setting undefined = true comes to mind, as well as overriding jQuery methods. Any suggestions beyond that?
I like Diodeus's idea of a video (or a screencast, etc.).
But if you absolutely, positively want an interactive demo, take jQuery, your plugin, and your demo code, put all three together, and throw the Closure Compiler at it (with advanced optimizations if you can get that to work with jQuery; with simple optimizations otherwise). The Closure Compiler is a lot more than just a minifier; it actually re-writes your code, inlining functions (even in simple mode), changing identifier names, etc. If all the code is compiled together, you don't have to tell it to "export" any symbols, it can have a renaming, inlining frenzy. :-) It will conflate the three parts (jQuery, plug-in, and demo) such that it'll be far more work than it's worth to unravel them.
The JavaScript environment, by its very nature, is insecure. Other than minifying the code, there's nothing you can really do. If the browser can see it, the user can see it. It's the same argument of trying to prevent people from stealing your images.
If you want to make a demo, make a video of it.
Don't make your deno code a jQuery plugin: instead, make it a plugin for a library that is functionally equivalent to jQuery.
Basically, take a copy of jQuery and rename all of the functions in it (and/or swap around the order of function arguments). Then make a demo copy of your plugin that is modified to use the new, messed-up copy of jQuery.
Alternatively (or additionally), minify it and have it torch/delete/ruin any component of jQuery that it doesn't need. Anyone who wants to use your minfied code will find their jQuery object has been substantially altered.
There are fairly simple workarounds to all of these defenses, but it might keep away anyone not sufficiently dedicated to understanding what's going wrong. In the end, you may find it's simply not worth the effort and just trust that honest customers will make development worth your while.
Add a check which will only pass on your own host. Then minify the code to obscure the workings.
Any many posts have suggested, most JavaScript can can ripped off without too much hassle, although it is possible to make it difficult for people. I would recommend using a good JavaScript Obfuscator; I found this one just now, and it seems to make it pretty unread-able to even the trained eye.
Before:
var somethingToSay = "hello world";
function saySomething(phrase)
{
alert(phrase);
}
sayHello(somethingToSay);
After:
eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c]||c}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('2 0="3 4";8 5(1){7(1)}6(0);',9,9,'somethingToSay|phrase|var|hello|world|saySomething|sayHello|alert|function'.split('|'),0,{}))
It's worth noting, that with any obfuscation, there might be a slight performance hit, but it's the price paid for "securing" your work.
You can minify the code to make it harder to read.
Publish your 'demo' in the form of a screen recording rather than live code.
If it's out there, it can get ripped off. You can minify, obscure, do weird things to the source code like splitting it over a bunch of JS files, but it can still be ripped off. If you really want a demo, have you considered recording a video demo?
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 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 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 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.
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 2 years ago.
Improve this question
(I understand that someone else asked a similar question and it was closed as 'argumentative', but I'm really interested in understanding the arguments around this.)
I know JavaScript really well. I've been writing it professionally for years. I've internalized a lot of the cross-browser incompatibilities and sketchiness, know DOM manipulation like the back of my hand, have worked with some of the best web developers in the industry & picked up a lot of their mojo.
I've been checking out jQuery. I understand the point of a javascript library (how many times have I written animation, getElementsByClass, and hide/show functions?). But to be honest, it seems like a waste of time to learn an entirely new syntax that isn't less complex. It seems like I'd be bashing my head against a wall to learn an entirely new interface to the same old JavaScript.
I'm not technically an engineer, so maybe I'm missing something. Could someone spell out the tradeoffs of jQuery? Is it really faster to learn and understand jQuery syntax than to just learn JavaScript?
There are a few big benefits to using a framework over homegrown/handwritten code:
Abstractions. I'm sure you're very proud of the fact that you've slung enough JS to be able to write animations from scratch. You should be! However, abstracting common functionality away from yourself is actually very liberating. You just call the method and know the innards will be executed, and executed well. Even if you're very fast at writing the low-level stuff yourself, that's still time you've spent on that instead of solving today's problems.
Common language. Using a common framework is like speaking a common language. You can collaborate with other developers very easily, and each can pick up where others left off without friction. (Compared to stepping into an application which uses a homegrown library for the things jQuery can do.)
Experts. The people working on jQuery are JavaScript gods. I am really, really good at JavaScript, and you probably are too, but there's a big difference between normal good and jQuery good. A team of insanely good people are constantly poring over a small set of common functionality - tuning it, tweaking it, enhancing it to make it the best it can possibly be. That represents a huge number of man-hours a single person like you or me simply cannot reproduce, no matter how good we are. And if you are as good as the jQuery guys, you can only benefit by combining your talent with theirs and contributing to the jQuery codebase. It's a melting pot of insane talent.
I'm not technically an engineer, so maybe I'm missing something. Could someone spell out the tradeoffs of jQuery? Is it really faster to learn and understand jQuery syntax than to just learn JavaScript?
jQuery is more than "just another interface" to Javascript. It allows you to express yourself in ways that are more compact and succincter than the corresponding Javascript implementation. At the same time, it's clearer and much more powerful. Specifically, the benefits you get include:
Expressiveness. jQuery is essentially a DSL for DOM manipulation and querying. This specificity is a major source of its utility and effectiveness.
Cross-browser. To a very large extent, jQuery is "write once, run anywhere". Even in 2009, this is still a surprisingly rare feat for web-based platforms. It's gratifying and relieving to know that you won't have to waste time debugging obscure problems on IE6 (well, most of the time).
Highly complete documentation. As a developer, I prize APIs and frameworks that have taken the time to spell out what all the moving pieces are supposed to be doing. Nothing is more encouraging than knowing that (1) things are stable enough that writing documentation isn't an attempt to hit a moving target and (2) things are useful enough that they've attracted enough people to flesh out the documentation fully.
In sum, the difference between Javascript and jQuery is analogous to the difference between assembly and higher-order programming languages. Although they're both technically both "an interface to machine language" and can both do similar things, the latter is considered far more powerful because of how easy it is to represent things and develop rapidly.
One thing I don't see mentioned is that the library is written to work cross browser on a wide range of popular browsers and platforms: IE6+, Firefox 2+, Safari 3+
That alone is reason enough to use jQuery then to write your own JavaScript and have to worry about cross browser issues yourself.
You can't learn jQuery without learning JavaScript, and you can't be a jQuery guru without being a JavaScript guru.
That said, it really is much faster to do things with jQuery than with "bare metal" JavaScript. Moreover, the way one works with jQuery is at a far more abstract level than the way one works with "bare metal" JavaScript. In addition, the jQuery syntax is very basic and not at all hard to learn, although the way you think about jQuery is very different from the way you think about "bare metal" JavaScript but enables you do to much more, much more rapidly.
community support
other developers writting and testing code, make it possible for you to do things you simply do not have time to do. Its not about doing anything you do not know how to do, its about doing things quickly, efficiently, and of very high quality (its already been tested).
From the sounds of it, you know much of the same stuff that jQuery knows about the DOM, and I can only assume you've built-up a nice DOM toolset for yourself over the years that incorporates all of this knowledge. In short, No, you don't need to use jQuery. However, some of the rest of us do not know as much about the DOM, and jQuery levels the playing field so we can get on with getting work done for our clients.
That is not to say you should not learn jQuery (as opposed to using it). You may pickup a few things you didn't know. The 3 main features that distinguish it from other DOM libraries (including your own probably) are:
built-in support for CSS selector syntax, useful for finding elements
methods that operate on the set of wrapped elements
chaining. Every method in jQuery.prototype (with "setter" behaviour) returns this
Personally, 1) and 3) don't hold a high premium. But 2) turns out to be huge for me. I never realized until jQuery how much my code tended towards operating on a set of nodes rather than a single node (if someone would have asked me I would have guessed the opposite tendency). 2) virtually eliminated all for loops from my code (or .forEach or however else I tended to abstract it), which was actually quite liberating. Now I notice it's the rare occasion where my code must operate on some single element.
Speed of development and turnaround of code.
One thing I haven't seen mentioned in the other answers is that, eventually, someone else is going to have to maintain your code. If it's all custom, they'll have a rougher time of it than if a more standard library is used. If that's not of any concern to you, and you don't think you're likely to need any of the really slick jQuery modules, then keep on with what you're doing.
For me, there are several benefits, like speed of development, etc.
But at the end of the day, it boils down to one thing:
It removes a HUGE amount of the cross-browser BS that can eat up so much time and resources, so I don't have to deal with it
jQuery allows you to write shorter, cleaner code that's easy to understand. Many people use it, so there are many plugins that work along with it, minimizing bloat. The same may not be true of your own personal library.
If you know JavaScript really well you should also know that jQuery's syntax isn't different from JavaScript's syntax.
What you might be referring to is the chaining idiom (used everywhere in jQuery) which seems to make things look very different from other sort of code. Well there's a reason for that, it's because it bonds really well with how the DOM works.
If you truly know JavaScript, you'll be at running speed with jQuery in under a week's time. If you don't already know your way around JavaScript, adding a layer on top might do more harm than good. But that's just like anything else!
You're going to be writing better looking and easier to understand JavaScript at a faster pace and only once — not once per browser. Downside? You're going to tack on another ~50KB of JavaScript. That's what caching is for :)
Jquery is javaScript in the hand of the designer.
It is as easy as writing CSS styles on an element.
Also Jquery is the easiest to understand, write maintain, add plugins.
I was working on a gallery program for a client (which is now exhibiting inexplicable behavior in IE6 and 7 - surprise, surprise - but I found that when I switched from bare-metal Javascript to jQuery a lot of the work got much easier. To me, it makes available the CSS view of the DOM while writing Javascript - which makes traversal and manipulation much more intuitive. Also, the cross-browser compatibility and brevity is wonderful.
It doesn't really matter if jQuery is great or awful. It's the powerhouse JS library now, used on a huge number of pages, and future browsers will have to accommodate it or be seen as themselves buggy.
What I don't like about jQuery: I'm not that thrilled about how it ignores mobile phone browsers in its test suites. It gets pulled in on all kinds of pages on mobile phones, and yet it makes no effort to ensure it works well on them.
jQuery degrades gracefully and it's one of the fastest (not THE fastest anymore though):
http://mootools.net/slickspeed/
There are many other frameworks out there, and whichever you choose, you probably wouldn't go wrong, but having uses jQuery myself, I'd definitely recommend it.
:)
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.
Is it a good idea to learn JavaScript before learning a JavaScript framework library such as jQuery, Prototype, etc.?
Sometimes I find myself struggling because I feel I don't know JavaScript as well as I should.
An emphatic YES. It won't take as long to learn as you fear and the rewards will be more than worth it.
Sometimes I find myself struggling
because I feel I don't know Javascript
as well as I should?
I think you answered your own question.
I'll go against the grain and say that, while ideally you would become proficient in JavaScript before learning jQuery, you can probably make great progress on both fronts by jumping in and coding using the library.
One of jQuery's strengths is that it makes it easier to do certain things in the browser. You can get a lot of real work done by cutting and pasting and adapting other people's code, so why not start doing that? As you go, when you encounter an idiom you don't quite understand, dig around and find out what it means or how it works.
Over time, you will become a master of both JavaScript and jQuery.
If you have any kind of programming background, a good book to read to get you up to speed quickly on JavaScript is Douglas Crockford's, JavaScript: The Good Parts.
Long as you learn the BASICS in Javascript; HTML document traversing, event handling, etc... you should have no problem learning jquery.
Then from learning the basics you will understand how Jquery is to help you do the things that javascript can do, but with less work.
The answer to your question is a definitive yes. jQuery, Prototype and the rest serve to overcome cross-browser headaches and ease AJAX, UI behaviours, DOM operations etc. You'll end up with some pretty bad code if you are just copy/pasting snippets or have no real understanding of Javascript.
As a litmus test, you should be able to follow everything that is said in this wonderful re-introduction to Javascript. It's a bare minimum for writing good code and may require some more Googling on your part. Only then should you read Willison's equally good introduction to jQuery.
That should provide you a good start to build upon. And then if you feel up to it, you can start digesting Crockford (start with Douglas Crockford — JavaScript: The Good Parts).
Yes it a good idea because jQuery provides you with shortcuts for some methods and effects. By learning JavaScript you get the complete idea about how jQuery is working. It will help you to solve bugs and issues in future, when you will be working on a project.
Call me old-fashioned, but I think it is best to learn the basics of one tool before moving on to its advanced cousin -- much like being competent with a handsaw before moving on to a circular saw.
If you are struggling, you've answered your own question. I feel you'll be better equipped to make good use of JQuery once you are comfortable with JavaScript.
When I started my switch from VBScript to JavaScript I was immediately enthralled with Jquery. After a short while I started to really understand how JavaScript and Jquery interacted with each other and I became a little confused and frustrated. My issue was with the desire to use the simplicity of Jquery but I felt like I was cheating myself by not learning JavaScript first.
It turned out that I learned both at the same time. As I wrote JQuery routines I found the need to learn JavaScript in order to understand why things worked the way they did and to help make certain Jquery routines work correctly.
I am still learning JavaScript and Jquery but I am much less concerned about becoming a master of JavaScript as I know my understanding will grow as it needs to. It definitely helps to have some basic understanding of JavaScript but I would say you should focus on learning how to accomplish specific tasks and not on learning JavaScript before JQuery...
My $0.02 worth.
As I see it, jQuery is nothing but a framework to make your life simpler. jQuery itself is written in javascript. So it helps to learn javascript.
Mind you, you need not be a master but should be able to make the necessary changes /work arounds, when what you can do with jQuery alone is not sufficient.
To some degree, but don't get hung up on object oriented programming like in the java world (in javascript it's prototyping anyway). It would help in the long run to have a good understanding of closures/anonymous function and how the special variable "this" is used (particularly with regards to events such as click) and how functions like "apply" work. I'd also make sure that you really understood CSS selectors as they are a central feature of jQuery and pretty much every other JS framework out there.
You're also going to need to be familiar with how to use the full functionality of firebug.
I'd also assume you have a basic understanding or knowledge of how the DOM works.
That's the start of tinkering in Javascript.
The value proposition for jQuery (or any other framework) doesn't only come from what it does with javascript. It also builds on the DOM, HTML, and a number of language-agnostic patterns. And you don't need to understand it all in depth to find frameworks useful. Of course, you'll be better off if you know all the pieces, but we all need to start from something less.
I learned jQuery and javascript simultaneously, and it worked quite well for me that way.
I think the question isn't so much which to learn first, but more to the point, you need to expect to become increasingly familiar with all the pieces and how they work together.
To me it's somewhat (not entirely) the same question as what you need to know before starting with WebForms. Sure it's better if you're already comfortable with C# (and the same DOM and html), but it's legitimate to use WebForms as a vehicle for your education. Same thing can be said for frameworks.
Suppose you should know the following about Javascript:
How to calculate the X and Y element offset for the absolute/relative positioned DIV for browsers IE6-IE8, FireFox, Opera, Safari (each of the browser has different model for this particular case).
What is closure and how to create it.
How to create onLoad event in the browsers listed above.
Have an example of the HTML/Javascript code where you have pure HTML code like
Remove
and javascript code that add special handlers in automatic mode for A tag using "rel" attribute.
After you get acquainted with this you may use jQuery library that hide the complexity of this :)
Regards,
Pavel
I think learning events the document object model, and JavaScript forms programming is enough to get started in jQuery.
Of course, it goes without saying. How can you use jQuery if you don't learn JavaScript first? After all, jQuery is nothing but a library for JavaScript.
Yes.
You obviously don't need to learn everything about JS. But at least learn the basics, and try to learn some best practices.
For me the trickiest part about Javascript is all the different implementations of it in the different browsers. But there are certain things you can do to help yourself avoid some of those problems. For example, it's usually preferred to use document.getElementById() to access elements in the DOM since it essentially works the same way in all modern browsers. Also, it's almost always best to use feature detection rather than browser detection. Little things like that go a long way in avoiding problems in specific browsers later on.
Fortunately JQuery was written pretty well for cross-browser compatibility, but there may be times when you don't want to use it directly and you may have to rely on your JS skills.
There are really two seperate aspects to JavaScript within the Browser. First, the JavaScript Language, and second the HTML DOM that allows you to manipulate the page using the JavaScript Language.
That said, then YES you should spend time learning the JavaScript Language. I recommend picking up a copy of "JavaScript: The Good Parts" by Douglas Crockford.
Now as to the second part, the HTML DOM. You really don't need to focus too much on learning the ins and outs of the HTML DOM if you are going to use a framework like jQuery. Just do things the "jQuery way" and then pick up as much HTML DOM as is necessary along the way.
Just enough to debug your code. Otherwise, you will never be able to figure out what's not working.
Learning JS would make life easier for coding JQuery but I don't see why you should necessarily learn it first. You'll just have to learn it eventually.
My first thought was that It's always good to learn something new and Javascript is becoming ubiquitous (now is on the server side too ).
It's seems that you have still not decided the best answer for you and AFAIK this question was posted before March 21 ... I see plenty of time to read at least this that was written by a very talented guy.
If you study javascript you will never come to SO asking question like:
What the keyword this mean in the contest of my snippet of code?
But if you always are in a hurry, without having time to improve your code and If you never have to build jQuery plugins go without Javascript.