The Brutal Lifecycle of JavaScript Frameworks


JavaScript UI frameworks and libraries work in cycles. Every six months or so, a new one pops up, claiming that it has revolutionized UI development. Thousands of developers adopt it into their new projects, blog posts are written, Stack Overflow questions are asked and answered, and then a newer (and even more revolutionary) framework pops up to usurp the throne.

Using the Stack Overflow Trends tool and some of our internal traffic data, we decided to take a look at some of the more prominent UI frameworks: Angular, React, Vue.js, Backbone, Knockout, and Ember.

Framework lifecycle

Stack Overflow Trends lets us examine how each of these technologies has been asked about over time. We can start by looking at some of the larger frameworks.

There was a time when jQuery was the darling of JavaScript tags on Stack Overflow, accounting for almost 8% of new questions. This picture quickly changed as AngularJS and later React were released, cannibalizing jQuery’s mindshare amongst the community. Then starting around 2016, there is a quick shift from AngularJS to Angular, which represents the subsequent versions (Angular 2+), as developers began to migrate to the latest and greatest flavors of the popular framework from Google.

These larger frameworks show only part of the picture. There also were smaller frameworks vying for dominance. The picture here shows just how brutal the lifecycle can be.

There appear to be two major phases in JavaScript framework usage. There appears to be a quick ascent, as the framework gains popularity and then a slightly less quick but steady decline as developers adopt newer technologies. These lifecycles only last a couple of years. Starting around 2011, there seems to be major adoption of a couple of competing frameworks: Backbone, Knockout, and Ember. Questions about these tags appear to grow until around 2013 and have been in steady decline since, at about the same time as AngularJS started growing. The latest startup is the Vue.js framework, which has shown quick adoption, as it is one of the fastest growing tags on Stack Overflow. Only time can tell how long this growth will last.

By Language or Technology

There are various factors that may go into a developer’s use of one particular front-end framework or another. Developers who primarily work with one programming language or technology may be more inclined to choose a certain UI framework. For instance, we might expect Node.JS developers to choose a different framework than ones who work with Ruby on Rails.

We can get a sense of this by breaking developers into groups based on the tag they most visit, and for each group examine the percentage of traffic that goes to each of these frameworks.

Both TypeScript and CSS users have relatively high traffic to JavaScript frameworks across the board compared to the other technologies we examined. This makes sense as developers who work with these technologies tend to do front-end development, so they’re more likely to use a JavaScript framework. The relationship of Angular to TypeScript is particularly strong as Angular (not AngularJS) is written in TypeScript.

As a gut check, we included C and C++ in this analysis. Since developers who primarily use C and C++ tend to do more systems programming, they are less likely to use a JavaScript UI framework, and this is apparent based on the relatively low percentages across each framework.

Angular and React are by far the most popular across the board, no matter the technology used. It makes sense that they are the clear frontrunners, supported by two of the biggest and most influential companies in tech. Just looking at those two frameworks, Angular is more visited amongst C#, Java, and (to a degree) PHP developers, whereas React is more popular with Rails, Node.js, and Python developers.

There are a couple of interesting observations when we look at some of the less popular tags. Ember.js and Ruby on Rails share a disproportionately strong relationship compared to other technologies. This marriage could be due to some of the philosophical similarities between the two frameworks. Ember was created by Yehuda Katz, a member of the Ruby on Rails core team. Due to this, both Ember and Ruby on Rails advocate a convention over configuration paradigm that make these two technologies complimentary and allow developers to quickly be productive without worrying about the nitty gritty configuration, until they need to.

Unsurprisingly, Knockout.js receives disproportionately more traffic by C# developers, most likely since Knockout is also a Microsoft technology. PHP is also an interesting case. It is designed for and primarily used for web development, but PHP developers are not visiting many Angular or React questions (and not too many to JavaScript frameworks as a whole), but visit a disproportionate amount of Vue.js questions.


The choice of JavaScript framework also varies by industry, which we can segment for US traffic by matching IP address to companies. Since React and Angular are the most popular frameworks, we compared the traffic to each tag in the median organization within each industry.

What industries tended to use each of these frameworks?

We can tell that the media and retail industries by far tend to use these frameworks and have a higher percentage across the board compared to other industries, as companies in these industries tend to gravitate to newer technologies to bring rich client-side experiences to their users to engage with content and refine the online shopping experience. This contrasts with the academic, government, and healthcare sectors, which appear to have little need for these types of frameworks. This may be because those industries are relatively more concerned with database management or data analysis rather than front-end web development.

The largest outlier and mystery is the insurance industry. Compared to other industries, Insurance companies as a whole seem to use Angular at very high rate, without using much React. We’re still looking further into why this would be the case, but if there are any developers who work for an insurance company reading this, feel free to leave your conjecture in the comments.

React and Angular Usage in the United States

As we have examined in previous posts, choice of programming technologies differ greatly by geography.

So, keeping with the React and Angular theme, which cities in the United States (among the 25 cities with the most visits overall) are more likely to use these frameworks?

Interestingly enough, this group of cities is split fairly evenly between the frameworks, with Dallas and Denver trending more towards Angular and Brooklyn and San Francisco more towards React. I like to think San Francisco and Brooklyn are two of the trendiest cities in the US, and that this is why developers in those cities are also trendy with regards to their choice of framework.


Let me be clear, even though I’m from Brooklyn and have a budding affinity for React, I am not advocating for the use of any framework in particular. Like every technology choice, it’s not about what’s “hot,” but more about identifying tradeoffs and finding the tool for the problem at hand. But let’s be honest, the size of a developer community certainly counts; it contributes to a thriving open source environment, and makes it easier to find help on Stack Overflow.

Whichever JavaScript frameworks you use, if you’re a web developer looking to take the next step in your career, here are some currently companies hiring front-end web developers on Stack Overflow Jobs.

We have something fun for ya. Our latest podcast episode is out!


Ian Allen
Ian is a developer on the Internal Tools team at Stack Overflow. He has strong opinions about user interfaces, basketball data, and Liverpool Football Club.

Related Articles


  1. disqus_NrkWMn1KOM says:

    Maybe learn to actually write code rather than rely on the latest trendy runway sensation framework.

    1. Meistertrollen ll says:

      Yeah, nothing like reinventing the wheel and spend hours on edge-case debugging. I’d much rather do that instead of using a tool that already handles it. /s
      Clearly your code has never seen production.

      1. You both have fair points. Probably better to learn the underlying language and get good at it. Frameworks come and go. That being said, the framework gets you the job more often than the language knowledge

        1. That is so sad, but so true. People just want all the boxes to be checked ignoring that you have 15 – 20 years experience and could probably learn a framework in a week. I find that recruiters often don’t know the difference between a framework and a language – a perceived skill vs. a real one.

          1. Meistertrollen ll says:

            I think it comes down to competition. If developer A has both Javascript and framework experience, it’ll be easier for that person to integrate in an existing team/project. Developer B (who doesn’t know the framework) won’t be able to integrate to the team as quickly, so it’s an added risk when you have deadlines. This is why framework experience often comes first. I believe that regardless of seniority level, developers would be best served by having at least have basic knowledge about the latest frameworks.

        2. steveknoblock says:

          There’s a balance. It’s become very snarky to say just write code, but in the Perl community, the suggestion is to go look for a module in CPAN for something you have never written before, someone else more expert than you had done it, and its been in use, so bugs have been found, so why reinvent the wheel unless there is something new to address. The CGI module is a good example, everyone was writing their own hackish or copy and paste HTTP to Perl vars conversion subroutines of varying quality, and thhe advice from the Perl community was why try writing some tricky decoding when accurate decoding is already sitting there waiting for you?

          That’s not a framework though.

          I’ve had experience where an ad hoc framework that was well thought out is simpler and easier to use than learning the concepts and requirements of a new framework. As service-oriented architecture grows, frameworks may be less valuable.

      2. If anything is reinventing the wheel it’s frameworks. Then they make achieving that same task take 5x as much lines of code. So much for being helpful. I like that you threw an ad hom in the end of your message. It is a clear flag for me to trust nothing you say.

    2. BassByTheBay says:

      Of course you need fundamental skills, but if an engineer is picking a framework because of (perceived) trendiness, that engineer’s rationale is obviously poor.

      The whole point of a framework/library is to save development time. Nothing is going to solve every problem, which is where those fundamental skills come in. But I couldn’t begin to quantify how much time I’ve saved using frameworks/libraries over the years.

      I’ve been writing JavaScript for 18 years — spent years writing core JavaScript before trying out any framework (first one I used was Prototype). jQuery was a game changer. And as flawed as it was, so was AngularJS. These are all just tools. Like any tool, you have to use it wisely, but I’d much rather have the tool than not.

      1. Zack Macomber says:

        “But I couldn’t begin to quantify how much time I’ve saved using frameworks/libraries over the years.”
        The complete opposite for me. I have a C.S. degree and have been programming web applications professionally for 11 years for multiple companies and industries. Every single time I’ve had to implement a framework and/or library in an application has costed me numerous hours. All of the “time saved” that frameworks and libraries bring is negated by all of the following (I’ve never once worked with a framework or library that doesn’t have all of these) – poor/confusing/incomplete documentation, bad examples, performance degradation, conflicts with other frameworks/libraries, new versions that break old ones, learning curves, hard to customize, hard to work-around bugs/missing features, etc…Core languages evolve to include what libraries and frameworks try to accomplish…just takes a little time for them to get new features in there…

        1. BassByTheBay says:

          “Every single time”? I honestly don’t mean to offend you, but you must be doing something wrong. Do you use an IDE? Does it save you time? How about dev tools? There are lots of tools we use. It’s just very odd that you end up losing numerous hours *every single time*. If your experience were the norm, frameworks obviously wouldn’t have gained the traction they have. jQuery has been in use for over a decade for a reason, and it’s not because it slows everyone down. The first project in which I used jQuery was an absolute joy to work on and shaved weeks off a months-long project.

          I mean, if you don’t wanna use ’em, that’s your call. But the intent of a framework/library is obviously to save time, and the experience of myself and thousands of other developers has been that, despite the occasional issue that arises from using them, they clearly do save time.

          1. Zack Macomber says:

            I mean “every single time” in the general long run…jQuery in particular I find to be among the better ones where you can easily look something up and implement it. Nonetheless, there is a growing “you might/don’t need jQuery” community that’s advocating that you can accomplish the same stuff without it. I wonder if a lot of these frameworks and libraries grow out of the laziness of developers to actually learn the languages they’re built on top of.

            I implemented a web app using angular 1 and bootstrap on the client side which took significant time when it came to customizing things and trying to write “proper” code based on angular/bootstrap docs. In the end, I wonder if I could have just written well structured html5, css3 and es6 code in the same amount of time with much more flexibility than having to conform to another developer’s vision of how html, css and javascript should look.

            “Frameworks” in particular have left me with sour experiences (Angular, Spring, Struts & Bootstrap are all frameworks I’ve worked extensively with). All of the negative points I listed above I have experienced with each of these. I’ve just had a lot of repeated trouble and then questioned the value of these “wrappers” that end up having leaky/incomplete abstractions.

            How are you measurably sure weeks were shaved off of a months-long project by using jQuery? Is it possible that learning/using JavaScript itself could have yielded similar times in that project? Just curious…

          2. BassByTheBay says:

            It’s not like I did some kind of study whereby I built that web app using jQuery and then built it without — boss wouldn’t have appreciated that :-D. But in case you missed it in my initial post, I had been writing core javascript — no frameworks — for about 8 years before the jQuery project I mentioned. I know the core language extremely well — certainly more deeply than I know any framework/library, so I trust my estimation because it was obvious to me how much more quickly I was getting work done than I had on anything in the previous 8 years. And which is faster to write?
            $(“#foo”).click(function() {
            or this:
            document.getElementById(‘foo’).addEventListener(‘click’, function() {
            var bar = document.getElementById(‘bar’);
   == ‘none’ ? = ‘block’ : = ‘none’;
            The latter isn’t even handling IE6-era syntactic differences. And this is just one trivial example. Extrapolate.

            I constantly tell junior engineers to spend time learning the core language. They’ll likely never write as much core js as I have, but it’ll give them a deeper understanding of what a framework is doing and how it’s doing it. So, yes, of course, learn the language well.

            I’m curious: do you write any node.js? You ever use Express? Using Express (or similar) is really a no-brainer if you’re using node. The amount of stuff it handles for you is significant, and it does it very well. I see no value in writing my own version of Express when Express works great and has a vibrant community which has been around for several years.

            Anyway, you’re obviously entitled to your opinion. If frameworks don’t work for you, don’t use ’em. That said, I suppose I don’t need to try to convince whoever might be reading this to try using frameworks since the overwhelming majority of relevant job postings list some framework(s) as a requirement.

          3. Zack Macomber says:

            Good jQuery example that proves your point. Frameworks/libraries reduce boilerplate.

            I have written Node/Express code and absolutely loved it. My experience with Node has only been good so far but I haven’t written large amounts of server-side JS yet.

            I have certainly benefited greatly from frameworks but I’m just trying to make the point that what frameworks do can be done with core languages (frameworks are written using core languages). Core languages evolve to reduce boilerplate as well and I long for the day when core languages reduce boilerplate to the same level that frameworks/libraries do.

            Thank you for your posts. I’m personally really frustrated right now with the plethora of web programming technologies and wish there wasn’t so many different choices in our industry right now. I tend to freeze when having to choose between so many different ways to do something. Many of my thoughts are based off of this frustration. I wish I could write everything in one language…

  2. AnonymousPrime says:

    Vue.js was adopted early by PHP’s popular Laravel framework, so that’s the likely source of the intersection of PHP users and Vue.js questions.

    1. steveknoblock says:

      Also, it could be many PHP sites were slow moving from jQuery to a framework until Vue.js was introduced and popularized.

  3. I doubt stack overflow is the right tool to track a frameworks lifecycle. Reacts simplicity and minimal api surface won’t cause you the same amount of questions asked like Angular or Vue would, both being far larger in scope and complexity compared to the two api functions one has to remember in React, while everything else is unabridged javascript. More meaningful stats would be npm’s, representing real-world production environments: The story they tell is a whole lot different from yours: the situation has long been stable.

    1. “Reacts simplicity and minimal api surface won’t cause you the same amount of questions asked like Angular or Vue would, both being far larger in scope and complexity compared to the two” Have you ever even looked at Vue.js? Its one of the easiest to pick up frameworks I have ever seen. Angular is complex and had a steep learning curve. React requires a intermediate to advanced level of modern JS understanding. People ask question on S.O. when they cant find the answers easily on the doc pages. React’s docs were crap until recently.

      1. Agree, I was able to roll vue into multiple existing projects without a problem. It plays nicely with existing code, and has a small enough footprint that you can use it on existing sites (not just SPA’s).

        1. 564765jhgfj says:

          Reacts footprint out of the box is only 6kb larger than Vue. React 16 was built modular, so you can exchange facebooks conventional react-dom with react-dom-lite, which boils down React to 15kb (8kb smaller than Vue). If you use a drop-in for production like nerv, you are at 9kb, if you use Dio you are at 4kb. React itself is a fraction of size of Vue in terms of api surface and structural width.

          1. I feel like @disqus_kaDAtjaa8u:disqus was referring to how unobtrusive vue is when used in an existing project. Not the overall file size. Vue can be added to existing project by just adding a few v- directives so you don’t have to rewrite all your existing view markup with JSX

      2. 564765jhgfj says:

        Vue is React dipped into Angular. It inherited all the complexity that Angular warrants: dependency injection, special mark up syntax, a js-like emulator, etc. Even the most basic things are harder, too: composition, using state, etc. Vue, like Angular is imperative, it can’t refer to state and components and needs registrations. Vue’s api documentation is almost 80 pages at this point, and you absolutely need to learn it.

        React on the other hand can be learned by looking at a few examples and that is it. It doesn’t require studying docs, there are only few apis, it doesn’t emulate a weird javascript-like language, it doesn’t invent code-like html syntax. React is plain javascript, you can learn it under an hour. Say what you want, this isn’t possible in Vue.

        1. Again, (and not trying to be rude but) you sound like someone who hasn’t even tried Vue or really looked at the docs and more of a React fan boy.

          “Even the most basic things are harder, too: composition, using state, etc.” – Really? I would like to hear why you think that is so.

          “it doesn’t emulate a weird javascript-like language, it doesn’t invent code-like html syntax.” – I am really curious as to what you are referring to. Vue is written in and uses plain JS alongside html-directives.

          “Say what you want, there is mathematically no way that React would ever lead to the amount of questions asked as would be the case for Angular and Vue.” – The data in this blog post says otherwise.

          I have only ever heard of Vue’s documentation referred to as good or great. It is verbose because every topic includes a detailed use case. Did it ever occur to you as a possibility that more people ask React questions on S.O. because their docs are lacking?

        2. I was thinking about using React, but for sorting a list of products in an existing website, Vue.js was ideal. The filesize was irrelevant.

          1. That’s great, we use Vue as well at work. There are places where it just fits.

        3. “React on the other hand can be learned by looking at a few examples and that is it. It doesn’t require studying docs, there are only few apis,”

          That’s only the view layer. Once you go beyond simple to-do apps you have to deal with real-life state management and plenty of other issues. Your statement may be true for simple to-do apps, but let’s be honest here — building anything complex in React is going to require much more knowledge than just the simple React API learned from the minimal available documentation.

          You’ll most likely end up using Redux with React, or some other implementation of the Flux architecture. Even though the number of API calls are small, there are many patterns to learn in order to effectively create React apps. Plus, these patterns, “best practices”, and the best libraries to use with React are constantly changing.

    2. Haha add jquery to that list and see magic.

      1. Meistertrollen ll says:

        And surprisingly, recruiters are also asking for jQuery a lot. It seems ES6 is still too verbose for a lot of devs.

        1. There’s still a LOT of existing jQuery code that isn’t going anywhere.

  4. Knockout isn’t a Microsoft product, although it was developed by a Microsoft employee. Nevertheless, it takes a lot of inspiration from WPF/Silverlight and WPF’s leverage of the INotifyPropertyChanged and INotifyCollectionChanged interfaces, which might explain the correlation between C# and Knockout.

  5. When frameworks are first introduced, they are very buggy and going through lots of churn with frequent fixes and new versions. This causes a lot of problems and questions early on in the lifecycle. As the frameworks mature and become more stable, there are less questions about “what does this error mean?”. Plus, as more questions are answered on Stack Overflow, there is less of a need to post new ones. So I don’t think you can make as strong of a correlation to your conclusions. But it’s a very interesting article.

  6. Insurance companies use products and ready built portals for online servicing. Many are built using Angular.

  7. What’s fascinating about this study is how companies can turn on a dime. I would have thought that once a company has committed to a framework it’s too cumbersome to adopt the new hotness.

    1. Meistertrollen ll says:

      You’d be surprise how many companies do major rewrites to _optimize / update_ their code for their next version. I’ve done that at every job I’ve been hired actually.

      1. Marty McKeever says:

        I don’t know about that — rewriting existing code is expensive for everyone involved and doesn’t add any new business functionality. Sure, if performance is crap, you have to refactor but if BAU is good enough the money flows to new things. And that’s where developers have some influence to introduce new frameworks — the testing costs are already built in. At least that’s what I see from my scrum…

        As an old school UI specialist, I see the trend towards college educated full-stack developers who can manage Java, Eclipse, and hopefully modern Javascript frameworks in the same day and largely the same way, using Typescript and ES6 NPM etc etc with the same sort of compile checks and automated unit testing they were taught to expect from backend tools. I’m well on my way to phasing myself out of a career here, now that browsers behave properly and generally agree on things 🙂

      2. You mean to migrate to the “next framework” here is that what you’re referring to? (if yes…why *do* companies do that so often I wonder…)

  8. These results seem slightly flawed – as a new technology appears sure there are going to be lots of questions about it. As those questions get answered then the number of new questions being asked drop off, as the answers already exist on the site.

    I’ve been using KnockoutJS recently on something for example, I’d struggle to come up with a new question that doesn’t exist yet. That doesn’t mean it’s not being used much, but that it’s more matured in the community (also by the way this is NOT a Microsoft product).

    1. Meistertrollen ll says:

      KnockoutJS is dead. No recruiter ever asks for it. They instead are asking for React and Angular. What does this tell you? That no new projects are adopting these old frameworks. The only time I’ve touched KnockoutJS was at a dinosaur-style company, and even then new hires were pushing for an Angular rewrite. The deal is simple: Either you update to what workplaces are asking for, or sooner or later you’ll struggle to find a job. That’s just the reality of the field.

      1. That doesn’t mean it is dead, there are plenty of existing websites using it though I completely agree it’s definitely not winning the popularity contest right now. The merit of a library of framework should be upon the technical benefits and drawbacks it brings, rather than which is the newest and shiniest – otherwise you end up constantly wasting effort re-writing things.

        That being said, I don’t believe it negates the point I was trying to make about the natural decline of questions as more of the library/framework is covered in pre-existing questions.

        1. Meistertrollen ll says:

          I agree with you, but I’m just basing my point on what I see recruiters asking for these days (on LinkedIn for example).

    2. David Robinson says:

      “as a new technology appears sure there are going to be lots of questions about it. As those questions get answered then the number of new questions being asked drop off”

      This generally isn’t the pattern we see. For one thing, many technologies that have existed for many years are still steady or growing (Javascript has had 1.5 million questions: don’t you think if it were possible to “run out” of questions, they would have done so by now?) And many new technologies either show rapid continued growth (e.g. Angular, Pandas) or level off to become steady (e.g. Swift): why would questions about Knockout “run out” while questions about other frameworks don’t?

      Secondly, we can see this isn’t the case by examining the visits to existing questions. For basically all tags (such as the ones examined in this post), the trend of what questions are visited matches the trend of what existing questions are asked: there are no cases where the rate of new questions declines but the rate of existing questions visited is steady or increasing.

      1. Hi David,

        Thanks for that elaboration – I don’t believe the article talked about visits but obviously that’s quite an important point. Indeed if the visits are also decreasing over time rather than staying relatively steady then that does support what’s being said. JavaScript as an example I would expect a continuation of questions – it’s still moving and having major releases and the tag will get pulled into all sorts of other new frameworks etc but your comparison with Swift being stable is a good one to invalidate that theory.

      2. Grant Armstrong says:

        But wouldn’t you also have to consider the the abundance of information found on other parts of the web as well? Documentation and explanations of common questions grow not only here, but everywhere on the internet. Even the frameworks developer documentation becomes more detailed and informative. This would lead me to believe that growth and abundance of information over the lifespan of a frame could, at least in part, be responsible for the trends that are observed here.

      3. why would JavsScript run out of questions? for one new features are added to the language every few months. then new APIs are added and nearly every question about those new APIs is tagged with JavaScript. as well, all these new JavaScript frameworks generate new question all of which are tagged as JavaScript.

        personally I notice this in my own topic, WebGL. it’s possible interest is going down but it’s also possible most questions have been answered

  9. I’ve noticed that if I am searching for an answer on Stack Overflow, it’s not about Ember. I learned to ask questions on the Ember community’s Slack chat instead of asking questions on Stack Overflow.

    1. Sergio Lepore says:


  10. Guy Schalnat says:

    As for insurance companies, Angular seems data driven (you write data expressions in html attributes). React seems to be more programming driven (you write functions that includes html). Insurance is heavily data driven, so the mindset of the typical long time insurance developer tends to be data driven. When I had to chose which framework to introduce to my team, I chose Angular, because I reasoned that my team understood data much more than object oriented programming, and thus would be able to follow what I was doing easier (even if they don’t really understand javascript).

  11. I would have liked to see jQuery included in the 3rd chart (mapping server languages to js frameworks).

  12. i thought enterprise used angular more readily bc it was licensed under MIT license. Reacts license was pretty weird until recently (they’re on GNU as of a few months ago) and i think basically said that no one who used React could sue facebook

    1. To be correct they were using BSD+patent.

  13. Mark Cupito says:

    In my current role, depending on which Application I’m working on at my Company, I’m responsible for Angular 1.4, Knockout, jQuery (duh), Kendo and now React 16.x. It keeps it interesting, that’s for sure.

    1. Tim Hawkins says:

      I don’t handle those frameworks, but I manage devs who do, Kendo has been an unmitigated disaster for us, and we are transitioning to react as fast as we can.

      1. But podcast “.NET Rocks” has/had adverts for Kendo UI.

        1. Tim Hawkins says:

          Not sure what that means, its still been a disaster.

    2. Marty McKeever says:

      IME most folks roll out of the team before they become responsible for all that nonsense. But some of us who are dumb enough to hang around might dabble in 5 or 6 legacy frameworks over a given cycle.

      The good news is, they keep paying me to learn new ones, which I would probably do in my own time anyway 🙂

    3. William Brian White says:

      It’s best practice to use all javascript frameworks at once. That will help you use every design pattern at once in your app.

      And it will make for lots and lots of questions on SO


  14. Aurelia doesn’t show up in this list as it has a great community site – no need for stackoverblow. It’s without a doubt the best framework I have ever used.

    1. I searched for aurelia and watched their intro video at their site. Very simple and clean design and I could tell what they were doing right away. Seems like a nice straight-forward library. Also, interesting, if you’ve done dotnet core development the CLI feels very similar to what I saw on Aurelia. thanks

      1. Excellent!

      2. Robert Harvey says:

        Aurelia is more of a framework than a library. If you watch Gulp as a build occurs you will see literally hundreds of Javascript libraries being loaded under the hood.

  15. Ludvig Larsson says:

    When enough questions have found answers, why would something be out of flavor?

    1. Joseph Stevens says:

      In knockouts / jquery’s case, performance is weak and the benefit is low. And the zip cost is high.

    2. Marty McKeever says:

      No seriously — he’s only counting NEW questions. Do you think after 5 or 6 years most of the good questions had been asked about jQuery and most of the good answers upvoted sufficiently and most of the redundant “new” questions moderated out of existence? New questions don’t measure popularity or adoption, they measure ambiguity which favors the new and undocumented.

  16. The “Language or Technology” section would be far more interesting if the usage were normalized against overall popularity of each framework. Then you could really tell the predilection or prejudice of each community.

  17. anandchakru says:

    lots of insights, thank you. PS: At the bottom of this blog I was searching for a ^ arrow :O

  18. US-centric. 🙁

  19. PHP and vue.js makes sense because of the Laravel framework’s increase in popularity. Laravel uses vue.js as one of the primary view frameworks.

  20. Alexander Romanenko says:

    Enterprises (insurance) do not spend their time making UI components, which is target audience for React. They often buy ready to go feature rich ui toolkit which would be built on top of Angular, Knockout, etc for data flow and binding. Even ExtJS is moving to Angular. So they have no reason to find answers how to make or customize UI components themselves, and if they do, they contact their UI toolkit vendor for support (which comes with license). Data manipulation and binding framework is not covered by the ui toolkit so they have to learn that on their own.

  21. Regarding why insurance companies use Angular, having worked at one insurance company for a few years, my guess would be because Angular is the oldest of the frameworks and insurance companies tend to be very conservative and use more antiquated technologies. The company I worked for seemed to fear any new technology and any new technology that was added to our system had to undergo a lot of scrutiny, sometimes by non-technical people who had no business making those types of decisions.

    1. Jared Chmielecki says:

      I would guess the licensing. React used to have some aspects that are objectionable to larger enterprises.

      1. William Brian White says:

        True, that was an issue at my company

    2. They need to use technologies in which they can hire a volume of programmers. Another reason they would choose an older more stable framework.

  22. Common sense says:

    Will you people stop making these unscientific “reports” based on Stack Overflow Trends already! Stack Overflow Trends gives the PERCENTAGE that a certain technology takes up out of all questions asked on Stack Overflow, which isn’t the same thing as its popularity! Popularity can only be measured by the AMOUNT of questions asked. If SO one year only consists of 2 questions about technology X and 2 questions about technology Y, then Stack Overflow Trends would give them 50% each. If the next year, there are 4 questions about technology X and 8 questions about technology Y, then by your flawed logic, technology X has gotten far less popular, even though its popularity has in fact doubled. This phenomenon is quite strong on SO, as you have programmers from completely different branches using the same forum. When the smart phone was getting popular around 2010, a whole new branch of programming appeared, and more programmers were needed. So a whole lot of questions were asked about app development and mobile OS. This does not mean that other forms of programming were suddenly not a thing any longer, in fact most of those technologies were growing also, just not as fast. There are different people asking questions about different technologies. There is no such thing as a programmer who works with every single programming-related technology.

    1. Totally agree with most of what you are saying, not even popularity can be measured, over time, by the amount of questions asked.

      I think the only metric one can derive from questions asked is how new a framework might be, or how many junior programmers are using it.

      As frameworks age, I would think folks get better at them, and thus have less questions. This does NOT mean they are less popular. Additionally, as frameworks age, the amount of code samples, tutorials, open open source project code etc. also increases, and this too (I think) would have the effect of decreasing questions asked.

      Based on that I would say that all new frameworks of ANY popularity will show a spike in questions early on as folks come up to speed. Then it would level out and decrease (as the data shows). But this DOES NOT measure a decrease in popularity, but rather, the point at which the industry has a critical mass of skilled programmers in that framework, etc.

      1. This is a very good point. You’d have to somehow combine the asking rate with the view rate over time. Then maybe compare with Tiobe for good measure. Could be a really interesting study to see if and how they correlate. But comes back to: ask rate alone does not popularity indicate.

      2. Charles Guillory says:

        especially if most of the immediate questions have been asked,and can be referred to when searching; this could happen quickly after questions about the topic start, then after that there would be only a few (new,non-duplicate) questions about more particular aspects.then anybody who would have come to the initial problem and asked,can see there’s already a question and not need to ask, they would be satisfied without adding to the stats without meaning they didn’t use it.

    2. JamEngulfer says:

      Ironically, you don’t seem to be applying much common sense to your response.

      They show the % of questions a technology takes up because showing the actual numbers is just skewed by how much traffic StackOverflow has. If you looked back a number of years and said Java had 5 questions, then looked to now and saw it had 500,000 questions, you would assume the technology increased in popularity by an incredible amount. Except it’s just that at the start of StackOverflow, not many questions were asked because nobody knew about the site.

  23. Thomas L. (@ookook) says:

    That article doesn’t even mention prototype.js (mother of jquery). I feel so old…

    1. William Brian White says:

      We originally picked prototype. Then jquery just dominated. So now our site has both, which is just awesome

      1. jQuery.noConflict()

  24. Liam Hughes says:

    There are people who use SO who live outside of America you know?

  25. Moved on 🌐 says:

    react.js is the best among other frameworks. thank me later if you learn this

    1. Urban Fighta says:

      wow you changed our lives.

  26. Shawn Mclean says:

    Sounds like people in Brooklyn and SF are having a hard time using and learning React. Maybe they should switch to something easier.

  27. Super interesting approach. Thanks, Ian.

  28. Gyuri Ordody says:

    It would be nice to cross reference this with the number of commits on their github repo or maybe the number of features that are released for each framework, and maybe also normalize it on the number of javascript questions asked over a given time period.

    Also, it would be interesting to compare these findings with Java or C# libraries to give context. There are some Java frameworks that show similar signs of “being fashionable” then dropped.

    Also, it would be interesting to cross reference the frameworks with the language features added to browsers/node.js to shed some light on why this cycle is happening…

  29. Matt Wilkie says:

    I think of the millions of person-hours and attention devoted to learning how to effectively leverage these frameworks that then fall out of favour so quickly and grow despondent. A young teenage friend was given toolbox full of mechanical tools for Christmas. With moderate care a goodly portion of those stand a reasonable chance of surviving regular use to his retirement and death. What a strange world software development is that we’ve come to consider a turn-over rate of months to years as normal and acceptable.

    1. Charles Guillory says:

      we need 4 years of experience in a framework released 6 months ago and will be discarded 2 months from now.

      1. “We’re looking to port our legacy Python 2 codebase to Python 3, so we need someone with a minimum 10-15 years Python 3 experience.” “…You do realize Python 3 just turned 9 years old last month?” Never gets old.

    2. Xiong Chiamiov says:

      This is a large part of why I shifted over to Operations – while some of my tools are fairly new, a great many of them haven’t changed substantially since the 80s or 90s. The time I’ve spent getting familiar with vim, for instance, will still be useful for another twenty years at least.

      1. What is Operations?

        1. Xiong Chiamiov says:

 , aka Web Ops, aka DevOps, aka Site Reliability Engineering, aka systems administration (the terminology is varied and confusing). Generally speaking, we’re the folks responsible for the care and feeding of the servers and your apps in production.

          1. I always love that stuff. “We’re looking to port our legacy Python 2 codebase to Python 3, so we need someone with a minimum 10-15 years Python 3 experience.” “…You do realize Python 3 just turned 9 years old last month?”

      1. Matt Wilkie says:

        That was good, thanks

  30. Please, stop making blogs about how popular something is based on the questions. Have you forgot how StackExchange works?! Every single question is a future reference for everybody. Every question decreases the amount of questions in the future. I.e. if a question has been asked “how do I do this?”, then probably less and less people will ask questions about this and just look at the previously asked ones. Even if amount of questions is lowering, that doesn’t mean it’s less popular. Just everything has been explained clear about the framework. It’s not like popularity is measured with how much % questions are now about it, but rather by amount of questions asked about it overall. The best solution would be if you calculated views of tagged questions, even if this still wouldn’t measure this very precise, but would still be better.

    1. Very true. I also would say that number of questions does not provide a direct correlation to popularity. For instance, React’s API has a small surface area as it is only for rendering the view while Angular is a complete framework. With React you are using vanilla javascript more frequently than other frameworks. So I would argue there are far fewer questions you could ask about React vs a full JS framework.

    2. Urban Fighta says:

      they just don’t care about correctness all they they care about is view. welcome to age of hypocrisy.

  31. jQuery didn’t lose popularity due to Angular or Backbone, but to ECMAScript slowly filling the void that jQuery was supposed to fit into.

  32. >PHP is also an interesting case. It is designed for and primarily used
    for web development, but PHP developers are not visiting many Angular or
    React questions (and not too many to JavaScript frameworks as a whole),
    but visit a disproportionate amount of Vue.js questions.

    Did you even research why that is the case? Laravel team endorse vue in particular.

  33. Apropos:

    “Every programming language embodies in it a philosophy about how problems should be solved. C reduces all problems to manipulations of memory addresses. Java turns every problem into a set of interacting objects. JavaScript summons Shub-Niggurath, the black goat of the woods with a thousand young, to eat the eyes of developers.” (From:

  34. Muhammad Omer Aslam says:

    this blog is going into bin as it is based on the assumption that least questions asked for a language is due to it is getting un-popular where as stackoverflow discourages asking a question again if it is asked , you can say that most of the commonly asked questions are majorly covered by stackoverflow for these specific languages rather than assuming that it is getting un-popular.

  35. Md Sadiqur Rahman says:

    How can you compare JQuery (library) with Angular (a complete framework)? Could not grasp it 🙁

    1. How do they “compare” them? The post is about the relative “popularity” of certain question tags on Stack Overflow (and their ebb and flow, over time)… and it’s certainly TRUE that jQuery was an extremely popular tool among frontend JavaScript developers early on, before its “mindshare” (as they say) began to erode in favor of AngularJS and friends — wouldn’t you agree? It doesn’t matter if they aren’t precisely equivalent, it only matters that they compete (or competed) for adoption within the same developer communities.

    2. That would be a problem if we are talking download numbers for example, because you have to download jQuery to use AngularJS.

      That’s different here. We are talking question tags. Not every question tagged AngularJS will also have the jQuery tag.

  36. Love the article Ian. Going blind these days with all the options out there. Great insights, Great work!

  37. The conclusion is that Angular is a much more complicated framework, and people have more questions about it than on React.

  38. Could it be that as the frameworks mature, less questions are asked over time because the answers are found through earlier asked questions?

    1. Sounds reasonable to me

  39. If you don’t like something in a frontend technology, you can wait for 2 years and it will change…

  40. You say, “There appears to be a quick ascent, as the framework gains popularity and then a slightly less quick but steady decline as developers adopt newer technologies.”

    It seems the fundamental approach to analyzing the data in the first graph is wrong. StackOverflow actively discourages the same questions being asked again. So the fact that a particular technology has a decaying number of “new questions” to be asked in my mind indicates, at least in part, that all the simple / common / newbie questions have already been asked, and that developers are finding what they need.

    For me, a much more interesting and accurate dive into the data would be looking at SO page views, search queries and Google trend data for search terms.

    Right? Or am I missing something with the data analyzed.

  41. helpful writeup.
    switch the words ‘currently’ and ‘companies’ in the last sentence. : )

  42. Regarding Insurance Companies, their public UIs are really really complex, change often and are based on data (as mentioned above).

    HTML/CSS programmers are crucial for these UIs, and I just think they have a much easier time with Angular (code written in html files) than React, (html written in code files).

  43. Vijay Singh says:

    Users hitting Stackoverflow for any framework, Shouldn’t that be a measure of its poor documentation. It would be worth to do an analysis of which language/framework has highest hit on stack and compare with how good or bad its documentation is.

  44. I’m one of the Knockout core devs, and just thought I’d mention that KO 3.5 just went into beta, and I did a major rewrite for KO4 over the last 18 months or so called tko, converting it to an ES6 monorepo. tko has been in alpha for a year, but it’s almost completely backwards compatible.

    Knockout still scratches an itch and has thousands of tests with a fairly mature support base of questions and communities, so I’m glad to see its stats plateauing.

    Incidentally, Steve Sanderson founded Knockout.js before he was hired by Microsoft. In part they picked him up because he had created Knockout.js.

    (Shameless plug for support !)

  45. One angle I do not hear discussed a lot is that some people are more likely to be followers, than independent thinkers. The pressure to conform is primarily derived from the pressure to be employed, or start something up. There is a cost to adopting any framework/library, just as there is a cost to learning a new programming language.

    In the case of JavaScript frameworks/libraries, the variety and tribalism are insane. The “it’s a tool argument” is being tossed out the window and replaced with “just do it this way.”

    I wish that the ACM, IEEE, ECMA, or ISO (etc ….) would create a JavaScript UI framework / library standard so that the core features of a compliant JavaScript frameworks / libraries would be the same, kind of like SQL is defined. The wild, wild west way of dropping frameworks on the industry needs to stop. If anything, security for the UI piece would improve with an open and well walked central core of standards.

    I feel that the development community needs better structure, consistency, and learning paths that separate standards from innovations.

    They say that DRY and not re-inventing the wheel are good programming practices. Why does this not apply to the development of public and free JavaScript frameworks/libraries that companies (ultimately) adopt?

  46. How do they “compare” them? The post is regarding the relative “popularity” of sure question tags on Stack Overflow (and their ebb and flow, over time)… and it’s definitely TRUE that jQuery was a particularly common tool among frontend JavaScript developers timely, before its “mindshare” (as they say) began to erode in favor of AngularJS and friends — wouldn’t you agree? It doesn’t matter if they aren’t exactly equivalent, it solely matters that they contend (or competed) for adoption at intervals an equivalent developer communities.

  47. Darrell Dixon says:

    With over 20 years in IT, I have seen people “over complicate UI” I have advised some of the largest Enterprises against framework adoption and use JQuery intelligently with added utility functions.

    I avoid all Frameworks. Anything a Framework can do JQuery can do with (UI and Charting Components)

    1. I appreciate this response immensely. As someone getting into web development, the ROI on frameworks is high, but not dependable. Straight JS and JQuery seems to be the way to go, and how even JQuery may not be necessary (helpful, but not strictly necessary):

  48. […] was a time when jQuery was the most pampered JavaScript tag on Stack Overflow, accounting for approximately 8% of new questions discussed in JS communities. Soon, a topsy-turvy change took place after the birth of AngularJS and […]

  49. A very nice blog compilation. I really appreciate reading it !. Thanks for sharing it ! Keep sharing such valuable and knowledgeable blog in the future.

  50. great article, i really happy to read this blog. thanks for sharing.

  51. I started using Vue about a year ago and I think it’s so well designed, that I hardly have any issues with it. If I do, my go-to reference is the official docs. But I realize than in a couple of years I might have to start learning a new JS framework that looks and works nothing like Vue.

  52. Steve Cranford says:

    as a user of both frameworks, I’d suggest that React overall has less questions because
    1. it’s SIMPLER!!
    2. react users are more likely to be asking redux or non-react questions.

  53. Nice Post. Thanks for sharing

  54. Heavy Applicaions – Angular
    Small Mid solutions/ Portals- React/ Vue
    Wait for few months some x emp from y company will bring z framework.. n we guys debate again 😉

  55. […] Article for further reference : […]

  56. […] popular, JSF has recently faced competition from Java-compatible web frameworks, including client-side JavaScript frameworks. Still, JavaServer Faces remains the Java standard, especially for large-scale, Java enterprise […]

  57. If building structures in the real world was anything like building software we would still be arguing on the shape of a door. Angular, React? They will be gone in 10 years as the whole concept of writing code, line-by-line, is awful work that hurts the back. I’d rather jog and dictate to my AI that produces code at a level of quality we will *never* achieve because, writing code for corporations is awful work. No amount of lipstick will every change this pig we call a career. Software engineering ONLY has appeal when you can build something for yourself that is an expression of your creativity—what language you use for your creative expression is, and should be, a later consideration (Rust!). Anyone allowing a corporation to profit on their personal creativity is a tool. A prime hand. Chit chat about this or that framework, or reminding ourselves what we already know is tantamount to insanity. You were born a wage slave. Think about how to change that and then I’m interested in the conversation. This conversation is a circle jerk that is repeated monthly. Your job that is YOU sitting in front of a computer all day is the worst job in the world unless you happen to be monitoring sick children or a rocket.

  58. […] 没有人可以确保哪种语言、工具或者框架一定可以持续活跃,特别是在前端这一领域。一个StackOverflow 博客的作者这样写道: […]

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.