Slashdot Mirror


'The State of JavaScript Frameworks, 2017' (npmjs.com)

An anonymous reader shares some new statistics from Laurie Voss, co-founder and COO of npm (the package manager/software registry for JavaScript): The sum of all the package downloads in the npm Registry shows that the npm ecosystem continues to experience explosive, continuous growth... Right now, we estimate about 75% of all JavaScript developers use npm, and that number is rising quickly to reach 100%. We believe there are about 10 million npm users right now.
The first post in a three-part series graphs the popularity and growth rate for seven JavaScript frameworks.
  • Preact is tiny but the fastest-growing.
  • Vue is also very fast growing and neck and neck with Ember, Angular and Backbone
  • Ember has grown more popular in the last 12 months.
  • Angular and Backbone have both declined in popularity.
  • jQuery remains hugely popular but decreasingly so.
  • React is both huge and very fast-growing for its size.

50 of 114 comments (clear)

  1. FALSE by Anonymous Coward · · Score: 3, Funny

    There is no statistics for the Vanilla JS library.

    Why people continue to use librairies and frameworks in 2018 is baffling. INTERNET EXPLORER IS DEAD, why the fuck are you still dragging megabtes of librairies and frameworks?

    1. Re:FALSE by fluffernutter · · Score: 2

      C is just stupid, Assembler was fully functional on its own.

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    2. Re:FALSE by Actually,+I+do+RTFA · · Score: 1

      Well, compiled down to WebAssembly, but yes.

      --
      Your ad here. Ask me how!
    3. Re:FALSE by fluffernutter · · Score: 1

      Exactly, sometimes higher level is better. It usually depends on precisely the problem you are trying to solve. Same for javascript frameworks.

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    4. Re:FALSE by murdocj · · Score: 1

      C is incredibly portable. If you are getting hung up on "machine-dependent types" you are doing it wrong.

    5. Re:FALSE by Anonymous Coward · · Score: 1

      We have had safe/safer alternatives to C for decades. Things like Algol, Ada and Pascal for example.

      Guess what? Programmers hated them and chose C instead.

    6. Re:FALSE by jlowery · · Score: 4, Insightful

      Node.js developer here. I've written probably 10K+ lines of jQuery code. I wouldn't start a new project using the push-pull DOM based approach jQuery offers. I've written enough React to know it's a far superior, data-driven approach.

      Now, I do use Babel, which is a little harder to defend. At some point, there will be no point in transpiling ES6 to ES5 code. But that moment hasn't yet arrived. Node.js still doesn't support ES6 imports, except in 'experimental' mode. I use them because they have a much cleaner syntax than CommonJS require().

      As for other libraries--why would you rewrite from scratch code that you can obtain from the internet and is well-tested, often written by people more knowledgeable than you? You should be focusing your efforts on your code business, and leave stuff like data-caching, transport, authentication, animation, responsiveness, etc. to people and companies who are actually good at it. The best you can hope for is to spend time rediscovering all the mistakes they encountered.

      --
      If you post it, they will read.
    7. Re:FALSE by dinfinity · · Score: 1

      So is Java, so is C#, so is PHP (it has come a long way -- especially compared to JS).

      Plenty of successful, effective people use frameworks and libraries in projects in those languages.

    8. Re:FALSE by mrun4982 · · Score: 1

      Because we don't like to reinvent the wheel. I worked with way too many people who insist on doing that and it drives me crazy.

    9. Re:FALSE by fireman+sam · · Score: 1

      If people never reinvented the wheel, we'd still be rolling on stone.

      BTW, it isn't always about reinventing the wheel, but rather providing a solution that just solves the problem and doesn't include a bunch stuff that isn't needed. Many javascript developers I've worked with will bring in a third party library to utilise one function in the code. Not only does this increase the resulting code size, it also introduces a dependency on someone else who happens to be maintaining (or not) the package used.

      Oh, and to counter your argument. I've worked with way to many people who were happy to end up with 5+MB of compressed javascript for simple applications, simply because they didn't want to "reinvent" any wheels.

      --
      it is only after a long journey that you know the strength of the horse.
    10. Re:FALSE by h33t+l4x0r · · Score: 1

      Hmm, I like React too but I will still use jQuery unless there's a lot of Javascript involved. Also I'd give them both up and use Flash again if those jerks hadn't killed it.

    11. Re:FALSE by BinBoy · · Score: 1

      Vanilla JS is too expensive.

  2. Great by Hognoxious · · Score: 1

    The three I've heard of are in decline to varying degrees.

    Shoot me. No, get off my lawn and then shoot me.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    1. Re:Great by edittard · · Score: 1

      Don't worry, this year's climbers will probably be next year's lamers.

      --
      At the bottom of the /. main page it says 'Yesterday's News'. Well they got that right.
  3. Frameworks or Limitations of Javascipt? by Anonymous Coward · · Score: 1

    There are so many frameworks and they are all trying to upstage one another. The lessons learned from these frameworks should be incorporated back in ECMA script. For example, the JQuery $() operator would be my first recommendation.

    1. Re:Frameworks or Limitations of Javascipt? by TFlan91 · · Score: 1

      No... Vanilla JS is just fine ty.

    2. Re:Frameworks or Limitations of Javascipt? by Anonymous Coward · · Score: 1, Informative

      $() is just cryptic crap. Don't turn Javascript into unreadable cryptic crap.

    3. Re:Frameworks or Limitations of Javascipt? by Anonymous Coward · · Score: 1

      Don't turn Javascript into unreadable cryptic crap.

      That ship sailed long ago.

    4. Re:Frameworks or Limitations of Javascipt? by murdocj · · Score: 2

      Yeah, that ship sailed when JS was created. funny how people end up building the stuff like classes and objects that other languages give you for free by creating unreadable mounds of Javascript, and then proudly announce that JS is better than those other languages.

    5. Re:Frameworks or Limitations of Javascipt? by Junta · · Score: 1

      Also, $() is a lot slower than the equivalent functions. I will admit to being annoyed by the tedium of the function names, but most editors will do a sane job of completion.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    6. Re:Frameworks or Limitations of Javascipt? by 0100010001010011 · · Score: 1

      But when Perl does it it's suddenly the only True Language?

    7. Re:Frameworks or Limitations of Javascipt? by gbjbaanb · · Score: 1

      when Perl does it, its a feature. If you can't understand it, you're not good enough a coder to work with it.

      Keeps the inferior, amateur and kiddie coders away. After seeing some code submitted by our outsourced department, I wish other languages could do the same.

  4. The more important question: by Gravis+Zero · · Score: 3, Interesting

    How long until there is an ad being served that runs Javascript/Webassembly code that exploits Spectre to steal all your passwords?

    I'm so glad we have "near native" execution speeds for this shit.

    --
    Anons need not reply. Questions end with a question mark.
    1. Re:The more important question: by darkHanzz · · Score: 1

      Firefox has been updated to not have high-resolution timers, so for private use, Spectre shouldn't be much of an issue. Since AMD's post on lkml, someone must have done that already, so 'seven days ago' is probably a reasonable answer.

    2. Re:The more important question: by Miamicanes · · Score: 1

      When, exactly, did web pages acquire the means of compiling random Javascript into literal x86/AMD64 assembly language? Oh wait... they didn't. WebAssembly is just a buzzword for "Javascript gets pre-optimized into slightly leaner & faster-to-execute intermediate code that's ultimately STILL interpreted by something higher-level than the CPU". If that intermediate code can exploit Spectre, then it's the fault of the intermediate-code's interpreter. And if there IS no real way Spectre could be exploited to perform drive-by attacks using Javascript, then I maintain that neither Spectre nor Meltdown is a serious concern (yet) for individual, non-enterprise users, nor does it justify willingly sacrificing a huge chunk of the computer's performance. We're basically being subjected to slowdowns so our corporate masters can maintain the sanctity of the locks they use to keep us from being in full control of our own computers (a/k/a, "DRM").

      Seriously. If I'm logged into Windows on my own computer, that isn't part of an enterprise network or subject to ActiveDirectory policies, with a user account that theoretically has full local admin rights, what -- exactly -- are the patches that suck down 5-30% of the computer's performance actually accomplishing (besides keeping me from being naughty and obtaining DRM decryption keys or bypassing Windows Product Licensing)?

    3. Re:The more important question: by Gravis+Zero · · Score: 2

      When, exactly, did web pages acquire the means of compiling random Javascript into literal x86/AMD64 assembly language? Oh wait... they didn't.

      It doesn't have to be literal because it's a timing based attack. It reads like you don't understand the issue and have no real place commenting here because they even made an example in the whitepaper of using javascript.

      --
      Anons need not reply. Questions end with a question mark.
    4. Re: The more important question: by Miamicanes · · Score: 1

      The PoC might have been written "in Javascript", but that doesn't mean it can be exploited by a random script referenced by an untrusted web page somewhere... there are OTHER, more-privileged ways to "run Javascript code", like Windows Scripting Host, server-side jScript, and probably things like browser extensions, Gnome, etc.

      I maintain... if a script in a web page can break out of its browser sandbox and deterministically read arbitrary bytes in RAM, the existence of these two vulnerabilities is the *LEAST* of our security concerns.

    5. Re: The more important question: by Gravis+Zero · · Score: 2

      The PoC might have been written "in Javascript", but that doesn't mean it can be exploited by a random script referenced by an untrusted web page somewhere...

      Actually, that's exactly what it means. Why do you think they went through the effort of dropping support for high resolution timers? https://hackaday.com/2018/01/0...

      How are you this dense?

      --
      Anons need not reply. Questions end with a question mark.
    6. Re: The more important question: by Miamicanes · · Score: 1

      Ok, I was wrong about the "Javascript in browser is effectively sandboxed" part.

      However, I maintain that the risk presented to end users can be wholly mitigated by an update to the browser itself, and requires no performance-killing changes to the underlying OS to achieve the goals an individual user running Windows on his own computer will actually *care* about.

      Disabling high-res timers appears to have eliminated the problem insofar as disclosure of browser-managed usernames & passwords is concerned. As far as I can tell, the scope of the vulnerability as it relates to web-delivered Javascript NEVER went beyond the address space of the browser process itself (maybe even further limited to the Javascript host process). So once you've eliminated the timers in your browsers, what's left to justify regarding Meltdown & Spectre as anything besides extremely hard-to-exploit multi-stage complex attacks whose primary real-world risks are mostly limited to:

      * enabling users with the ability to run binaries able to defeat constraints imposed by administrators & DRM (or just DRM, if it's truly a single-user non-shared system, and the user IS the computer's local admin)

      * potentially enabling code running within a VM to "break out" and read memory of the host PC (which, in all likelihood, would itself have to be code running at ring 0 on the guest OS's VM).

      Admins of multi-user (or locked-down) computers SHOULD be concerned about the vulns, and admins of servers hosting multiple containers for different entities probably shouldn't sleep until they're patched. But individuals with their own computers? Patch the browser, and scream to holy hell if Microsoft pushes out a mandatory update that slows down your computer for no reason you genuinely *care* about.

    7. Re: The more important question: by Gravis+Zero · · Score: 1

      Ok, I was wrong about the "Javascript in browser is effectively sandboxed" part.

      that is the only part i was arguing. everything else you are saying is irrelevant.

      --
      Anons need not reply. Questions end with a question mark.
  5. a case for frameworks by fluffernutter · · Score: 2

    I've made a couple highly dynamic javascript page with jquery. We're talking a lot of sliding panels being positioned nicely etc. The damn thing worked the same on every mobile device, every browser, anywhere we tried it. I can't see that happening without a lot of testing on native javascript.

    --
    Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    1. Re:a case for frameworks by Actually,+I+do+RTFA · · Score: 1

      What does your page look like with JavaScript off?

      --
      Your ad here. Ask me how!
    2. Re:a case for frameworks by fluffernutter · · Score: 2

      It looks like a message that the user should activate javascript or they can't expect to use the highly dynamic part of the site.

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    3. Re:a case for frameworks by Shados · · Score: 2

      Thanks to aria attributes, ours work just fine (we have some people frequently testing with screen readers)

      JavaScript off is harder, but for actual line of business applications (as opposed to documents), it's just not worth the trouble.

    4. Re:a case for frameworks by Junta · · Score: 1

      One, you'd be surprised how consistent browsers in the last 3-4 years have been.

      Two, 99% of the time if you are using java script to animate, you are failing to use the far more efficient CSS to do the same thing, and more easily degrade to accessible use.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    5. Re:a case for frameworks by mrun4982 · · Score: 1

      Who cares? Unless you're google or facebook maybe, folks who turn off JavaScript aren't worth catering too.

    6. Re:a case for frameworks by cheesyweasel · · Score: 1

      Yeah that's right. In the same way, a lot of MVVM frameworks have patches to make things work on all browsers, and have kind of taken over the job of jquery. All browsers still have nuances that can cause big problems without a lot of testing.. history api is one example.

  6. JavaScript celebrity news by Anonymous Coward · · Score: 1

    Angular is pregnant, Vue was the Maxim hottest framework of the year, and jQuery gained 15 pounds on its vacation, pictures inside!

    You couldn't ask for a better illustration of Alan Kay's statement that most programming is pop culture.

  7. what case? by Anonymous Coward · · Score: 3, Insightful

    You presume anybody but circle-jerking javascript-monkeys wants all that sliding shit.

    Me, I want the content. Preferably still readable using a probably text-only but certainly javascript-free browser. It doesn't have to look "exactly the same" on wildly disparate devices, since I'm not looking at ten different ones at a time. It only has to be readable on this one right before me. And amazingly, that's not a "mobile device" nor a "tablet" or whichever "content consumption device" is the latest fad, but in fact probably a 80x25 screen (in 19", but still), because that's my best shot at being productive, whether it be writing code or writing prose.

    And yes, at the end of the day, serving that content to all comers, not serving it the way your latest fad would have it, but carefully and politely serving it how those website visitors want it, is what ought to lead your "design". Even should I be the last person on earth to still use 80x25 screens, then you still will bow to my wishes and make it work. It does not currently work that way in the 'web, and that deficit is a major reason why the 'web sucks so much it is barely usable at all. Your javascript addiction helps for nothing but worsening the problem. Plus that the wholy "dynamic" shitstack has the staying power of a mayfly, and brings with it a veritable host of other problems besides. But let's explore that some other time.

    Then again, anything that isn't readable the most straight-forward and simple way probably isn't worth my time in the first place. This already became clear with the dark grey on light grey in teeny tiny fonts sizes "design" fad. So carry on, I guess. Anything that disqualifies itself from my attention is that much less to read when I have too much to read already. Carry on.

    1. Re:what case? by Anonymous Coward · · Score: 1

      I'm looking forward to 80x25 on a 40" 4K display. You'll be able to see the hairs on the letter R!

    2. Re:what case? by Anonymous Coward · · Score: 1

      Nobody wants to see the hairs on your R's. (Say it out loud with a British accent for full effect.)

    3. Re:what case? by DahGhostfacedFiddlah · · Score: 1

      You presume anybody but circle-jerking javascript-monkeys wants all that sliding shit.

      While I agree, that's not the point. The point is that a library allows you to create something that works cross-browser and cross-platform without having to test it all yourself. I'm surprised at the high-rated comments here complaining about frameworks in general. Browsers haven't de-balkanized enough that you can just write it and forget it. You need a buffer library between your code and all of the systems that will actually execute it, unless you want to spend half your time debugging browser-specific problems.

    4. Re: what case? by walllaby · · Score: 1

      As a web designer, I'm all for accessible, progressively-enhanced websites. Everything should be accessible without JavaScript.

      But I'm not going to waste my time designing for 0.5% of my client's audience just because they demanded so on a tech blog. And I'm definitely not going to waste my time designing for your use case, since analytics utilities are run using JavaScript.

      tl;dr: Go back to bed, grandpa.

  8. Re:Fuck Frameworks and NPM by murdocj · · Score: 3, Insightful

    You have it absolutely backwards. Coding your own crap instead of using the good, solid, portable, tested code in jQuery is the sign of a code monkey, hacking away until they get something that sort of looks like it works.

  9. Re:Fuck Frameworks and NPM by Njovich · · Score: 1

    Ha, I completely agree with your premise, but I don't think jQuery is really a bad offender in this respect. Basically it's just a way to query the DOM using CSS selectors and some utility functions for working with it that way. Hardly Lego. Some other frameworks are pretty bad in this respect though.

  10. Re:Said it before: Javascript = bs & why by Junta · · Score: 1

    Done correctly, javascript can be a more efficient way of interacting with data server side, both client and server.

    Rendering new whole pages is more expensive than manipulating DOM content to handle updates.

    Now going over the top with ugly animations like a high schooler with power point.....

    --
    XML is like violence. If it doesn't solve the problem, use more.
  11. Re:Fuck Frameworks and NPM by gbjbaanb · · Score: 1

    And even then its a nuisance as they get updated in breaking versions - my mate works with Angular and spits feathers when its mentioned. What incompatible version is it on now? Angular 5?

  12. Re:Fuck Frameworks and NPM by cheesyweasel · · Score: 1

    I feel like that too. But the problem is, browser just aren't fucking good enough. We're restricted by the shortcomings of them, so you have to use other people's code or you'd never get anything written. But it's definitely a good point about using other people's libraries (who use other people's libraries) and so on.

  13. Re:Fuck Frameworks and NPM by Waccoon · · Score: 4, Insightful

    Nothing on the web, including Javascript itself, is good, solid, portable, and tested. If these frameworks were stable, they wouldn't be updated literally every day!

    Most frameworks I've come across are for convenience, not portability. I've had my fill of frameworks that did batshit insane stuff, like testing for features by probing for the browser's trademark name, all in the name of delivering bleeding-edge features for the lazy that shouldn't be used in the first place.

  14. Javascript variable declaration by najajomo · · Score: 1

    What I've always wondered is why didn't they stick with C type declaration?