JavaScript Devs: Is It Still Worth Learning jQuery? 218
Nerval's Lobster writes: If you're learning JavaScript and Web development, you might be wondering whether to learn jQuery. After nearly a decade of existence, jQuery has grown into a fundamental part of JavaScript coding in Web development. But now we're at a point where many of the missing pieces (and additional features) jQuery filled in are present in browsers. So do you need to learn jQuery anymore? Some developers don't think so. The official jQuery blog, meanwhile, is pushing a separate jQuery version for modern browsers, in an attempt to keep people involved. And there are still a few key reasons to keep learning jQuery: Legacy code. If you're going to go to work at a company that already has JavaScript browser code, there's a strong possibility it has jQuery throughout its code. There's also a matter of preference: People still like jQuery and its elegance, and they're going to continue using it, even though they might not have to.
VanillaJS Framework (Score:5, Funny)
I hear great things about that new-fangled VanillaJS [vanilla-js.com] framework. Very lightweight and fast, and already more popular than jQuery.
Re:VanillaJS Framework (Score:5, Funny)
I will admit: I looked at the page and was very interested and got super excited until I looked at the code examples harder. Well played, internet... well played.
Re:VanillaJS Framework (Score:5, Insightful)
Not defending jQuery, but I think the VanillaJS page over simplifies things and it's examples are not quite equal, and seem to tout themselves as far better, when in fact, there is a lot of complexity that something like jQuery hides.
Examples:
1. AJAX - sure, you can memorize the special incantation of r.onreadystatechange and remember that you have to check if readyState is 4 (4? wtf?) and status isn't 200. Except in the little excerpt there there is no error handling, and you basically end up with an unresponsive page with anything except the happy path.
2. Fadeout - sure, you can do the same thing in approximately the same number of characters, but the vanilla example is far more difficult to read and interpret.
3. Selector speed - sure, it might be a lot faster to do getElementById or getElementByTagName, but again, you sacrifice a lot of readability and without good tools it is really cumbersome to write.
If performance is an issue, perhaps a different, Javascript compiler is the solution. But to suggest that everybody should hand code everything in native JS instead of using the more convenient syntax that a library provides is ridiculous.
Re: (Score:2)
XMLHttpRequest.DONE === 4
Nobody bothers to use the long form. But it's there.
Re: (Score:2)
You mean it's there now. Going back through previous version of the XMLHttpRequest spec, it wasn't added until June 2007 [w3.org].
Who knows when it finally made it into enough browsers to be safe to use. By now no one uses it more out of momentum than anything else, but it wasn't a part of the spec originally, and people writing tutorials would use "4" because that would work even in browsers that hadn't been updated to use the latest spec.
Re: (Score:3)
Well, sure, but here's a question for you:
What was the first version of Internet Explorer that included it?
Because the IE XMLHttpRequest documentation doesn't list it [microsoft.com] as a member. (I think that's the most recent documentation, but with MSDN, who even knows.)
And their example uses oReq.readyState == 4 /* complete */.
Then again, who knows when that page was last updated, and the standards they link to do include DONE. (And I checked: IE 11, at least, has it.)
Re: (Score:2)
To your examples
1. If you're really that slow, write a single, very short (If performance is an issue,
Performance usually doesn't become an issue until you start using jQuery. Nothing kills your UI faster than that nightmare.
Re:VanillaJS Framework (Score:5, Interesting)
Basically this. jQuery is one of those things that's almost literally bloat: it adds nothing that your browser can't already do, it just wraps around it. You absolutely do not need to use it.
However it saves on development time. It's effectively a bunch of boilerplate code that you don't have to deal with. It's one of those things that if you were to decide not to use it, you're likely to end up rewriting a chunk of it by the time you're done anyway, so you might as well go ahead and use it from the get-go and save yourself some time.
(Which isn't to say you should always use it. I've written pages where the amount of dynamic code was small enough that using jQuery would make absolutely no sense. But the larger your project gets, the more sense it makes to use frameworks like jQuery.)
Re: (Score:3)
In a trade-off between speed for the user, and development time, there's never one 100% true answer. Everything depends on what you're developing. But a bias towards the user is a good mindset to cultivate.
Re: (Score:2)
Technically, isn't that true of any library or framework in any Turing-complete language?
Re: (Score:2)
It's technically true of anything except machine code. Ever assembler is an abstraction.
And even then, a CPU is just a generalized abstraction of dedicated chips.
Re: (Score:2)
You forget memory usage... (Score:4, Insightful)
When you load a javascript library the browser has to allocate memory to every function in the library even if they are never used and most web sites are using dozens of javascript libraries. While this is ok on a desktop, on a tablet - which has much less memory - it means you only have enough memory to have one web page open at a time. Some web pages are so infested with javascript libraries they cause the tablet browser to crash. And they are just displaying static text and images, something that doesn't require javascript.
Re: (Score:2)
Re: (Score:2)
Wow... so your solution to avoiding the common case of re-inventing the wheel and having "a mess of implementations of half-maintained half-abandoned libraries" is to... wait for it... use "custom in-house libraries"? Even worse, those will only do "what is required, nothing more, and won't cover special cases that you don't use" (at that time for that app).... so when you try to get all your various in-house incantations using the same incantation, you'll simply have to rewrite... well, everything. Good lu
Re: (Score:2)
You've posted several reasons why it might be acceptable to choose jquery. However, I think there's an even more compelling reason for why you probably SHOULD use jquery (unless you can come up with a really compelling reason otherwise). I posted about it nearly a year ago: http://mobile.slashdot.org/com... [slashdot.org]
Here is the most relevant part from my previous post:
Re: (Score:2)
Re: (Score:2)
Personally I just make sure to compile jQuery using VanillaJS to take advantage of all the speed VanillaJS offers!
Re: (Score:2)
Maybe I missed the whoosh, but there are definitely "VanillaJS jobs" out there - friend of mine recently got a nice job with Apple with about 10 years of "frameworks are for the weak" JS experience - built his whole career on vanilla JS.
Re: (Score:2)
Slashdot using it isn't really an outstanding endorsement. I mean, they can't even get their comment system working right. So Vanilla JS doesn't help much there.
meh (Score:3, Informative)
jquery makes an absolute mess out of javascript. Much of it involves DOM manipulation, which is something you generally want to avoid doing as much as possible. It's a pain in the ass to read, has a nasty learning curve, and it's slow as fk. Don't bother, unless you need to operate on existing jquery code, or have some other very specific reason to use it or interact with code that uses it.
Re:meh (Score:5, Informative)
It's a pain in the ass to read, has a nasty learning curve, and it's slow as fk
Eh? It took me all of a few days to read through one of the many reasonable books about jQuery, and I found it makes it a whole lot easier to make sense of the DOM. In a browser, what else is there to JavaScript, other than messing around with the DOM? Of course, I only use JavaScript on the client side, for the server side I use J2EE and GlassFish. jQuery is perfect for my use and very, very easy to learn.
Re:meh (Score:5, Insightful)
Much of it involves DOM manipulation
Yeah? Much of jQuery is about DOM manipulation. If you don't want to make a hole, don't use a drill.
Expand details of part of the document (Score:4, Interesting)
Instead of throwing many small fragments at the browser and stealing user cycles to cobble it all together, just serve up the content already.
I have served the document. Now the user has activated a control to expand details of a particular part of the document. How should this click be processed?
Or I have served the document. Now the user has opted into real-time updates of part of the document. How should these updates be served?
"as much as possible" (Score:2)
I agree. One can avoid doing JavaScript. But it's still "DOM manipulation, which is something you generally want to avoid doing as much as possible." el is a DOM element, and assigning to its outerHTML property is manipulation. I guess I may have misunderstood XO's opinion of "as much as possible."
Besides, a web application's offline mode (using application cache, local storage, and IndexedDB) still has to manipulate the DOM because it doesn't have a server to conveniently format the data as HTML for insert
Re: (Score:2)
You want to go back to the days of full page reloads every time you do something?
Re: (Score:3, Insightful)
I agree in the main that DOM manipulation is the root of all JS sin, but the list you provide is not my experience as all. Like all code, well-written JS+jQuery ought to be self-documenting. Again: caveat is well-written. The learning curve is no steeper than figuring out JS's own native esotericisms. Yes, jQuery is slow as fuck. $('#something') is something like thirty times slower than document.getElementByID(), BUT when you are in the realm of milliseconds I will trade those extra keystrokes because I'm
Re: (Score:2)
Re: (Score:2)
jQuery is for lazy, fat, "developers" (Score:4, Insightful)
Also, jQuery allows developers to be very lazy. Example: Many sites bring back JavaScript in their AJAX returns. Did you know that jQuery uses EVAL to process any JavaScript returned via AJAX?
jQuery UI is a horrendous memory and performance hog. There are billions of JavaScript code examples to perform the individual functions of jQueryUI without forcing your customers to download that monster.
Don't be lazy.
Re: (Score:2, Insightful)
Im not being lazy, im being productive. jQuery helps you get things done quickly. Could I get everything I needed done without it? Of course, but when I can get things done much faster with it, I will use it.
Re: (Score:2)
Im not being lazy, im being productive. jQuery helps you get things done quickly. Could I get everything I needed done without it? Of course, but when I can get things done much faster with it, I will use it.
You could get things done faster with jQuery so you have more time to be on /.? :-D
Re: (Score:2)
So I presume you write everything in machine code then? Or do you take the easy way out and just use assembly for all your projects?
Re: (Score:2)
The options are: 1) Use a library that harms both performance and readability 2) Don't use a library and enjoy better performance and readability.
With jQuery, you save maybe a few minutes of development time, assuming the developer is already familiar with the library, but it costs you a lot in application performance and maintenance costs. The few extra minutes it takes to do things right in the first place quickly pays for itself.
Re: (Score:2, Insightful)
Billions of code examples to search and sort through that may or may not actually work, instead of one set of code that does most of what I need right now? And this is supposed to be an argument against jQuery?
Don't forget legacy BROWSERS. (Score:5, Insightful)
A site may wish to continue using JQuery because some of its clients are using older browsers that don't support the new features that allegedly obsolete JQuery code.
Drop the JQuery code and you drop those customers. Develop future code without it and the pages with the new features won't perform with people using legacy browsers. And so on.
I've seen similar things happen over several generations of web technology. Use care, grasshopper!
Re:Don't forget legacy BROWSERS. (Score:4, Insightful)
This is tricky. It's tempting to support legacy browsers, but if you do too good a job of supporting them, you don't incentivize your users to ever get their sh*t sorted, and upgrade their browsers. It's a vicious cycle I am eager to avoid.
Yeah, but when your "users" are more properly called "customers" -- or even more important, "potential customers" -- then some web dev's desire to preach the gospel must take a back seat to doing the job the way it needs to be done, rightly or wrongly.
It's fine to push for strict browser standards when the only people who will ever see your web applications are within your own organization. Public-facing sites are a different matter.
Sometimes you have to fire some customers (Score:3)
but when your "users" are more properly called "customers" -- or even more important, "potential customers" -- then some web dev's desire to preach the gospel must take a back seat to doing the job the way it needs to be done, rightly or wrongly.
There are customers you want, and customers you ought to fire. Users of Internet Explorer before version 9 are probably using Windows XP, an operating system that cannot run IE 9. This means they're less likely to spend money on replacing a decade-old unsupported system with known security vulnerabilities. This in turn means they're less likely to have disposable income to buy your product. It also means they're less likely to care about the security of the payment information with which they buy your produ
Re: (Score:2)
Latest statistics indicate that Internet Explorer has less then 15-20% of market share, with versions older then IE 10 being just 2.5% of the market. Looks like IE 6 is under 1% now.
A year ago, you'd be a fool to cutoff sup
How does that argument play versus Linux? (Score:2)
CustomerP are generally too cash poor to be good customers. They are going to nickel and dime you for any project that you do for them because they are either too cheap to invest in newer technology or too poor to do so.
Latest statistics indicate that Internet Explorer has less then 15-20% of market share, with versions older then IE 10 being just 2.5% of the market. Looks like IE 6 is under 1% now.
It was similar arguments that massively hampered the adoption of Linux, Netscape/Firefox, .... Too few users,
Re: (Score:2)
Only idiots on Winblows are affected, and you don't want their business anyway. They have no awareness.
Thanks for that segue. Now, back in the real world, one doesn't usually have the luxury of choosing one's customers. Furthermore, one very seldom has the opportunity to choose the customer's home PC environment for them either.
People in the real world make decisions based upon their personal and business needs; the black-and-white views of basement-dwelling trolls tend to factor less into their calculations than you might expect. No, really.
Comment removed (Score:5, Insightful)
Re:JQuery is something to learn? (Score:5, Insightful)
Same here. $('select something').do_stuff(function (e) {...});
That's about it. I don't feel as though I have some big investment there.
IE 6 (Score:2)
Re: (Score:2)
Must be nice.
In my world html5 comes in 2020 when Windows 7 Goes EOL
Re:IE 6 (Score:4, Funny)
Re: (Score:2)
Re: (Score:3)
But can you give me an example of jQuery creating a terrible mobile experience? In my experience, I haven't noticed any issues on mobile devices for websites using jQuery.
Re: (Score:3)
In my experience, I haven't noticed any issues on mobile devices for websites using jQuery.
I can list of plenty of mobile websites with horrible experiences that use jQuery.
But I would not say jQuery itself is the reason for that.
jQuery itself is not inherently a problem. It can be leveraged to do many memory-hungry and processing-heavy actions that break mobile browsers, but that's not jQuery's fault. People can make memory-hungry and processing-heavy PC-centric websites using many different tools.
Re: (Score:2)
You mean ignore the customers with spare cash to burn in favour of those with no (spare) cash?
Re: (Score:2)
Re: (Score:2)
Dump em!
It is 2015 and 90% of large enterprise have moved off IE 6 or use another browser like Firefox esr in their builds.
Did you know modern IE has compatibility mode! No really most incompetent admins use it now for adding IE 7 sites and later to the intranet zone. This means they can upgrade and emulation runs for older sites.
Banning IE 8 is almost there as you can remind them to install Firefox or Chrome which most should also have. Getting close indeed. It is not 2005 anymore where people have no othe
Uh... yes (Score:4, Insightful)
That is, If you like frameworks that are bug free, extensively tested, universally known and hide a lot of the weirdness between browsers and browser versions providing a consistent interface, then yes, definitely learn it, it takes a lot of pain away.
If you like pain, or always want to use the shinny new fancy thing, or want to learn all about IE9 and Opera edge cases. Then don't use it.
SharePoint.... (Score:5, Funny)
Never learned jQuery (Score:2, Informative)
I've been using Javascript for 15+ years and never seen the reason to learn jQuery.
Know about it, don't learn it (Score:3)
I don't know that I'd start a new project in it, but jQuery has permeated the web to such a degree that I don't know if you *can* be a front-end web without being vaguely aware of it. It's worth *knowing about* but there isn't much to *learn* about it. It's a library for "querying" the DOM the way you do in CSS; that's why it became popular -- that particular task used to be difficult, even though now it's part of the DOM [mozilla.org]. I still use it for Ajax requests, mainly because the syntax is easier for me to remember than native JS. But most of what jQuery made easy is already easy in bleeding-edge browsers and frameworks. The rest - promises, events, animations, ajax - are sort of "helper fluff" that are also better done in other libraries, or native JS/CSS at this point.
TL;DR - Yes, you should learn it, but don't go out of your way to focus on it. If you understand modern JS & DOM techniques, then you'll be able to figure out jQuery easily when the day comes that you need to debug/modify/replace it.
Yes... (Score:3, Insightful)
Re:Yes... (Score:5, Funny)
>> Web is for video playback, reading news and blogs, Business app?, desktop
And how long have you been out of work?
Re: (Score:2)
Re: Yes... (Score:3)
How portable will your desktop app be? How easy to deploy to 10000 users? How quickly can you turn round a layout problem? There's a reason why Web apps are popular - they're using a piece of middleware that is on every system. It looks like mobile apps are where you want to be. Tied into one platform and far less convenient to deploy any changes.
Re: (Score:2)
Re: (Score:2, Insightful)
Don't want to? Then shut up and go back to programming a web-app. The Internet as you know it evolved, sorry it ran you over in the process.
Business app?, desktop, using web services.
Yeah, because everyone in my company is parked behind a desktop all of the time. And there are no conceivable reasons why they may want to interact with a business system when they are't at their desk.
Re: (Score:2)
Web is for video playback, reading news and blogs
You forgot to mention the cat pictures.
Re:Yes... (Score:4, Insightful)
Web is for video playback, reading news and blogs, Business app?, desktop, using web services.
2001 called, it wants its antiquated attitude back. The web evolves: deal with it. You bitching about what the web is now isn't going to make us all suddenly go back to "video playback, reading news and blogs".
Re: (Score:2)
Re:Yes... (Score:5, Insightful)
With a standalone app, you've got to worry about things like
Re: (Score:2)
DLL Hell has long been solved as you can do the decent thing and use ilmerge to merge your application, its requirements and dependencies into one binary .exe. .Net versions are easy to handle, since you just need to target the runtime versions (of which there four of any note) and the compiler will compile all "newer" features available for .Net versions using that runtime down to IL which runs on that basic runtime - so all you need to actually target in a release is .Net 1.0, 1.1, 2 and 4.
But I would sti
All the world is not Windows (Score:2)
.net works from XP to 8.1, and it'll work on 10
But how well does .NET work on 10.6 through 10.10? Or 12.04 through 15.04? Or 4.0 through 5.1? All the world is not Windows; people also run OS X, Ubuntu, and Android respectively.
How else to reach Windows users? (Score:2)
If you are developing an app that hyperar believes "should not be on the web", then how should you reach users of Windows without "writ[ing] code for Windows"? In all but the most niche cases, charging $700 for the app and shipping a free Mac mini with it is out of the question.
Re: (Score:2)
Re: (Score:2)
Which is why there is only one framework for desktop apps.
Yeah, you don't need a framework to do basic things
The same is true of the web [youmightno...jquery.com] so long as you aren't trying to support ancient IE.
Re:Yes... (Score:4, Funny)
Web is for video playback, reading news and blogs, Business app?, desktop, using web services.
I thought the web was to add inline images to your gopher menus :P
Web apps vs. desktop apps (Score:2)
If you develop a native app people will use everywhere, you probably need these version:
1. Windows
2. Linux
3. iOS
4. Android
And then you need to convince people to download and install your software, because it is not malicious. OTOH, with a web app they just need a browser.
Native apps may be a better solution when you are doing a custom application for a specific business, and all their employees have Windows desktops or laptops.
Re: (Score:2)
No, but people are a lot more likely to browse a web site than they are to download a program.
Can you run a Mac app on Windows? (Score:2)
Business app?, desktop, using web services.
Good luck getting users of anything but a Mac to run an app developed on and for a Mac. Web is more cross-platform than native.
Yes (Score:3, Insightful)
JQuery as a framework is, frankly an utter joke. However, as a utility library it's invaluable. Learn Angular, React, or some other modern framework, and lean on JQuery for things those frameworks don't do. Simple example: Ever try to submit a from from an AngularJS controller? Yeah, not doable. Add 2 lines of jQuery? Done! So yes, learn it, and use it where it fits.
Re: (Score:2)
Don't use just one bloated library, use two!
Re: (Score:3)
Simple example: Ever try to submit a from from an AngularJS controller? Yeah, not doable. Add 2 lines of jQuery? Done! So yes, learn it, and use it where it fits.
If you're not able to submit a form in Angular you're not using the framework correctly.
Re: (Score:2)
Why would you do that? Angular is based on the concept on binding form controls to a model and (a)synchronously posting that model to an API endpoint. That's the way you submit forms.
If you need the old style submit with form-data instead of json-data that can be done as well using a properly configured call to $http. You need to set a header and transform the model using $param.
This tutorial has more: https://scotch.io/tutorials/su... [scotch.io]
Re: (Score:2)
And the above is of course using jQuery ($.param)...
It is trivial to construct a function doing the same as $.param. There is no reason to pull in jQuery for this.
Re: (Score:2)
The reason why it's not good as a framework is probably because it's not a framework, and never intended to be.
Perhaps you're thinking of jQuery UI which is not jQuery, and not really a framework but more like a set of somewhat similar widgets.
Mobile (Score:2)
I recently started putting together a web app for someone and I wanted it to design it primarily for mobile.
Looking at google analytics of several web sites I see the majority of web traffic is mobile.
So if JQuery is bloat, unnecessary, outdated and "features are present in [modern] browsers" what should I be using instead of:
http://jquerymobile.com/
This seems like the perfect solution to me?
Re: (Score:2)
I don't personally like jquery mobile because I don't like one-page apps, or indeed, any framework that dictates how I organize my application. Though it may be an unpopular opinion, I dislike the whole convention over configuration theme that's popped up during the RoR popularity phase. Not only can my IDE write out any boilerplate, but I can also search for the linkage, and all that without making 80% of my application easy at the expense that 20% will be hard or impossible.
Now, most of the applications
I don't get it (Score:5, Insightful)
JQuery is just encapsulating some primarily dom-related javascript mainpulation routines with the added bonus that they try to eliminate browser differences. So, when you're saying that the browser provides features that jquery was needed for, you're really saying that the browser does things that javascript is no longer needed for.
I'm just not seeing it though. With pure HTML & CSS and a fancy new browser, can I:
Write ajax requests and parse and conditionally apply the results to various page elements?
Dynamically add and remove elements?
Perform liquid resizing based on a layout approach with glue elements and fixed-but-scalable areas - that is dependent upon the size of other elements rather than explicit browser viewport height/width?
How about perform custom input box validation?
Maybe set the value of a text box only when a value in a linked select box is changed?
Pop up a dialog when a button is clicked?
Start an image upload when you drag an image over a browser region?
In the age of ever-closer-to-desktop-application websites, I'm only seeing more and more use of javascript frameworks - of which jquery is one - and frankly I don't see how anyone could do without it. Maybe if you're making static brochure sites, I suppose, but then you weren't using javascript for that anyway.
Maybe the original poster meant to say "is it worth learning jquery instead of another framework or library" ? Otherwise I can't see anyone who actually creates web applications for a living even asking this.
Re: (Score:3)
Agree with this. Most of the people in this thread seem to spend their time reinventing the wheel as opposed to using libraries for what they are. Maybe certain aspects of JQuery aren't necessary anymore with modern browsers, but for the most part it offers some pretty awesome tools for getting your work done. And I'd prefer to spend more time developing unique stuff for my app as opposed to inventing generic stuff that JQuery already does fairly well.
Re: (Score:2)
Yes...
Re: (Score:2)
Yes, you can (jQuery just encapsulates a lot of 'common' JS tricks). But the post is advocating for the latest framework/library du jour which does the same thing, sometimes faster, sometimes with more options or less code but the same nonetheless. jQuery is fine for what it does. I've tried using Angular, Backbone etc but unless you have something you can build something from the ground up around those libraries, they're quite useless or require a lot of custom implementation when using existing data sourc
5 Minutes (Score:5, Insightful)
Re: (Score:2)
CSS (Score:2)
Yes, partly because it's easy (Score:2)
If you need to support IE 7, definitely. But if you don't, you what? Use it anyway. The best of jQuery has been brought into the JavaScript language itself and other libraries. But jQuery still makes a lot of little things easier.
You could use the new querySelectorAll functionality in JavaScript, but learning that teaches you the basics of how to use jQuery. Also, I think jQuery still has a few selectors that aren't in querySelectorAll . Furthermore, querySelectorAll is very long to type.
You can use a
Re: (Score:2)
document.queryselectorall(".class") and $(".class") are just as readable in a world where people know what jquery is, which they do, or can learn in a minute. Which one would you rather type hundreds of times?
jQuery is a crutch. (Score:4, Interesting)
A few facts about latency and user behavior: "...250 milliseconds can be the difference between a return customer and an abandoned checkout cart." "...every 100 milliseconds of latency resulted in a 1% loss of sales." "...lose 20% of their traffic for each additional 100 milliseconds it takes a page to load."
The average overhead jQuery adds to a website: "... add roughly 150ms to 1 full second of load time..."
He goes into many other good reasons too, it's well worth a read.
Slide here: https://github.com/joshbroton/... [github.com]
Compatibility (Score:2)
document.querySelector (Score:2)
Less than Before (Score:2)
Not available for your platform (Score:2)
Learning Javascript is a ghetto because so many entry-level people, who are ignorant and arrogant as shit, write bad tutorials, give anti-pro tips, and generally don't have any fucking clue what they're doing.
In common use, "JavaScript" refers to both the DOM API or the ECMAScript language that calls it. To which are you referring? If the latter, inside ECMAScript is a beautiful language struggling to get out. JavaScript: The Good Parts exposes this language.
FWIW (for those less experienced devs/engineers), most JS frameworks are bullshit, replicating functionality found in the browser.
Only if you are willing to fire customers who use outdated browsers on unsupported operating system. Some of this functionality isn't in IE before 9.
I'm not advocating reinventing the wheel, I am advocating not using a wheel when you walk next door.
Some people routinely use a wheel to walk next door [wikipedia.org]. Likewise, on the web, it's wise to make your web applica
Re: (Score:2)
[Raw JavaScript] is good, it is fast, and there are VERY TINY inconsistencies between browsers, even old IEs, unless it is DOM-crap or stuff relating to inputs and CSS rules. Everything else is FINE.
Except that's exactly why people use jQuery: to ensure that "DOM-crap or stuff relating to inputs" works for all viewers.
What would you prefer? (Other than .exe) (Score:2)
Without JavaScript, how would you prefer that Internet-connected interactive applications be deployed to users of PCs that run an operating system different from yours?
Depends on how you define JavaScript (Score:2)
You can't use jQuery without knowing ECMAScript, but you can use it without knowing W3C-standard DOM API. This technically means you can use it without knowing JavaScript, so long as you define JavaScript as the sum of ECMAScript and DOM API. I'm assuming that the so-called guru implicitly defines it as such.