I certainly agree with the hypothesis of this article. I'd like to see how this compares with languages and not just frameworks overtime. How does this curve compare with mature/in-demand languages such as Java, PHP, JavaScript, .Net, Python etc. Do we find a similar graph with languages?
The Brutal Lifecycle of JavaScript Frameworks
81–90 of 128 posts
Re: The Brutal Lifecycle of JavaScript Frameworks
#82Re: The Brutal Lifecycle of JavaScript Frameworks
#83One of the things I don't think it accounts for in talking about the downfall of something like jQuery is that as time goes on, the questions have already been asked. So of course there's going to be less questions asked about jQuery in 2017 versus 2009, because if I need to figure out how to select elements based on an attribute rather than a class or id, it's already there.
Similarly, JQuery questions remain higher than the other ones in that chart; does that mean JQuery remains popular, or that JQuery is hard and people need a lot of help for it? Speaking for myself, it was often easier to copy / paste SO answers (in jquery) than try and figure things out for myself. I can imagine a lot of beginning developer start with jQuery and go to advanced frameworks after that.
In addition to the possibilities you listed, it might mean:
* most sites aren't SPAs, and progressive enhancement of a document with light interactivity via jQuery is a development model that's a good fit for those sites
* progressive enhancement of a document is an easier development model to move into from having started to author HTML & CSS than many of the SPA frameworks (note that this is also true of PHP), and many training materials that bring people into web authoring use js+jQuery as the next step
* many sites aren't rewriting their codebases particularly frequently, and anything used there remains relevant longer.
Re: The Brutal Lifecycle of JavaScript Frameworks
#84Earlier quoted context omitted.
On the same note, the older frameworks solved older problems. jQuery was the killer framework because it handled browser compatibility back in a time when people not only needed to support IE8, but IE6, and few companies felt comfortable telling people to just update their browser. Well, those days are past, so that problem is no longer a reason to choose a framework, and when you take that out of the picture, jQuery…
Yeah with jquery we were composing templates server side. Compared to Vue trying to do a SPA in jQuery is a season in hell. It can be done but it's brutal and fragile.
I'm quite surprised at this conclusion. I've always felt that doing SPA with jQuery was the easiest thing I've ever done in my development career. It's so easy to get something set up and running. And it's a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code.
Is it just me, or are many of the newer frameworks actually harder to use? I tried Angular 1 about 4 or 5 years ago and it seemed like a complete disaster. Recently, I've been working on Vue and this seems a bit better.
Re: The Brutal Lifecycle of JavaScript Frameworks
#85One of the things I don't think it accounts for in talking about the downfall of something like jQuery is that as time goes on, the questions have already been asked. So of course there's going to be less questions asked about jQuery in 2017 versus 2009, because if I need to figure out how to select elements based on an attribute rather than a class or id, it's already there.
On the same note, the older frameworks solved older problems. jQuery was the killer framework because it handled browser compatibility back in a time when people not only needed to support IE8, but IE6, and few companies felt comfortable telling people to just update their browser. Well, those days are past, so that problem is no longer a reason to choose a framework, and when you take that out of the picture, jQuery…
I am not at all a front-end developper. But isn't jQuery the DOM API done right? [Which is a good thing, but only the beginning of the journey.]
Re: The Brutal Lifecycle of JavaScript Frameworks
#86My question as a Java/Swing developper is this: what is the difference between React and Web Components? As far as I understand, both create self-contained components that you can use in your HTML, and that will react when you alter their DOM structure (for example changing an attribute value, or binding an HTML input value with an internal value inside the component).
And from that perspective, will we see in the future off-the-shelf HTML components (based on React or Web Components) just like we can use custom Swing components ?
Re: The Brutal Lifecycle of JavaScript Frameworks
#87Earlier quoted context omitted.
On the same note, the older frameworks solved older problems. jQuery was the killer framework because it handled browser compatibility back in a time when people not only needed to support IE8, but IE6, and few companies felt comfortable telling people to just update their browser. Well, those days are past, so that problem is no longer a reason to choose a framework, and when you take that out of the picture, jQuery…
I am not at all a front-end developper. But isn't jQuery the DOM API done right? [Which is a good thing, but only the beginning of the journey.]
Yes, in a way... it’s certainly (IMO) nicer to use than the DOM API. But “done right” used to mean not just “nicer to use” but “actually implemented correctly” (unlike major browsers at the time). Now that the DOM basics are pretty well-standardized, it’s mostly just “sugar” which isn’t necessarily worth the extra bundle size.
Another, bigger factor is that most modern frameworks use some form of templating and binding which means that you have less need to modify/interact with the DOM directly.
Re: The Brutal Lifecycle of JavaScript Frameworks
#88One of the things I don't think it accounts for in talking about the downfall of something like jQuery is that as time goes on, the questions have already been asked. So of course there's going to be less questions asked about jQuery in 2017 versus 2009, because if I need to figure out how to select elements based on an attribute rather than a class or id, it's already there.
ha, i came here to say this. I'd rather see web traffic results.
Re: The Brutal Lifecycle of JavaScript Frameworks
#89The interesting story in this post is not about JS frameworks. It is about StackOverflow.
The Ember community made a proactive decision to abandon StackOverflow around the 2.0 release (about 2.5 years ago). StackOverflow simply does not provide the tools we needed. For example when you answer a question: Are you answering for version 1.0 of a library? 2.0? Perhaps the "correct" answer for each is different. Perhaps, over time, an answer that once was correct is now suggesting something deprecated or not in line with best practices.
StackOverflow doesn't provide any features for dealing with versioning and changes in what is correct over time.
If your community has a StackOverflow moderator, perhaps you can update all the answers you want on a regular basis. I don't know, because our community had no such person, and the StackOverflow team was disinterested in helping us come up with a solution (the Ember project reached out).
Additionally as a tool matures (Ember is over 5 years old) you take more of this stuff under your own wing. Ember has a robust set of companies offering video training, in person training, and books. We have a community chat, a forum, and very active meetups. All of these things are controlled by members of our community, meaning they can respond to changes more fluidly than StackOverflow (moderated by some people outside our community) ever could.
StackOverflow just is not designed for long-lived multi-versioned software. So guess what happens? Users of that software don't stick around on StackOverflow. For living projects the short-term trend will almost always look better than long-term trends.
Ember's story here is not universal. I'm glad there are developers finding StackOverflow useful for other libraries. I think the story StackOverflow should tell is one that focuses on what they do well. But to draw a meaningful lesson about the JS community as a whole from such a idiosyncratic data source is a fools errand.
Re: The Brutal Lifecycle of JavaScript Frameworks
#90Just because the number of questions decreases about a framework does not mean people have stopped using the framework. I ask very few questions because I am normally working behind the bleeding edge and can get my questions answered simply by searching.