Slashdot Mirror


Which JavaScript Framework is the Most Popular? (infoworld.com)

An anonymous reader quotes InfoWorld's report on which JavaScript frameworks are the most widely-used: In a study of 28-day download cycles for front-end JavaScript frameworks, NPM, which oversees the popular JavaScript package registry, found that React has been on a steady upward trajectory; it now accounts for about 0.05 percent of the registry's 13 billion downloads per month as of the fourth quarter of 2017. Web developers as well as desktop and mobile developers are adopting the library and it has spawned an ecosystem of related packages. Preact, a lightweight alternative to React, also has seen growth and could become a force in the future.

On the down side, Backbone, which accounted for almost 0.1 percent of all downloads in 2013, now comprises only about 0.005 percent of downloads (about 750,000 per month). Backbone has declined steeply but is kept afloat by the long shelf life of projects using it, NPM reasoned. The jQuery JavaScript library also remains popular but has experienced decreasing interest. Angular, the Google-developed JavaScript framework, was the second-most-popular framework behind React, when combining the original Angular 1.x with the rewritten Angular 2.x. Version 1.x was at about 0.0125 percent of downloads last month while version 2.x was at about 0.02 percent. Still, Angular as a whole is showing just modest growth.

They also report that the four JavaScript frameworks with the fastest growth rates for 2017 were Preact, Vue, React, and Ember.

But for back end services written in JavaScript, npm reports that Express "is the overwhelmingly dominant solution... The next four biggest frameworks are so small relative to Express that it's hard to even see them."

33 of 161 comments (clear)

  1. Vanilla-JS.com by ChunderDownunder · · Score: 5, Insightful
    1. Re:Vanilla-JS.com by holostarr · · Score: 4, Insightful

      Yea, try building and maintaining a large scale application using nothing more than vanilla JS. The reason JS frameworks are popular is because they do a whole lot of stuff behind the scenes like variable binding, efficient rendering of the DOM (for example virtual DOM), implementation of patterns such as MVVM, state management, routing, and a whole lot more. There is no way you could build an application such as Youtube or Facebook without some sort of a framework; best case scenario you will end up rolling your own, at which point why not just use one of the many existing ones with a community support and a full time team that is focused solely on the framework development. Unless you are a very large corporation with lots of resources such as Google or Facebook where you can devote resources to building and maintaining your own framework, it doesn't make sense to roll your own. You will make something that works, but works badly and perhaps with lots of security vulnerabilities compared to one of the major frameworks.

    2. Re:Vanilla-JS.com by holostarr · · Score: 3, Insightful

      Try making a compelling reason to the management that they need to hire a team of say 2 developers, a project manager, and a QA just to build and maintain an in house JS framework, when there is a plethora of frameworks out there! Large corporations like to focus on areas that is relevant to their business, and for most building an in house JS framework is not relevant. Facebook and Google do it because they are sufficiently large, and they are in the business of platform as a service, so they provide tools and frameworks to attract developers to their platforms. They are also on top of the food chain so they are big enough that they need to invent solutions to their unique problems, because they are constantly trying to push technology forward.

    3. Re:Vanilla-JS.com by evileeyore · · Score: 2

      But then again, you can also make the app 100 times smaller than using these grossly bloated frameworks.

      You really should learn how modern JS applications work, my code has 0 extra "Bloat" code because it is removed during build / compile of the system.

    4. Re:Vanilla-JS.com by WaffleMonster · · Score: 2

      If you application is well written and there is a good separation of business logic from the UI, then 2 to 3 year lifespan for a framework is pretty good.

      This is fucking insanity.

    5. Re:Vanilla-JS.com by WaffleMonster · · Score: 2

      No one is forcing you to rewrite your application using the latest fad framework!

      Developing a product using components only supported for 2 or 3 years is totally insane.

      You have access to the source after official support ends and can continue to modify it and use it for development it as long as your heart desires!

      Official support is the point.

      But if you want the latest, most cutting edge features, then you might want to rewrite your presentation layer using a newer framework.

      What specifically do you get in return for a critical dependency only being supported for 2 or 3 years? Are there new conceptual advances in UI design requiring cutting edge support libraries to implement?

  2. But they all force Javascript on users by cjonslashdot · · Score: 3, Insightful

    What if the user does not want to use Javascript, for security reasons? Javascript is the primary vector for a large percent of malware infections. Yet, with single-page web apps, one has to enable Javascript to see anything. Not so with websites such as the NY Times and other major news sites; why should it be with company XYZ site? Javascript has destroyed the Web, but with the latest frameworks we are shoving it down people's throat.

    1. Re:But they all force Javascript on users by holostarr · · Score: 4, Interesting

      Every time there is an article about Javascript, there is an individual like you complaining about why Javascript is needed. I'm sorry that all you want to use your browser is to read news on NY Times, but the truth is that there are a lot of people out there who want to do more than just browse static pages. The browser is the most efficient app delivery system today. You no longer have to worry about whether the end user has the latest update of your app, and which OS or version they are running, your app will just work! If you are paranoid and don't trust the browser sandboxing, then maybe you should run Qubes OS or browser in a VM, otherwise, perhaps it is best to stick to printed news.

  3. This one! ;-) by ls671 · · Score: 3, Insightful

    This one:
    https://en.wikipedia.org/wiki/...

    No seriously, wasn't there an article here a few days ago saying that the most popular js framework changes every six months and that things become a major cluster-fuck? I also remember an article saying that third party js libs loaded from third party sites sometimes disappear when the developer decides to pull them off. With regards to that, I always tell my devs not to load from third party sites and to download and install locally instead. It is also less scary for people with uMatrix or noscript looking at your site!

    --
    Everything I write is lies, read between the lines.
    1. Re:This one! ;-) by i_ate_god · · Score: 2

      yes, but this iteration is a bit different.

      In the past you had rather different concepts at play. Roll your own solution with jQuery (which is nothing more than a functional approach to the DOM), Backbone, Angular, Ember, etc. All quite different in concepts.

      React and Vue however are far more similar and are now the dominant frameworks. Seems the community is coalesced around a single concept and have two different approaches to it. Vue is better imho because it's syntax is so much cleaner.

      > I also remember an article saying that third party js libs loaded from third party sites sometimes disappear when the developer decides to pull them off.

      Nexus supports NPM so this is an irrelevant problem. You should be using a cache between your tech stack and its main repo, whether it's npm, pip, maven, nuget, composer, etc...

      --
      I'm god, but it's a bit of a drag really...
    2. Re: This one! ;-) by Dog-Cow · · Score: 2

      It’s the extra apostrophe’s killing bandwidth.

  4. Fleeting popularity . . . by PolygamousRanchKid+ · · Score: 4, Funny

    Which JavaScript Framework is the Most Popular . . . ?

    What day of the week is it . . . ?

    This is more of a question for a celebrity poll on tmz.com.

    We live in a throwaway society. We begin each day by tossing out yesterday's JavaScript Framework, and replacing it with something new that promise to taste better, and last longer!

    --
    Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
    1. Re:Fleeting popularity . . . by jrumney · · Score: 2

      Looking at the figures (0.05%, 0.1%, 0.02%) the correct answer to the headline seems to be none. They are all decidedly unpopular.

  5. Angular of course. by Anonymous Coward · · Score: 5, Funny

    I sat the team down and said were moving to Angular 14. They said it moves to fast and we wouldd always be updating if we put in Angular 17. I said nonsense, we were putting in Angular 23 and that was final!

    1. Re:Angular of course. by rudy_wayne · · Score: 2

      I sat the team down and said were moving to Angular 14. They said it moves to fast and we wouldd always be updating if we put in Angular 17. I said nonsense, we were putting in Angular 23 and that was final!

      Best comment ever.

      +10

  6. back end servicesin JavaScript by dehachel12 · · Score: 4, Interesting

    But for back end services written in JavaScript. WHY ???

    1. Re:back end servicesin JavaScript by KiloByte · · Score: 5, Insightful

      But for back end services written in JavaScript. WHY ???

      For JavaScript developers, if all they have is a pillow, every problem looks like a nail.

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    2. Re: back end servicesin JavaScript by K.+S.+Kyosuke · · Score: 3, Insightful

      Nodejs is pretty decent for backend. You can do a lot in few lines of code. Takes a while to get used to the asynchronous model

      Seriously? There's nothing wrong with "the asynchronous model" but you certainly can't "do a lot in few lines of code" if you're writing what is effectively CPS code in an unsuitable language. Also, lack of composability.

      --
      Ezekiel 23:20
    3. Re: back end servicesin JavaScript by Junta · · Score: 2

      I will say the async model frequently leads to a mess that's hard for most developers to wade through. It's ok when the flows have one or two step interactions, but as a flow involving IO gets more involved, it devolves to an indecipherable mess.

      --
      XML is like violence. If it doesn't solve the problem, use more.
  7. NIH Framework by 0100010001010011 · · Score: 3, Funny

    I've been in multiple software industries for ~10 years. The NIH framework has been universally accepted everywhere.

    • Does everything the other frameworks don't.
    • Does everything you need.
  8. Sadly, this is how we make decisions on frameworks by MobyDisk · · Score: 3, Insightful

    This seems to be the way we make decisions on frameworks these days. Survey what is most popular and pick that, in the hopes that someone will still be using it and supporting in 3 years. This isn't a good thing. It makes me think of the Has open source changed the world? and npm spam flag discussions. Open source is fine, but we need some commercial entities standing behind these things. We have really good infrastructure and really good tools. But now we need stability. We can't have frameworks changing this fast, and minor errors causing the entire world's IT infrastructure to hiccup.

    Some suggestions if you are creating an important commercial product or web site:
    * Keep a local package cache (npm, nuget, rpm, deb, apt, yum, MSI, ...)
    * Don't lock-in to any infrastructure that you aren't paying for (CDNs, "free" cloud services, "free" email services)
    * Give back to the open-source community, don't just siphon from it (or it won't be there in the future)

  9. Skyscrapers, Sandy Beaches and JavaScript by Anonymous Coward · · Score: 2, Insightful

    I'm a systems developer at heart, but I've had to do some web apps in more recent times, and I've found that building an application on top of JavaScript is like building a skyscraper on a beach. You can do it, but you have to dig all the sand out of the way first and make your foundation firm. Node.js is an example of one way I've seen it work. But web apps are by nature building a sand scryscraper on top of a sandy beach, especially if you are using frameworks. You rely on the browser not to have any bugs, then that there aren't any bugs in the framework, and finally that your JavaScript is a clean implementation of {{framework_of_the_month}} and that the custom code you had to write to handle {{unreasonable_customer_feature}} doesn't break somewhere in the patch cycle (why you should ALWAYS host your own scripts, including frameworks).

    At one point, it was easy enough to build a site using HTML, CSS and JavaScript. Then we added JQuery to take out a lot of the boilerplate we kept writing. And along came Angular, because people wanted to do more and write less code over and over again. Understood, but with each implementation, our customers kept walking in with more demands (wet sticks) and asked us to build bigger fires. So we did things that broke the frameworks. No problem, create new frameworks to handle those situations. Now we are to the point where developers have become so entrenched in our frameworks that we forget that small things can still be handled with HTML, CSS and JavaScript.

    I'm starting to get into wasm now, and I'm hoping beyond hope that it will replace a lot of what is now handled in frameworks, especially since it is backed by standards that the browser developers can work towards.

  10. Explain your reasoning please by Anonymous Coward · · Score: 2, Insightful

    How does "code signing by well-known big commercial parties in the business" help with... wait for it... this one user complaint:

    <strong>
    <em>
    <marquee>
    <blink>
    "I DO NOT WANT ANY JAVASCRIPT"
    <blink>
    <marquee>
    <em>
    <strong>

    Do tell. I'd be very interested to see how your reasoning manages to conclude anything other than "it does not help at all".

    At best it means that you've handed that much more power to large corporate interests, because now they own the keys to the code. But it still means you're forcing javascript down your users' throats, and they just said they didn't want any.

    And they didn't want any, because they don't know what's in there. Code signing only means that you know some other party signed it, not what they put in there. And if you infer (it's really only inferrence, nothing more) that they'll only do that with code that's good for them, it still doesn't follow that it must therefore be good for you, too. So code signing is not a viable solution to any such security problem. Same with, inevitably, "TPM/Palladium", "UEFI secure boot", and so on, and so forth. Same discussion, same bullshit. In fact, it's also (just one of many reasons) why PKI is so terminally broken.

    So, given all that, how do you justify code signing anyway? Explain your reasoning please.

  11. If I had to offer a guess, I'd say... by QuietLagoon · · Score: 2

    ... uBlock.

  12. NoScript by DrYak · · Score: 5, Informative

    Remember, Mozilla was bribed to cripple noscript on Firefox.

    Huh?
    Giorgio Maone *did* successfully port NoScript to the WebExtension engine. I'm using it right now.
    What are you complaining about ?

    (and the other "internet condoms" like uBlock Origin, Privacy Badger, etc. are also all available as WebExtensions as well)

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  13. The one with the best GC by Snotnose · · Score: 2

    Any Javascript framework with decent garbage collection will know to bury itself 6 feet under, cuz javascript is by definition garbage.

  14. Re:In search of a problem by Lunix+Nutcase · · Score: 4, Insightful

    The problem was not enough shitty Javascript in the world. Now the same incompotent monkeys can not only write insecure front-end code, they can also write the insecure back-end code, too!

  15. What is NPM? by pedz · · Score: 3, Insightful

    Seriously... first, don't they need to demonstrate that NPM is what most developers are using? I don't use it. I deploy my javascript such as jQuery by pulling down a copy and embedding it in my app. It seems a more reasonable approach to understanding the current state of Javascript is to ask the spiders that crawl the web and see what packages they encounter.

  16. Change like their underwear by gabrieltss · · Score: 4, Insightful

    People change JS frameworks like they change their underwear. One week is one library, next it's a different one.
    In one year a company I was with had 50 different apps with 50 different JavaScript libraries I swear. Who THE FUCK is going to support all of that mess? Managers should be slamming keyboards on developers hands! Pick one and stay with it - quick FUCKING changing them all the time. Just because some A-Hole thinks they can re-invent the wheel or thinks they are being cute - we get a new JavaScript library. Message for all of you STOP THIS SHIT! We have enough of them already! Why don't you all get together and pick one or two and make them better instead of creating a new one. You want to write your own as a hobby - great - leave it on your system for your hobby purposes! Better yet, help out on an existing one to make it better.

    Seriously - why do people STILL think this language is so great. It's POS! Pick the latest JS library - they all come from the same root Language. One that was written in 10 days! Hell even the company that had it developed didn't even implement it properly. And now people think we should run it on the server side. WHAT THE FUCK is wrong with you? I DO NOT allow server side JS libraries on MY servers - PERIOD! You want to code on the server - use a REAL language! JS libraries come and go WEEKLY! I've been developing for over 32+ years - I DESPISE the thing. I avoid it like the plague. It only gets used when I absolutely have to.

    The only people that were in total love with JS is/was the PORN industry!

    --
    The Truth is a Virus!!!
  17. Some reactJS problems... by Parker+Lewis · · Score: 3, Insightful

    I joined a reactjs/flux project some months ago. I properly learned how it works quickly, and liked the idea. Several years ago I've worked with desktop UI apps (in C++, later Java/Swing and C#), so I had no trouble with the idea.

    But then I tried to create, like in the GUI desktop world, when you have a nice hierarchy of components/containers, a parent component that will have most the logic, then 2 children classes, including only the different logic. First wall: the same guides in other crap OO language/frameworks. "you're not supposed to use inheritance, you need to use composition ".

    The most irritant issue: of course, several things that worked in the past with reactJS simple were removed or are under constant changes. I can even handle that, but the problem: a LOT of the erros and warnings just don't handle a stack. They simply give you a warning/error message and you'll have to dig in the code where it was raised. Again, terrible OO.

    Even flux it a weird flow, because it relies in a dumb event system: just a big pipe raising all events. If you want to listen for an event, you need to plug into this big pipe, listen all events and use a switch/case to get the ones your component wants.

    Not to mention some repeat-code-everywhere approach, when you have thousands contants that are just the same string as the constant. This for a dynamic language... i.e., people will make a typo in the name of the constant too and nobody will notice.

    I can just saw that JS turned the new PHP: developers that don't want to proper learn how to code everywhere with "brilliant ideas".

    1. Re:Some reactJS problems... by Parker+Lewis · · Score: 3, Informative

      If you really used GTK+, Qt, wxWidgets, WinForms in C#, etc, I'm sure you'll be familiar with GUI hierarchy, as all of those you've cited are based on inheritance hierarchy, and if you've used them seriously, you probably created re-usable components inheriting any other component. And, funny, any reactJS component is inheriting a reactJS component too. It's just so bad designed that it supports just 1 level of inheritance.

    2. Re:Some reactJS problems... by Lunix+Nutcase · · Score: 3, Insightful

      ...In desktop GUI programming, inheritance is used very rarely, ... I can only speak for GTK+, Qt, wxWidgets, WinForms in C#, etc.

      And you speak poorly about them. Qt, for example, uses inheritance all over the place in its widgets.

      Just one example: QPushButton inherits from QAbstractButton which is inherited from QWidget which inherits from QObject.

      You also are wrong about WinForms:

      Let's look at the Button class:

      Inheritance Hierarchy
      System.Object
      System.MarshalByRefObject
      System.ComponentModel.Component
      System.Windows.Forms.Control
      System.Windows.Forms.ButtonBase
      System.Windows.Forms.Button

      I could go on but I won't. You couldn't have been more wrong if you tried.

  18. I'm thiking NFJS is for me... by AmazingRuss · · Score: 2

    No Fucking Java Script!