In a way, it's an end of an era. What jQuery did for the industry when it first came out was amazing. Normalizing differing browser APIs, making cumbersome APIs more palatable, providing powerfully expressive query selectors, enabling fairly trivial plugin development, and the nifty monadic chaining.
Some of those issues have been addressed by browsers, making vanilla JS a little less unreasonable. For other bits, rails-ujs provides some niceties that aren't worth carrying all of jQuery to have. These days most developers will want to use le framework du jour, and don't need jQuery for DOM querying and manipulation.
It was much more than that. jQuery made difficult things easy and paved the way for future technologies by using browser specific abilities and providing a unified API for developers to use.
It also standardized around a plugin architecture making it easy for people to write code others could easily reuse.
If you think there is only one iE6 bug that jQuery helped alleviate you'd be wrong. There are thousands of quirks/bugs/proprietary crap that jQuery handled for web developers.
Reducing it to an IE6 bug fix is out of touch with reality.
jQuery was a major productivity boost when first released but it didn't scale well and encouraged creation of tightly coupled glue code. It's decline being the result of evergreen browsers maintaining good parity where "vanilla JS" is now a feasible option and from it no longer being needed in the premier JS SPA frameworks which scales better and allows for the creation of better componentized and modular code-bases.
In someways we've digressed significantly and made it ridiculously more complicated to build a modern web app in contrast to what jQuery gives you out-of-the-box with a simple script include. Now to create a basic Angular2 App you need to download 32k+ files from npm and become an Angular2 build master just to setup your development environment and configure your package/deploy scripts.
You can still go a long way with just Bootstrap + jQuery - which would still be my goto if I just need to spruce up a web page with some behavior. Although that's happening less and less and find myself reaching for VS.NET/TypeScript/JSPM/React as my choice SPA stack which scales well with a great ecosystem, minimal complexity and maximum utility.
Yeah I get flak when I still use jQuery in new projects. Why do I use it? It fucking works, with no need to depend on npm, the application is a lot snappier than using Angular.
If I move on from jQuery, it won't be to Angular. I tried React, but I also found it too much boilerplate. I'm trying VueJS next.
I've noticed that the people that ridicule you for using stuff that works (like jQuery) are the same people that have trouble maintaining their own older code, because they'd much rather just start over.
Nowdays that true of vanilla JS. (Didn't use to be.)
addEventListener, documentQuerySelector, XMLHttpRequest...yes not everything is a one character function name ($), but it's all quite usuable if you value barebones-no-dependency simplicity.
I beg to differ... There's still weird Safari/Android bugs from old devices that are out in the wild. Even Windows 8 + IE11 has warts and might be used by application users.
I guess it depends on what you're working on, but for us it's expressly not an option to say "we only support the latest version of [insert browser]". Some users aren't even technical enough to differentiate between a browser and the internet
It's not just Angular. I really do like React, but the ecosystem complexity is staggering there as well.
Facebook's "create-react-app" tool does a great job of packaging all the pieces... But the cost is apparent when looking at the size of an empty create-react-app boilerplate app:
> 85,174,715 bytes (148.8 MB on disk) for 23,387 items
This is on Mac, so the wasteful HFS+ file system means that an empty web frontend project takes up 150 MB of disk space. Each project I make with create-react-app will have this same overhead. That's fairly incredible.
People think C++ is complex, but a full C++14 compiler and dozens of libraries will fit in less space than a web boilerplate.
Yep React's also culpable to npm's "micro module" madness, where often the scope of a npm package is wrapping a single function! Which explains why blank SPA templates requires 1000's of files.
But I've got my choice SPA stack down to a solution I'm happy with, where a blank App is down to:
- TypeScript (using Type Definitions in npm package or @types)
- JSPM (package/dep management, module loader + bundler)
- Gulp (automate all tasks in reusable scripts)
- React
JSPM `bundle` feature also lets you combine all React's deps into a single .js file which speeds up iterative dev workflow by combining the 100's of runtime dep requests down to 1 .js file.
Also using jspm@beta means I don't have to configure a separate tool like Webpack as JSPM reuses your dependencies where its 'build' feature rolls up your app into a single stand-alone, minified .js file to give you an optimal packaged app for deployment.
Using the TypeScript integration in VS.NET means I don't have to run any external processes or watchers as TypeScript automatically re-compiles every modified .ts file on save where it's ready by the time I reload the page.
Unfortunately it looks like npm has passed the point of no return and every developer is stuck building on this complexity. Honestly if it wasn't for the potential of React Native I'd strongly consider moving to Vue.js (https://vuejs.org/v2/guide/) since it's still a modern well supported SPA fx, but lets you reference a single script include. Ideally React would offer a simplified solution where it also maintains a parallel "react-dev" npm package with no deps, but it's unlikely since it goes against npm's micro module madness trend - but it's something I'm keen on exploring if I ever get the free time.
Can we please stick to the facts? Where exactly does it promote micro-modules? For example, React was repeatedly criticized for not splitting virtual dom implementation into a separate npm package. That's completely opposite side of the spectrum.
> Here I am thinking that 20k+ files
This are separate files and not necessary as many separate modules. Different things, really. That's ought to be solved with some kind of jar-like packaging format. I'm surprised node.js/npm doesn't have something like that implemented yet.
I've already made this clear, a blank Hello World App requires 20k+ files and 100's runtime dependencies. It literally takes minutes to download everything which I've had often fail. npm installs of SPA templates are one of the few things that can cause my MBP CPU to burn and HDD to thrash for long periods of time where I'd expect it to consume a non-trivial amount of energy.
The fact there's so many deps mandates additional tooling to manage and bundle them down to a manageable number of deps during development.
Facebook's recommendation for a hello world app [1] wants you to use their package manager, Webpack, Babel, Flow, a Linter, CSS preprocessor, their test runner, an embedded HTTP server just for starting off, building any meaningful App requires more dependencies where eventually you'll also consider a module loader. Then you're going to need to package/deploy your App and if you go off-script you'll need to manage and understand how all the different moving parts work together which you'll also need to know when wasting time chasing down dependency conflicts and tooling integration issues after package updates.
Your point about their being only 2 dependencies is completely inconsequential for development and shows inexperience in the recommended state of the art React SPA development.
> I've already made this clear, a blank Hello World App requires 20k+ files and 100's runtime dependencies.
That's a legitimate complaint but I don't think it has anything to do with micro-modules. You can easily have thousands of files per one npm package just as well. Now, if you actually mean commonjs-modules as opposed to npm packages, then you have a point. We really need to avoid unpacking all this files on disk separately.
> Your point about their being only 2 dependencies
Not my point. In fact, React has exactly zero runtime dependencies and as many development dependencies as you like.
> recommended state of the art React SPA development.
I only have the issue with the recommended part. All that React does is just trying to cooperate cleanly with the most popular js development stack out there. That unfortunately means npm mess (for now).
Start from any recommended starting React dev template and count the no of files, seperate tools, config files and runtime dependencies required to maintain an iterative dev workflow. The dependencies have gotten so out of hand Facebook's even developed their own package manager to manage it since npm has issues managing it properly.
> For example, React was repeatedly criticized for not splitting virtual-dom...
That's for production deployments, it doesn't represent the complexity and cognitive overhead required during development.
> I'm surprised node.js/npm doesn't have something like that implemented yet.
There's a number of bundlers available, it just requires integrating more tools and maintaining more config files.
> In someways we've digressed significantly and made it ridiculously more complicated to build a modern web app in contrast to what jQuery gives you out-of-the-box with a simple script include.
That's true, but I find that things are complicated because either 1) the complexity is higher because we're dealing with a proper app, in which case jQuery wouldn't be much simpler (you'd probably use Backbone.js at the very least, and that gets messy quick), or 2) people use a lot of 'state of the art' stuff that they don't really need.
In regards to 2: if what you need to do can be done with a script tag and jQuery, you probably wouldn't need anything beyond 'plain' React and it would still be a benefit. And if you go for something like Preact, the download size is smaller than jQuery, so you could even consider using both at the same time; preact for dom updates, and jQuery for everything else.
More and more I find myself opting for (p)react even for simple things like a slideshow widget or a tabbed element. I find it nicer than jQuery and if you avoid using all the 'cool stuff' (redux, etc.) it's simpler too.
I think what drives me nuts is that so often jQuery+Bootstrap would deliver a faster quicker product. While the big frameworks are incredible, they really are designed [1] for really large applications, ala Angular and Gmail. But, I see them being pushed onto what would otherwise be very simple projects: static websites, sites with a single contact form, etc.
The premier SPA frameworks: Angular/2, Ember, Polymer, Aurelia, Knockout,...
Fundamentally React has a one major concept "Components" which is very easy to create and JSX gives you the full power of JS without needing to learn the nuances of a crippled templating language. I use Redux to manage state which like React is simple and extremely powerful and centralizes all your App's state in clean data structures. E.g. with very little effort you can create a "Networked Time Traveller App" [1].
I also believe React's "Learn Once, Write Anywhere" approach lets you get maximum utility for your existing knowledge and decent code-reuse where you can use it to build cross-platform native iOS/Android Apps with arguably a more productive development workflow than the native iOS/Android toolkits on offer, although it's still a bit immature atm but has great momentum with a bright future.
The other day I downloaded project files from somebody and extracted it to my Dropbox folder before realizing it had a node_modules folder... crashed Dropbox on every single computer I had attached to it. I have to do the full Git remote repository push/pull dance, with each PC 'npm install'ing, just to work on any small project that might be related to Node.
jQuery still boils down to mutating DOM state, forcing you to become a bookkeeper where you have to carefully ensure your App's state and rendered DOM are in constant sync and you also have to deal with interim state transitions where it's easy to run into bugs for state transitions you've never tested or thought about, which gets complicated quickly.
React's Virtual DOM means you only have to care about the representation of a given state and React takes care of transparently and optimally handling all the DOM mutations required to sync the DOM with your App's state. React also has great componentization making it natural and easy to encapsulate reusable logic. The benefits really stand out in medium to large code-bases where it scales much better than jQuery. It's still ok for Apps maintaining little state, but there's a large class of Apps I'd never consider creating in jQuery which I've found trivial to develop with in React.
There was never a 'problem' with jQuery apart from that it's quite a heavy file, especially for mobile, and some people want to stop having to download it.
It's never been faced by the problems that backbone, angular, react, etc. where they rapidly die as soon as something else comes along, because it's a well built utility library, not a framework that had to include nasty hacks to work.
But, technically, there are no problems with it. If it were included by default in browsers, everyone would still be using it over vanilla javascript as even the new vanilla javascript has really poorly designed and wordy APIs.
I will personally continue to use jQuery for many years to come. It's a lot of power in few concise lines of code and it really makes sense. And it comes at the cost of a single request. For the small amount of JS my sites use its perfect. I don't know why everyone in thread is saying goodbye to jQuery. Are that many people coding in vanilla JS?
I think it just depends on what type of web application/site you are making.
For a simple site, it's probably not that big of a deal to hook in jQuery and write some basic scripts.
In my limited experience, if you are writing a Single Page Application, it gets really hard to rationalize changes when everything is hooked in through the DOM. It also gets pretty expensive with mobile browsers as DOM elements carry a huge list of properties and attributes; this why I think libraries like React were made as to have data change and manage state as opposed to the DOM.
At the end of the day, the end user and businesses don't care about what technologies that you use, they just want a site that works and can be delivered on time. I just think that with jQuery, there is a lot of cost in terms of making complex changes in the view that other libraries such as React/Angular/Mithril have been designed to get around. These libraries, however, do have a cost in terms of complexity that I think jQuery never really had.
I agree with you about jQuery getting quickly out of hand if you want to create something like a one page app and you should certainly use something like React or Angular. I do use it. But to do a quick Ajax post, read some data and display a message or show and hide something jQuery is awesome. To tie a quick event listener to a dropdown and do something or to find children of some element jQuery is still few lines of code that don't even need to be cross browser tested. Using vanilla JS for these things when you can do this in few lines of jQuery code seems masochistic.
I agree to an extent. I think in the example you mention, I would probably do it in vanilla JS. XHR is a negligible amount of code with vanilla javascript. It's also the same thing with event handlers but you do not need the overhead of the entire jQuery library. If you want animations, I would borrow a few CSS declarations from animate.css and add/remove classes or data attributes as needed.
I think it really depends on how you structure your HTML as well; having tortured myself into learning Angular has really helped with understanding how to think about data structures as opposed to strict DOM elements and this has carried over to how I write javascript nowadays.
One thing that I will mention is that I have worked really hard to not use jQuery over the last year, so my preferences may not be shared by you. I guess it depends on what is quicker and easier to maintain for you.
> XHR is a negligible amount of code with vanilla javascript
That was one of the pains the Fetch API cured for me. The syntax and overall concept is just so much nicer.
I was using Nanoajax library before that. It's great (and light, 620 bytes gzipped), but I moved almost completely to Fetch as soon as i started getting used to Promises more.
I guess libs like these and maybe even the Fetch in current browsers were somehow inspired by jQuery's $.ajax…
Definitely, I totally agree jQuery did a lot of good in terms of making javascript easier to work with as well as influencing the current spec. I completely forgot about Fetch! Thanks for bringing that up, been too lost in the pre-ES6 syntax.
See you've made an effort to go back to document.getElementBy... where I just wouldn't be able to go back to that after 10 years of such concise syntax that so closely matches CSS. But I'm a bit lazy and tend to find the easiest and quickest way to get to the result.
I find that the current state of things is that, indeed, jQuery is often still worth using, but only just, and especially if older browsers have to be supported.
If download size is at all an issue, jQuery is the first thing to go. I have a tiny collection of helper functions that make 'plain js' almost as simple as jQuery in most cases. Almost.
For example, at the very least I'll have a '$' helper function that makes document.querySelector(All) simpler/quicker to use, and I use a helper function for events to make it a bit more like $(<selector>).on().
But considering the fact that I have quite a few projects where the client will upload some huge image for the home slideshow or where there's no time or incentive to do any lazy loading of images, jQuery is often still the pragmatic solution. Especially when other devs need to deal with the project at a later stage.
I can't help but think the obsession with download size of script files in the JavaScript community is a bizarre premature optimization. I'm saving 400 kb by dropping useful library XYZ. Meanwhile, the page is loading 47 different snippets of non-async advertising and tracking code, social media buttons, non-optimized full-size PNG images, auto-playing videos, and more useless resources that dwarf any amount of JavaScript code.
I think that's a bit of a non-sequitur. Many people are focusing on performance in more areas than just dropping "useful" libraries - moving to async ads and tracking (if they have any), optimizing images, using SVG, etc.
Besides, 400k of (blocking) JavaScript can be the difference between the site loading quickly on mobile and the user giving up.
crucially, because events bubble up, even a click on a child element of <target element> will register as a click on the target element.
in plain js it doesn't seem to work that way. I'd do <root-elem>.addEventListener(), but I'd run into the problem that the event.target would point at the exact element that was clicked on instead of the parent element that I wanted to register clicks on.
Given the structure ".item .inner .title", I can't just check if event.target.classList contains 'item', because it might only contain 'title' or 'inner'.
event.path to the rescue! I can simply check if any of the parent nodes do contain the 'item' class. Except event.path doesn't work in safari mobile, so it needs a polyfill. Plus on every event handler I have to go up event.path to check.
Obviously it's not that hard to write a helper function that basically emulates .on(), but I can't help but feel that I'm maybe missing some simpler, plain solution. Any suggestions?
> in plain js it doesn't seem to work that way. I'd do <root-elem>.addEventListener(), but I'd run into the problem that the event.target would point at the exact element that was clicked on instead of the parent element that I wanted to register clicks on.
Unless I misunderstand, I think you might be looking for "event.currentTarget". event.target is the element that was clicked on, event.currentTarget is the element that has the event listener attached.
Yeah, but that would then either be 'document' or the 'root' of my widget/component, no? Not the 'item' which is somewhere in between the root and the target. $().on() is very convenient in that way.
I see, I missed the "<target element>" part of the call. Well, why not just attach the event listener to that, then? `querySelector` / `querySelectorAll` can be called on any old element, not just document.
<root-element>
.querySelector(<target element>)
.addEventListener('click', function(event){
// event.currentTarget refers to
// <target element> no matter which of its
// children were clicked
});
Admittedly, this doesn't work as well for multiple target elements. I use a forEach polyfill which could loop through them, but that could create a lot of event listeners when possibly you'd only need one higher up. Depends how many there are, I suppose.
The problem with attaching the listener to the 'actual' target is that it goes wrong when your markup is dynamic and so the target element is not (always) there the moment you create the listener.
This is why one of the early lessons you learn as a jQuery user is to use $().on() instead of something like $().click();
Plus, while I don't suppose it's a real performance issue much of the time, adding an event listener to each of, say, a few hundred items in a list is probably rather inefficient compared to adding it to the root element of the list.
This is what I use in my vanilla js projects for event delegation.
function delegate(el, evt, sel, handler) {
el.addEventListener(evt, function (event) {
let t = event.target
while (t && t !== this) {
if (t.matches(sel)) {
handler.call(t, event)
}
t = t.parentNode
}
})
}
delegate(document, 'click', '[data-behavior="open"]', function (event) {
event.preventDefault()
})
You'll need a matches polyfill if supporting browsers that don't support el.matches
Sorry, no time right now for that. I'll try to explain more clearly. There's no problem if I can bind directly to the element. However, that's often not possible. Imagine a <Carousel> element that is initialized, event listeners and all, but only receives data (<Item> elements) at a later time.
In jQuery I can do something like this:
$(<Carousel>).on('click', <Item>, function(e) {
// using this 'this' gives you the <Item> element. Always. Even
// if you click on a child element of <Item>. And it works if
// you add or remove items. Also it doesn't add a listener
// to *every* single item, which matters if you've got a whole
// bunch of them!
});
The vanilla equivalent is often presented to be as simple as:
<Carousel>.addEventListener('click', function(e) {
// e.target is the actual element you clicked. So now we need to
// figure out if this element is inside an <Item>, and perhaps
// also *which* <Item>. There's various approaches, and it's
// not rocket science, but it's all extra work for something that
// seems like a common scenario.
});
I still think we should discuss it via a real fiddle we can test the approaches with. Talking about pseudecode with placeholders is much more nebulus then talking about real code.
See my reply child post. But anything from tying a quick event of any kind to an element and posting a form using Ajax and consuming the response, doing quick show and hide. And the ease of implemting a million different plugins for all kinds of things, from morals to slides, in this jQuery is still a champ.
Maybe check out Zepto. It aims to have the same API as jQuery without all the debt of supporting older browsers. I still prefer to use jQuery over vanilla JS, but often I'm building apps that'll only be used on evergreen browsers, so that tends to be a better choice for me.
jQuery is/was incredible, and deserves every single bit of praise heaped upon it. But it is nice to see coding going back towards "vanilla" JS - it wasn't so long ago that every JS answer on Stack Overflow just assumed you were using jQuery and you struggled to find an answer that didn't require it. That's not the case any more.
Why is everyone on this thread talking if this is an obituary for jQuery. jQuery is pretty amazing and will continue to be the most popular framework out there for a long time to come. It is just that rails wont ship with it by default.
Nikanj isn't wrong (and is funny), but I think the other (more justifiable) reason is that jQuery largely isn't necessary anymore: when it came out, there were an uncountable number of browser incompatibilities that needed painting over, and APIs for remote requests, DOM querying & manipulation and the like were very immature, so a library to make everything usable was extremely valuable.
Now, those APIs are mature & standardized & it's generally not too hard to write vanilla JS that works across all the major browsers.
I don't think jQuery has failed, but for the kind of baked-in functionality Rails wants it's not really needed, and there are good reasons not to pack another dependency into your framework if it will increase page download size & is increasingly unlikely to be used by the framework's users.
I recall reading that element.querySelector(All) was inspired by jQuery. If true, it means jQuery was so much of a success that parts of it were implemented natively in browsers!
(I couldn't confirm this by googling, so if anyone can confirm or deny that this is the case I'd love to know!)
Exactly. For my little JS needs I just use vanilla JS (even though the APIs are poor and the language is worse), since it will very likely work across all browsers I care about (recent FF/Chrome/Edge).
Although the comparison isn't perfect, you can think of jQuery as PHP in the late 90s and early 00s.
PHP made web development accessible to the masses. Because PHP is embedded in the HTML itself, it is way easier to work with than Perl or Java, especially in the context of The Web In 1999.
In the same vein, jQuery filled a very important niche when the web was just getting started. It made Javascript accessible, by smoothing out the differences between browsers, and by providing a useful set of abstractions over the mountain of quirks that is client-side Javascript.
Most importantly, jQuery made hard things that people wanted to do stupidly simple.
But in 2016, there are fewer differences between browsers, and more importantly, our knowledge of How To Build Software has massively improved through lots of trial, error, and iteration.
And things that used to be really hard in Javascript are now a lot easier, thanks to improvements in browsers, languages, and tooling... well, the tooling still needs work, but that's a different discussion.
The world that jQuery served no longer exists, and it has largely been replaced by more effective abstractions. It will never truly go away, but neither will it be the choice for most people that are looking to create something new.
>PHP made web development accessible to the masses. Because PHP is embedded in the HTML itself, it is way easier to work with than Perl or Java, especially in the context of The Web In 1999.
PHP didn't make it easy. It made it possible.
Until fairly recently, getting a VPS was insanely expensive, so any learner, hobby, startup went to shared hosting.
As a result, any tech which required starting servers or elevated permissions was out, so Java and ISAPI (remember that?) were out.
So the only choice was PHP/ASP or perl/C/tcl cgi scripts.
cgi scripts had to be located in the /cgi-bin directory, so they looked ugly in the URL and simply wasn't designed for the web (so no url_parsing libraries (but no register_globals!)) and no git/github/blogs/stackoverflow whee to just go and download them.
So one had a choice between PHP and ASP.
ASP costed quite a bit more for the license, so PHP took over the internet.
CGI scripts were also a lot harder to secure on shared hosting. I remember the hosts supporting them required security review before being installation. Then PHP came along with safe_mode and open_basedir, and if there were commonly-deployed solutions for CGI after that, I sure didn't see them because everyone was already using PHP.
I was lucky. I was able to upload cgi myself. It was just too much hassle for little gain (whatever security exploits you'd get in PHP, you'd get writing your own C code).
Oh, and how can I forget, mod rewrites were a terrible pain, so if you wanted your website to be dynamic (so you can have, say, your login name at the top corner), you'd have to make your website look like http://www.example.com/cgi-bin/main.pl?url=/directory/page5
There were a few CGI script websites around, like Matt's Script Archive and his (in)famous FormMail.pl.
There were also URL libs, eventually, as well as other CGI-specific tools, like counters, banners etc.
You are right that PHP was the logical simpler choice, and it did take off in the second half of the 90s. But for the best part of the decade the web was built on CGI.
I would argue that the CGI era was a good one. Writing a CGI required low-level knowledge of HTTP, HTML, how web servers worked, and very likely knowing your way around a UNIX system. Solid skills, that are still useful today, marked a high bar which raised the overall level.
Furthermore, the nature of CGIs made for better architectures. Simple entry and exit points, dedicated services. Connecting them to something else required careful consideration. They made you gravitate naturally towards KISS, REST and other best practices which are still observed today.
I would also add that there were several other hobbyist fields popular at the same time, like MUDs (usually built in C) or IRC servers/clients/bots (also Perl/C/TCL) to name just a couple. Knowledge gained in one of them lent itself fairly easily to another.
No. You could give CGIs any filename, in any directory, on many shared hosting environments in the 90s. I know because I did it. Some shared hosting providers allowed persistent processes. Also, in the 90s, many small businesses self-hosted on tower PCs connected by fractional T1s. Many hobbyists self-hosted on dorm Ethernet (which had publically routed static IPs then) or got a corporate network administrator buddy to give them bootleg colocation.
PHP was successful because it was embedded in the HTML which lowered the barrier of entry. That's the only reason.
>Also, in the 90s, many small businesses self-hosted on tower PCs connected by fractional T1s
You were lucky you weren't on a 14.4 kbps modem sharing a phone line with the family, on a dynamic IP, and had an extra PC to devote to hosting a website which could stay on 24/7.
Oh, and weren't scared that someone would hack into your home network just for fun.
> Some shared hosting providers allowed persistent processes
Most didn't.
> PHP was successful because it was embedded in the HTML which lowered the barrier of entry. That's the only reason.
No. That's not the _only_ reason. Right now, unless $5/10 a month is too much, you can get root on a VPS on DO.
>PHP was successful because it was embedded in the HTML which lowered the barrier of entry. That's the only reason.
JSP also allowed Java code in HTML (The new syntax came later). Yet, it never took off (though being a memory hog back then definitely didn't help it).
I apologize in advance and mean no disrespect, but I think this analogy is terrible.
PHP was browser-agnostic. PHP was a flawed tool that existed alongside other tools, and survived based on various merits and despite various drawbacks.
jQuery was a life preserver. Javascript is wholly browser dependent, and at the time of its inception, browser compatibility was a jungle full of king kongs and velociraptors.
Before jQuery, your javascript might work. With jQuery, it would work.
Since then, browser compatibility has gotten better, and the language has advanced. Much of what was previously speculative has become basic.
Pour one out for jQuery, but don’t feel sorry for it’s demise; be grateful for where it brought us.
I'd like to point a possible flaw in your counter-argument: jQuery wasn't the only choice and it wasn't the first. PrototypeJS, which came before it, did an arguably better job since it didn't have many of jQuery's design flaws, like hijacking 'this' or silent selector errors.
The PHP analogy is therefore spot on IMHO: both it and jQuery (and I'd like to throw MySQL in there while we're at it) were tools that achieved success by lowering the quality bar in exchange for feature abundance and "if it works why do you care how".
I overlooked the fact that PrototypeJS was first (in fact, I was one of the unfortunates who backed that horse), but I still disagree. I don't think the jQuery lowered any kind of quality bar, it made absurd and redundant work irrelevant.
If you're referring to those legions of people who "don't know javascript, but know jQuery," without jQuery they simply would have been lousy javascript developers instead of lousy javascript developers, that doesn't change anything.
You bring up prototype of all things as an argument for having less design flaws than jquery...sorry, I really don't want to sound snarky, but that made me chuckle.
Their moronic choice of directly extending the DOM was a more fundamental and far-reaching flaw than any of the - definitly numerous - problems and bad choices jquery has and had in the past, and it's one of the reasons it's has all but vanished for years now.
It didn't have any failures, the browser APIs have just finally caught up with it. I would guess that 99% of jQuery usage was for ajax, event normalization, and CSS selector queries, which are now trivial and cross platform in vanilla JS (with a little help from the fetch polyfill for ajax). I personally haven't used jQuery in a project for at least two years, and I doubt I'm in the minority of front end developers in that regard.
I can't answer that, but I'll say that I still include it in most projects without a second thought. Maybe I'm not aware of some existing superior replacement, but since I don't care much for the popular modern JS frameworks JQuery + vanilla JS is still my goto choice. Following good coding principles, I haven't yet had any project grow to be too messy, but maybe I'm just not working on extremely complex front-ends.
jQuery to me was always meant as a DOM manipulation library. It didn't fall behind per se, it's just that browsers became good enough and standard enough that you no longer needed this type of tool. I think it would have been a huge mistake for jQUery to have attempted to become a Backbone, Angular or React, because it really was never meant for building web apps (of course you could still use jQuery in Backbone and Angular, and in fact those projects kind of assumed you were using it, or at least something that was API compatible).
If you're just targeting modern browsers, You Might Not Need jQuery [0]. jQuery was great when dealing with browser inconsistencies and when all you had to do was wire up a few things.
If you're building a marketing website or a lightweight app, I think using jQuery is fine. But if you're building anything more sophisticated, like a highly interactive web app you'll probably skip on jQuery and just use React or something similar.
I think context is very important. Are you building something that is being maintained by multiple engineers? Does it have to accommodate regularly changing requirements? You can go really far with server-side rendered Rails and a few bits of jQuery thrown into the mix. But once you're past that point, embracing the ecosystem becomes more useful.
jQuery isn't dead, and wasn't a failure. It is still widely used and probably will be for some time to come. There are many different types of web projects! For those that require more than vanilla js, and less than a full blown framework (Angular, etc.), jQuery still has its place.
I don't think there are any failures in it - it could have grown outwards to become what React is today, or something, but it always kept to the principle of doing one thing and doing it well: unifying browser APIs across vendors and simplifying them. (yes, I realise that's two things, but...)
These days there are many fewer differences between vendors, and things like the Fetch API are making the kind of simplifications jQuery pioneered a core part of the browser experience.
jQuery is for adding behavior to web _pages_. It thrived in the era where most web development happened on the backend and frontend development was really about sprinkling interactivity and effects onto a page. jQuery does not supply powerful-enough abstractions for writing applications. Early attempts to layer MVC on top of jQuery did not meet with much success; Angular and other libraries used it initially for DOM manipulation but as time went on they mostly found ways to drop the dependency.
I still think that if you're building _pages_ instead of an application, you should consider it. Plus, it is a great tool for understanding and manipulating the DOM. I think it will continue to be popular with casual web developers for a long time, although frontend engineers have probably not been using it for years. I think the death of jQuery is exaggerated, but only time will really tell.
> It is a bit sad to say goodbye to such an old friend.
I see this as more of correcting a poor design decision on the part of Rails, rather than having anything to do with the relevance and usefulness of jQuery today.
I loved jQuery when it first appeared, but it is from another era, for sure. The rise of the Single Page Application was one big strike against jQuery. Frameworks such as Angular 1.0 emerged which relied on jQuery, and the software built with those frameworks revealed the dangers of mutable state, especially when combined with something async like Ajax. Anyone who has worked on a large Javascript project is eventually burned by mutable state. Then other frameworks such as React and Om Next emerged, which advocated for immutable data. The team behind Angular realized their mistakes and tried to fix them, so Angular 2.0 was a radical re-write of Angular 1.0, and yet despite that, more and more developers continued to flock to something like React. The immutable frameworks offer the idea that all state should be held in a single immutable atom, and the views should merely be straight reflections of the state that is held in that atom. One could still potentially use jQuery in the background to handle the actual update of the DOM elements, but there are many other ways of updating DOM elements, and many of those other methods are more efficient than jQuery, so jQuery's importance has declined.
Back in 2007, if you wanted to add some simple visual effects to your CRUD app, then jQuery was like a gift from God. But nowadays, given the complex systems that people are building, jQuery has less to offer. It never had an opinion about managing state, so it leaves the core question of building a large app to other frameworks, and those frameworks have various built-in ways of updating the DOM, so the ease-of-use offered by jQuery is no longer such a noticeable advantage.
jQuery was the my first language that got me into coding; I had started javascript but it became very difficult to write a short amount of code for some basic things that I was working with back in 2012.
Ruby on Rails was my first framework for developing web applications. I still use it today, but would remove jQuery as a dependency. I thought it was strange how much of dependency it was for certain things like deleting objects for Rails; I guess it was the right tool for the time.
jQuery is/was a beautiful thing in that it was a concise and fairly nice API for interacting with the DOM. I feel like it was the right tool for the time but now a lot of developers have come to learn the cost of DOM interactions especially with mobile browsers. I am not too certain about ES6 but that stems from my ignorance and not any technical concerns.
I think that while there has been strides in understanding how to make rich clients with javascript without performance issues, I do not think there has been anything as simple as using jQuery. I prefer to use Angular now or vanilla javascript if it is a small scale application and while I like/understand Angular, it took an incredible amount of time and work to properly understand what I was doing. Vanilla js can be incredibly performant, but often times I have had to write 3 times the amount of code to get something going which is a costly in time and maintenance.
jQuery was literally something that took a day for me to understand as non-developer. I hope as javascript progresses that API developers focus on simplicity and ease of use when creating the next big javascript framework.
Really interesting, the replacement is a vanilla js implementation called rails-ujs and was made by someone who went through Google Summer Of Code!
"The new rails-ujs was developed by @liudangyi as part of Google Summer of Code, all credits for this goes to him and to his mentor @pixeltrix "
- https://github.com/rails/rails/pull/27113
rails-ujs has been around for a long time (I want to say since the Rails 3 era, but not certain), the change here is to move that from jQuery to vanilla JS, just as back in the day it was once migrated from Prototype.js to jQuery
Yeah, it's a bit more verbose, although some of that can be alleviated with a helper function or two, well enough that it's worth it for me in many cases.
But I still regularly find myself just using jQuery for convenience, as there's still a bunch of gotchas with plain js.
For example, I rather liked the event.path property to deal with event bubbling, only to discover that safari (mobile, at least) doesn't support it. Adding a helper function for that was trivial, but it's still one extra thing to do, and it makes it just a bit harder for other devs to get going. I ran into a number of these minor issues.
I'm not a fan of CoffeeScript but do they really need to lug the huge amount of dependencies babel brings along with it? Why not target ES5 with some ES2015 sprinkles in depending on compatibility and slowly work towards ES6?
I'm not sure how you slowly 'work towards' ES6. Unless you decide to only support bleeding edge browsers, you cannot use ES6 or ES7 features in production applications.
The only way we can use them is through transpiling. This will be the case for at least another three or four years.
> I'm not sure how you slowly 'work towards' ES6. Unless you decide to only support bleeding edge browsers, you cannot use ES6 or ES7 features in production applications.
Not really.
First it depends on your target audience. How new are their web browsers? Where are you developing your web applications? Some projects I've worked on have web applications that run in only a single environment so those are easy. Others I've had highly technical websites that the vast, vast majority went to using newer web browsers.
Second, pick and choose your ES2015 features. Honestly you don't need ES2015 at all but if you want to use it then some items, like let and const, are supported all over the place but others, like fat arrows, not as much.
> The only way we can use them is through transpiling. This will be the case for at least another three or four years.
Again all depends on your target audience. Maybe? Then again I've never been the biggest fan of transpiling one language into another just to access a couple of minor feature additions. It's a huge amount of dependencies, build time, etc all to support a few minor things.
I somehow still seem to need jQuery. Mainly because I need to use a UI component, and out there one already exists, which does exactly what I need. So jQuery gets in as a dependency. Maybe because I have used it for more than 8 years now, I seem to know the jQuery based components well.
Especially times when one needs things like https://fullcalendar.io/ and Kendo UI jQuery becomes a required dependency.
To those, how to you program enterprise systems, without jQuery? Do you any mature UI toolkits which don't depend on jQuery? I am genuinely interested in knowing about these.
I build pretty simple sites on the public side - mostly restaurants and gyms and other small businesses. I've been moving away from jQuery for everything except my ecommerce sites over the past few months.
The back-end administrative panel of those sites is more complex. It uses Bootstrap, so there's some incentive to include jQuery there, though I don't always use features that require it. But this is an area I struggle with as well - there are so many external components, like date and time pickers, drag & drop image uploads, etc, that aren't easily replaced with vanilla JS components that have feature parity. Curious to see what others have to say about this as well.
I think it was included because it was consistent across browsers.
There's some weird Rails specific things that I am not too sure make sense (like having the ability to use DELETE as a data method for a hyperlink) but make CRUD apps simple to follow in terms of the Rails way-of-thinking.
I'd have to check the source, but I think it was also used for AJAX forms. I think the safe answer is that Rails is great to create something quick but the built-in helpers aren't always very sane.
It's a full stack framework. You can include JavaScript for your views, probably most commonly used to show, hide, and insert and remove elements from the DOM.
To expand on this, the tool of choice for the frontend part used to be PrototypeJS. In Rails 3.1 the relevant portions were decoupled and became options rather than baked-in, with jQuery as the default but still an option among several: http://weblog.rubyonrails.org/2011/4/21/jquery-new-default/
I only use flexbox in CSS and Svelte for raw JS, less code and speedier workflow. It's more easier when combine Svelte with Redux and transpile with Rollup. With Sever-side Rendering include, this is so much better and doesn't force me to stick to one framework.
No, ujs is used to automaticslly implement RoR functions declared in your rails templates. Eg, you can add a confirm attribute to a link, which is then implemented by ujs in the browser, causing a confirm dialog when clicking the link
The amount of arrogance in this comment is very telling. While jQuery isnt used to build modern webapps, what jQuery did for web development is no small feat. Yes, you dont use Wright brothers' aircraft to fly people these days, but dont compare an early (and pioneering) tool against best practices of the day
You're probably getting downvoted because of the combination of unsubstantiveness and dismissiveness. That's bad for an HN comment, so please don't do that.
When it was created - jQuery definitely made javascript not shittier. Javascript was a mess (or browser support for it) and IMHO the most import jQuery goal was to eliminate of cross-browser incompatibilities [0].
Indeed. jQuery and prototype.js made writing browser-independent JavaScript possible. That was huge. And the early competition between the two made introduced (or at least drove the widespread use of) a lot of browser behavior that's commonplace now. Not to mention Ajax.
This is completely uncalled for. Two people have already commented on your posts today in this thread. Please take extra care to post civil and constructive comments here.
Some of those issues have been addressed by browsers, making vanilla JS a little less unreasonable. For other bits, rails-ujs provides some niceties that aren't worth carrying all of jQuery to have. These days most developers will want to use le framework du jour, and don't need jQuery for DOM querying and manipulation.