Hacker News Reader

Comment by Karunamon | Hacker News Reader

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.

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

View on HN

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.

jQuery is not cool. It's been there, done that for most, we all know where that road leads.

...we all know where that road leads.

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.

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.

> Large projects are never simple

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.

Reply on news.ycombinator.com