Slashdot Mirror
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.
No
I hear great things about that new-fangled VanillaJS framework. Very lightweight and fast, and already more popular than jQuery.
Socialism: a lie told by totalitarians and believed by fools.
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.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
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.
Some things need to be said...
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!
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I always used it like "fuck it, I'm lazy, lets go"
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.
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.
So yes you need it to do the stuff that SharePoint doesn't do.
I've been using Javascript for 15+ years and never seen the reason to learn jQuery.
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.
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.
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.
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?
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.
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.
Troll is not a replacement for I disagree.
Learning JQuery is just learning CSS. CSS is pretty important to know, if you want to do anything with the web.
Troll is not a replacement for I disagree.
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.
Democracy Now! - your daily, uncensored, corporate-free
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.
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.
-- Support a free market in the field of government
Don't use just one bloated library, use two!
Required reading for internet skeptics
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.
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.
Remember, there are no stupid questions. But there are a lot of inquisitive idiots.
Do you really have to learn jQuery? I feel like a skilled developer should be able to become productive using that library pretty quickly.
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/...
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.
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.
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?
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.
.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.
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.
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?
[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.
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.
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?
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.
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.
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...
Remember, there are no stupid questions. But there are a lot of inquisitive idiots.
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.
Remember, there are no stupid questions. But there are a lot of inquisitive idiots.
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?
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Does most of what i ever wanted jQuery for.
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...
"The wisdom of the Patriarchs was that they *knew* they were fools." --Master Foo
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.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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.