Please create an account to participate in the Slashdot moderation system


Forgot your password?
Open Source Programming Stats

Stack Overflow Stats Reveal 'the Brutal Lifecycle of JavaScript Frameworks' ( 165

A developer on the Internal Tools team at Stack Overflow reveals some new statistics from their 'Trends' tool: 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...

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.

"Let's be honest," the post concludes. "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."
This discussion has been archived. No new comments can be posted.

Stack Overflow Stats Reveal 'the Brutal Lifecycle of JavaScript Frameworks'

Comments Filter:
  • And maintainability? (Score:5, Interesting)

    by plopez ( 54068 ) on Saturday January 13, 2018 @05:04PM (#55923063) Journal

    What happens if you need to patch or upgrade in a few years? Like for security? Do you have to rely on unsupported frameworks or throw everything away and start over? How does it work?

    Remember, companies pay huge licensing fees exactly for support.

  • by Anonymous Coward

    Still just using jQuery and jQuery UI. They do pretty much everything I need. All HTML generation happens server side, and jQuery simply inline replaces the HTML content from whats pulled from the server. Doing things this way means only 1 UI stack, and it works across all environments, since only the servers need updating (plus of course routine updating of the jQuery/UI JS files themselves)

    • by guruevi ( 827432 ) <evi&evcircuits,com> on Saturday January 13, 2018 @05:28PM (#55923181) Homepage

      Exactly this. The problem with Angular and all the other libraries is that they're trying to solve the problems of 'simple' libraries like jQuery but then end up even more complex or break all sorts of convention and expectation trying very hard not to become jQuery, and then you get a new library trying to solve whatever problem is in that library.

      What you need in a framework (regardless of language) is not complexity (trying to do "everything") but simplicity. If the framework is dictating how your application should work/flow/represent the data, you're going to run in a situation sooner or later where your framework doesn't quite fit your problem and then you'll spend an eternity trying to make it work and you'll end up writing most of your code in the native language anyway.

      • by Paul Fernhout ( 109597 ) on Saturday January 13, 2018 @06:22PM (#55923441) Homepage

        Yes; thus Rich Hickey's talk on "Simple made Easy": []
        "Rich Hickey emphasizes simplicity's virtues over easiness, showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path."

        I agree on Angular having a lot of "accidental complexity".

        I've also run into the "leaky abstraction" issue you reference, like with the Dojo Toolkit and Dijit -- where I ended up spending large amount of time trying to understand why Dijits behaved unexpectedly and to make kludgy workarounds. People hope some frameworks will spare them from learning details of CSS and JavaScript, but in the end, edge cases and bugs mean you still need to learn all that -- as well as an arbitrary framework with its own quirks.

        I much prefer the combination of using JavaScript/TypeScript with Mithril/HyperScript, Tachyons, and a Flux-like one-way-data-flow architecture. You need to know JavaScript and CSS somewhat well to use those libraries -- but they are simple enough that they rarely do unexpected things, require long debugging sessions, or get in the way of doing anything advanced that you want to do. Those libraries are not perfect -- just a lot better than something like Angular (which I have to deal with for my day job; see also my related comment below). And those libraries are simple enough that any reasonably good developer could maintain them on their own if absolutely required.

        One of the reasons such libraries don't as much attention as they should is precisely because they are so reliable and simple to use. Unlike Angular, neither Mithril or Tachyons *requires* thousands of StackOverflow questions to learn how to use it, debug it, or upgrade it. In a way, picking libraries based on numbers of SO questions or blog posts on it is kind of like picking a car based on how many complaints are filed against the manufacturer with the Better Business Bureau. That's not a 100% valid comparison -- but there is more truth there than one might think at first.

        • Sounds like good a good thing, with those edge cases. We don't want to end up with a bunch of magical machines that nobody knows how to maintain.
        • I much prefer the combination of using JavaScript/TypeScript with Mithril/HyperScript, Tachyons, and a Flux-like one-way-data-flow architecture.

          I had to read your post twice to be sure it wasn't parody. Man, the names of those frameworks sound exactly like science fiction movies technobabble.

          • LOL. Here is an example I wrote of what I am talking about that uses those approaches:

            The overall discussion here general reminds me of many health discussions on the internet about relative merits of different complex interventions and prescription drugs for various chronic diseases while avoiding discussing the root causes of so much chronic disease from poor nutrition, lack of sunlight, lack of exercise, and various other lifestyle issues (i.e. "Blue Zones" and a "Whole

    • They do different things, and can - and often are - used together.

  • by mykepredko ( 40154 ) on Saturday January 13, 2018 @05:21PM (#55923155) Homepage

    There is so much wrong about Javascript revealed here that I think we have to question its use going forwards.

    The language itself is a great start to programming websites but the need for frameworks, which become "flavours of the month" that makes support so much more difficult as time goes on and the framework goes out of favour resulting in companies scrambling to find people with the skills to maintain them (sort of a short term Cobol analog). This gets worse when you realize that most web page developers don't know how to code and are using published features of the frameworks or example snippets on things like Stack Overflow.

    What about security of the various frameworks and ensuring they don't do anything nefarious. I guess the extreme examples would be collecting customer data and running cryptocurrency miners on end-users webpages - but I'm sure there are a lot of more minor security issues that can be hidden in these frameworks.

    Finally, I have to wonder about the maintainability of all these frameworks. On one hand, I guess frameworks with issues get identified by the community quickly and are abandoned (but, going back to the previous point, companies have to spend more money because their developers aren't competent to move the page to different frameworks).

    I'm not sure I see a solution for these problems. Maybe WebAssembly will be the ultimate solution (with tested and supported libraries that web developers can use and rely on) but I'm hoping that W3C and other groups are looking ahead to the next generation of web development tools.

    • The worst (or best) is when the monkeys load in the calls from or somewhere without actually hosting a copy locally. This is especially a problem on corporate networks where a firewall policy of "Thou shalt not go outside the network" will now break the internal website. This means you now have to open up requests to the outside making another hole for proprietary data to leak out undetected, either with a compromised or just making it look like normal traffic.
      • If you don't have enough access to change the link to point to a local copy, then you're probably below the monkeys in the hierarchy and should mind yourself before the monkeys learn of your betrayal and other-source your role.

    • Meanwhile, I came in this weekend to fix a bug involving a corrupted stack and am going to be digging through cores and assembler to figure it out. I am amazed (and dismayed?) at the vast gulf of distance between what I do as a programmer and what a web developer does.

      • I came into a company that was a recently bought out startup where I found the CTO to be incredibly knowledgeable about web programming, PC application programming and PICmicro firmware programming.

        Now, that I'm doing a startup and programming for multiple targets (namely, HTML in Javascript with jQuery and Angular, PC and MaC programming in Java/C/C++/C#/Objective C and firmware in C) I think I would probably impress new programmers coming into the company in the same way.

    • Mostly that Javascript has a lot of new developers, new enough that they're easily influenced by hype. The Javascript community seems to over-emphasize having a pretty website rather than technical merit.

      Also, that Javascript exists in an environment with a different set of problems than most others. Solutions have yet to be well fleshed out, and there are a lot of different ideas being tested. So even the more experienced devs are going to be more prone to create a shifting landscape.

    • It's not about JavaScript because A) all the big popular frameworks are some kind of MVC, they are all about interfacing with the DOM and users, JavaScript is just what's available. B) There is a work in progress standard to better solve this problem as part of the web platform.

      Also, the interpretation of these stats is flawed, it assumes new questions asked per month equates purely to popularity, but if you give it more than 2 seconds of thought you realise that there will be a saturation of common questio

    • There is so much wrong about Javascript revealed here that I think we have to question its use going forwards.

      Did this just occur to you now?

      The language itself is a great start to programming websites

      Nope, it isn't. It seems great but that's only up until you realise that you've been deluding yourself. For some, this never happens, which stands to reason because it'd make them ashamed of that fat paycheck.

      but the need for frameworks,

      It starts way before this, but yes, that should have told you that javascript is not great, because no staying power. It's fairly natural for a programmer to try and build higher abstractions on the building blocks available, and that's fine. What would not be fine, and h

      • I find thing to both agree and disagree with in this comment.

        I agree that ideally the web should be mostly about serving static content. Unfortunately, with a web funded mostly by advertising revenue, much of the JavaScript on the web is about putting together feeds of multiple items to entice you to click on other documents to get the next ad impression served -- as well as to track those clicks. Why should, say, a news site have a sidebar with current articles to click on merged into content for each arti

    • The frameworks arise as members of the community try to implement interesting development ideas or facilitate advanced programming for people with less advanced skills. It may not be the greatest language but the community is a helpful one and the language is one where new users can easily create projects that mean something to them eg. a website. That is why it is popular and appealing. A similar phenomenon can be seen in the scientific community where Python is on the rise even though programming eliti

  • We had GUIs in the 1990s with straightforward architectures. You could develop quickly with Delphi. No problems. JS front ends are just GUIs so why do we need mountains of css, html and js to get it to work?

    Front end development is an expensive clusterfuck.

    • On the other hand, you had Swing. When Sun won a victory over MS and got Sun Java included in Windows, I said MS should retaliate by also including Swing. Use Swing to render the Sun logo at startup...Provide instructions so users could disable the whole mess and have a machine that was usable in less than 10 minutes.

      Clusterfucks have always existed. Pick the right tool for the job. Old advice but still valid. Avoid magic bullets, they are always bullshit.

    • by Paul Fernhout ( 109597 ) on Saturday January 13, 2018 @06:00PM (#55923341) Homepage

      As a once Delphi programmer, that is one reason I like the combination of JavaScript/TypeScript, the Mithril vdom [] (which uses a "HyperScript"-like API to define HTML via code), and Tachyons [] for embedded CSS where each class defines the CSS effect (e.g. "underline") -- along with a simplified Flux-like one-way data flow architecture. Although people could swap out Mithril and Tachyons for similar systems to get a similar effect.

      Sadly, for my day job I am stuck using Angular, which is a my-way-or-the-highway framework with a lot of questionable design choices leading to excessive complexity and difficult debugging.

        • On two-way (Angular default) vs. one-way (Flux) data binding: []

          But Mithril does one-way data binding naturally so you usually don't need much to be made explicit: []

          But apps may still benefit from undoable commands or transactions being run against a data model, so sometimes a more formal flux/reflux/redux approach may be worth it -- or not. I feel it makes sens to keep things simple with POJOs and then see if a more formal data store model is n

          • I am a back end developer and I can't get our front end developers to do any data modeling in angular at all. They want to work in terms of screens, with the back end serving each page the data it needs in the format it needs. I really don't know what is going wrong. Browsers have a lot of processing capacity now but where I work we don't seem to be using it.

            • It's usually a best practice in corporate settings to have a well-defined long-lived data model in a database and then create views on it as needed. Applications then work from the views and might use a short-lived application-specific data model. For JavaScript apps, you might create JSON APIs connecting to the views.

              Somewhere in the social process of dividing up responsibility and labor is some negotiation between what issues are best solved by convenient views on the database versus best solved by specif

            • I really don't know what is going wrong. Browsers have a lot of processing capacity now but where I work we don't seem to be using it.

              There is nothing going wrong, that isn't your processing capacity and you shouldn't be coveting it. It isn't yours, use your own server for your processing capacity.

  • I won't just stand here and proclaim that javascript is the largest collective waste of human effort in history since it's gone from novelty to serious security threat, I use a chair like a normal person. Anyway, javascript was neat but now it's a threat and it needs to be stopped. The good news is that CSS3 is very advanced and with a few tweaks to HTML we could provide all the modern functionality for webpages without a single script tag. It's too bad it won't happen because large companies have a vest

  • by dremon ( 735466 ) on Saturday January 13, 2018 @05:51PM (#55923307)
    As the fastest and leanest framework []
    • Yes! My favorite! (OK, I'll admit to a little jQuery as well...)
    • Provided you're coding only for web browsers that support Vanilla. Edge and Safari, for instance, have tended to lag behind Firefox and Chrome in their Vanilla support, needing a "polyfill" framework to replicate some of the missing parts. And unless you target Edge and Safari, you won't reach Windows 10 S and iOS.

      The one silver lining is that IE prior to 11 no longer receives security updates, giving a convenient excuse not to support browsers that are that downlevel. This means the more convoluted Vanilla []

  • It's natural that there're going to be more questions with new frameworks, and as those questions get answered - fewer new questions. That is the nature of Stack Overflow - look for someone who's already answered your question, before you ask.
  • Vue (Score:5, Interesting)

    by richardtallent ( 309050 ) on Saturday January 13, 2018 @06:05PM (#55923375) Homepage

    I started using Vue this year. I evaluated React but I just couldn't enjoy the JSX syntax. Angular 2 had just come out and I found it to be far too obtuse, too far from "the metal." I briefly experimented with Riot, but it was losing IE11 compatibility too fast.

    Vue hit the sweet spot for me -- the ramp-up was easy, the code and API have a small but powerful footprint, it works well either interpreted in-browser or compiled via webpack, the Chrome dev tools are great, and I didn't have to learn the entire ecosystem (Vue, Vuex, Axios, etc.) to become productive. Coding single-file components reminds me of the good old days of writing server-side ASP.NET controls -- markup and script are separate, the lifestyle is simple to grok. The framework just does one thing--it handles the DOM update/manipulation details, allowing me to focus on behavior and state. I also like that the vast majority of my Vue code isn't really "vue," it's just plain HTML and JavaScript, so whatever comes next (web components, etc.), the transition will be much less painful than if I were using a more opinionated framework.

    • This pretty much sums it up for me too - vue is nice because it's easy to just use some basic parts of it (e.g. two-way data binding) without having to fundamentally alter your application or way of thinking to fit some model. My first few projects with vue didn't use vue components or any server-side build process or anything like that because vue by itself did all I need.

      And then when I did take the plunge and structure my app to make use of vue components, I still found it fairly straightforward to adopt

    • Metal? Somewhere a C kernel programmer is laughing.
  • by tomxor ( 2379126 ) on Saturday January 13, 2018 @06:46PM (#55923537)

    It says it right there on the Y axis of their graph: "% of stack overflow questions that month"... When you don't know how to X in framework Y? you google, and probably land on stack overflow if the question exists; you don't post another question. This metric doesn't equate to popularity it equates primarily to question saturation and secondly to popularity in terms of uptake (less questions asked by advanced users).

    We all know JS frameworks come and go quickly compared to other languages but this analysis is the height of numerology... if you're going to do some statistics be objective.

  • The latest startup is the Vue.js framework

    Hmm, article characterizing cyclic rise/fall of frameworks names a single one as the new hotness. Maybe intended as an advertisement, maybe not. Over on a subreddit about unsolved mysteries, they refuse to allow postings about anything newer than 6 months, essentially to prevent current frenzy/churn over something fresh from taking over the intended ambience of mysteries that have stood the test of time; I think that principle might be well-applied when it comes to "assessing" technological cycles, namel

  • A few people have questioned the validity of rating Framework popularity by the question rate on Stack Overflow. I just wanted to say that I think it's valid in this case if I compare it to other surveys of different programming languages based on the rate of new questions - I see something every year or so like ( in which the popularity of different programming languages is rated by the activity on each language.

    I'm of mixed thoughts about Stack Overflow - Al

  • The reason you keep seeing new frameworks pop up is that the prior frameworks don't really solve the base problems that need to be solved.

    To make it worse there will be groups that have different perception of what the "base problems" are. I am sure there are more than two such categories of players.

    Hence, more frameworks.

    You need to stop and ask are web SPAs with rich interactivity really needed in the first place? Having thought about it my conclusion is a resounding YES. If you don't agree obvi

  • It's not surprising. Firstly, most of the framework seem to ignore the lessons learned from those "old" desktop GUI frameworks. But it makes sense, those frameworks take full advantage of a language with easily expressed class inheritance which overall is a excellent match for GUI based systems. It doesn't translated to raw JavaScript, and you get a lot of reinvention. Take React. Mixing markup and code seems very easy, but it ignores that ASP and JSP already did that, and it turns out not to be very mainta

  • Before a Javascript framework even gets to first beta release, it's already months obsolete. This makes it scary for companies investing in high-end web apps. It's unnerving to commit to a framework when you know the support community could suddenly die away without warning.
  • by Qbertino ( 265505 ) <> on Saturday January 13, 2018 @08:54PM (#55923977)

    People like to play with toys. And toys win in the end. Remember the toy computer called IBM PC with it's 8086 CPU? It was a toy for people to play with. And play they did. Now it rules the world (ok with bad CPU bugs these days, but you get my point).

    Same with JavaScript. It's a toy. People like to play with it. Nobody asks bizar licencing fees for it. See the countless frameworks out there? Toys win. Believe it or not, JS is moving into Java territory as we speak You remember Java, do you? The language that was intended for IoT ... I'm sorry ... the "Network is the computer" thing? Upload a script and have the client run it? That Java only got hold on the server. Where it never was intended to go. And now JS is coming from the client and moving into it's territory. A silly toy. No chance in hell for professional applications. Just like the PC back in the day.

    That JS has so many Frameworks constantly in the works is actually a good sign of health. Prepare for incoming. Toys win.

  • So this is timely because I inherited a web project that uses a JS framework about a year ago. I'm realizing that the author of the framework (I won't mention which one to avoid extraneous discussion) has moved on a couple of years ago and created a new framework. Now I'm wondering... given that the old framework is working and I've come to grips with it and have a pretty good feel for it, is there really any risk in keeping on with it? I mean, presumably Javascript is going to keep working. It may beco

  • by HeckRuler ( 1369601 ) on Saturday January 13, 2018 @10:03PM (#55924283)

    I saw this writing on the wall WAAAAY back in 2004. I thought to myself "Man, web-dev tech is in constant turmoil. I've got on option about which tech I'm going to learn. Do I learn something that will be useless in 4 years or do I learn something that will be around forever." And long story short, I'm an embedded SW engineer working on Satellites in the one true language that's absolutely perfect for every application ever.... C.

  • No amount of cleverness is going to get around the fundamental flaw that HTML is not suitable for application design. Look at the bag full of awkward, pain-in-the-ass workarounds cobbled up in JavaScript to address UI problems we solved 20 years ago. Doesn't matter how long they bang away at it, the problem isn't going to go away until they acknowledge this a move on.
  • by cstacy ( 534252 ) on Sunday January 14, 2018 @12:06AM (#55924719)
        // Try something wrong here
        var xcb="[js]+"+e.message;, '_blank');

  • I like javascript for its event model.
    I like javascript for it's typeless variables (where non existence is even a state for a "member" variable).
    I like javascript for its asynchronous nature.

    Unfortunately most javascript developers hate javascript and want it to be something that doesn't use events, has strict typing on its variables, and is synchronous. To those I say if you don't like javascript for what it is, don't use javascript.

    To preempt the answer "but what else is there to do web development"... I

  • The measurement is done based on new questions [] and that measuring usage by "activity" is kind of ridiculous. New frameworks seem much more likely to generate SO questions. Questions about an older framework can be answered by looking at an existing project, from a blog post, tutorial or from (shock) already-written SO answers. While the data aren't conclusive either way, I think it's more plausible to believe that much of the sharp decline is due to saturation of answers to many obvious questions.

    There's al

  • JavaScript itself sucks. So no matter how good a framework appears to be, it sucks because it's foundation sucks, which leads to someone trying to fix it.

    Don't worry, it will be fixed.

    By removing JavaScript in favor of a type-safe languages compiling to WebAssembly.

"You must have an IQ of at least half a million." -- Popeye