13 ms·

The Brutal Lifecycle of JavaScript Frameworks

224 points by lainon 9y ago

Kajayacht 9y ago
One 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.
- slig 9y ago
  Agreed. It'd be nice to have graphed the number of pageviews of each tag as well.
  - Waterluvian 9y ago
    Just made me think about a great metric as a developer: understanding how popular each SO page is about your library. Ie. "X is still catching up everyone, it's a very busy page. We have done a good job making Y more obvious, people aren't searching for it anymore."
- aalleavitch 9y ago
  Yeah, it’s not like these sites have stopped using jquery altogether: my site uses React components but I still write a couple lines of jquery here and there for basic uses.
- nicoburns 9y ago
  Yep! Same for React. It has a much smaller API surface area than Angular (and goes wrong it mysterious ways less often!), so fewer people will be asking questions about it. From my perspective, it appears that React is still very much in ascendancy.
  - jsight 9y ago
    The chart seemed to show React to be growing very quickly as well.
  - dentemple 9y ago
    From my anecdotal experience of just watching SO's React queue, most questions about React that show up (that aren't repeats) are almost always regarding how it's used with some library in the ecosystem. React-router, Redux, Webpack, Material UI, etc. So even though the API itself small, there's still an endless number of questions out there for people to ask!
- jcadam 9y ago
  Right, jQuery is good and mature, and I can usually find what I need in the documentation. It will never die. I don't use jQuery by itself these days, of course. I'm using it in combination with mithril.js (not as popular as React, but similar in concept) at the moment.
  - puobelle 9y ago
    https://www.reddit.com/r/programmingcirclejerk/comments/7q81bv/i_dont_use_jquery_by_itself_these_days_of_course/ https://www.reddit.com/r/programmingcirclejerk/comments/7q81...
- iambateman 9y ago
  This intuitively makes sense, but I'd like to see some control data. Has the volume of PHP questions (for example) fluctuated much over time?
  - itcmcgrath 9y ago
    http://sotagtrends.com/?tags=[jquery,python]&relative=false http://sotagtrends.com/?tags=[jquery,python]&relative=false
    - emodendroket 9y ago
      That seems like a pretty compelling counterpoint.
- emodendroket 9y ago
  Looking at the regex tag would suggest this logic doesn't necessarily hold.
- collyw 9y ago
  Surely they could have used the number of times questions were viewed rather than asked.
- lettergram 9y ago
  Indeed! In fact, after I spent time using react and angular for two separate products, I actually switched back to mostly rolling my own JQuery (usually). It just works, and takes up much less of my mindshare than trying to learn various frameworks every time I roll a new site (which incidentally is every 3 - 6 months). There is always more support for it (with all the questions being answered), and the API never changes. I actually develop faster, although typically I’m using web frameworks with templating backends - such as Rails (Ruby), Django (Python), Flask (Python), and Revel (Go)
  - jamra 9y ago
    I did that on a product as well. It went pretty well. The issue is with more complicated UI. The more complicated it is, the faster JQuery breaks down. That being said, it's better to have a bit of a spaghetti JQuery than to try and retrain unwilling programmers in Angular.
    - mythrwy 9y ago
      jQuery doesn't have to be spaghetti though. It gets that rap I think because most people that used it weren't good/experienced enough to organize bigger code. It can/usually does turn into a mess though but is faster to bang small things out in for me anyway.
      - jamra 9y ago
        It doesn’t have to be spaghetti. You are right. However, when you change state in multiple places, they either have to be aware of each other or you need some kind of state management. The benefit of libraries like React are that they abstract view rendering and take care of DOM diffing. The benefit of frameworks like Angular is that it manages state in addition to what React does. On simpler projects, JQuery is more productive. But my main point is to program where it is comfortable and practical. The better academic choice is not necessarily the better choice. View your programming resources as people and make the pragmatic choice.
- codingdave 9y ago
  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 just isn't so needed. The same path is likely on all frameworks - they were designed to solve specific use cases, and as the entire industry matures, different solutions will embed themselves in the industry in different ways, reducing the raison d'etre for each framework, over time.
  - deleted 9y ago
    [deleted]
  - shams93 9y ago
    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.
    - eitland 9y ago
      > It can be done but it's brutal and fragile. Actually many who did jQuery were proud of it. Some of us made rock solid sites or improved exiting ones quite a bit using a technology known as progressive enhancement. Let me tell you what is fragile: the cool things I make today that won't even try to work if I disable Javascript. :-) Edit: and given what we have seen over the last few days now would be a good time to reconsider if every website really needs to be able to run Javascript.
      - djroomba 9y ago
        I miss progressive enhancement, when/why did it die.
        bronson 9y ago
        Did progressive enhancement ever catch on? It made for some great Rails 2 tutorials but I don't remember seeing it much in the wild. It's going away because you basically have to write everything twice and it's hell to keep consistent.
- itcmcgrath 9y ago
  "Of course there's going to be less questions" Yet there are counter examples that show that can't be the complete story: http://sotagtrends.com/?tags=[jquery,python]&relative=false http://sotagtrends.com/?tags=[jquery,python]&relative=false
  - dmitriid 9y ago
    You could argue that jQuery covers handling (a part of) DOM APIs which are updated only rarely. Once you know what $().append().on().trigger() does, there's not that much left to know about jQuery. And most everything can be understood from docs. Python, however, is a continuously evolving language with an ever expanding number of libraries and areas of application.
    - kbenson 9y ago
      Python is just an outlier when looking at this. Here's[1] a larger set of languages and frameworks, and given the premise it's not hard to guess the JS frameworks from the graph. 1: http://sotagtrends.com/?tags=[jquery,angularjs,c,c%2B%2B,ruby,javascript]&relative=true http://sotagtrends.com/?tags=[jquery,angularjs,c,c%2B%2B,rub...
- myth_drannon 9y ago
  StackOverflow's job posts show the same trend. Jquery is required less and less http://www.reallyhyped.com/?keywords=angularjs%2Creactjs%2Cjquery http://www.reallyhyped.com/?keywords=angularjs%2Creactjs%2Cj...
  - lakechfoma 9y ago
    But again probably less <this is losing popularity> and more <this is no longer cool to tag>. That's a really nice tool though
    - myth_drannon 9y ago
      That's a possible explanation too. No one wants to say that the job is mostly maintaining large Angular codebase in addition to a small internal tool written in React that only senior stuff is allowed to play with...But hey we are a React shop!
  - Kajayacht 9y ago
    I think part of that is that jQuery is pretty universal and it's probably assumed that if someone says they know JavaScript, they know jQuery. Or, I at least assume that when I'm doing interviews.
    - myth_drannon 9y ago
      I think that would apply more to an Html than Jquery
- qaq 9y ago
  Very good point and this obviously can skew the results greatly. Working in a fairly senior mid-size team I don't remember any of my colleagues asking any question on SO either so results could be also skewed by composition of user base and how good the docs are for a given proj.
- Cthulhu_ 9y ago
  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.
  - wwweston 9y ago
    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.
- jonnycomputer 9y ago
  ha, i came here to say this. I'd rather see web traffic results.
mkern 9y ago
The PHP and Vue correlation can at least partly be explained by the fact that Laravel, a popular PHP web framework, has first-hand support for Vue and installs Vue by default in projects bootstrapped with their cli tool.
- progx 9y ago
  WordPress.com But Vues triumphal march starts before Laravel or WordPress.
  - dktp 9y ago
    My understanding is that this tweet https://twitter.com/taylorotwell/status/590281695581982720?lang=en https://twitter.com/taylorotwell/status/590281695581982720?l... kickstarted the Vue popularity. Taylor Otwell is the creator of Laravel. Here's Evan You (creator of Vue) https://youtu.be/D_z-RAweP1k?t=3m9s https://youtu.be/D_z-RAweP1k?t=3m9s talking about the tweet.
  - claudiulodro 9y ago
    WordPress.com uses React[1] and the new WordPress CMS Gutenberg[2] editor is also using React. (Just FYI) [1] https://github.com/Automattic/wp-calypso https://github.com/Automattic/wp-calypso [2] https://github.com/WordPress/gutenberg https://github.com/WordPress/gutenberg
rwbcxrz 9y ago
> PHP developers [...] visit a disproportionate amount of Vue.js questions. I would guess this is because the installer for Laravel (one of the most popular PHP frameworks) defaults to scaffolding a Vue.js app for your frontend.
cies 9y ago
Remember that Merb was merged into Rails? That's a community converging, that's what brought Ruby to the point that it is recruiter-speak synonymous to Rails. In the JS world: not so much. But that prolly has many reasons. I can think of: the language changing rapidly, the community not very "close", people coming to JS from widely different places, and the fact that a JS framework can span either the FE or the BE or both!
- scottmf 9y ago
  io.js?
  - cies 9y ago
    Yups. Nice one!
rplnt 9y ago
The JavaScript/jQuery community (no difference from outside) was absolutely cancerous. It was impossible to find a javascript question that didn't include top answer "In jQuery...". Makes my blood boil just thinking about it years later. I wonder what effect this has on usage. How likely are new developers to use it if virtually every question they have is answered by this (no matter how irrelevant the answer should be today).
- bigmanwalter 9y ago
  To be fair, that's because the jQuery solution was usually orders of magnitude simpler. Although newer versions of javascript have absorbed enough of the jQuery api that this is no longer the case.
  - rplnt 9y ago
    Acceptable way would be "Hey, it's done like this, but since the language sucks there's this random library where you can do it this way". Including jQuery for one small task would be stupid. Including jQuery in a non-web project would be weird. Including jQuery in some es variants would be impossible.
    - bigmanwalter 9y ago
      At that time, javascript was used exclusively for client-side web development. It was pretty much impossible to write ajax requests in any sane fashion that worked cross-browser. It's not such a stretch to assume the user asking the question could use jQuery.
      - rplnt 9y ago
        The first part is not true. And while I agree with the second, I'm talking about general language questions not related to web in any way (no DOM manipulation, no http requests, etc..).
- dictum 9y ago
  The contemporary equivalent, albeit one or a few steps up the abstraction ladder, is "how to get started with (javascript|frontend development)" guides — append "in 2018" for better SEO — which boil down to "use React".
scotchio 9y ago
Woah... Was honestly surprised to see Vue.js was so tiny in comparison to Ang and React regarding "% of Stack Overflow questions that month". I thought it was much bigger
- kozhevnikov 9y ago
  Vue.js has a spectacular tutorial that answers most if not all questions one might have about the framework.
  - deleted 9y ago
    [deleted]
- romanovcode 9y ago
  As much as it is praised in HN it is not that much adopted compared to Angular or React in the real world.
- progx 9y ago
  Good documentation and you did not need to ask so many questions.
- werber 9y ago
  You also have to take into consideration that the Vue community has the most Chinese devs of the JS SPA contenders and that might be reflected super well by SO data.
- seangrogg 9y ago
  Maybe this should serve as a reminder that the HN bubble is not at all representative of the web development community at large nor it's membership a strong indicator of the community's sentiment.
- rk06 9y ago
  Angular and react are used by more devs than Vue. also keep in mind that Angular is complex enough to warrant 10x more questions. and React community, has done a lot of RnD in areas like flux, graphql, cssInJs etc. hence they too would have more questions.
lakechfoma 9y ago
Why is the measurement on questions asked for the first couple of graphs and then user traffic for the latter set? I wonder if traffic is the better measurement for the first two as well but I bet the graphs won't look quite as doom and gloom.
- var_explained 9y ago
  The first few graphs use the interactive [Stack Overflow Trends](http://insights.stackoverflow.com/trends http://insights.stackoverflow.com/trends) tool, which is all public data. This is useful since it lets readers modify the graphs (for example, to add a few more tags to the comparison). The later graphs use data that's already not public (what tags users visit together, and what countries tags are visited from), so there's no reason not to use visits instead. The graphs for visits over time do look very similar (in general question traffic by tag roughly matches questions asked, but as a slightly lagging indicator)
mkirklions 9y ago
About to make an App using React(and react native?) Up until this point, I usually would make most things from scratch and pull in libraries sparce. No big deal because my previous programs didnt need to. (Self taught programmer for 11 years.) For the next 3 months, I'll be working on this almost alone. Is it worth using some of my resources to hire a React developer? Also, this topic implies React will be gone in about ~5 years? That sounds good for me.
- dentemple 9y ago
  React's API is fairly small. Most of the code you're writing with React (outside of libraries) is based on ES6. You can easily get by with someone that has years of Javascript experience instead, preferably a developer who's familiar with Functional-style JS.
- brentm 9y ago
  I would learn React if I was you. Check out create-react-app on Github. It will set you up with a working app to play with in a matter of seconds. If you're expecting to use React Native it looks like they have a create-react-native-app also.
  - bvm 9y ago
    and don't eject until you really need to! CRA is fantastic and surprisingly extensible.
  - mkirklions 9y ago
    Right now I'm stuck working on getting SDKs installed. I got my android app running which was easy after all the installs and updates. Now I'm doing some weird command line stuff to try to get my Javascript server to wake up. Changing ports, more SDK updates, etc... Changing my App.js doesnt update, except if I turn everything off and back on again.
- ashark 9y ago
  > Up until this point, I usually would make most things from scratch and pull in libraries sparce. No big deal because my previous programs didnt need to. (Self taught programmer for 11 years.) You can still do this with React. Some of the most-common general-purpose libraries for working with React aren't that big and could be written from scratch pretty easily. If you recognize when something's entire purpose is apparently to replicate OO features while staying "purely" functional by jumping through a series of awkward hoops, you can recall that the language you're writing in does, in fact, support OOP, and avoid the library altogether by using built-in language features (I keep seeing this in the React ecosystem and it drives me nuts). Probably use Redux because everyone and everything expects that you are. It's easy to understand if you ignore their bad terminology and go in knowing it's just an event/messaging system, more or less. Action = event. "Action creator" = anything that dispatches an event. Reducer = your event handlers. Exactly what you'd expect from an event system with centralized event handling. Utterly mundane and non-magical. Figure out how to leverage "combineReducers" to keep your file structure sane and just go. The closest thing it has to magic going on is that when an event comes through it checks to see whether any of the refs in your "state tree" changed as a result of that event, and triggers re-renders on relevant connected view(s) (React views, in your case). That's it. Note that with a very little creativity one can decouple one's Redux code and most/all of one's business logic into its own library to share it between React and React Native. If you use React Native, you're in for a treat if you're used to fully native cross-platform dev. It really does a great job of rounding off the many, many rough corners on Android that make it such a pain-in-the-ass to work with. Warning: the ecosystem's kinda nutty and does a bad job of keeping in sync, so avoid dependencies that directly target React Native as much as possible if you want to ever be able to, say, upgrade your React Native version without breaking everything. Pure JS libs that have no truck with React Native, good. Libs that add narrowly-scoped extra native integration for RN, usually good. Mostly JS libs that add on to React Native itself, typically just a disaster waiting to happen, no matter how nice they seem at first. Oh, and use Typescript. For the love of god use Typescript. Just start the project with it, and never look back.
kuon 9y ago
I moved my frontend (I mean "in browser" by that) dev to elm about a year ago, and it's been a year of peace. I know elm has flaws, and it's development workflow can be criticized for being too slow or conservative, but it's been so predictable, so easy to work with, so maintainable and so solid in production, I have never been so happy about frontend dev.
mattmanser 9y ago
As an aside from the interesting article, does any one else find it pretty scary and privacy invading that stackoverflow think it's ok to match our IP addresses to the company we work in? It seems like a massive invasion of privacy (which I guess lots of websites are doing). But to me that SO can so casually mention the mass surveillance and privacy invasion they're doing without thinking that there's anything wrong with it is the worst part of it. I certainly never knowingly agreed that they could check my IP address and then try and figure out what company I work at from it. EDIT: Once GDPR is live in the EU, I think it might be interesting to see if I can challenge this privacy invasion and inappropriate use of personally identifying data. I guess we'll see if GDPR has any actual teeth in this instance.
- dasil003 9y ago
  Does SO operate in the EU?
  - mattmanser 9y ago
    They don't block EU users, so they do business in the EU. As it offers goods and services to EU citizens, it has to operate according to GDPR as far as I understand it. And it does do sales in the EU, there are plenty of SO jobs being advertized (and paid for) in the EU.
    - dasil003 9y ago
      I know GDPR is written this way, the question is how it will be enforced? If SO has no operations in the EU, and it's literally just take EUR payments, and the volume is relatively small (or they figure out some offshore processing hack) then they could make the decision to stop processing EUR and give GDPR the middle finger. That's a lot of ifs, but it's not a foregone conclusion that European markets are worth the GDPR headache.
      - mattmanser 9y ago
        No, they'd have to block the whole of the EU from accessing the site.
catpolice 9y ago
I always have to show up to reiterate this is not a problem limited to Javascript. There have been framework fads for as long as there have been frameworks. I have dim memories of dozens of C++/Java/Python/Ruby/etc. next-big-things. It does seem like there are more of them and they rise and fall faster in the Javascript world, but this is probably better explained by the sheer number of Javascript programmers than anything else. The labor statistics I can find peg the number of US software developers in 2002 at around 612,000 and around 3.87 million in 2016 - and most of the new ones focus on web development. There are way more web programmers out there than there have really ever been, so it makes sense that the rate of frameworks appearing (and to a degree, the overall lifecycle churn) would be accelerated.
- pjmlp 9y ago
  > I have dim memories of dozens of C++/Java/Python/Ruby/etc. next-big-things. While true, none of them have changed so quickly as JavaScript ones, which seem driven by devs eager to create portfolios on Github.
  - Can_Not 9y ago
    > which seem driven by devs eager to create portfolios on Github. Is this supported by any facts? It seems like a hand-wavey hasty generalization.
    - pjmlp 9y ago
      The increasing trend of startups asking for Github accounts on their job offers. You just need to search on job boards.
Sawamara 9y ago
It is not really a brutal lifecycle at all, to be honest. Everyone loves a good rant about how fast the JS frameworks burn out, but it is not frameworks that burn out, but rather: In the 8+ years since Iphone/Android duo made a HUGE change in how we consume web content, we went from: - Having static resolution for websites to dynamically changing site resolutions - Having static HTML renders with some dynamic bits sprinkled over to full-blown SPA-s because of a variety of reasons* - Having major new JavaScript versions and INSANE amounts of Javascript engine speedups that allow things that were unimaginable 8+ years ago - Having gone from "nothing" to a CPU-based <canvas> to a full OpenGL ES-implementation, full GPU-based (<webGL>), - Had went from procedural code to semi-class based systems towards functional towards functional reactive programming systems And I could go on and on and on and on. The DOM api matured during these years. The renderers got replaced. Their performance altered dramatically. Layouts went from "JUST USE TABLES" towards CSS, then towards Compile-to-css alternatives, etc. Single-core event systems got SharedArrayBuffers, webWorkers, we got from callbacks to promises, towards async/await. And do not get me started on almost getting observables properly. The web has seen more transformations in terms of what is an "app" or a "website" in 8-10 years than ANY OTHER area in programming. It is only natural that widely different tasks need widely different tools to work with.
- webDevSucks 9y ago
  > And I could go on and on and on and on. True, it's enough to say "websites became big and slow". Additionally you can say "now we are after cross-platform native apps - set money aside for a device upgrade".
- Klathmon 9y ago
  (heads up, you need have a blank space between lines in HN to render them on different lines) I completely agree. Many people claim the web is overly complex, but then go back into the C++ world where you need a build tool to build your makefile which builds your project using cross compilation on a handful of platforms. I like to remind people that 10 years ago Android didn't exist, streaming video was still only just becoming a thing, and the iPhone had just been released and wouldn't have an "app store" for another 6 months. There have been several massive changes to the web and to computers and how we use them in that time. It only makes sense that we will use different frameworks and paradigms to create applications.
baybal2 9y ago
I thank YUI and later jQuery for getting me my first real software development job. Today it looks surreal that a mere portfolio of mind boggling animation effects would be enough to get a 21 year old an $84k job, but back in the time of peak web 2.0 craze, just having words jquery and 3 years experience on your resume was just enough to get 3 to 4 calls with ready offers every month.
nailer 9y ago
Why are 'angular' and 'angular.js' seperate tags?
- tboyd47 9y ago
  AngularJS refers to major version 1, Angular refers to 2.
  - nailer 9y ago
    Wow. That's really unintuitive.
    - jedwardhawkins 9y ago
      I agree with the sentiment. Most people view them as distinct frameworks. I believe the use of the name Angular for major version 2+ helped retain a lot of users. I've seen a lot of uninformed devs and managers assume that because they already have so much code in AngularJS that Angular is the next logical tool for their team to use.
- _greim_ 9y ago
  Presumably that reflects the 1.x / 2.x split. They're arguably different enough to be treated as separate frameworks.
_greim_ 9y ago
> Stack Overflow Trends lets us examine how each of these technologies has been asked about over time. So what are we measuring here? It seems obvious that more popular frameworks would generate more questions, but so would: - Newer ones which not as many people are familiar with. - Poorly-designed ones which lots of people nevertheless use. - Ones which disproportionately attract inexperienced devs.
larrik 9y ago
Alternative hypothesis: Brand new frameworks have zero docs and zero questions in Stack Overflow. Older frameworks have (hopefully) complete docs and a library of SO questions. In between you get a gradient. I'm just not convinced that the data they're looking at means what they think it means.
ToJans 9y ago
IME Vue is so well designed, that I hardly have any issues with it. If I do, my go-to reference is the official documentation. You shouldn't base your usage assumptions on the amount of questions asked; Vue just doesn't require so many questions...
- FLGMwt 9y ago
  Ditto for React. Pretty much every "how do I do this" is covered in the official tutorial and every "how should I do this" is covered by supplemental guides (still official docs). Some good ones: "thinking in React", "lifting state up", "controlled components", and similar docs in redux: "you might not need redux"
rodolphoarruda 9y ago
Pretty much a Gartner's Hype Curve like behaviour on each case. Accelerated adoption, a peak, then delusion kicks in causing many people to lose interest and step away from the technology. Late adopters find lower barriers of entry later on caused by lessons learned and improvements made to the same technology. Usage increases again but a lower level when compared to the initial peak. Expectations around tech's capabilities are now more concrete and realistic, bringing stability to the ecosystem as a whole.
systematical 9y ago
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?
lolive 9y ago
My 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 ?
- pjmlp 9y ago
  That could be the idea, but currently it seems Angular devs are more open to that idea, given that WebComponents are mostly driven by Google. https://summit.polymer-project.org/ https://summit.polymer-project.org/ https://developer.chrome.com/devsummit/ https://developer.chrome.com/devsummit/ You can some components here, as well as, the current state of browser support. https://www.webcomponents.org/ https://www.webcomponents.org/ Currently only HTML Imports seem to be a point of disagreement. I am looking forward to them, as they can be the way for more sanity on Web development.
mixonic 9y ago
The 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.
- simonsarris 9y ago
  I think this is the most important takeaway. It's especially true for smaller libraries and commercial libraries. And even for huge ones like Rails, questions answered 6 years ago might be little more than a catalog of improper practices by now! For a hard numbers example of "trends" being poor, I develop a JavaScript diagramming library, GoJS: https://gojs.net https://gojs.net It has competition, such as JointJS, jsPlumb, etc. If I look at StackOverflow tags, I would think we're in big trouble: * 180 questions tagged gojs * 449 questions tagged jointjs * 518 questions tagged jsplumb These aren't even enough to show up on StackOverflow's trend tool, and they make the case look pretty dire for GoJS! But behold, Google trends: https://trends.google.com/trends/explore?date=all&q=gojs,jointjs,jsplumb https://trends.google.com/trends/explore?date=all&q=gojs,joi... (ignore the last, partial-data month) In search interest GoJS is clearly ahead of these other two libraries. What's more, if you compare the forums for each product, you'd see that GoJS gets 10x-100x the traffic of the others. StackOverflow is simply not the a good place to gauge library interest and activity over the long term, and its not a good place as you say to ask or find answers to questions for products that have ecosystems which continuously improve their APIs and evolve.
watsocd 9y ago
Just 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.
drderidder 9y ago
It's easy to see graphs trending down and say, oh, interest is waning. But the initial spike could just be lots people going through a learning curve. It tells you something about popularity, but ease-of-use, quality of docs, etc. must all factor in as well. I tend to see the high number of questions on certain frameworks as a red flag.
simooooo 9y ago
Knockout isn't a Microsoft technology

224 points by lainon 9y ago

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

slig 9y ago
Agreed. It'd be nice to have graphed the number of pageviews of each tag as well.
- Waterluvian 9y ago
  Just made me think about a great metric as a developer: understanding how popular each SO page is about your library. Ie. "X is still catching up everyone, it's a very busy page. We have done a good job making Y more obvious, people aren't searching for it anymore."
aalleavitch 9y ago
Yeah, it’s not like these sites have stopped using jquery altogether: my site uses React components but I still write a couple lines of jquery here and there for basic uses.
nicoburns 9y ago
Yep! Same for React. It has a much smaller API surface area than Angular (and goes wrong it mysterious ways less often!), so fewer people will be asking questions about it. From my perspective, it appears that React is still very much in ascendancy.
- jsight 9y ago
  The chart seemed to show React to be growing very quickly as well.
- dentemple 9y ago
  From my anecdotal experience of just watching SO's React queue, most questions about React that show up (that aren't repeats) are almost always regarding how it's used with some library in the ecosystem. React-router, Redux, Webpack, Material UI, etc. So even though the API itself small, there's still an endless number of questions out there for people to ask!
jcadam 9y ago
Right, jQuery is good and mature, and I can usually find what I need in the documentation. It will never die. I don't use jQuery by itself these days, of course. I'm using it in combination with mithril.js (not as popular as React, but similar in concept) at the moment.
- puobelle 9y ago
  https://www.reddit.com/r/programmingcirclejerk/comments/7q81bv/i_dont_use_jquery_by_itself_these_days_of_course/ https://www.reddit.com/r/programmingcirclejerk/comments/7q81...
iambateman 9y ago
This intuitively makes sense, but I'd like to see some control data. Has the volume of PHP questions (for example) fluctuated much over time?
- itcmcgrath 9y ago
  http://sotagtrends.com/?tags=[jquery,python]&relative=false http://sotagtrends.com/?tags=[jquery,python]&relative=false
  - emodendroket 9y ago
    That seems like a pretty compelling counterpoint.
emodendroket 9y ago
Looking at the regex tag would suggest this logic doesn't necessarily hold.
collyw 9y ago
Surely they could have used the number of times questions were viewed rather than asked.
lettergram 9y ago
Indeed! In fact, after I spent time using react and angular for two separate products, I actually switched back to mostly rolling my own JQuery (usually). It just works, and takes up much less of my mindshare than trying to learn various frameworks every time I roll a new site (which incidentally is every 3 - 6 months). There is always more support for it (with all the questions being answered), and the API never changes. I actually develop faster, although typically I’m using web frameworks with templating backends - such as Rails (Ruby), Django (Python), Flask (Python), and Revel (Go)
- jamra 9y ago
  I did that on a product as well. It went pretty well. The issue is with more complicated UI. The more complicated it is, the faster JQuery breaks down. That being said, it's better to have a bit of a spaghetti JQuery than to try and retrain unwilling programmers in Angular.
  - mythrwy 9y ago
    jQuery doesn't have to be spaghetti though. It gets that rap I think because most people that used it weren't good/experienced enough to organize bigger code. It can/usually does turn into a mess though but is faster to bang small things out in for me anyway.
    - jamra 9y ago
      It doesn’t have to be spaghetti. You are right. However, when you change state in multiple places, they either have to be aware of each other or you need some kind of state management. The benefit of libraries like React are that they abstract view rendering and take care of DOM diffing. The benefit of frameworks like Angular is that it manages state in addition to what React does. On simpler projects, JQuery is more productive. But my main point is to program where it is comfortable and practical. The better academic choice is not necessarily the better choice. View your programming resources as people and make the pragmatic choice.
codingdave 9y ago
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 just isn't so needed. The same path is likely on all frameworks - they were designed to solve specific use cases, and as the entire industry matures, different solutions will embed themselves in the industry in different ways, reducing the raison d'etre for each framework, over time.
- deleted 9y ago
  [deleted]
- shams93 9y ago
  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.
  - eitland 9y ago
    > It can be done but it's brutal and fragile. Actually many who did jQuery were proud of it. Some of us made rock solid sites or improved exiting ones quite a bit using a technology known as progressive enhancement. Let me tell you what is fragile: the cool things I make today that won't even try to work if I disable Javascript. :-) Edit: and given what we have seen over the last few days now would be a good time to reconsider if every website really needs to be able to run Javascript.
    - djroomba 9y ago
      I miss progressive enhancement, when/why did it die.
      - bronson 9y ago
        Did progressive enhancement ever catch on? It made for some great Rails 2 tutorials but I don't remember seeing it much in the wild. It's going away because you basically have to write everything twice and it's hell to keep consistent.
itcmcgrath 9y ago
"Of course there's going to be less questions" Yet there are counter examples that show that can't be the complete story: http://sotagtrends.com/?tags=[jquery,python]&relative=false http://sotagtrends.com/?tags=[jquery,python]&relative=false
- dmitriid 9y ago
  You could argue that jQuery covers handling (a part of) DOM APIs which are updated only rarely. Once you know what $().append().on().trigger() does, there's not that much left to know about jQuery. And most everything can be understood from docs. Python, however, is a continuously evolving language with an ever expanding number of libraries and areas of application.
  - kbenson 9y ago
    Python is just an outlier when looking at this. Here's[1] a larger set of languages and frameworks, and given the premise it's not hard to guess the JS frameworks from the graph. 1: http://sotagtrends.com/?tags=[jquery,angularjs,c,c%2B%2B,ruby,javascript]&relative=true http://sotagtrends.com/?tags=[jquery,angularjs,c,c%2B%2B,rub...
myth_drannon 9y ago
StackOverflow's job posts show the same trend. Jquery is required less and less http://www.reallyhyped.com/?keywords=angularjs%2Creactjs%2Cjquery http://www.reallyhyped.com/?keywords=angularjs%2Creactjs%2Cj...
- lakechfoma 9y ago
  But again probably less <this is losing popularity> and more <this is no longer cool to tag>. That's a really nice tool though
  - myth_drannon 9y ago
    That's a possible explanation too. No one wants to say that the job is mostly maintaining large Angular codebase in addition to a small internal tool written in React that only senior stuff is allowed to play with...But hey we are a React shop!
- Kajayacht 9y ago
  I think part of that is that jQuery is pretty universal and it's probably assumed that if someone says they know JavaScript, they know jQuery. Or, I at least assume that when I'm doing interviews.
  - myth_drannon 9y ago
    I think that would apply more to an Html than Jquery
qaq 9y ago
Very good point and this obviously can skew the results greatly. Working in a fairly senior mid-size team I don't remember any of my colleagues asking any question on SO either so results could be also skewed by composition of user base and how good the docs are for a given proj.
Cthulhu_ 9y ago
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.
- wwweston 9y ago
  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.
jonnycomputer 9y ago
ha, i came here to say this. I'd rather see web traffic results.

mkern 9y ago

The PHP and Vue correlation can at least partly be explained by the fact that Laravel, a popular PHP web framework, has first-hand support for Vue and installs Vue by default in projects bootstrapped with their cli tool.

progx 9y ago
WordPress.com But Vues triumphal march starts before Laravel or WordPress.
- dktp 9y ago
  My understanding is that this tweet https://twitter.com/taylorotwell/status/590281695581982720?lang=en https://twitter.com/taylorotwell/status/590281695581982720?l... kickstarted the Vue popularity. Taylor Otwell is the creator of Laravel. Here's Evan You (creator of Vue) https://youtu.be/D_z-RAweP1k?t=3m9s https://youtu.be/D_z-RAweP1k?t=3m9s talking about the tweet.
- claudiulodro 9y ago
  WordPress.com uses React[1] and the new WordPress CMS Gutenberg[2] editor is also using React. (Just FYI) [1] https://github.com/Automattic/wp-calypso https://github.com/Automattic/wp-calypso [2] https://github.com/WordPress/gutenberg https://github.com/WordPress/gutenberg

rwbcxrz 9y ago

> PHP developers [...] visit a disproportionate amount of Vue.js questions. I would guess this is because the installer for Laravel (one of the most popular PHP frameworks) defaults to scaffolding a Vue.js app for your frontend.

cies 9y ago

Remember that Merb was merged into Rails? That's a community converging, that's what brought Ruby to the point that it is recruiter-speak synonymous to Rails. In the JS world: not so much. But that prolly has many reasons. I can think of: the language changing rapidly, the community not very "close", people coming to JS from widely different places, and the fact that a JS framework can span either the FE or the BE or both!

scottmf 9y ago
io.js?
- cies 9y ago
  Yups. Nice one!

rplnt 9y ago

The JavaScript/jQuery community (no difference from outside) was absolutely cancerous. It was impossible to find a javascript question that didn't include top answer "In jQuery...". Makes my blood boil just thinking about it years later. I wonder what effect this has on usage. How likely are new developers to use it if virtually every question they have is answered by this (no matter how irrelevant the answer should be today).

bigmanwalter 9y ago
To be fair, that's because the jQuery solution was usually orders of magnitude simpler. Although newer versions of javascript have absorbed enough of the jQuery api that this is no longer the case.
- rplnt 9y ago
  Acceptable way would be "Hey, it's done like this, but since the language sucks there's this random library where you can do it this way". Including jQuery for one small task would be stupid. Including jQuery in a non-web project would be weird. Including jQuery in some es variants would be impossible.
  - bigmanwalter 9y ago
    At that time, javascript was used exclusively for client-side web development. It was pretty much impossible to write ajax requests in any sane fashion that worked cross-browser. It's not such a stretch to assume the user asking the question could use jQuery.
    - rplnt 9y ago
      The first part is not true. And while I agree with the second, I'm talking about general language questions not related to web in any way (no DOM manipulation, no http requests, etc..).
dictum 9y ago
The contemporary equivalent, albeit one or a few steps up the abstraction ladder, is "how to get started with (javascript|frontend development)" guides — append "in 2018" for better SEO — which boil down to "use React".

scotchio 9y ago

Woah... Was honestly surprised to see Vue.js was so tiny in comparison to Ang and React regarding "% of Stack Overflow questions that month". I thought it was much bigger

kozhevnikov 9y ago
Vue.js has a spectacular tutorial that answers most if not all questions one might have about the framework.
- deleted 9y ago
  [deleted]
romanovcode 9y ago
As much as it is praised in HN it is not that much adopted compared to Angular or React in the real world.
progx 9y ago
Good documentation and you did not need to ask so many questions.
werber 9y ago
You also have to take into consideration that the Vue community has the most Chinese devs of the JS SPA contenders and that might be reflected super well by SO data.
seangrogg 9y ago
Maybe this should serve as a reminder that the HN bubble is not at all representative of the web development community at large nor it's membership a strong indicator of the community's sentiment.
rk06 9y ago
Angular and react are used by more devs than Vue. also keep in mind that Angular is complex enough to warrant 10x more questions. and React community, has done a lot of RnD in areas like flux, graphql, cssInJs etc. hence they too would have more questions.

lakechfoma 9y ago

Why is the measurement on questions asked for the first couple of graphs and then user traffic for the latter set? I wonder if traffic is the better measurement for the first two as well but I bet the graphs won't look quite as doom and gloom.

var_explained 9y ago
The first few graphs use the interactive [Stack Overflow Trends](http://insights.stackoverflow.com/trends http://insights.stackoverflow.com/trends) tool, which is all public data. This is useful since it lets readers modify the graphs (for example, to add a few more tags to the comparison). The later graphs use data that's already not public (what tags users visit together, and what countries tags are visited from), so there's no reason not to use visits instead. The graphs for visits over time do look very similar (in general question traffic by tag roughly matches questions asked, but as a slightly lagging indicator)

mkirklions 9y ago

About to make an App using React(and react native?) Up until this point, I usually would make most things from scratch and pull in libraries sparce. No big deal because my previous programs didnt need to. (Self taught programmer for 11 years.) For the next 3 months, I'll be working on this almost alone. Is it worth using some of my resources to hire a React developer? Also, this topic implies React will be gone in about ~5 years? That sounds good for me.

dentemple 9y ago
React's API is fairly small. Most of the code you're writing with React (outside of libraries) is based on ES6. You can easily get by with someone that has years of Javascript experience instead, preferably a developer who's familiar with Functional-style JS.
brentm 9y ago
I would learn React if I was you. Check out create-react-app on Github. It will set you up with a working app to play with in a matter of seconds. If you're expecting to use React Native it looks like they have a create-react-native-app also.
- bvm 9y ago
  and don't eject until you really need to! CRA is fantastic and surprisingly extensible.
- mkirklions 9y ago
  Right now I'm stuck working on getting SDKs installed. I got my android app running which was easy after all the installs and updates. Now I'm doing some weird command line stuff to try to get my Javascript server to wake up. Changing ports, more SDK updates, etc... Changing my App.js doesnt update, except if I turn everything off and back on again.
ashark 9y ago
> Up until this point, I usually would make most things from scratch and pull in libraries sparce. No big deal because my previous programs didnt need to. (Self taught programmer for 11 years.) You can still do this with React. Some of the most-common general-purpose libraries for working with React aren't that big and could be written from scratch pretty easily. If you recognize when something's entire purpose is apparently to replicate OO features while staying "purely" functional by jumping through a series of awkward hoops, you can recall that the language you're writing in does, in fact, support OOP, and avoid the library altogether by using built-in language features (I keep seeing this in the React ecosystem and it drives me nuts). Probably use Redux because everyone and everything expects that you are. It's easy to understand if you ignore their bad terminology and go in knowing it's just an event/messaging system, more or less. Action = event. "Action creator" = anything that dispatches an event. Reducer = your event handlers. Exactly what you'd expect from an event system with centralized event handling. Utterly mundane and non-magical. Figure out how to leverage "combineReducers" to keep your file structure sane and just go. The closest thing it has to magic going on is that when an event comes through it checks to see whether any of the refs in your "state tree" changed as a result of that event, and triggers re-renders on relevant connected view(s) (React views, in your case). That's it. Note that with a very little creativity one can decouple one's Redux code and most/all of one's business logic into its own library to share it between React and React Native. If you use React Native, you're in for a treat if you're used to fully native cross-platform dev. It really does a great job of rounding off the many, many rough corners on Android that make it such a pain-in-the-ass to work with. Warning: the ecosystem's kinda nutty and does a bad job of keeping in sync, so avoid dependencies that directly target React Native as much as possible if you want to ever be able to, say, upgrade your React Native version without breaking everything. Pure JS libs that have no truck with React Native, good. Libs that add narrowly-scoped extra native integration for RN, usually good. Mostly JS libs that add on to React Native itself, typically just a disaster waiting to happen, no matter how nice they seem at first. Oh, and use Typescript. For the love of god use Typescript. Just start the project with it, and never look back.

kuon 9y ago

I moved my frontend (I mean "in browser" by that) dev to elm about a year ago, and it's been a year of peace. I know elm has flaws, and it's development workflow can be criticized for being too slow or conservative, but it's been so predictable, so easy to work with, so maintainable and so solid in production, I have never been so happy about frontend dev.

mattmanser 9y ago

As an aside from the interesting article, does any one else find it pretty scary and privacy invading that stackoverflow think it's ok to match our IP addresses to the company we work in? It seems like a massive invasion of privacy (which I guess lots of websites are doing). But to me that SO can so casually mention the mass surveillance and privacy invasion they're doing without thinking that there's anything wrong with it is the worst part of it. I certainly never knowingly agreed that they could check my IP address and then try and figure out what company I work at from it. EDIT: Once GDPR is live in the EU, I think it might be interesting to see if I can challenge this privacy invasion and inappropriate use of personally identifying data. I guess we'll see if GDPR has any actual teeth in this instance.

dasil003 9y ago
Does SO operate in the EU?
- mattmanser 9y ago
  They don't block EU users, so they do business in the EU. As it offers goods and services to EU citizens, it has to operate according to GDPR as far as I understand it. And it does do sales in the EU, there are plenty of SO jobs being advertized (and paid for) in the EU.
  - dasil003 9y ago
    I know GDPR is written this way, the question is how it will be enforced? If SO has no operations in the EU, and it's literally just take EUR payments, and the volume is relatively small (or they figure out some offshore processing hack) then they could make the decision to stop processing EUR and give GDPR the middle finger. That's a lot of ifs, but it's not a foregone conclusion that European markets are worth the GDPR headache.
    - mattmanser 9y ago
      No, they'd have to block the whole of the EU from accessing the site.

catpolice 9y ago

I always have to show up to reiterate this is not a problem limited to Javascript. There have been framework fads for as long as there have been frameworks. I have dim memories of dozens of C++/Java/Python/Ruby/etc. next-big-things. It does seem like there are more of them and they rise and fall faster in the Javascript world, but this is probably better explained by the sheer number of Javascript programmers than anything else. The labor statistics I can find peg the number of US software developers in 2002 at around 612,000 and around 3.87 million in 2016 - and most of the new ones focus on web development. There are way more web programmers out there than there have really ever been, so it makes sense that the rate of frameworks appearing (and to a degree, the overall lifecycle churn) would be accelerated.

pjmlp 9y ago
> I have dim memories of dozens of C++/Java/Python/Ruby/etc. next-big-things. While true, none of them have changed so quickly as JavaScript ones, which seem driven by devs eager to create portfolios on Github.
- Can_Not 9y ago
  > which seem driven by devs eager to create portfolios on Github. Is this supported by any facts? It seems like a hand-wavey hasty generalization.
  - pjmlp 9y ago
    The increasing trend of startups asking for Github accounts on their job offers. You just need to search on job boards.

Sawamara 9y ago

It is not really a brutal lifecycle at all, to be honest. Everyone loves a good rant about how fast the JS frameworks burn out, but it is not frameworks that burn out, but rather: In the 8+ years since Iphone/Android duo made a HUGE change in how we consume web content, we went from: - Having static resolution for websites to dynamically changing site resolutions - Having static HTML renders with some dynamic bits sprinkled over to full-blown SPA-s because of a variety of reasons* - Having major new JavaScript versions and INSANE amounts of Javascript engine speedups that allow things that were unimaginable 8+ years ago - Having gone from "nothing" to a CPU-based <canvas> to a full OpenGL ES-implementation, full GPU-based (<webGL>), - Had went from procedural code to semi-class based systems towards functional towards functional reactive programming systems And I could go on and on and on and on. The DOM api matured during these years. The renderers got replaced. Their performance altered dramatically. Layouts went from "JUST USE TABLES" towards CSS, then towards Compile-to-css alternatives, etc. Single-core event systems got SharedArrayBuffers, webWorkers, we got from callbacks to promises, towards async/await. And do not get me started on almost getting observables properly. The web has seen more transformations in terms of what is an "app" or a "website" in 8-10 years than ANY OTHER area in programming. It is only natural that widely different tasks need widely different tools to work with.

webDevSucks 9y ago
> And I could go on and on and on and on. True, it's enough to say "websites became big and slow". Additionally you can say "now we are after cross-platform native apps - set money aside for a device upgrade".
Klathmon 9y ago
(heads up, you need have a blank space between lines in HN to render them on different lines) I completely agree. Many people claim the web is overly complex, but then go back into the C++ world where you need a build tool to build your makefile which builds your project using cross compilation on a handful of platforms. I like to remind people that 10 years ago Android didn't exist, streaming video was still only just becoming a thing, and the iPhone had just been released and wouldn't have an "app store" for another 6 months. There have been several massive changes to the web and to computers and how we use them in that time. It only makes sense that we will use different frameworks and paradigms to create applications.

baybal2 9y ago

I thank YUI and later jQuery for getting me my first real software development job. Today it looks surreal that a mere portfolio of mind boggling animation effects would be enough to get a 21 year old an $84k job, but back in the time of peak web 2.0 craze, just having words jquery and 3 years experience on your resume was just enough to get 3 to 4 calls with ready offers every month.

nailer 9y ago

Why are 'angular' and 'angular.js' seperate tags?

tboyd47 9y ago
AngularJS refers to major version 1, Angular refers to 2.
- nailer 9y ago
  Wow. That's really unintuitive.
  - jedwardhawkins 9y ago
    I agree with the sentiment. Most people view them as distinct frameworks. I believe the use of the name Angular for major version 2+ helped retain a lot of users. I've seen a lot of uninformed devs and managers assume that because they already have so much code in AngularJS that Angular is the next logical tool for their team to use.
_greim_ 9y ago
Presumably that reflects the 1.x / 2.x split. They're arguably different enough to be treated as separate frameworks.

_greim_ 9y ago

> Stack Overflow Trends lets us examine how each of these technologies has been asked about over time. So what are we measuring here? It seems obvious that more popular frameworks would generate more questions, but so would: - Newer ones which not as many people are familiar with. - Poorly-designed ones which lots of people nevertheless use. - Ones which disproportionately attract inexperienced devs.

larrik 9y ago

Alternative hypothesis: Brand new frameworks have zero docs and zero questions in Stack Overflow. Older frameworks have (hopefully) complete docs and a library of SO questions. In between you get a gradient. I'm just not convinced that the data they're looking at means what they think it means.

ToJans 9y ago

IME Vue is so well designed, that I hardly have any issues with it. If I do, my go-to reference is the official documentation. You shouldn't base your usage assumptions on the amount of questions asked; Vue just doesn't require so many questions...

FLGMwt 9y ago
Ditto for React. Pretty much every "how do I do this" is covered in the official tutorial and every "how should I do this" is covered by supplemental guides (still official docs). Some good ones: "thinking in React", "lifting state up", "controlled components", and similar docs in redux: "you might not need redux"

rodolphoarruda 9y ago

Pretty much a Gartner's Hype Curve like behaviour on each case. Accelerated adoption, a peak, then delusion kicks in causing many people to lose interest and step away from the technology. Late adopters find lower barriers of entry later on caused by lessons learned and improvements made to the same technology. Usage increases again but a lower level when compared to the initial peak. Expectations around tech's capabilities are now more concrete and realistic, bringing stability to the ecosystem as a whole.

systematical 9y ago

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?

lolive 9y ago

My 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 ?

pjmlp 9y ago
That could be the idea, but currently it seems Angular devs are more open to that idea, given that WebComponents are mostly driven by Google. https://summit.polymer-project.org/ https://summit.polymer-project.org/ https://developer.chrome.com/devsummit/ https://developer.chrome.com/devsummit/ You can some components here, as well as, the current state of browser support. https://www.webcomponents.org/ https://www.webcomponents.org/ Currently only HTML Imports seem to be a point of disagreement. I am looking forward to them, as they can be the way for more sanity on Web development.

mixonic 9y ago

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

simonsarris 9y ago
I think this is the most important takeaway. It's especially true for smaller libraries and commercial libraries. And even for huge ones like Rails, questions answered 6 years ago might be little more than a catalog of improper practices by now! For a hard numbers example of "trends" being poor, I develop a JavaScript diagramming library, GoJS: https://gojs.net https://gojs.net It has competition, such as JointJS, jsPlumb, etc. If I look at StackOverflow tags, I would think we're in big trouble: * 180 questions tagged gojs * 449 questions tagged jointjs * 518 questions tagged jsplumb These aren't even enough to show up on StackOverflow's trend tool, and they make the case look pretty dire for GoJS! But behold, Google trends: https://trends.google.com/trends/explore?date=all&q=gojs,jointjs,jsplumb https://trends.google.com/trends/explore?date=all&q=gojs,joi... (ignore the last, partial-data month) In search interest GoJS is clearly ahead of these other two libraries. What's more, if you compare the forums for each product, you'd see that GoJS gets 10x-100x the traffic of the others. StackOverflow is simply not the a good place to gauge library interest and activity over the long term, and its not a good place as you say to ask or find answers to questions for products that have ecosystems which continuously improve their APIs and evolve.

watsocd 9y ago

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

drderidder 9y ago

It's easy to see graphs trending down and say, oh, interest is waning. But the initial spike could just be lots people going through a learning curve. It tells you something about popularity, but ease-of-use, quality of docs, etc. must all factor in as well. I tend to see the high number of questions on certain frameworks as a red flag.

simooooo 9y ago

Knockout isn't a Microsoft technology