JavaScript Devs: Is It Still Worth Learning jQuery?

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.

Comments

Is it still worth it?

[Anonymous Coward]

No

Re: Is it still worth it?

[Anonymous Coward]

True. I reach for jQuery when I don't know what I'm doing, knowing how it works isn't important, speed doesn't matter, and someone needs it fast.

Otherwise I prefer to avoid jQ.

Re:Is it still worth it?

[davesque]

Why? Is it really that much of a time investment?

Re:Is it still worth it?

[Anonymous Coward]

If it was a fad, yes. The large cost isn't in learning how to write legacy code, but in maintaining it.
The time investment for learning VRML is pretty small too but that doesn't mean that you would use it if you needed a page where it is possible to see 3D representations of objects.
jQuery has been around for less than ten years and its usefulness is already questioned.

Re: Is it still worth it?

[Anonymous Coward]

I look at it this way. It really doesn't take any time to "learn" it. If it does take you time instead of just using it you may want to rethink your occupation.

I wouldn't hire a dev that was unable to use it if needed. This is also not to say that it is always needed. But it should be add easy as tying your shoes... another thing that if you can't do would get you not hired by me.

Re:Is it still worth it?

[Anonymous Coward]

No, no, no no no no. It's easy to get by without it.

http://youmightnotneedjquery.com/

Your life will be even more simplified if you drop support for any browser below IE 10 in addition to not using jQuery. So many CSS oddities in earlier versions.

VanillaJS Framework

[lgw]

I hear great things about that new-fangled VanillaJS framework. Very lightweight and fast, and already more popular than jQuery.

Re:VanillaJS Framework

[Anonymous Coward]

Even slashdot uses it. wow, it really must have to cut development costs and simplify coding!

Re:VanillaJS Framework

[antiperimetaparalogo]

I hear great things about that new-fangled VanillaJS framework. Very lightweight and fast, and already more popular than jQuery.

Now hiring a VanillaJS developer with a minimum of 10 years experience - info: thisjokedoesnotwork@slashdot.sucks

Re:VanillaJS Framework

[halivar]

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

[lgw]

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:VanillaJS Framework

[Stewie241]

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:VanillaJS Framework

[dissy]

Personally I just make sure to compile jQuery using VanillaJS to take advantage of all the speed VanillaJS offers!

Re:VanillaJS Framework

[The MAZZTer]

XMLHttpRequest.DONE === 4

Nobody bothers to use the long form. But it's there.

Re:VanillaJS Framework

[antiperimetaparalogo]

I can't accuse you for ruining the joke because it was already a bad joke my friend!

Re:VanillaJS Framework

[narcc]

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

[_xeno_]

You mean it's there now. Going back through previous version of the XMLHttpRequest spec, it wasn't added until June 2007.

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:VanillaJS Framework

[_xeno_]

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:VanillaJS Framework

[Anonymous Coward]

At some point you have to say "too old, not supported." Or do you still support HTTP/0.9? Or do you still use Bink video because not everyone's on-board with H.264 and VP9 yet?

Re:VanillaJS Framework

[_xeno_]

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 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:VanillaJS Framework

[lgw]

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:VanillaJS Framework

[master5o1]

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.

Re:VanillaJS Framework

[Anonymous Coward]

I know someone will call out shameless plug, but I wrote something not long ago something similar.

Re:VanillaJS Framework

[rch7]

What you will learn about such libraries hard way is that they come and go, and when you come later and see the code that is a mess of few half-maintained half-abandoned libraries that were very cool & popular just few years ago, you are lost. And than suddenly you need to adopt to changing client base and your library maintainers didn't released new version and or are not interested in fixing bugs quickly. What is your plan then? Fork your own version? Fine, but the library tries to be super-universal and is super-complex and messy as a result. It may take much more time & money to maintain/debug it all by yourself comparing to custom in-house library that does just what is required, nothing more, doesn't need to cover special cases that you don't use, and is based on standard syntax and well defined logic that everybody knows very well and can read without learning some new or old "Invent The Wheel v4.99" reference manual.

Re:VanillaJS Framework

[LordKronos]

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...

Here is the most relevant part from my previous post:

You know what I like to actually optimize? Getting things working correctly. Think jquery is a waste? Well, lets look at that fading example above. Pretty darn simple, isn't it? Surely nothing tricky there. So lets see. jQuery seems to work fine. How about that more monstrous vanilla.js version they posted. ok, it's working fine in firefox. How about chromium. Oh interesting. Look at that. It fades out almost all the way, but never totally disappears and gets hidden. Why is that? The code LOOKS to be correct (though perhaps that < 0 should be <= 0 ...nope, that wasn't it). Ok lets do some debugging of the opacity value on each iteration:

1
0.9
0.8
0.7000000000000001 (uh oh, I see where this is going)
0.6000000000000001
0.5000000000000001
0.40000000000000013
0.30000000000000016
0.20000000000000015
0.10000000000000014
0.10000000000000014
0.10000000000000014

oh, hey. look at that. chromium never lets the value get below 0, so that function keeps getting called forever, but never actually finishes and hides it. OK, so that's one stike against it.

Here's another thought...what happens if the element with id 'thing' doesn't actually exist? Oops, he forgot to check for null, so anything after his .style in the first line of code line will never get executed because the javascript will abort with an error at that line. OK, 2 strikes.

OK, now what about when it is time to reshow the block we just hid. Hmmmm...now was that #thing object set to block or inline display? Oops, he forgot to save the state. We can set it to blank to go back to the default, but what if it was already overridden before we got to the value? Ooops. Strike 3.

Yes, his example could be adjusted to fix all of these issues, but that's the point. The code looks horrendous and it has at least 3 bugs in that simple example so you are going to have to make it even more complex. Meanwhile my jquery example simply worked and I'm already on to the next thing.

Re:VanillaJS Framework

[wasteoid]

Sure all the points made by Vanilla-JS are valid, but using the more convenient syntax than a library provides is ridiculous.

Re:VanillaJS Framework

[Lobo42]

"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."

Technically, isn't that true of any library or framework in any Turing-complete language?

Re:VanillaJS Framework

[Anonymous Coward]

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.

Sounds a lot like PHP.
The problem usually is that while it is easier to get going the functions tend to do almost what you want, you just need to add a small wrapper to fix the input/output or whatever.
A couple of years down the road with some end user feedback added you have a tangled mess where it would require less code to do the thing you wanted than what you already have in workarounds around the framework.

That doesn't mean that you shouldn't use it, but usually "easy to get started" means get things done fast, do not maintain.
Every programmer should have one or two of those languages in their toolbox, sometimes a problem is solved with enough duct tape.
That doesn't mean that every problem is solved with duct tape.

Re:VanillaJS Framework

[davester666]

wrong domain. should be @dice.com

Re:VanillaJS Framework

[dave420]

You are forgetting something rather crucial which jQuery provides - cross-browser compatibility with the same code. You talk of "your browser", when jQuery targets all modern browsers. Without mentioning that it seems you might not fully understand the benefits, which I'm sure was just an oversight on your part.

Re:VanillaJS Framework

[mwvdlee]

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:VanillaJS Framework

[Anonymous Coward]

You had a point until you said "modern browsers". All modern browsers stick pretty close to the standard. The whole browser compatibility thing was a good reason for jQuery back when you couldn't tell IE6 users to just upgrade already.

Re:VanillaJS Framework

[antiperimetaparalogo]

wrong domain. should be @dice.com

Thank you Sir - reply at: slashdotsuckedalready@dice.com

Re:VanillaJS Framework

[Anonymous Coward]

Final exam for EE 899 (Principles of Super-Advanced Computer Architecture):

Behind your desk is a large bin containing two billion 2N2222 transistors, 28 miles of 30-ga. wire, a wire-wrap tool, a 12" x 12" section of wire-wrap board, a diagonal cutters, and a 3.6 megawatt power supply. Create a functional equivalent to an Intel i7 processor. Prove your work by demonstrating your CPU running Windows, the original DOOM, and Crysis. You have two hours.

Re:VanillaJS Framework

[unrtst]

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 luck with that.

Re:VanillaJS Framework

[Anonymous Coward]

I tried to download it. I didn't really like the joke when my editor opened up a blank page, but I'm OK now.

Re:VanillaJS Framework

[tingentleman]

The things is, the VanillaJS comedic examples actually make me WANT to use jQuery for it's elegance and clarity. For instance:

In jQuery:
$('#thing').fadeOut();

In JS:
var s = document.getElementById('thing').style; s.opacity = 1; (function fade(){(s.opacity-=.1)0?s.display="none":setTimeout(fade,40)})();

Re:VanillaJS Framework

[Anonymous Coward]

That's why I write all my web apps in pure binary CPU instructions.... LOL.

Learn abstraction and how its evolved technology to where it is. Why reinvent the wheel?

Re:VanillaJS Framework

[Anonymous Coward]

And when your clients (read: 99%) don't want to invest in creating and maintaining their own specific library.... you foot the cost

And for what...? A slightly better/smoother experience that will be replaced in a couple of years anyway.

hmmmm....

Re:VanillaJS Framework

[lgw]

Or, you know, make a library with the stuff you actually need, as it will (likely) be a tiny slice of the whole of jQuery.

meh

[XO]

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

[Anonymous Coward]

"People still like jQuery and its elegance"

LOL, elegent... When I have to look at JQuery code, it reminds me of the crap I used write in highschool. Can we please move forward.

Re:meh

[jandersen]

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

[meustrus]

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.

Re:meh

[halivar]

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 on a deadline, and the user will not notice 99 times out of a hundred. Almost every time I've had to diagnose slow jQuery, the author was doing something bad, like reselecting the same DOM elements in tight loops.

IOW, there has to be a balance between performance and ease of development, and jQuery is my optimal point. Sometimes it's the wrong fit: when speed is the overriding factor above all others, it's not appropriate. But to extrapolate that into a never, never, never rule smacks me as throwing the baby out with the bath water. The problems with it are usually academic, not practical.

Re:meh

[wisnoskij]

So if you are trying to avoid manipulation the DOM than avoid using the DOM manipulation library. Got it.

Re:meh

[Anonymous Coward]

That indeed makes jquery a losing proposition. You really shouldn't rely on fscking with the DOM so much. Instead of throwing many small fragments at the browser and stealing user cycles to cobble it all together, just serve up the content already.

Which just goes to show that much of jQuery, and javascript in general, is dev jerks circle wanking.

Re:meh

[Anonymous Coward]

To be fair, it's a problem foisted upon them by management.

Case in point: Here's this shiny framework that we bought, not knowing how to use it, and not having anyone who knows how it works. So, we've hired you to go in with jQuery and fix all the pages without changing the framework... because our boss's wife spent like 300,000 dollars licensing it.

Re:meh

[Anonymous Coward]

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.

This is bullshit. If you expect to build dynamic web apps, and aren't using something like Facebook's ReactJS, then manipulating the DOM is how you do it. Manipulating the DOM is far easier and clearer using jQuery, and the performance is acceptable.

Re:meh

[Anonymous Coward]

I agree in the main that DOM manipulation is the root of all JS sin

And yet wasn't that the reason that JS was created in the first place? To manipulate the DOM?

Re:meh

[umafuckit]

Nasty learning curve? Really? I don't know JS, but I needed something to do simple dynamic DOM manipulations for an in-house web page. Couldn't do it with CSS. JQuery was easy to learn and it got the job done.

Re:meh

[mcvos]

You want to go back to the days of full page reloads every time you do something?

Re:meh

[hattig]

Err, updating the DOM and making updates to small parts of the page as a result of Ajax calls within a front-end Javascript application is the right way to create modern web apps.

What you are advocating is the full page reload, which is a massive horror for many websites. The only use case for full page reload for trivial content updates these days is to serve another bundle of ads around the next bit of content, and single-article based websites where the content is most of the page (e.g., a news site where you are clicking between stories via category links and indexes of articles).

Seriously, many modern websites are a set of single-page applications (and maybe static pages). The only page reloads should be switching between these applications. [Page resources (JS, images, etc) should ideally be stored in a CDN if you can afford that.].

Re:meh

[Anonymous Coward]

Ultimately even ReactJS is going to update the DOM, it just has its own DOM abstraction over the top to optimise the process of updating the DOM and (presumably) minimise UI jankiness.

Yes

[deuterium]

Yes it is.

Re:Yes

[narcc]

Don't use just one bloated library, use two!

Re:Yes

[erlando]

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:Yes

[Anonymous Coward]

I'd be curious why you need to submit a form from your controller at all. If you've embraced angular you should be using restful services. Wire up an ng-submit onto your form and do a post via $http.

Your example is a tad out there as you shouldn't be interacting with the dom at all from an angular controller. If it's a directive controller you can always require your form to get the reference.

Re:Yes

[Anonymous Coward]

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.

Sample code or it didn't happen.. In all seriousness, I tried like hell to do an HTTP POST form submission from a controller. $('#form').submit().. can't do it in angular as best as I can tell, but I welcome being corrected.

Re:Yes

[olau]

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.

Re:Yes

[erlando]

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...

Re:Yes

[erlando]

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.

jQuery is for lazy, fat, "developers"

[Needs2BeSaid]

No. jQuery is bloated by their desire to make sure your pages are compatible with ancient Microsoft browsers.

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:jQuery is for lazy, fat, "developers"

[master_kaos]

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:jQuery is for lazy, fat, "developers"

[narcc]

I'd rather do things right. Sacrificing performance and, in the case of jQuery, readability to save a few minutes seems ridiculous.

Re:jQuery is for lazy, fat, "developers"

[Anonymous Coward]

There are billions of JavaScript code examples to perform the individual functions of jQueryUI

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?

Re:jQuery is for lazy, fat, "developers"

[Paradise Pete]

And this is supposed to be an argument against jQuery?

On the internet, people reach a opinion first and then come up with reasons why, so often the reasons only make sense in that context. And oh yeah, besides the internet that happens everywhere else too.

Re:jQuery is for lazy, fat, "developers"

[Anonymous Coward]

Also, jQuery allows developers to be very lazy. Don't be lazy.

You might as well say, "don't be productive". Sometimes less is more and that's doubly true in code. The more code you write the more likely it is that you will make mistakes and even if you code it perfectly you now have to maintain all of it. The real lazy developers are the ones who throw code at the wall, cutting and pasting and repeating themselves until everything sticks. The experienced developers, whom you call "lazy", are the ones who do the same thing with one tenth the code and make it readable too.

Re:jQuery is for lazy, fat, "developers"

[Anonymous Coward]

I'd rather do things right. Sacrificing performance and, in the case of jQuery, readability to save a few minutes seems ridiculous.

I hope that I never have the displeasure of maintaining code written by you. It's developers like you that give the profession a bad name. Who wants to maintain your awesome spaghetti code even if it does perform better, which it probably doesn't? Not me. Been there, done that, had to rewrite it. If you need to write "high performance" code, please do it on your own hobby project instead. Your professional code is not the place to get cute.

Re:jQuery is for lazy, fat, "developers"

[Anonymous Coward]

No. jQuery is bloated by their desire to make sure your pages are compatible with ancient Microsoft browsers.

Sure... except that they also have a version that doesn't support old IE.

But you know what? Some of us actually have to support users with old IE versions. Okay, maybe not IE6 any more, but IE8 is still heavily used.

Also, jQuery allows developers to be very lazy.

I've heard it repeated many times: "A good developer is a lazy developer". Yes, I agree, that's a somewhat trite aphorism, and while it contains grains of truth, it isn't something you'd want to live by. But the message that it's trying to get across is that finding ways to save yourself some time as a developer is not a bad thing. Frameworks are the ultimate expression of this: they exist to make things easier and quicker for the developer.

Example: Many sites bring back JavaScript in their AJAX returns. Did you know that jQuery uses EVAL to process any JavaScript returned via AJAX?

Uh. No, it doesn't. Maybe *you* should be less lazy, and actually check your facts before stating them. The jQuery code is here: http://code.jquery.com/jquery-1.11.2.js.

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.

Like any framework, most sites that use it will only actually make use of a small part of its code. This does mean that you're loading more code than you need to, which does impact performance. However, for the parts of it that you are using, jQuery is actually pretty efficient. It's the plug-ins that typically contain the clunky slow memory-hungry code, not jQuery itself.

Don't be lazy.

The one thing you haven't done in your little rant here is suggest what people should use instead of jQuery.

A large part of what jQuery does is the kind of boilerplate code that you'd need to write anyway, so if you're suggesting using VanillaJS, then that's fine, but over time you'll end up writing a set of utility functions to wrap up the common boiler-plate code. Before you know it you'll have something that replicates a lot of what jQuery does. But probably not as good.

Or you could suggest AngularJS? If that's where you're going, then I hate to burst your bubble, but it's every bit as slow and memory hungry as jQuery. Perhaps even more so. I'm not knocking Angular for this; it's a good framework, and the right choice for a lot of projects. But if your main gripe with jQuery is that it's memory hungry or has performance issues, then ultimately you're going to be disappointed by Angular, and just about every framework out there too.

The other important thing to understand is that good quality code is about more than just performance and memory usage. Sure, they're important, but so is security, maintainability, flexibility, reliability, productivity, compatibility, etc.

jQuery is not right for every project, but it certainly is right for a lot of projects. The arguments you've made against apply to virtually every framework ever written.

Re:jQuery is for lazy, fat, "developers"

[Anonymous Coward]

"I'd rather do things right. Sacrificing [...] readability to save a few minutes seems ridiculous."

I hope that I never have the displeasure of maintaining code written by you. It's developers like you that give the profession a bad name. Who wants to maintain your awesome spaghetti code even if it does perform better, which it probably doesn't? Not me.

Which generation of developers consider readability == spaghetti code? And yes, using jQuery does sacrifice readability compared to well written object oriented Javascript. JQuery may not quite be Perl level, but it comes close.

Re:jQuery is for lazy, fat, "developers"

[Guildor]

If you were part of my development team, I'd be questioning your ability to code about now. True, anything jQuery can do, we can too - and we've our own "infrastructure.js" code which seems to come along for the ride on many projects and pages. But the notion of being blissfully ignorant of newer browser features, and letting jQuery keep up to date on that means we get compatibility at a compromise of performance. But seriously, if you feel performance is a problem, then I'm assuming you must be handling far too much data on the client side. As for the readability, I find that when our developers chain lots of jQuery together that it is perfectly readable. I tend to encourage the use of jQuery as it means there's less testing needed, as we can happily assume jQuery features work as expected. Can't say the same for some of our developer's code! Hence, less development time, leaving more time for other development, or as breathing space in the project for other areas where you need more time. Just to cap off the performance issue - I'd love to see C# completely replace javascript, but that'll never happen. The closest M$ got to it, was SilverLight - and who works with that?? So we're left with a nasty language like JavaScript, which can do pretty much anything we want it to, but it's all a compromise in how you write your code to achieve things like namespaces and property getters and setters. But I digress. If performance is what you need, then Javascript isn't going to be your solution. The reason Javascript is so popular, is because we all know every browser has it - and so it's the ubiquity of it that makes it popular, at the cost of performance. It offers performance in other ways, by being on the client side, and not the server - and with AJAX methods for getting at the data, we can write single page applications for many things. But I do think it's a bit of a passing phase. Everyone seems to recognise that javaScript itself should be replaced by something far more robust, which will be a subject of much speculation for years to come, but in the meantime, Javascript is here to stay, and you can't at least maintain existing websites without it. The future may well belong to Angular, but with sockets making communication between servers and clients that much more responsive, we might find a lot more processing heading back to the server in future, as I believe we've all become a little blinkered in our approach to website client/server models.

Re:jQuery is for lazy, fat, "developers"

[hattig]

1. Don't use the compat version of jQuery then if you don't need to support old browsers. jQuery 2 exists for a reason.

2. Yes, JSONP is a way to transport data between different domains. Don't call domains you don't absolutely trust. JSONP isn't a fault of jQuery, but the browser security model.

3. jQueryUI is a different dependency. Don't use it if you don't want it. It really depends on your application though, if it's presenting a UI, then are you going to implement it all yourself, or pick one of the many UI JS libraries that will be in the same size ballpark. Browser downloads once, browser caches, job done - and these libraries are usually accessed from a CDN, so you probably already have it in your cache.

Re:jQuery is for lazy, fat, "developers"

[parkinglot777]

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:jQuery is for lazy, fat, "developers"

[cdrudge]

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:jQuery is for lazy, fat, "developers"

[narcc]

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.

Don't forget legacy BROWSERS.

[Ungrounded Lightning]

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.

[extranatural]

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.

In my experience if your target market is the general public legacy support isn't thaaat important, people tend to upgrade their personal browsers out of necessity, so just create that necessity and the people will follow.

It's really only when you are catering to large enterprise businesses that only upgrade their workstations once in a while that you really have to sweat that sort of thorough backwards compatibility.

Re:Don't forget legacy BROWSERS.

[PCM2]

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.

Re:Don't forget legacy BROWSERS.

[extranatural]

I think there is a monetary argument to be made for skipping legacy support. The amount of time that dev's must spend on supporting old IE browsers can be astounding depending on the site.

At least for some business in the long run it's not just preaching standards, it's a cost saving measure.

Notably the Australian retailer Kogan, instituted an [IE7 tax](http://www.bbc.com/news/technology-18440979) back in 2012. This surcharge I think was a brilliant way to offset the expense of supporting antiquated browsers.

No doubt it comes down to your customer demographics, and if you can afford to ignore that share of your potential market. These days I think IE8+ is a pretty safe bet for retail (maybe IE7 for B2B).

Re:Don't forget legacy BROWSERS.

[Sardaukar86]

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.

Re:Don't forget legacy BROWSERS.

[WuphonsReach]

Customers who are running old, outdated, and insecure systems like WinXP 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.

A year ago, you'd be a fool to cutoff support for IE on WinXP with 10-12% market share. Now? Not so much and it's not worth development time to support a 1% market share for IE 6.

Re:Don't forget legacy BROWSERS.

[Gaxx]

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.

Yes- and providing seat belts means you lose the incentive to drive carefully. Except you don't. There's a lot of other reasons to drive carefully in the same way there's a lot of other reasons to use modern browsers. Insisting that a bunch of potential customers use a browser they aren't happy with isn't a way to get them to change, it's a way to lose potential customers.

In the real world you support the technologies that your customer base wants supported or you go under. The opportunities to dictate technology stack to your customers are few.

Re:Don't forget legacy BROWSERS.

[extranatural]

Near as I can tell you aren't providing any reasons or evidence for why legacy support is so imperative.

Also that seatbelt example is laughable, seat belts are in no way analogous to limiting legacy support.

Thing is if your look at browser market shares, much of the time it's not cost effective to spend the time writing legacy support. Unless your target demographic is enterprise, or 3rd world nations, it's a pretty safe bet to drop IE6 & IE7.

JQuery is something to learn?

[YoungManKlaus]

I always used it like "fuck it, I'm lazy, lets go"

Re:JQuery is something to learn?

[Tailhook]

Same here. $('select something').do_stuff(function (e) {...});

That's about it. I don't feel as though I have some big investment there.

Re:JQuery is something to learn?

[Anonymous Coward]

JQuery: the Cobol of JavaScript

Re:JQuery is something to learn?

[Anonymous Coward]

Exactly! After understanding some simple basic concepts, "learning" jQuery means browsing through the documentation to find a function or selector that does what I need.

Re:JQuery is something to learn?

[szmccauley]

And my pages load and execute blinding fast even with this purported memory/performance hog. A lot of FUD being displayed here, but let's be honest, this is slashdot.

IE 6

[irrational_design]

Yes, at least until IE 6, 7, 8, etc. are truly dead. Our browser stats show that enough people are still using non-evergreen browsers that we are required to still support them. As far as I can tell the higher ups won't let us drop them until they are down to 0 hits a month. Sigh.

Re:IE 6

[oh_my_080980980]

Mobile...because that's all it's for *eye roll*

Re:IE 6

[irrational_design]

It's not really old vs young. Most of those on older browsers are coming from foreign (non-USA) countries or are coming from corporate networks where they don't have control over what browser they are running.

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:IE 6

[seoras]

You mean ignore the customers with spare cash to burn in favour of those with no (spare) cash?

Re:IE 6

[Tablizer]

You mean ignore the customers with spare cash to burn in favour of those with no (spare) cash?

Let's say old browser users spend twice as much money at your site as new browser users (typically mobile). Then the break-even point would be when you have twice as many new browser users as old browser users. Example:

IE 8 or less users:

-- 200 transactions per month.

-- Average expenditure: $80.00

-- Total revenue: $16,000

Mobile users:

-- 405 transactions per month.

-- Average expenditure: $40.00

-- Total revenue: $16,200

In this scenario, it's probably time to focus on mobile-friendly sites/apps and dump legacy IE support.

(I'm assuming your org doesn't want to re-code the same app/site for multiple browser versions.)

Re:IE 6

[Billly Gates]

Must be nice.

In my world html5 comes in 2020 when Windows 7 Goes EOL

Re:IE 6

[Great Big Bird]

OR -- detect the client in the case of old IE versions and serve a page for them, and keep making $32,200 instead of $16,200.

Re:IE 6

[Frobnicator]

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:IE 6

[Lodlaiden]

$20 and I'll turn off my regression suite that checks if your site is still IE6 compatible.

Re:IE 6

[Tablizer]

if (client.ie6) {
  document.write("This is your IE6 page. It's limited because we are moving to mobile-friendly pages and don't want to keep this old one up. ");
  document.write("And no, we're not getting off your lawn.");
  window.location("ie6.html");
}

Re:IE 6

[Tablizer]

Oops, I forgot a confirmation button or pause. I probably shouldn't bother to care, but some readers flip over such.

Re:IE 6

[Billly Gates]

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 other browsers

Re:IE 6

[Anonymous Coward]

Can I bring popcorn the day you tell your boss he should lose half his revenue?

Re:IE 6

[Paradise Pete]

I'm not a "troll", I'm an Agitation Engineer.

So you fix washing machines?

Uh... yes

[ZipprHead]

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....

[oh_my_080980980]

So yes you need it to do the stuff that SharePoint doesn't do.

Never learned jQuery

[Anonymous Coward]

I've been using Javascript for 15+ years and never seen the reason to learn jQuery.

Re:Never learned jQuery

[Intrepid imaginaut]

That's probably why you've never seen a reason to learn jQuery.

Know about it, don't learn it

[Lobo42]

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. 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...

[hyperar]

As long as the web is used to publish extremely complex apps that should not be on the web, yes. Web is for video playback, reading news and blogs, Business app?, desktop, using web services.

Re:Yes...

[xxxJonBoyxxx]

>> Web is for video playback, reading news and blogs, Business app?, desktop

And how long have you been out of work?

Re:Yes...

[hyperar]

Currently web developer, hate it.

Re:Yes...

[codeButcher]

Web is for video playback, reading news and blogs

You forgot to mention the cat pictures.

Re:Yes...

[hyperar]

50% of the web.

Re:Yes...

[Anonymous Coward]

And BASIC is the only language you need to know, and you only need 640k of ram. I just love these people for whom the internet is for documents and the web browser should only be a document viewer, maybe they should switch to PDF for everything.

Re:Yes...

[Literaphile]

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:Yes...

[hyperar]

Today you need to learn Knockout, jQuery, Angular, and whatever hipsters are doing now. I could do the same with a desktop app and easily. And believe me, you don't need to apply 10 hacks for a button to be placed in the right place, you don't need to make anything float to align it to the left. I've been a web developer for 5 years, everyday, i hate it even more.

Re:Yes...

[hyperar]

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".

Does it evolves?, i just see you have to learn more and more frameworks that get ditched a sometime later forcing you to apply hack after hack after hack. It's called opinions, you may enjoy learning a new framework each month to do the smallest things, i really don't.

Re:Yes...

[Pascoea]

Go find a new job then.

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:Yes...

[jbmartin6]

And SMTP is for simple messages only.

Re:Yes...

[Literaphile]

But the fact is that the web is not just used for reading blogs/news and "video playback" now. You don't have to "learn a new framework each month" (but thanks for the straw man) - you just need to realize that the web does a lot more than it did 15 years ago, and that's not going to change.

Re:Yes...

[hyperar]

Pfff, go luck trying to work with a 60 fields grid on a fucking mobile.

Re:Yes...

[hyperar]

The thing is that it never should have, that's why you need 10 different "frameworks" to do the same as a simple desktop app, and not always working, multibrowser compatibility is a utopy. After a year you spend more time making that framework salad work than actually adding new features.

Re:Yes...

[Anonymous Coward]

>need to learn Knockout, jQuery, Angular

Who says you need this? If you aren't trying to get an uber-hipster code-rockstar-guru-ninja job at a San Diego startup then you don't need 99% of the framework-of-the-week shit javascript has.

Re:Yes...

[Anonymous Coward]

Which is why there is only one framework for desktop apps.

Re:Yes...

[hyperar]

Yes, go tell that to the moron that makes the calls

Re:Yes...

[dissy]

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

Re:Yes...

[SoCalChris]

Yeah, those are legitimate concerns with a web app. But pretending that developing a standalone app doesn't have its own set of equally painful problems is ridiculous.

With a standalone app, you've got to worry about things like .Net versions, DLL hell, installation packages, keeping users up to date, windows versions, etc... Yes, modern languages will typically take care of most of this for you, but to pretend like they don't exist is just being naive.

Re:Yes...

[hyperar]

While every platform has its own problems. I get you don't develop much on .net. Having the right framework version solves your problems, if you used a external library you must include it on the setup, if don't, well is not really a platform problem. Keeping users up to date?, if you can open a web site you clearly can download the latest version of the app. Windows versions?, are you still on 98?, .net works from XP to 8.1, and it'll work on 10. I don't pretend anything, i was just talking about the damn UI, which is the only thing web has, Web services are just published, they run on your server, you don't need to worry about DLLs, that is if you were smart enough to don't use stupid frameworks, which required. I'm talking about how web sites work, you disabled a button and then i press F12 and enable it again, i can mess up the entire page. What about having to "float: left" a tag to align it to the left, not to mention the stupid empty div with the clear: left/both; to keep a tag within its container. I'm not saying is impossible, but for complex apps, the web is not the place, at least i don't find a good reason why they should be.

Re:Yes...

[hyperar]

Yeah, you don't need a framework to do basic things, and if you do, then your development platform is bullshit

Re: Yes...

[cyber-vandal]

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:Yes...

[Anonymous Coward]

I concur. The web UI is a kludge. Win32 was way better with Delphi or C#. VB, not so much.

Re:Yes...

[tepples]

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 so long as you aren't trying to support ancient IE.

Re:Yes...

[Anonymous Coward]

You only have to worry about those things if you write code for Windows.

Re:Yes...

[Anonymous Coward]

I'm talking about how web sites work, you disabled a button and then i press F12 and enable it again, i can mess up the entire page.

Just like you can do with .NET. Open the exe/dll in Reflexil or something similar and do whatever you want.

Then again, who cares if you can enable it or not if it's not going to work anyway since real check is done by server?

Re:Yes...

[dave420]

You don't need 10 different "frameworks" to do the same as a simple desktop app. You can use Bootstrap for the CSS, and, say, AngularJS for the logic. If you can't pick both of those up within a week, you really should find a new field of work.

Re:Yes...

[the grace of R'hllor]

Good luck trying to check your app's dashboard and tweak some settings while out of the office on your 'fucking' desktop.

Re:Yes...

[Richard_at_work]

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 still take a web app over a native app for a significant portion of my tasks any day of the week.

Re:Yes...

[hyperar]

Why are you out of office, you should be working, you lazy bastard

Re:Yes...

[Pascoea]

Why are you out of office

I know you were being facetious, but the fact of the world (at least the one I live in) is that 2500 of users' "office" is a job site out in the middle of nowhere. We have a real need for these people to interact with our business system, recording hours expended, material installed, equipment utilization, etc. etc. For these type of workers, a desktop just isn't realistic.

Which leaves me in a quandary: Native app(s) or web-app. We don't have the appetite to develop and maintain several versions of the app for different devices. We don't have the need for super fancy/flashy UI, I envision something simple, plain, and utilitarian. And it has to have some off-line capabilities. Those all lead me towards a web-app...

Re:Yes...

[Anonymous Coward]

I thought the web was for catlulz and gifs???

I've been doing it wrong for years!

(10+ years web dev)

Re:Yes...

[Anonymous Coward]

I'm wondering what magical programming language you use for your desktop applications to run cross platform without hacks. Is either you develop in Visual Basic, GTK+/C and XCode to have native apps in the desktop, or you simply using a super hack like java or python with some framework behind. So you will have to maintain different code and compile for different platforms every time you have a new version or fix a bug... of course if you use Java you only maintain one code, but then again, don't mock jQuery, Java is just the mother of all hacks, is a giant beast of hack.

Yes

[Anonymous Coward]

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.

Mobile

[seoras]

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:Mobile

[Anonymous Coward]

Bootstrap

Re:Mobile

[quietwalker]

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 end up writing are fairly complex, don't need fancy animated transitions from page to page, don't require touch/multitouch interfaces, so maybe I'm not the intended audience.

I suppose if you're writing a fairly simplistic application, like say, showing a bus schedule or reading a review, it'll be fine. I wrote a jquery mobile app once that's just a series of short forms that produce sets of calculations at the end, which made really complex calculations for initial settings on industrial tools accessible to an operator without requiring a shift manager or technician to come over and reset things for them. I remember it still being quite a pain pulling values from other pages and doing some of the calculations. I especially disliked how my nagivation logic ends up in the javascript, rather than in the backend with the rest of my controller & business logic.

Really though, it's up to personal preference.

I don't get it

[quietwalker]

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:I don't get it

[Anonymous Coward]

Or, the OP is a shill trying to generate clickbait for his blog? I'd go with that option nine times out of ten for silly posts like this one.

Re:I don't get it

[TigerTime]

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:I don't get it

[LDAPMAN]

Yes...

Re:I don't get it

[Anonymous Coward]

I read the OP completely differently than you.

you're really saying that the browser does things that javascript is no longer needed for

No, the headline speaks directly to Javascript devs, not 'web devs', not 'front-end devs', and it doesn't ask if the language is worth learning just if a single library/framework is worth it. A framework that is primarily or at least was originally used for things that were difficult/impossible to do in vanilla JS (such as using CSS style selectors) or for smoothing out inconsistencies between browsers.

Nothing was said about not using any frameworks or doing without Javascript.

The, the way I read it is: now that things like .querySelector are available and now that there is more consistent performance and adherence to standards between browsers, do we really need a library that was designed to accomplish those very things?

Re:I don't get it

[guruevi]

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 sources or UI's.

Re:I don't get it

[Anonymous Coward]

dont forget support for older (yet still used) browsers. Looking at you IE

Re:I don't get it

[jwhitener]

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...

I don't get why people call jquery a framework. It has never been a framework. The first sentence on their site is: "jQuery is a fast, small, and feature-rich JavaScript library".

Proves you can ignore fads

[Anonymous Coward]

This just proves that you can ignore the latest shiny Web-frippery, and someone or something will replace it soon enough. Tough break, "Comp Sci" majors whose senior projects were website design projects.

My most common alternative...

[Anonymous Coward]

I find this site far more useful than jQuery most of the time: http://youmightnotneedjquery.com/

5 Minutes

[wisnoskij]

It takes like 5 minutes to learn to use Jquery, it is used in 90% of all current websites, and is still one of the best if not the best library for dynamic DOM manipulation and has incredibly easy to use ajax requests. I cannot imagine creating a dynamic website without it.

Re:5 Minutes

[Anonymous Coward]

Except you need not access the DOM any longer; so why would I need jQuery?

Re:5 Minutes

[wisnoskij]

Well if you do not want/need to access the DOM than there is little to no reason to use a JS library designed to access and modify the DOM. Sure there are still things that it makes easier, like it has built in fancy HTML gui creation, but an HTML5 library would be better if you were designing from scratch and did not care about legacy browser users.

CSS

[wisnoskij]

Learning JQuery is just learning CSS. CSS is pretty important to know, if you want to do anything with the web.

Time to move on

[Laz10]

Stop manipulating the DOM. It is too brittle.
Better to leave that to something like React.
That gives you a much better level of abstraction as a developer and better performance.

https://facebook.github.io/rea...

fixed

[Anonymous Coward]

If you're learning JavaScript and Web development, you might be wondering what the retarded cunt who invented this shit was smoking.

- FTFY

Yes, partly because it's easy

[bigsexyjoe]

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 different AJAX library, but is that library any easier or better than jQuery? You can do AJAX with no library, but bare JavaScript API is ugly.

It might be better to use Q for promises, but the API for Q is about the same as the jQuery promises API.

Again, you might get these things from other libraries but it has deep extend. It is much nicer to trigger events with jQuery. Ready is much nicer with jQuery.

Ironically, I'm going to refer you to http://youmightnotneedjquery.c... Because guess what? When you look, a lot of those things are a lot easier with jQuery and that site makes it clear.

Also, there are jQuery plugins. I don't think writing jQuery plugins is something that you want to do for a modern webapp, but you might find yourself supporting them.

Re:Yes, partly because it's easy

[Anonymous Coward]

querySelectorAll is "very long to type"?

That's the kind of thing I hear from people who think "a" and "b" are great variable names. Verbosity may take an extra second or two from time to time, but the readability you gain in exchange is a godsend for the person who comes after you. Or yourself a month later.

Re:Yes, partly because it's easy

[Gavagai80]

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?

Re:Yes, partly because it's easy

[Anonymous Coward]

autocomplete has been a thing in editors like forever, this is a non-argument

Learning jQuery?

[Anonymous Coward]

tldr; Learn Javascript and jQuery will be easy.

Learn Javascript and you will be able to use jQuery. It's a library and not exactly complex to use. Fuck, even hacking the source and writing plugins is easy. If it seems difficult, it's because you don't know how to write Javascript. I can verify this from my own personal experience when starting out oh so long ago (when jQuery was new and relevant)-- I thought I knew Javascript because I could use jQuery to make shit happens, oh how fucking naive I was... Fast-forward 8+ years and a lot of Javascript later, I realize that.

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. Learning jQuery will not help fix that in anyway, if fact, it probably hurts because it abstracts away what the hell is going on...

FWIW (for those less experienced devs/engineers), most JS frameworks are bullshit, replicating functionality found in the browser. Not to mention they don't really do anything-- honestly. If you understood the code better, you'd clearly see that. Also, the "framework author" might be a total fucking idiot or part of an organization of idiots. I'm not advocating reinventing the wheel, I am advocating not using a wheel when you walk next door.

Lastly, who the fuck wants to develop for the browser any more? CSS, Javascript, and HTML are a clusterfuck compared to native-development and provide a worse experience. I loved the idea of web apps, but a lack of real standards have killed those dreams (Chrome being the new IE 6 was my icing on the shit cake).

Yes, if you like stupid eye-candy crap.

[Anonymous Coward]

Yes, sure, if you like to make websites with stupid eye-candy crap that eats away battery life on portable hardware, which is used more now than ever.

If you aren't writing a piece of crap corporate site for business types, don't even bother learning it and write something that I won't want to close after 5 minutes of using.

God damn am I sick of terrible sites that use all this flashy jQuery shit everywhere.
OH BOY, I sure love your loop that is waiting for your slow-ass server running every millisecond and eating 50% CPU constantly. Bravo, you fucking tube.
BOY OH BOY do I love your infinitely loading page. I bet you were SO HAPPY when you wrote that, weren't you? You threw your arms in the air after an hour of work and figuring out those weird bugs and then styling it. Gonna be great! Oh, wait, no, it fucking blows. Fuck you, give me my pages back. Infinite scrolling is the worst disease to hit the web. It hit it real good. If I ever come across infinite scrolling, the sites JS is blocked. If it doesn't function without it, it is perma-blocked entirely. Fuck that noise.

Do not get pulled in to this.
The DOM is literally the worst part about web dev and god only knows why that shit thing hasn't been rewritten from the ground up.
jQuery makes it INFINITELY WORSE by wrapping DOM-heavy code in enclosure-heavy code, another thing that is horrifically slow.

Libraries for prototyping. Period.
If you yourself cannot understand that library, stop fucking using it and learn JavaScript.
It 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.

Re:Yes, if you like stupid eye-candy crap.

[Anonymous Coward]

Lynx user detected.

Re:Yes, if you like stupid eye-candy crap.

[tepples]

[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.

Yes, It's still valid

[Anonymous Coward]

One of the most important reasons to use any JS framework is to provide cross browser stability. In that regard, jQuery works wonderfully and it's age (experience) is a benefit. In any other regard jQuery is nothing more than one tool to consider for any one job. It is not the solution for all jobs. That said, in my 15 years of experience, *most cases no not require anything more than a little DOM manipulation* and making the move to a full MV* framework, like Angular, is overkill and over complicating the task at hand. jQuery, perfectly hits the middle ground and has a large enough reach to both ends of the spectrum. It really is the Goldilocks of Javascript frameworks.

For better AND for worse, jQuery has a large, mature community with plenty of supporting plugins that can help extend the capacity of the single tool into a full tool box. I think the problem many developers have with jQuery, especially legacy jQuery, is the mindset of many developers to solve every problem by throwing jQuery plugin after jQuery plugin into their web app with little to no regard for the impact such decisions have on the user experience. You don't need both moment.js and date.js to simply format how a date is displayed, for one common example. I think a lot of the grief you see in this thread is related to that mindset and not jQuery specifically. All frameworks suffer from the same gluttony of plugin hell with the notable exception of whatever the new framework du jour happens to be because there are no plugins with which to commit the sin in the first place.

A number of criticisms in this thread are about the degraded mobile experience when running jQuery. That, I think, is a fallacy as the hit to load with jQuery Mobile is the same as any other *comparable* framework. Are there lighter mobile frameworks available? Yes of course; maybe it makes sense to use those instead of jQuery mobile *given the scope of work*. I wouldn't want to use any of those lighter frameworks for a larger application. jQuery Mobile hits the middle quite nicely and has a large reach to both ends of the spectrum. jQuery Mobile has a syntax you already learned using regular jQuery (which is also notably similar to NodeJS) making the learning curve much shorter.

I will leave this comment with a rant about developers learning plain JavaScript regardless of which framework they use. It boggles my mind the number of junior devs I've worked with who complain about not being able to find a jQuery plugin to replace what is in the SPL. For example, .split() or .push(). If you haven't wasted hours of your time writing document.getElementById() for example, you probably don't know the SPL. Learn the basics, damn the framework.

Nobody disables Javascript anymore?

[Anonymous Coward]

Why is this even a question? Doesn't everyone disable JS on their browser to protect them from M$-world bloatware?

The answer is no, no they don't.

Web apps vs. desktop apps

[qbzzt]

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:Web apps vs. desktop apps

[hyperar]

Again, Business apps, corporate apps, and the "because is not malicious", sure, the web is malware free, right?

Re:Web apps vs. desktop apps

[qbzzt]

No, but people are a lot more likely to browse a web site than they are to download a program.

Re:Web apps vs. desktop apps

[Anonymous Coward]

for people with any sense of security you'll need to convince them to download your js to,
because they'll use umatrix or noscript or something similar to block it by default
why ? because running random code from random places on the web is asking for trouble, sandbox or no

though granted most people don't have a sense of security and for them it'll work just fine

Re:Web apps vs. desktop apps

[Anonymous Coward]

5. OsX ?

JQuery is not the problem

[Anonymous Coward]

Most of the devs I interviewed said "I hate jquery it is too complex."

And their JQuery code was complex.

Because they did not understand CSS selectors to pin point an element in the page, or even how to correctly separate CSS class in backend info (product) position and formating.

Some of these geniuses hating JQuery even did not understand why there elements IDs had to be unique in the whole DOM.

As this experience repeated itself very often I want to state the truth: you cannot modify the DOM or access it without understanding how it works and what it is.

There is no technology that will make you cut corners on learning the hard way, slackers.

You forget memory usage...

[edxwelch]

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:You forget memory usage...

[hattig]

I think that Javascript devs need to learn more about creating a build process to minify and crush the JS dependencies into a single file, rather than which new framework to use for each new project they start.

If your build process takes your dependencies (from npm, for example) and then concatenates them, and minifies them into a single dependency, that saves bandwidth, http calls, and time. If it can do dead code analysis too, to remove those unused functions, then great.

From reading comments, etc, there seems to be an argument into splitting the Ajax convenience methods of jQuery out from the rest, as lots of developers use the former, but you don't need the other niceties such as the highly abstract and overhead inducing $('thing') notation. Perhaps the jQuery 3 work will go some way to fixing this anyway, as it will be far smaller in the non-compat option.

Wow!

[Anonymous Coward]

This is the olde C vs. C++ debate (or vi vs. Emacs), except in colour!

I use a Custom Library Instead

[Anonymous Coward]

I typically just throw in my own custom library that I have written over the years, to wrap the functions that suck to type: document.getElementById, document.getElementsByClassName, AJAX requests, etc. I then throw in some of my own String prototype functions that I usually need: startsWith, endsWith, includes/contains(I know it is coming, and I fully wrap all my prototype functions in checks before defining, so I don't break websites in the future).

I can always expand it to fit the website at hand, maybe I need date and times in a pretty format, throw in an implementation of: String.prototype.prettyDate and String.prototype.prettyTime, String.prototype.prettyDateTime and we're set.

I also develop 2 versions of my base library: base.js and base_debug.js

Once I am ready for production I just swap base_debug.js with base.js and I am good to go. base_debug.js just contains more error messages / alert dialog boxes to aid in development, and base.js supresses a lot of warnings and errors or console.log them instead so I can get to the errors from client's if I need to without annoying the crap out of them or worse breaking webpages because I threw a loop around a function with an alert (eww!). That is fine for development, but in production that is a no no!

I can read and write JQuery, I just choose not to use it if I can. Most times I rarely need anything from it.

Don't get the question

[davesque]

Do you really have to learn jQuery? I feel like a skilled developer should be able to become productive using that library pretty quickly.

jQuery is a crutch.

[extranatural]

I saw a very insightful & funny talk on this subject last year. The very clever Josh Broton lays out exactly why jQuery has become an excuse not to do it right the first time. Basically it comes down to this:

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/...

Re:IE 6 it's a vicious cycle.

[extranatural]

They won't hit 0 hits a month until we stop supporting them. Don't be an enabler. Be brave, make your CTO talk some sense into management at large. IE6 still has market share only because we let it have market share.

You Might Not Need jQuery

[Anonymous Coward]

http://youmightnotneedjquery.com/ - jQuery and its cousins are great, and by all means use them if it makes it easier to develop your application.

If you're developing a library on the other hand, please take a moment to consider if you actually need jQuery as a dependency. Maybe you can include a few lines of utility code, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with.

At the very least, make sure you know what jQuery is doing for you, and what it's not. Some developers believe that jQuery is protecting us from a great demon of browser incompatibility when, in truth, post-IE8, browsers are pretty easy to deal with on their own.

Stop adding more crud to the world!

[Anonymous Coward]

If you lame arses would just stop using and promoting javascript, we'd get something better.

Stop adding shit to the world! We are knee deep in it already.

It's a good library

[Anonymous Coward]

It has been around for a long time and many "plug and play" web components use and require it. Most modern js frameworks are inspired by it.

It was made to make developers lives easier and it still does. Even just for Dom selectors and ajax handling it's worth throwing it in.

Please self host too instead of using the CDN. The size is smaller than a jpeg and not everyone has a great ISP with a reliable DNS (thai internet).

Expand details of part of the document

[tepples]

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?

Re:Expand details of part of the document

[Anonymous Coward]

I think he wants you to do full page reloads or something. At least, that's the only way I can think to change the content of a page without manipulating the DOM

Re:Expand details of part of the document

[Anonymous Coward]

Seems even shorter to type not using jQuery.

JQUERY
$(el).replaceWith(string);

IE8+
el.outerHTML = string;

Sometimes you have to fire some customers

[tepples]

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 product, which can lead to an increased rate of chargebacks.

Re:Sometimes you have to fire some customers

[Dog-Cow]

It's also likely that they have disposable income because they don't replace a system that works for them.

It's also likely that you're an incredible moron and a complete disgrace to your family

Re:Sometimes you have to fire some customers

[micahraleigh]

also likely that people using ad hominems are despairing for a persuasive argument ...

All the world is not Windows

[tepples]

.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.

Can you run a Mac app on Windows?

[tepples]

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.

Not available for your platform

[tepples]

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. Likewise, on the web, it's wise to make your web application accessible to people with disabilities.

CSS, Javascript, and HTML are a clusterfuck compared to native-development and provide a worse experience.

How is "This application is not available for your platform" a better experience?

jQuery without JavaScript?

[Anonymous Coward]

A guy introduced in TFA as a "web development guru" says

JavaScript is hard, it's hard to get into, it's much harder than jQuery.

and even

As a front-end developer I am pretty passionate about knowing my tech, and admittedly I began with jQuery and moved to learning JavaScript, I know many others have too.

Now I'm really curious: How do you use jQuery without knowing JavaScript? Is there a VBScript flavor of jQuery or what?

How else to reach Windows users?

[tepples]

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.

What would you prefer? (Other than .exe)

[tepples]

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?

Re:What would you prefer? (Other than .exe)

[Anonymous Coward]

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?

The new fangled Java Applets, Silverfish and Flash, of course!! Oh, and don't forget about the terrific new tech called ActiveX that all hispters will now use - Active and X and from Microsoft. WOOOO!!

Who needs this stupid javascript anyway.

Depends on how you define JavaScript

[tepples]

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.

Still faster and cleaner

[Anonymous Coward]

Javascript with jquery still makes for smaller amounts of code. Traversing a DOM tree continues to be possible, but its a lot less fun that using jquery. Jquery *still* means writing less code and getting the job done. If they fully integrated the functionality of jquery into javascript, then it would go away. Until that time, it remains. Also, there are old-timery browsers that will fail using new stuff, and its that "old browser still good" functionality that javascript provides. How many people do you want to turn away because the site looks cruddy because the old browser can't decode some of the page? There are versions of javascript that support way back to IE6. Sure its old, and the newer version drops support to post IE8. Dropping jquery altogether though is just painful for the developer.

Good lord use what works best for you

[Anonymous Coward]

Programmers...lol

Compatibility

[fluffernutter]

I recently coded a highly dynamic webpage using jquery and to my surprise it ended up working in all versions of IE, all versions of Firefox, and Chrome on Android. This greatly enhances the availability of my site. How do I get such compatibility for free without using jQuery?

document.querySelector

[tomxor]

Does most of what i ever wanted jQuery for.

Less than Before

[TechNeilogy]

I find myself relying less and less on jQuery and more and more on AngularJS and native HTML5/CSS3 (+Bootstrap), (and Lodash for the FP bits). The AngularJS stuff encapsulates the DOM manipulation more cleanly and HTML5/CSS3 has gotten powerful enough to do declaratively what you used to have to do programmatically. However, it is still handy to know some jQuery, particularly to shim the code a bit around the edges of Angular and for various programming tasks. jQuery can make code cleaner, too, though it is a two-edged sword: used badly it can make code even worse. So I'm glad I know jQuery, which is not quite the same thing as thinking it's a good idea to learn jQuery, but still, if you have the spare time...

It isn't as simple as "Jquery: sucks or not?"

[Anonymous Coward]

A lot of developers are (rightly or wrongly) convinced that jQuery (and other libraries) are suited (or unsuited) to their apps, to what they do in their code shop.

But the web is much bigger. Some coders on this thread are talking about big corporate outfits with certain OSes and versions of a browser that are in use on tens of thousands of machines, often on an intranet. Others are talking about websites that really target the latest web browsers or web apps for mobile browsers. And mobile/desktop apps on a corporate intranet is a world of difference from simple game apps or general mobile apps.

Most of the coders here are talking about very different development and deployment targets, server-based apps versus classic single-page web apps.

The thread's topic is hopelessly broad. You only get a lot of opinions flung around from people who aren't really talking about the same thing.

How does that argument play versus Linux?

[Ungrounded Lightning]

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, too cheap, expecting too much frree stuff. No money to spend.

It's one of the reasons general adoption took - and is still taking - so long.

It's also one of the reasons that companies that DID support them ended up with an edge on their competition, becoming some of the big-name companies in their markets.

Becoming market-dominant and ubiquitus includes not dropping substantial chunks of customers because you perceive them as "marginal". If you support 90+ percent of the market and your competition supports 70%, you keep getting little extra advantages. The outcome of competition is driven by tiny margins.

It's called progress

[Anonymous Coward]

jQuery is yesterday's crutch for web developers. With the JS ecosystem evolving as rapidly as it is, jQuery is only a lingering dinosaur, if not a worse impediment.

"as much as possible"

[tepples]

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 insertion as an element's innerHTML or outerHTML property. Using DOM methods is the HTML counterpart of SQL parameterized statements so that you don't end up with a script injection vulnerability.

Replace javascript with a real language

[Anonymous Coward]

Original "Coward" here (though how can you tell?)...

One way to get interactive applications is to load a new page per interaction. That's how it used to be before javascript took over. I like that, but accept that few others do.

The next way is to define a language that is not braindamaged and use that. Reject javascript because the stupidity level is just too high.

People are attempting to do this by compiling to javascript but that just embeds javascript more firmly into the web and that means the web is underpinned by a bucket of shit.

We need to replace javascript entirely. It is not sufficient for our needs.