Hacker News Reader

Comment by incepted | Hacker News Reader

jQuery filled a need.

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).

View on HN

That need was filled by Prototype.js before jQuery. I remember the times when Rails defaulted to Prototype (author was a member of Rails core team, iirc). I also remember when we still had to choose between the two for the new project and I was unhappy if the choice was Prototype. So they both solved the problem, but jQuery's solution was more focused and way more elegant.

thing about prototype is it fundamentally changed how you dealt with javascript.

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 agree whole heartedly thats what i am getting at... jQuery succeeded not by trying to be everything but by trying to solve a real straightforward common issue that affects big projects and small projects, super senior developers and junior developers...

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...

Meteor fills a need.

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).

I haven't used Meteor but that makes it sound like .Net WebForms. Is that accurate?

I haven't used ASP.NET Web Forms but from giving them a brief look I would say so. Combined with SignalR.

If this is true then no wonder meteor hasn't gained the popularity they were hoping for. Webforms just tries to put this layer of abstraction over the web, which severely limits its flexibility, and means you are developing against webworms as opposed to the web itself. I know some people and companies are willing to make that trade off because they want the rapid development benefits, but I think the majority of experienced developers understand the long-term drawbacks to this scenario.

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.

I wouldn't say that jQuery is something that should be avoided. It depends on your current experience in JavaScript. I remember that our designer at a former company was preparing the HTML markup and CSS styles for us (mainly JavaScript developers) and he was comfortable using jQuery for prototyping animations and other stuff.

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.

>> 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.

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.

it wasn't "quick" though. React had a good run. One of the best "runs" you could hope for at the end of the day.

You mean JQuery had a good run?

oops, yea.

Reply on news.ycombinator.com