I am amazed by how the article attempts to look forward to what the future will hold with JavaScript frameworks... and yet seems to be completely both dismiss or misunderstand (perhaps willfully) why previous frameworks have succeeded.
jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not attempt to be a fundamental ui framework like those guys, it didn't try to be full featured, it didn't try to change javascript to look like another language and didn't try to shift the paradigm of the front end development world.
Silly question - why are is everybody talking about jQuery in the past tense and why are you saying it "did not succeed"?
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.
I think you've misread the parent. S/he isn't insinuating that jQuery didn't succeed, but that it (has) succeeded because of a set of reasons which are not part of the modus operandi of the teams behind a lot of modern UI frameworks.
Doesn't really scale to larger projects. Managing application and UI state becomes too cumbersome.
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.
Large projects are never simple and fun. Blaming it on tools is too often just scapegoating.
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.
I didn't mean to imply that you personally are in the habit of restarting projects on new frameworks. But I've certainly seen it happen a lot.
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.
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).
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...
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).
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.
well said. another important thing to remember is when jQuery came about interfacing with the DOM was really messy across browsers. Ajax queries as well. simplifying those, in my opinion, the killer features of jQuery at the time.
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.
The big change I experienced with Jquery is that it operates on sets of elements. It eliminated most guards and loops I'd been accustomed to when dealing with the DOM.
+1. Meteor should try to optimize their build time (for example, when I just changed one JS file, there's no point to spend more than 20 seconds to reload a simple page) and be frontend agnostic. The main thing I like Meteor (and also why I'm still sticking around) is how it manages data and the DDP stuff. Never a fan of Blaze, but certainly not sure about this "future vision".
Frameworks succeed for diffrent reasons. I am guessing your definition of success is being widespread.
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.
jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not attempt to be a fundamental ui framework like those guys, it didn't try to be full featured, it didn't try to change javascript to look like another language and didn't try to shift the paradigm of the front end development world.