Slashdot Mirror


Stack Overflow Stats Reveal 'the Brutal Lifecycle of JavaScript Frameworks' (stackoverflow.blog)

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

14 of 165 comments (clear)

  1. And maintainability? by plopez · · Score: 4, Interesting

    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.

    --
    putting the 'B' in LGBTQ+
    1. Re:And maintainability? by 110010001000 · · Score: 4, Insightful

      You throw it away and start over. There are a million JavaScript monkeys out there that are willing to do it. It keeps them busy.

    2. Re:And maintainability? by Anonymous Coward · · Score: 5, Funny

      Like for security?

      Javascript doesn't support security, so that's a non-issue

    3. Re:And maintainability? by PolygamousRanchKid+ · · Score: 4, Informative

      What happens if you need to patch or upgrade in a few years?

      In this nude gig based economy, no one stays at a job long enough to do maintenance. Once the gig is shipped, you'd best already have moved to a new job.

      It's kinda sorta like a combination of Bitcoin pin the tail on the donkey. The last one holding Bitcoin before the crash loses, as does the donkey last original developer to leave the company, who gets all the defects pinned on him.

      Maintenance will be outsourced to India or China.

      --
      Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
    4. Re:And maintainability? by Anonymous Coward · · Score: 3, Insightful

      All the effort people go through to design a site with shittons of flashy interactive bullshit, then I come along and strip every last bit of it out with adblock filters until the page is nothing but a 5 kb text file with just the info I actually came to see.

    5. Re:And maintainability? by cascadingstylesheet · · Score: 4, Interesting

      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.

      Well, you could just keep using jQuery like we do. It's still maintained and developed.

      It won't get you 100 recruiter calls a day, but hey.

  2. What does this say about Javascript? by mykepredko · · Score: 5, Insightful

    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.

    1. Re:What does this say about Javascript? by plopez · · Score: 4, Insightful

      Obscure code is bad code. If you can't do it simpler you;
      1) are using the wrong tools
      2) Don't know what you are doing
      3) don't understand the first thing about programming, which is 90% of the cost of a program is maintenance
      4) trying to be clever, which is stupid

      I hereby sentence you to 5 years maintnce programming on code produced by clueless programmers like yourself.
      (odds are in 6 months you won't be able to fix you own code.)

      --
      putting the 'B' in LGBTQ+
  3. Re:Still just using jQuery/UI by guruevi · · Score: 3, Insightful

    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.

    --
    Custom electronics and digital signage for your business: www.evcircuits.com
  4. Vanilla.js still keeps it's #1 position by dremon · · Score: 3, Interesting

    As the fastest and leanest framework

  5. Try Mithril and Tachyons by Paul+Fernhout · · Score: 3, Interesting

    As a once Delphi programmer, that is one reason I like the combination of JavaScript/TypeScript, the Mithril vdom https://mithril.js.org/ (which uses a "HyperScript"-like API to define HTML via code), and Tachyons http://tachyons.io/ 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.

    --
    A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
  6. Vue by richardtallent · · Score: 5, Interesting

    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.

  7. Re:Still just using jQuery/UI by Paul+Fernhout · · Score: 3

    Yes; thus Rich Hickey's talk on "Simple made Easy": https://www.infoq.com/presenta...
    "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.

    --
    A 21st century issue: the irony of technologies of abundance in the hands of those still thinking in terms of scarcity.
  8. StackovweOverflow Javascript by cstacy · · Score: 5, Funny

    try{
        // Try something wrong here
    }
    catch(e){
        var xcb="http://stackoverflow.com/search?q=[js]+"+e.message;
        window.open(xcb, '_blank');
    }

    // https://github.com/gautamkrishnar/tcso/blob/master/javascript/tcso.js