Can anyone explain when did jQuery start to fall back in the tech era? What were its failures? It is a bit sad to say goodbye to such an old friend.
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 couldn't confirm this by googling, so if anyone can confirm or deny that this is the case I'd love to know!)
I can't remember the detail of document.querySelectorAll; it was first proposed around the time jQuery was originally released.
element.querySelector I think was largely inspired by jQuery's usage of it (in part to make it easier to run more of jQuery's selectors natively!).
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 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.
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
PHP was successful because it was embedded in the HTML which lowered the barrier of entry. That's the only reason.
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.
How much did these features cost back then?
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).
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.
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.
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".
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.
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.
Modern browsers have partially solved both these issues. (The former with .querySelector() and the latter with the deprecation of MSIE 6/7/8.)
What would you call jQuery UI?
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.
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.
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.
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.