It just got a beta release of a major version less than a week ago, it's a core part of Bootstrap, which just about anyone building webapps has used at some point, and depending on whose statistics you look at[1], powers a frankly absurd number of sites, including things everyone's heard of like Microsoft and Yahoo and Amazon.

That's the opposite of a has-been thing that did not succeed in my book.

[1]: http://w3techs.com/technologies/details/js-jquery/all/all

Code that works without surprises, experience that accumulates, projects that can be executed reliably?

But of course that's not much fun when compared to tinkering around with to-do example apps on the new new thing.

With that said the new things are still very rough, I agree, but they will make our lives easier after it all settles down. It's already beginning to settle down with React becoming semi-standard.

Chasing a magic bullet can temporarily make it look like you're avoiding the problems of large projects, because when you're constantly switching frameworks you never actually reach the point of having built something large enough.

I disagree. When designed correctly, large projects are simple to work on individual features and only complex when observed in aggregate as as complete system.

> Chasing a magic bullet can temporarily make it look like you're avoiding the problems of large projects, because when you're constantly switching frameworks you never actually reach the point of having built something large enough.

I never alluded to scrapping or restarting projects to get on the latest framework so not sure where this comment came from. I've build large systems with "jQuery", large systems with React and Flux. The latter was simpler to work on, more fun, and suited the needs of the client.

Deciding on a framework for a project takes understanding of both the application domain and the tools. When both are lacking, framework hopping happens.

I'd recommend experimenting with one or the other. If you know the domain, feel free to experiment with tools. If you don't know the domain, it's a double hazard to try to learn a new framework at the same time even though it might superficially look like a great fit.

It's as simple as that.

Its success has nothing to do with looking in the other direction or not redefining Javascript: it solved a problem that a lot of Javascript developers were struggling with.

Now what's really fascinating to me now is that while one can safely say jQuery created a revolution in the Javascript world when it came out, it is today widely looked as a smell and avoided as much as possible in favor or frameworks that modify the model instead of the UI.

And this quick rise to success and fall to obscurity could very well happen to the successful frameworks we are currently using today (including React).

jquery was just easy dom selection and manipulation, easy ajax, and easy events... you could drop it into any project and it didnt really proscribe anything else...

I am not suggesting we go back to jquery, i am suggesting that the next really successful widespread framework is going to get adopting by solving a specific widespread problem in a way that appears simple to the consuming developer...

as for jquerys run, it had the best run of any javascript framework in history, by a wide margin... and it really got supplanted not by other frameworks, or even by just losing popularity... it was so successful that it drove all the modern browsers to adopt its api and build it natively into the browser engine...

When a developer starts a new javascript project he/she is stuck with the task of choosing from an array of frameworks, backends, libraries, bundlers, etc.

Also, like jQuery, Meteor is doing something in the opposite direction as all of these other frameworks. Rather than being just one piece of the pie and leaving the rest up to the developer, it simplifies development end-to-end (in theory).

re: popularity of jquery... jquery makes it easier for you to interact with the DOM. WebForms (and maybe meteor? I don't know) makes it HARDER to interact with the DOM.

The more I learned about frontend technologies the more I started to realize where it makes sense to use jQuery and where not. With increasing knowledge one starts to think more about optimizing code and reducing the amount of libraries used etc. At the current company I'm working now, we also had use cases where we had to use native JavaScript due to some restrictions.

All in all, we still have a fair usage of jQuery and I honestly don't see anything wrong with that.

I agree with this completely.

Worth noting: for jQuery, the solution was aligned with the landscape of the time. Javascript support was a mess. Vendor implementation and feature support varied. A key benefit provided by jQuery was easy, performant 'write-once' code - the library provided an abstraction over often non-trivial issues.

Parallels can be drawn to the issues that the current generation of frameworks are oriented around. As upcoming browser features stabilise and become commonplace (i.e. web components, web workers etc), I think that the popular frameworks will consequently and inevitably evolve.

Interfacing with the DOM was not even something that dojo, mootools etc were doing at the time. At least that part wasn't as obvious/easy in those frameworks.

Of course, having to swap out both your front and back end or start a new app from scratch to take advantage will limit the number of applications for it.

Why did Wordpress succeed, by the way?