Every time I try to build something without jQuery, I regret it.
Not because of selectors, that's (sometimes) easy to do for lots of (basic) selectors. Not because of DOM manipulation, as long as you're willing to sacrifice simplicity and readability, you can build iterative loops to modify a collection of HTML elements.
No, it's the unexpected things that cause me pain. Want to use event handlers on dynamically generated DOM objects? Write your own event bubbling library. Want to create custom events/handlers? Ditto. Promises, .serialize(), .extend(), etc. might all be simple to write your own version, but when you realize you've reimplemented 50% of jQuery to avoid using jQuery, you feel like an idiot. [Source: I do this every 3 years]
Yep. Use the built in browser methods? For which browser?!? All of them? I have to support some enterprise guys on IE8, sometimes I'm lucky to have them on IE9.
Life isn't always a hipster website where people can get lunch delivered on their phone or whatever. Things like jQuery are fine.
There are other libraries though which provide (IMHO better) implementations of each of those things. jQuery has been around for ten years and has to remain backwards compatible. It's just not possible for it to be the best implementation of Promises, or AJAX or any of the other individual things it does.
Real bundling with tools like Browserify is making it more and more feasible to use single-purpose libraries instead of monolithic ones like jQuery.
> There are other libraries though which provide (IMHO better) implementations of each of those things. jQuery has been around for ten years and has to remain backwards compatible. It's just not possible for it to be the best implementation of Promises, or AJAX or any of the other individual things it does.
I agree with all those things. jQuery is the lowest common denominator. It's the best at nothing, bloated with support for Palm Pilot browsers and Safari 1.0, and doesn't have all the cool grunt/gulp/amd/broccoli/cucumber/jsx/fotm neologisms. If I'm building a new, long-term project, I'm going to evaluate all the options, and craft the best possible technology stack for my new app.
But sometimes worse is better. Like a smooth pebble pulled out of a stream, it's taken a long journey and had most of the rough edges rubbed off. It's already in your browser cache from 4 different CDNs. Someone else can pick it up and support it easily. And that's what often makes it the best choice, when you want to avoid bikeshedding over what the hottest new thing is, and just make a webpage.
jQuery may not be the best technology, but it's a sane default.
I'm sure you're aware of this, but for others who may not know: the 2.x versions of jQuery dropped support for old browsers (IE 6, 7, 8) to reduce size (12% smaller) and complexity necessitated by being so backwards-compatible [0].
Thankfully we only support IE9+ where I work, so I grab the latest 2.x version these days.
The thing is there's always other libraries that provide better implementations of things. Likely the instant you pick one, there will be something "better". jQuery has the benefit of being as much of a standard library for the web as anything else. Often it's not worth the time and effort to hunt down the absolute perfect combination of libraries to accomplish the same thing.
> Life is definitely too short to not be using npm, browserify and React!
These are all cool things, but sometimes you want to simply make a web page without setting up node and npm and all that jazz.
Think of it this way... jQuery is like getting a subset of the most common functions you get by using in browserify, but without requiring a build step!
> sometimes you want to simply make a web page without setting up node and npm and all that jazz
No, absolutely impossible. That would mean I'd have to actually write JavaScript instead of LiveScript and that would be unbearable... ;)
On a more serious note: yes, node is a bit of an overhead. It may be too much for very simple, one-off projects, but it starts making sense as soon as the project becomes even a little bit more complex.
jQuery's imperative DOM manipulation is a horrible way to manage state compared to React.
These tools aren't just "cool things". They were designed to solve really pressing issues related to managing complexity in front-end web applications by eliminating global state in both the DOM or the JS runtime environment. They tend towards a more declarative and functional approach to system design.
A build process that integrates with a versioned package manager is fantastic.
Yes, why use a tried and tested tool that can be incorporated into your site and served efficiently with just a single extra line, when instead you could make building your site more complicated than compiling an entire Linux distribution from source, spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do, and lock yourself into a proprietary framework that will be considered legacy code as soon as next week’s trendy framework arrives, leaving you with a maintenance headache for as long as your project lasts after that?
Doing the simple, effective thing is just crazy talk, I tell you.
spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do
Just search npm and pick the one that is being used the most.
lock yourself into a proprietary framework that will be considered legacy code as soon as next week’s trendy framework arrives
The problems that npm and browserify solve are at the level of builds and package management. You could use any number of trendy frameworks and tools on top of this.
The problems that npm and browserify solve are at the level of builds and package management. You could use any number of trendy frameworks and tools on top of this.
Right. But last week it was RequireJS, not Browserify. Today, as well as NPM, we have Bower and gem and pip and however many other package managers. Last week it was Angular, this week it’s React, and next week maybe it will be Web Components. Last week it was Grunt, this week it’s Gulp, and next week who knows?
The list goes on, but it always seems to be the same basic argument: for some reason, we are told, we suddenly need 73 different tools and templates and scaffolds and packages and boilerplates just to start a simple project. It’s long past time we stopped accepting that kind of rhetoric as if it’s some unquestionable truth. Ultimately web pages are still primarily made of the HTML, CSS and JavaScript that you serve to browsers. Everything else should have to pay its way, and there are always costs in complexity and maintainability when you introduce any external dependency into your project.
Now just to be clear, I am absolutely not saying don’t use good tools. If you are working on a large, complicated project, of course you should be systematic about it and control your dependencies and automate your processes. Even if you’re only working on a small project, low cost tools like jQuery or SASS might more than pull their weight. But it’s important to choose tools that fit the problem and offer a good cost/benefit ratio. Most web projects aren’t large and complicated, and many don’t need elaborate build processes and package management schemes at all. There is no good reason that such projects should give up on a simple, effective tool like jQuery just because you can also solve the same problems now with heavyweight tools like React and Browserify and some combination of NPM-managed packages.
We could have an actual discussion about the evolution of front-end tools if you could leave some of your hyperbolic rhetoric at the door.
But last week it was RequireJS, not Browserify.
I used RequireJS for a number of projects before being introduced to browserify and npm.
I had reservations at first because I didn't want my front-end code to be reliant on a back-end environment even if the language was Javascript.
However, after having my reservations answered by people in the node community and seeing how they were using it and seeing the incredible volume of front-end code that was being published to npm, I came around to it.
Today, as well as NPM, we have Bower and gem and pip and however many other package managers.
Bower really doesn't make any sense to use and seems to be falling completely out of favor. Gem and PIP are not Javascript module repositories so they don't make sense in this conversation.
Last week it was Angular, this week it’s React, and next week maybe it will be Web Components.
I spent a year with Angular and I found it suffered from a good many issues. It is slow. It is bulky. It does too much.
React's virtual DOM and expressive JSX are fantastic. It is fast. It works on the front-end and the back-end.
Last week it was Grunt, this week it’s Gulp, and next week who knows?
I agree with you here. I use Make. It works just fine.
Most web projects aren’t large and complicated, and many don’t need elaborate build processes and package management schemes at all.
Can you please backup your claims that browserify and npm are an "elaborate build process"?. Like anything there it takes a little time to become familiar with something but it is a very straight forward process that makes development and starting new projects much quicker and easier.
Perhaps you just need to work with these tools a bit more so you can understand what they do?
I mean, if you're using SASS, you've already got a build process.
But I get it. The gulp thing and grunt thing was always totally insane. Here's a little template and a bit of a joke I made a few months ago:
It's a build process that uses good ol' Make. I've been using Make for a long time. It works just fine.
Lemme just sum up with this: I've been writing web applications since the mid-90s. I started with perl scripts and cgi-bin. I moved on to J2EE and Tomcat. I worked with Rails for years.
I've seen Javascript go from a bunch of random functions strewn throughout an HTML file to what it is today. In between I've used Prototype.js, mootools, jQuery, and who even knows what else.
The web has been evolving. The power of the Javascript engines in browsers has been evolving. The world is in a constant state of flux and I am ALWAYS looking for better tools. I personally feel that I've been doing this for long enough to recognize what is really an advancement and what is just some flash-in-the-pan idea.
I definitely don't need you lecturing me about software tools and pretending like I don't question my process.
"We suddenly need 73 different tools and templates and scaffolds and packages and boilerplates just to start a simple project"
That's the problem here. You certainly don't need any of them for a toy project. Of course, you don't need a test suite either. Or a build process. Or any kind of automation.
But guess what, I incorporate them anyway because I've built up a discipline over the years. I don't feel overwhelmed by all the different libraries and tools out there because I actually take some time on a regular basis to catch up with the state of the art. It's part of the profession. Any profession, really.
I definitely don't need you lecturing me about software tools and pretending like I don't question my process.
I’m sorry you saw my posts that way. My intent was simply to challenge the specific post to which I responded, where you appeared to be claiming quite clearly but without any particular argument or evidence that projects today should be using Browserify, React and a bunch of NPM modules instead of jQuery. I stand by that challenge and my comments here, but please don’t read more into them than is there.
If you are interested in one more concrete example of where my opinions come from and why I still hold them, you might like to read a post I made a few months ago[1], in which I described the rather disappointing results of a recent experiment in using a few modern tools.
By the way, you and certain other posters here also seem to be assuming I’m the new guy who doesn’t know modern tools or understand the state of the art. I have no interest in getting into anatomical measurement competitions over this — I’d rather debate the merits of an argument objectively — but just so you know, I’ve been building web sites for going on 20 years and software generally for longer than that. I am not cautious about certain modern tools because I don’t know the current state of the art. I’m cautious because I do know the current state of the art, and after considerable research and experimentation, I don’t think it’s healthy.
I’m sorry you saw my posts that way. My intent was simply to challenge the specific post to which I responded, where you appeared to be claiming quite clearly but without any particular argument or evidence that projects today should be using Browserify, React and a bunch of NPM modules instead of jQuery. I stand by that challenge and my comments here, but please don’t read more into them than is there.
If you don't want to be misinterpreted you might want to limit the amount of sarcasm and hyperbole in your statements and instead focus on clearly defined criticism of these tools.
You can chalk all the issues that you've had to growing pains.
In the last 5 years the web browser has changed immensely. It is now capable of running incredibly complex applications. These kinds of applications need sane module and build systems. Once you're familiar with these tools they do not get in the way even when building simple weekend projects.
The jQuery way of handling DOM manipulation comes from an era where the majority of HTML was being processed on the back-end and Javascript was used for light-weight modification of state.
Using jQuery for building complex interactive web applications is a difficult task because state becomes incredibly hard to reason about.
There are a number of declarative front-end frameworks but I feel that React is the clear winner.
One big issue with Angular and Ember is when it comes to rendering HTML on the server. They're also very slow especially on mobile.
Yeah, the last 2 years have been a mess. We're not out of the clear yet. State and identity management is gearing up to have it's foundations rattled to the core by cryptographic systems that introduce PKI. Because React is just a view layer it'll remain agile enough to work with any sort of upside-down state and data management. Clients keep getting more and more power.
Within the node community the foundations for a decentralized package management system are being built. One that will be just as capable of publishing, loading and building modules from WebRTC as it is from a centralized server.
Yeoman, Bower, Gulp or Grunt don't really solve anything that isn't solved better by other tools.
I urge you to take another look at this stuff. I understand your frustrations but the solution should not be to give up and just go back to jQuery.
You can chalk all the issues that you've had to growing pains.
No. I’m sorry, but the issues aren’t that simple and you can’t just hand-wave them away like that.
The discovery and maintenance overheads, when libraries get so fine-grained that you wind up spending a lot of time just trying to find decent ones that will be compatible and then keeping an eye on them for updates or replacing them when they are no longer sufficiently supported, can be substantial. This has been an issue with general software development since forever. I sometimes call it the “max problem”: if you need a function to return the maximum of two values and it isn’t part of your language’s standard library, then it is almost certainly going to be faster to implement the one-liner function again on the spot than to search for an existing implementation, but this can easily lead to duplicated code, which is undesirable. The increasing reliance on powerful package managers in front-end web development is just a symptom of these problems.
The downsides of using a framework, meaning code that controls the overall architecture of your system into which you plug your own code as a subservient part, are also real. I’ve written about these on HN before, too[1]. Given that a lot of frameworks implement some sort of plug-in system to try to give back part of the flexibility they inherently take away, it is common to run into the excessive discovery and maintenance overheads I mentioned before on the same projects.
In the last 5 years the web browser has changed immensely. It is now capable of running incredibly complex applications.
But they aren’t!
Browsers are now capable of running non-trivial UI applications written in JS, and it’s true that those JS code bases are significantly more complicated than what we worked with a few years ago. However, developers have been building substantial front-end UIs using the likes of Flash or Java to overcome the performance and scalability problems with JS for a long time, and even the largest of these front-ends are only medium-sized projects on the scale of “all software”. There are no magic barriers being discovered in the front-end web development world that haven’t long since been encountered and overcome in other parts of the software industry.
In any case, as I said in my previous post, I am absolutely not suggesting that for these larger JS projects you shouldn’t adopt good tools to automate the development process. Of course you should. I’m just saying that most web sites are nowhere near that scale or complexity, and many don’t need to incur the overheads of adding heavyweight tooling, which is the point I originally objected to. Most sites are not SPAs or CMSes that need to scale up to hundreds or thousands of different types of content.
I think it is also worth keeping in mind that quite a few of the problems these heavy tools solve are only problems in the first place because of other poor tools. As Exhibit A, I cite the use of tools like RequireJS or Browserify to do basic modular design, which is necessary only because JS is a terrible language for developing larger projects and lacks even a basic module system of its own. But again, I’m not disputing that for large web apps by today’s standards a systematic module system is useful, I’m just saying you can go a long way with a one-liner to run Uglify and a one-liner to run SASS, and for many projects that sort of level is all they need.
Using jQuery for building complex interactive web applications is a difficult task because state becomes incredibly hard to reason about.
People keep telling me this, but I have never found it so, and among other things I maintain some substantial code that was built that way and has already successfully outlasted plenty of projects written in trendy web frameworks.
In a project right now that uses grunt, gulp, bower, npm, and angular (w. bootstrap). Just getting up and running to the point where we could actually code took too much brain. Going along nicely now though, at least until something needs styled, then there's all the bootstrap stuff and custom css from the main project bleeding into our plugin :)
So, basically, you end up rewriting the glue code and plumbing, keeping track of twenty-eight security bulletins instead of one, and hoping that someone doesn't get a zero-day in a less used library that doesn't has much security attention paid to it.
And that's fine, if writing a framework per project is something you have time for. But make no mistake -- you're writing a framework.
I'm not sure what you mean. Can you give an example?
keeping track of twenty-eight security bulletins instead of one, and hoping that someone doesn't get a zero-day in a less used library that doesn't has much security attention paid to it
System administrators, developers of pretty much any language, and even chip designers have to deal with the issues related to code that wasn't written in-house. We live in a modular world.
But make no mistake -- you're writing a framework.
React and the Common JS module system are enough of a framework especially when compared to jQuery.
I'm getting the feeling that most people on this forum don't really know nor care how these tools work and are mainly interested in making snarky jabs.
Your criticism isn't digging deep enough in to these tools to even make much sense.
I don't like how browserify will only ever work by serving combined files. Granted it has source maps but it's still terrible that you just can't debug your app with individual files with it. Neither do I assume setting breakpoints works very well in it?
I really really want to use all of these new tools, and to a certain extent I already do, but they just seem like layers of overhead on top of other layers and by the time you get down to doing what you need to do, jQuery is just much simpler.
Yeah, the problem with jQuery is all that other stuff that nobody uses and backwards compatibility with browsers nobody supports. A "lite" jQuery with the same familiar API but a stripped-down featureset for higher performance and smaller size would be nice.
There are valid reasons to use a CDN (get the scripts closer to the end user, offload the data transfer costs to the CDN provider, etc) but it isn't due to the potential for a cache hit.
You can "eat the cake and have it too" with something like this: http://microjs.com/
Basically you import everything you need and only what you need. Need extend? No prob: http://microjs.com/#extend - just pick one. And with browserify and npm literally everything you need to do to include a library in your project is a single command, so having to include "that many libraries" is not really a problem.
I'm a huge fan of having many little libraries instead of a few big ones, and JS - both on the backend and frontend - makes this possible to the bigger extent than most other environments.
Same. Between Micro JS, Vue.js and Browserify, I can craft the perfect tech stack with best-of-breed libraries, and come out with a much smaller, faster, and less janky site at the end of it. Oh, and being CommonJS modules via Browserify makes life pretty great, and my code maintainable and easy to follow!
I've only used jQuery once, for a client who insisted we use it, and it was the worst experience of my company's life. It only made us use bold on all our documents which proudly states, "No JQuery!".
My client was mad I was trying to charge him an extra $6000 for the time I spend to get the stuff I write to work across different browsers and asked me to use jQuery instead.
Still reading through but it mentions, IE7 when, as I've found out recently, going to a 2.x jQuery release will break IE8 functionality which is still used within organizations either as the actual browser or through compatibility mode. I didn't care for the format of the page but do like the author's tone and points so far.
I think a lot of the issues people have with jQuery is that (as the article mentions) it's become synonymous with Javascript and abstracts so many things that many people using it don't understand the underlying framework and functions. That and why include more resources if you don't really need to.
There are two parallel tracks of JQuery maintained, with _identical functionality_, one which supports IE8 and less, one which doesn't.
JQuery team is supporting both. If they don't behave identically, that's a bug. If you don't need IE8 or less support, you can use the smaller higher-performance JQuery that doesn't support IE8. If you do need IE8 or before you use the other variant.
Your code remains identical either way.
JQuery still supports IE8 and less, and has announced no plans to stop.
A lot of people are confused about this, and it's made more confusing by their mistakes about version labelling.
At present, these two variants are JQuery 1.x (IE8 no problem), and JQuery 2.x (IE9 and above). There are identical parallel versions of each. 1.11.0 and 2.1.1 have identical functionality. Yes, this is super confusing, so going forward in the future, they will call the old-browser-compat variant "JQuery compat", and the no-old-browsers variant "JQuery", and version numbers will be sync'd.
At present, the JQuery team is still committed to maintaining identical functionality in an old-browser-compat variant, and a newer no-old-browser variant, sync'd, for the indefinite future. And in fact they recommend the Compat version "for most web sites, since it provides the best compatibility for all website visitors."
They could at some point in the future decide to stop doing so -- they have said they won't do so until usage of older browsers has dropped significantly.
Thanks for the detailed response, that is clearly my mistake. I did an install from NuGet and went with 2.1.1 making an assumption that the latest build was the greatest build and not really doing a lot of research. On my end, it was a browser compatibility mode setting and a meta tag resolved the issue for just my site and is fine for the usecase.
Hopefully the change to calling the variants "JQuery Compatibility" and "JQuery" will help -- although since they are still saying they recommend "JQuery Compatibility" for most sites, I think they should have called it "JQuery" (the compatible one) and "JQuery Future" or "Jquery Non-Compatible" or whatever.
Anyway, you also could have simply dropped in the equivalent JQuery 1.x version for old-browser-compat with no changes to your code.
In all seriousness I'd recommend watching Adam Sontag's keynote from jQuery UK 2014 which covers the "not needing" jQuery stuff http://vimeo.com/97723665
You can basically sum up this entire rather ridiculous site with "Yes, you don't need jQuery, you can just use the built-in methods, but using jQuery is generally more pleasant, more consistent, and involves less typing". One particularly egregious example from the site:
The author summarises this, helpfully: "As usual, more characters, but still easy without jQuery."
Of course, if you were doing that remove class operation quite often, rather than writing all that code out each time, you might wrap it up in a helper method, and maybe you'd call it, I don't know, "removeClass" or something; perhaps if you were doing a whole bunch of DOM operations you might create little helper methods for each one, again to save you some typing. Pretty quickly you might end up with a little library of helper methods... and, of course, being a wonderful programmer who never makes mistakes, I'm sure that little library would be every bit as optimised, reliable, and correct as a battle-tested library used on hundreds of thousands of web sites.
This may seem anecdotal, but I can tell you from writing a lot of non-jQueryified code that with modern browsers, applying classes to dozens of elements dynamically can be an anti-pattern. 99% of the time, when doing something which previously would have required that, I can use a single class on a parent element.
In which case you don't want to be using jQuery at all and should instead be using a virtual DOM implementation like virtual-dom, famo.us, react or mithril.
Sure, the native APIs are slowly catching up, and classList is definitely a useful one.
You'd better hope that there actually is an element with an ID of "foo", though, otherwise your example will throw an exception. The last time I pointed this out here, there was some disagreement as to whether jQuery's behaviour is actually desirable. I think it is, but I'm probably biased from writing too much jQuery over the years.
So when those new native api functions arrive, jQuery will start using them and gain some performance boost (using native vs. custom js code) while at the same time remaining backwards compatible (by doing feature detection). No one wants to write their own feature detection code so this whole page about using native apis is instead of jQuery is ridiculous.
If the point of that website was to educate people on the apis that jQuery calls under the hood, it chose a really poor name.
This a thousand times, I know with $.trim it will use trim() for good browsers and then whatever hack effort was necessary for IE8. It would be devastating to have to write this manually.
If that's all you need, then that would be fine. However, for most projects you end up needing many other such polyfills, to the point that you might as well use one library—jQuery—to provide them all (plus a lot of other functionality).
While I'm waiting for that, and still writing applications that have to support ancient versions of IE, I think I'll stick with Jquery. Can't wait for the future though
If I saw that, first comment on the PR would be to wrap that eye sore in a wrapper function with a clear name. Which is basically what jQuery is doing.
I agree that's a lot nicer. But it also looks like essentially a mechanical transformation. Instead of a runtime library (whether jquery or roll-your-own), would it be possible to handle cases like that via syntactic sugar that expands at deployment time, and doesn't require shipping a library to the end-user's browser? (Or does something like that already exist? I haven't really spent any time with CoffeeScript and other compile-to-JS languages, so it's possible they already have nice syntax for this kind of thing.)
> Instead of a runtime library (whether jquery or roll-your-own), would it be possible to handle cases like that via syntactic sugar that expands at deployment time, and doesn't require shipping a library to the end-user's browser?
You could, but that would require user-agent sniffing (and thus continuous maintenance), and would probably need a pretty unusual caching setup.
That makes the site a pretty good illustration of one of the reasons why, although you don't have to use jQuery, you maybe should. With jQuery you benefit from years of development and testing, which your own code probably hasn't undergone.
Although, I do occasionally use jQuery, I'm more comfortable and productive when not using it. Also, if I shamelessly take a peek at jQuery's source now-and-then to see how they implement certain features so I can make a helper for it.
This is exactly the point. I don't mind the extra typing in those first few examples because jQuery is mysterious and it's nice to cut through the mystery. However, I don't want to have to fill my code with conditional logic based on the user's browser - that's lame.
The real value of this site is not what it says, but rather a reminder that jQuery is an abstraction and is made of code rather than magick.
or you can use just what js you need instead of loading pages down with dozens of bloated js library's and wondering why your site sucks and is slow as a slow thing
Actually since forever, you don't need to use document.getElementById("x") in any case. You just by putting the id to the element, it is already available to you referencing it by such id.
That won't work on Android 2.x, which doesn't support `.classList`. Performance isn't even an issue here since changing classes will cause a reapply-styles and layout.
Note the Jquery ticket for this issue can be tracked link below. In most cases Jquery will try to use to native implementations this is the ticket in this case they've never found it to be "miles away more performant".
Perhaps I'm being a bit dense (I've done prettymuch no front-end JavaScript), but since className gives a single string with class names separated by spaces[1], won't
fail if the element in question has more than one class? In that case, you'd need to get the className attribute, split it by spaces, do the replacement in the resulting array, and then join back and assign, I believe.
You're right it will only work for one class. This is actually a perfect example of jQuery smoothing out the rough edges for you. I think the split method would work (provided you remember to split with \s instead of just space). It actually took me a while to come up with a regex replace that won't break in some corner cases ( I think)
It's something you see a lot of, especially from non-frontend developers that don't really think twice about downloading an extra 80-90kb of JavaScript. I do find the support for events in JQuery quite convenient, especially for projects that still require IE8 support. Although if that's all you're using it for, there are probably better ways.
The AJAX examples fall a little flat. Yes, .ajax is a wrapper, and it was written because the API for XMLHTTPRequest is needlessly complicated and verbose.
If you're developing a single page application, you only load jquery once, then do the rest with AJAX calls for JSON and assets. It's worth the <100 KB on initial page load, at least for the projects I've worked on.
So many of the author's examples required different bits of code for different browsers. It's almost like they don't understand why people use jQuery and just chalk it up to ignorance when using a framework it's almost a necessity these days.
It's this stupid "you're not a real developer unless you're twiddling bits on your hard drive with a magnet" mentality that I absolutely despise.
It's a page and a half of mostly IE bugs. You should know your bugs and not try to cover them up but, more troubling that you don't want to know these things. Programmers I know want to write code, especially things as insignificant as these.
I developed a Cordova application recently, and I only needed jQuery for Bootstrap. All custom JS was able to be done using the DOM API. However, I was spoiled since I only had to develop against a recent webkit version (my target was iOS 7)
I had the same feeling when started working with angular, were you don't need jQuery or anything else to manipulate the DOM. It is spoiled, I agree, but it feels good to be "free" :p
Lots of blanket statements in this article. He asserts there is a 'proper' order to learning JavaScript but makes no demonstration of that assertion. For me, jQuery was a gateway that hid much of the incidental complexity of working with a byzantine API (the dom). That was incredibly useful. If every beginner started with trying to understand the DOM, they'd probably be scared off (and rightly so).
What you call Byzantine, I call normal. Some things are harder to learn than others but you can't throw your hands up in the air and let someone else (jQuery) do the simple things for you.
Working with the DOM is what we programmers do. I've never seen so many people complain so much about programming than those who use jQuery.
The DOM strikes as being composed of layers of incidental complexity that get in the way of the actual problem you're trying to solve. jQuery, or abstractions like it, allow us to compose more elegant and semantically meaningful solutions to problems. If writing boilerplate is interesting for some reason, be it for performance reasons perhaps, then by all means. I find it a bit tedious and appreciate tools that allow me to focus on the problems at hand, rather than obscure browser differences and internal API implementation inconsistencies.
I also don't need a calculator but I regularly use one to do even simple arithmetic operations, because it speeds up the operation and guarantees a certain result with given inputs.
The purpose of an SDK such as jQuery is to help a developer do common tasks without needing to write his own library. If it's used widely in the industry then even better. If it's open source, even more betterer.
This guy's argument is strikingly similar to that of the one made by those people who are anti-Apple, despite the fact that working with Apple products is a commonly pleasant experience, simply for the fact that they're Apple.
Just because a lot of people use something that they're not being forced to use doesn't necessarily mean that they've been "tricked" into doing so.
Using Apple products is a pleasant experience. Using jQuery is to avoid learning how to code while purporting that it makes things easier cross browser. Of course, if that were the real reason, we would also have cQuery and c++Query and so on but, instead, we just learn how to code.
jQuery is usually cached in your browser because of how common it is. From what I understand, the slowing is negligible. Part of a developer's role is to mitigate site performance with the speed of process. Inlining of critical CSS is one way to balance out initial page load, for example.
This is part myth. The chances your site has the same version of jQuery that the visitor's browser cache is are pretty low. iirc, someone once said it was less than 5%.
well that's the trade-off, isn't it? unless my app is speed-heavy, i'm not gonna spend the extra man-hours needed (that jquery saves me) so that website runs negligibly faster.
good luck ranking in google and explaining your self to your md when your major publishing site takes 20 seconds to load I wont mention any names but I know of two cases of this.
From experience where there is jquery there is normally at least a dozen other js files cut n pasted at random along with a similar number of css files with no thought to efficiency - hell most sites I se they can't even optimised the godamm images using Photoshop properly.
"JQuery is bad because some people who use it do unrelated things wrong"? Should I stop driving because some other people who use cars happen to cheat on their taxes?
There is a case to not use JQuery: When you really don't need it. I.e. you have one call to JQuery and it can easily be done natively. Then by removing JQuery you make the page download and load faster.
If you are using just the basic JQuery features you could consider Zepto instead, so a smaller download but still giving you the abstraction you desire.
And your point is? Pointing the blame at a different source doesn't mean the problem isn't present. If a client needs IE support, what do you do? Write the code three times? Detect IE and redirect the user to chrome-frame, then cry when you don't get paid?
I don't care who caused the problem. Just that it wasn't me, I can't fix it, and I have a deadline to meet and constraints to follow. jQuery is a lifesaver.
The tutorial in how to do things without JQuery is actually hugely useful to me.
I have been considering a project where for various reasons it would be much better to avoid JQuery, and I realized that I had no idea how to do some common things without JQuery. This is a well-organized guide.
It would be even better if he took out the three sentences after every section that just say, over and over again, "So why would you use JQuery, isn't this just as good?"
Who cares, sometimes I agree sometimes I don't, and the boilerplate argument repeated over and over sounds whiny and gets in the way of the actual useful information OP has to impart.
If you have your own external reasons to consider doing without JQuery (as I do), then an _honest_ assessment of where you are likely to have the most trouble would be more useful, than just repeating "Really, you're an idiot if you think you need JQuery" over and over again.
I do need JQuery because I want to focus on the application and not nuances of different js implementations. And I want to use the simple selector mechanisms. Then there's plugins, I use those too and many assume/require JQuery.
If you spent any time trying to get your website to load in under 1 second, removing jquery plugins is the first thing you do. Not only do you have to load the jquery, you need to load the plugins after you already have jquery which makes it even slower.
200 comments
[ 3.1 ms ] story [ 235 ms ] threadNot because of selectors, that's (sometimes) easy to do for lots of (basic) selectors. Not because of DOM manipulation, as long as you're willing to sacrifice simplicity and readability, you can build iterative loops to modify a collection of HTML elements.
No, it's the unexpected things that cause me pain. Want to use event handlers on dynamically generated DOM objects? Write your own event bubbling library. Want to create custom events/handlers? Ditto. Promises, .serialize(), .extend(), etc. might all be simple to write your own version, but when you realize you've reimplemented 50% of jQuery to avoid using jQuery, you feel like an idiot. [Source: I do this every 3 years]
Life is too short to not use jQuery.
Life isn't always a hipster website where people can get lunch delivered on their phone or whatever. Things like jQuery are fine.
Real bundling with tools like Browserify is making it more and more feasible to use single-purpose libraries instead of monolithic ones like jQuery.
I agree with all those things. jQuery is the lowest common denominator. It's the best at nothing, bloated with support for Palm Pilot browsers and Safari 1.0, and doesn't have all the cool grunt/gulp/amd/broccoli/cucumber/jsx/fotm neologisms. If I'm building a new, long-term project, I'm going to evaluate all the options, and craft the best possible technology stack for my new app.
But sometimes worse is better. Like a smooth pebble pulled out of a stream, it's taken a long journey and had most of the rough edges rubbed off. It's already in your browser cache from 4 different CDNs. Someone else can pick it up and support it easily. And that's what often makes it the best choice, when you want to avoid bikeshedding over what the hottest new thing is, and just make a webpage.
jQuery may not be the best technology, but it's a sane default.
Thankfully we only support IE9+ where I work, so I grab the latest 2.x version these days.
[0] - http://blog.jquery.com/2013/04/18/jquery-2-0-released/
https://www.npmjs.com/package/browserify
https://www.npmjs.com/package/react
And then use just what modules you need. All the functionality of jQuery has already been ported to various modules.
https://www.npmjs.com/package/extend
https://www.npmjs.com/package/promise
https://www.npmjs.com/package/serialize-form
These are all cool things, but sometimes you want to simply make a web page without setting up node and npm and all that jazz.
Think of it this way... jQuery is like getting a subset of the most common functions you get by using in browserify, but without requiring a build step!
No, absolutely impossible. That would mean I'd have to actually write JavaScript instead of LiveScript and that would be unbearable... ;)
On a more serious note: yes, node is a bit of an overhead. It may be too much for very simple, one-off projects, but it starts making sense as soon as the project becomes even a little bit more complex.
jQuery's imperative DOM manipulation is a horrible way to manage state compared to React.
These tools aren't just "cool things". They were designed to solve really pressing issues related to managing complexity in front-end web applications by eliminating global state in both the DOM or the JS runtime environment. They tend towards a more declarative and functional approach to system design.
A build process that integrates with a versioned package manager is fantastic.
Doing the simple, effective thing is just crazy talk, I tell you.
http://browserify.org/
Browserify is not at all complicated.
spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do
Just search npm and pick the one that is being used the most.
lock yourself into a proprietary framework that will be considered legacy code as soon as next week’s trendy framework arrives
The problems that npm and browserify solve are at the level of builds and package management. You could use any number of trendy frameworks and tools on top of this.
Right. But last week it was RequireJS, not Browserify. Today, as well as NPM, we have Bower and gem and pip and however many other package managers. Last week it was Angular, this week it’s React, and next week maybe it will be Web Components. Last week it was Grunt, this week it’s Gulp, and next week who knows?
The list goes on, but it always seems to be the same basic argument: for some reason, we are told, we suddenly need 73 different tools and templates and scaffolds and packages and boilerplates just to start a simple project. It’s long past time we stopped accepting that kind of rhetoric as if it’s some unquestionable truth. Ultimately web pages are still primarily made of the HTML, CSS and JavaScript that you serve to browsers. Everything else should have to pay its way, and there are always costs in complexity and maintainability when you introduce any external dependency into your project.
Now just to be clear, I am absolutely not saying don’t use good tools. If you are working on a large, complicated project, of course you should be systematic about it and control your dependencies and automate your processes. Even if you’re only working on a small project, low cost tools like jQuery or SASS might more than pull their weight. But it’s important to choose tools that fit the problem and offer a good cost/benefit ratio. Most web projects aren’t large and complicated, and many don’t need elaborate build processes and package management schemes at all. There is no good reason that such projects should give up on a simple, effective tool like jQuery just because you can also solve the same problems now with heavyweight tools like React and Browserify and some combination of NPM-managed packages.
But last week it was RequireJS, not Browserify.
I used RequireJS for a number of projects before being introduced to browserify and npm.
I had reservations at first because I didn't want my front-end code to be reliant on a back-end environment even if the language was Javascript.
However, after having my reservations answered by people in the node community and seeing how they were using it and seeing the incredible volume of front-end code that was being published to npm, I came around to it.
Today, as well as NPM, we have Bower and gem and pip and however many other package managers.
Bower really doesn't make any sense to use and seems to be falling completely out of favor. Gem and PIP are not Javascript module repositories so they don't make sense in this conversation.
Last week it was Angular, this week it’s React, and next week maybe it will be Web Components.
I spent a year with Angular and I found it suffered from a good many issues. It is slow. It is bulky. It does too much.
React's virtual DOM and expressive JSX are fantastic. It is fast. It works on the front-end and the back-end.
Last week it was Grunt, this week it’s Gulp, and next week who knows?
I agree with you here. I use Make. It works just fine.
Most web projects aren’t large and complicated, and many don’t need elaborate build processes and package management schemes at all.
Can you please backup your claims that browserify and npm are an "elaborate build process"?. Like anything there it takes a little time to become familiar with something but it is a very straight forward process that makes development and starting new projects much quicker and easier.
Perhaps you just need to work with these tools a bit more so you can understand what they do?
I mean, if you're using SASS, you've already got a build process.
But I get it. The gulp thing and grunt thing was always totally insane. Here's a little template and a bit of a joke I made a few months ago:
https://github.com/williamcotton/makeify
It's a build process that uses good ol' Make. I've been using Make for a long time. It works just fine.
Lemme just sum up with this: I've been writing web applications since the mid-90s. I started with perl scripts and cgi-bin. I moved on to J2EE and Tomcat. I worked with Rails for years.
I've seen Javascript go from a bunch of random functions strewn throughout an HTML file to what it is today. In between I've used Prototype.js, mootools, jQuery, and who even knows what else.
The web has been evolving. The power of the Javascript engines in browsers has been evolving. The world is in a constant state of flux and I am ALWAYS looking for better tools. I personally feel that I've been doing this for long enough to recognize what is really an advancement and what is just some flash-in-the-pan idea.
I definitely don't need you lecturing me about software tools and pretending like I don't question my process.
"We suddenly need 73 different tools and templates and scaffolds and packages and boilerplates just to start a simple project"
That's the problem here. You certainly don't need any of them for a toy project. Of course, you don't need a test suite either. Or a build process. Or any kind of automation.
But guess what, I incorporate them anyway because I've built up a discipline over the years. I don't feel overwhelmed by all the different libraries and tools out there because I actually take some time on a regular basis to catch up with the state of the art. It's part of the profession. Any profession, really.
I’m sorry you saw my posts that way. My intent was simply to challenge the specific post to which I responded, where you appeared to be claiming quite clearly but without any particular argument or evidence that projects today should be using Browserify, React and a bunch of NPM modules instead of jQuery. I stand by that challenge and my comments here, but please don’t read more into them than is there.
If you are interested in one more concrete example of where my opinions come from and why I still hold them, you might like to read a post I made a few months ago[1], in which I described the rather disappointing results of a recent experiment in using a few modern tools.
By the way, you and certain other posters here also seem to be assuming I’m the new guy who doesn’t know modern tools or understand the state of the art. I have no interest in getting into anatomical measurement competitions over this — I’d rather debate the merits of an argument objectively — but just so you know, I’ve been building web sites for going on 20 years and software generally for longer than that. I am not cautious about certain modern tools because I don’t know the current state of the art. I’m cautious because I do know the current state of the art, and after considerable research and experimentation, I don’t think it’s healthy.
[1] https://news.ycombinator.com/item?id=8228537
If you don't want to be misinterpreted you might want to limit the amount of sarcasm and hyperbole in your statements and instead focus on clearly defined criticism of these tools.
You can chalk all the issues that you've had to growing pains.
In the last 5 years the web browser has changed immensely. It is now capable of running incredibly complex applications. These kinds of applications need sane module and build systems. Once you're familiar with these tools they do not get in the way even when building simple weekend projects.
The jQuery way of handling DOM manipulation comes from an era where the majority of HTML was being processed on the back-end and Javascript was used for light-weight modification of state.
Using jQuery for building complex interactive web applications is a difficult task because state becomes incredibly hard to reason about.
There are a number of declarative front-end frameworks but I feel that React is the clear winner.
One big issue with Angular and Ember is when it comes to rendering HTML on the server. They're also very slow especially on mobile.
Yeah, the last 2 years have been a mess. We're not out of the clear yet. State and identity management is gearing up to have it's foundations rattled to the core by cryptographic systems that introduce PKI. Because React is just a view layer it'll remain agile enough to work with any sort of upside-down state and data management. Clients keep getting more and more power.
Within the node community the foundations for a decentralized package management system are being built. One that will be just as capable of publishing, loading and building modules from WebRTC as it is from a centralized server.
Yeoman, Bower, Gulp or Grunt don't really solve anything that isn't solved better by other tools.
I urge you to take another look at this stuff. I understand your frustrations but the solution should not be to give up and just go back to jQuery.
No. I’m sorry, but the issues aren’t that simple and you can’t just hand-wave them away like that.
The discovery and maintenance overheads, when libraries get so fine-grained that you wind up spending a lot of time just trying to find decent ones that will be compatible and then keeping an eye on them for updates or replacing them when they are no longer sufficiently supported, can be substantial. This has been an issue with general software development since forever. I sometimes call it the “max problem”: if you need a function to return the maximum of two values and it isn’t part of your language’s standard library, then it is almost certainly going to be faster to implement the one-liner function again on the spot than to search for an existing implementation, but this can easily lead to duplicated code, which is undesirable. The increasing reliance on powerful package managers in front-end web development is just a symptom of these problems.
The downsides of using a framework, meaning code that controls the overall architecture of your system into which you plug your own code as a subservient part, are also real. I’ve written about these on HN before, too[1]. Given that a lot of frameworks implement some sort of plug-in system to try to give back part of the flexibility they inherently take away, it is common to run into the excessive discovery and maintenance overheads I mentioned before on the same projects.
[1] https://news.ycombinator.com/item?id=8070050
In the last 5 years the web browser has changed immensely. It is now capable of running incredibly complex applications.
But they aren’t!
Browsers are now capable of running non-trivial UI applications written in JS, and it’s true that those JS code bases are significantly more complicated than what we worked with a few years ago. However, developers have been building substantial front-end UIs using the likes of Flash or Java to overcome the performance and scalability problems with JS for a long time, and even the largest of these front-ends are only medium-sized projects on the scale of “all software”. There are no magic barriers being discovered in the front-end web development world that haven’t long since been encountered and overcome in other parts of the software industry.
In any case, as I said in my previous post, I am absolutely not suggesting that for these larger JS projects you shouldn’t adopt good tools to automate the development process. Of course you should. I’m just saying that most web sites are nowhere near that scale or complexity, and many don’t need to incur the overheads of adding heavyweight tooling, which is the point I originally objected to. Most sites are not SPAs or CMSes that need to scale up to hundreds or thousands of different types of content.
I think it is also worth keeping in mind that quite a few of the problems these heavy tools solve are only problems in the first place because of other poor tools. As Exhibit A, I cite the use of tools like RequireJS or Browserify to do basic modular design, which is necessary only because JS is a terrible language for developing larger projects and lacks even a basic module system of its own. But again, I’m not disputing that for large web apps by today’s standards a systematic module system is useful, I’m just saying you can go a long way with a one-liner to run Uglify and a one-liner to run SASS, and for many projects that sort of level is all they need.
Using jQuery for building complex interactive web applications is a difficult task because state becomes incredibly hard to reason about.
People keep telling me this, but I have never found it so, and among other things I maintain some substantial code that was built that way and has already successfully outlasted plenty of projects written in trendy web frameworks.
Sure, it’s prohibitively diff...
And that's fine, if writing a framework per project is something you have time for. But make no mistake -- you're writing a framework.
I'm not sure what you mean. Can you give an example?
keeping track of twenty-eight security bulletins instead of one, and hoping that someone doesn't get a zero-day in a less used library that doesn't has much security attention paid to it
System administrators, developers of pretty much any language, and even chip designers have to deal with the issues related to code that wasn't written in-house. We live in a modular world.
But make no mistake -- you're writing a framework.
React and the Common JS module system are enough of a framework especially when compared to jQuery.
I'm getting the feeling that most people on this forum don't really know nor care how these tools work and are mainly interested in making snarky jabs.
Your criticism isn't digging deep enough in to these tools to even make much sense.
This is basically the algorithm for picking jQuery
http://zeptojs.com/
So ..using jQuery via a CDN, depending on which you use you have a 1 in 119, or 1 in 833 chance of the user having a cached copy. http://www.i-technology.net/2013/11/the-myth-of-cdn.html
more data: http://www.stevesouders.com/blog/2013/03/18/http-archive-jqu...
There are valid reasons to use a CDN (get the scripts closer to the end user, offload the data transfer costs to the CDN provider, etc) but it isn't due to the potential for a cache hit.
That statistics has assumptions on what's the most popular jQuery versions being used. It would make sense if there was real data to support that.
Basically you import everything you need and only what you need. Need extend? No prob: http://microjs.com/#extend - just pick one. And with browserify and npm literally everything you need to do to include a library in your project is a single command, so having to include "that many libraries" is not really a problem.
I'm a huge fan of having many little libraries instead of a few big ones, and JS - both on the backend and frontend - makes this possible to the bigger extent than most other environments.
My client was mad I was trying to charge him an extra $6000 for the time I spend to get the stuff I write to work across different browsers and asked me to use jQuery instead.
I think a lot of the issues people have with jQuery is that (as the article mentions) it's become synonymous with Javascript and abstracts so many things that many people using it don't understand the underlying framework and functions. That and why include more resources if you don't really need to.
There are two parallel tracks of JQuery maintained, with _identical functionality_, one which supports IE8 and less, one which doesn't.
JQuery team is supporting both. If they don't behave identically, that's a bug. If you don't need IE8 or less support, you can use the smaller higher-performance JQuery that doesn't support IE8. If you do need IE8 or before you use the other variant.
Your code remains identical either way.
JQuery still supports IE8 and less, and has announced no plans to stop.
A lot of people are confused about this, and it's made more confusing by their mistakes about version labelling.
At present, these two variants are JQuery 1.x (IE8 no problem), and JQuery 2.x (IE9 and above). There are identical parallel versions of each. 1.11.0 and 2.1.1 have identical functionality. Yes, this is super confusing, so going forward in the future, they will call the old-browser-compat variant "JQuery compat", and the no-old-browsers variant "JQuery", and version numbers will be sync'd.
http://blog.jquery.com/2014/10/29/jquery-3-0-the-next-genera...
At present, the JQuery team is still committed to maintaining identical functionality in an old-browser-compat variant, and a newer no-old-browser variant, sync'd, for the indefinite future. And in fact they recommend the Compat version "for most web sites, since it provides the best compatibility for all website visitors."
They could at some point in the future decide to stop doing so -- they have said they won't do so until usage of older browsers has dropped significantly.
Hopefully the change to calling the variants "JQuery Compatibility" and "JQuery" will help -- although since they are still saying they recommend "JQuery Compatibility" for most sites, I think they should have called it "JQuery" (the compatible one) and "JQuery Future" or "Jquery Non-Compatible" or whatever.
Anyway, you also could have simply dropped in the equivalent JQuery 1.x version for old-browser-compat with no changes to your code.
(Sorry ;))
In all seriousness I'd recommend watching Adam Sontag's keynote from jQuery UK 2014 which covers the "not needing" jQuery stuff http://vimeo.com/97723665
Of course, if you were doing that remove class operation quite often, rather than writing all that code out each time, you might wrap it up in a helper method, and maybe you'd call it, I don't know, "removeClass" or something; perhaps if you were doing a whole bunch of DOM operations you might create little helper methods for each one, again to save you some typing. Pretty quickly you might end up with a little library of helper methods... and, of course, being a wonderful programmer who never makes mistakes, I'm sure that little library would be every bit as optimised, reliable, and correct as a battle-tested library used on hundreds of thousands of web sites.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Element.cla... [2] http://caniuse.com/#feat=classlist
https://github.com/Matt-Esch/virtual-dom
You'd better hope that there actually is an element with an ID of "foo", though, otherwise your example will throw an exception. The last time I pointed this out here, there was some disagreement as to whether jQuery's behaviour is actually desirable. I think it is, but I'm probably biased from writing too much jQuery over the years.
If the point of that website was to educate people on the apis that jQuery calls under the hood, it chose a really poor name.
You could, but that would require user-agent sniffing (and thus continuous maintenance), and would probably need a pretty unusual caching setup.
Although, I do occasionally use jQuery, I'm more comfortable and productive when not using it. Also, if I shamelessly take a peek at jQuery's source now-and-then to see how they implement certain features so I can make a helper for it.
The real value of this site is not what it says, but rather a reminder that jQuery is an abstraction and is made of code rather than magick.
So this:
Can become to this: And is miles away more performant than slow jQuery.http://bugs.jquery.com/ticket/5087
[1]: https://developer.mozilla.org/en-US/docs/Web/API/Element.cla...
If you're developing a single page application, you only load jquery once, then do the rest with AJAX calls for JSON and assets. It's worth the <100 KB on initial page load, at least for the projects I've worked on.
https://docs.google.com/document/d/1LPaPA30bLUB_publLIMF0Rlh...
Pretty sure they're not all fixed, and this is just the ignorance du jour.
It's this stupid "you're not a real developer unless you're twiddling bits on your hard drive with a magnet" mentality that I absolutely despise.
http://youmightnotnotneedjquery.com/
or
https://gist.github.com/rwaldron/8720084#file-reasons-md (discussion: https://news.ycombinator.com/item?id=7153630)
I developed a Cordova application recently, and I only needed jQuery for Bootstrap. All custom JS was able to be done using the DOM API. However, I was spoiled since I only had to develop against a recent webkit version (my target was iOS 7)
Working with the DOM is what we programmers do. I've never seen so many people complain so much about programming than those who use jQuery.
https://github.com/kenwheeler/cash
https://github.com/finom/balalaika
http://zeptojs.com/
The purpose of an SDK such as jQuery is to help a developer do common tasks without needing to write his own library. If it's used widely in the industry then even better. If it's open source, even more betterer.
Just because a lot of people use something that they're not being forced to use doesn't necessarily mean that they've been "tricked" into doing so.
[1] https://tools.ietf.org/html/rfc1149
If you are using just the basic JQuery features you could consider Zepto instead, so a smaller download but still giving you the abstraction you desire.
That alone is enough reason to use jQuery and not having to bother.
I don't care who caused the problem. Just that it wasn't me, I can't fix it, and I have a deadline to meet and constraints to follow. jQuery is a lifesaver.
I have been considering a project where for various reasons it would be much better to avoid JQuery, and I realized that I had no idea how to do some common things without JQuery. This is a well-organized guide.
It would be even better if he took out the three sentences after every section that just say, over and over again, "So why would you use JQuery, isn't this just as good?"
Who cares, sometimes I agree sometimes I don't, and the boilerplate argument repeated over and over sounds whiny and gets in the way of the actual useful information OP has to impart.
If you have your own external reasons to consider doing without JQuery (as I do), then an _honest_ assessment of where you are likely to have the most trouble would be more useful, than just repeating "Really, you're an idiot if you think you need JQuery" over and over again.
Still, useful documentation, thanks.
So no, I disagree. Stupid article.