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.

114 comments

  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 Anonymous Coward · · Score: 0

      This is the year of C++ on the server and client side.

    2. Re:FALSE by Hal_Porter · · Score: 0

      Soon... Soon...

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    3. Re:FALSE by Anonymous Coward · · Score: 0

      Amen. Frameworks are stupid. JavaScript is a fully functional language on its own.

    4. 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.
    5. Re:FALSE by Anonymous Coward · · Score: 0

      depends how you define 'functional' I guess..

    6. Re:FALSE by Actually,+I+do+RTFA · · Score: 1

      Well, compiled down to WebAssembly, but yes.

      --
      Your ad here. Ask me how!
    7. Re:FALSE by Anonymous Coward · · Score: 0

      C should have been thrown on the ash-heap immediately after its inception just because of machine-dependent data types and assembly-style pointer arithmetic. If you're going to work in something higher-level than assembly then it should not, under any circumstances, be machine-dependent.

    8. 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.
    9. 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.

    10. Re:FALSE by Anonymous Coward · · Score: 0

      It took decades to get it there. If it had been dumped earlier we could have avoided the early problems and had a better language now. Even with the added portability features, its closeness to assembly makes it easy to create bugs. C pointers are of the devil.

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

    12. 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.
    13. 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.

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

    15. 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.
    16. Re: FALSE by Anonymous Coward · · Score: 0

      The 5mb argument is bullshit. It's a one-time download for new users, and only if it's not pulled from a cdn and already cached by the browser from a visit somewhere else.

    17. Re: FALSE by Anonymous Coward · · Score: 0

      Ah, so by "it's bullshit" you actually mean "it's not bullshit" but er caching or whatever.

      Fuck you, I'm paying for bandwidth.

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

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

      Vanilla JS is too expensive.

  2. Npm by Anonymous Coward · · Score: 0

    I dont think npm stats can be used to tell what frameworks are truly most popular. Many people "roll thier own" and do not use npm.

    1. Re: Npm by Anonymous Coward · · Score: 0

      I don't think you understand how statistical analysis works.

  3. 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 Anonymous Coward · · Score: 0

      Don't worry about keeping up with all the libraries and frameworks. 90% of frameworks are crappy or redundant. But that's not an excuse not to keep abreast of the 10% worth knowing.

    2. Re:Great by Anonymous Coward · · Score: 0

      No no no no no.

      THEY get off your lawn, and then you shoot THEM. Preferably dead, but severely wounded is OK in a pinch.

      You got a lot to learn about being old.

    3. Re: Great by Anonymous Coward · · Score: 0

      No no no no. That is illegal.

      You shoot a foot and tell them God gave them two. The other is to get off your lawn or lose. Repeat with arms & head.

    4. Re: Great by Anonymous Coward · · Score: 0

      And the 10% worth knowing are...?

      If people agreed on this there wouldn't be so many out there.

    5. 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.
  4. I'm sneaking currency miners into your javascript by Anonymous Coward · · Score: 0

    And I will use encrypted media extentions so you can't block it. Welcome to the javascript zone.

  5. Ember why won't you die? by Anonymous Coward · · Score: 0

    In 2018, Ember, die. Really. I mean it. Die.

  6. 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 Anonymous Coward · · Score: 0

      You mean

      function $(a,x) { return (x||document).querySelector(a); }

      WTF?

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

    9. Re:Frameworks or Limitations of Javascipt? by Anonymous Coward · · Score: 0

      var $ = document.querySelectorAll

      Your are welcome

  7. 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 Anonymous Coward · · Score: 0

      > When, exactly, did web pages acquire the means of compiling random Javascript into literal x86/AMD64 assembly language?

      Chrome has been JIT'ing Javascript down to machine code since its introduction in 2008. So at least since 2008.

    4. 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.
    5. 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.

    6. Re: The more important question: by Anonymous Coward · · Score: 0

      The sandbox relies upon Spectre and Meltdown not existing. The whole point of Spectre is that it doesn't matter how much privilege you are given, you can access arbitrary memory by tricking a process into tricking the CPU into loading that memory into cache. You do this by giving a program like the javascript sandbox, which could be written perfectly under the assumption that Spectre doesn't exist, some input which causes the speculative executor to touch stuff it shouldn't.

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

    9. 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.
  8. Bottom line: by Anonymous Coward · · Score: 0

    Worse than the usual "90% of everything is crud", this is at least five nines of pure "I really don't want any of this in my browser".

    This is your relevance, dear javascript monkey.

  9. 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 FictionPimp · · Score: 0

      What does your website read to the blind? How does it work for the visually impaired?

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

    5. 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.
    6. Re:a case for frameworks by Anonymous Coward · · Score: 0

      CSS has had animations and transitions for about 10 years, you should try it.

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

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

    9. Re:a case for frameworks by Anonymous Coward · · Score: 0

      I've made a couple highly dynamic javascript page with jquery. We're talking a lot of sliding panels being positioned nicely etc.

      On behalf of web users everywhere ... fuck you and your goddamned fucking sliding panels.

      Jesus Christ but web developers focus on pointless fucking shit.

    10. Re:a case for frameworks by Anonymous Coward · · Score: 0

      I guess you love you some Windows Store Apps then huh....

    11. Re:a case for frameworks by Anonymous Coward · · Score: 0

      Nobody cares

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

    1. Re:JavaScript celebrity news by Anonymous Coward · · Score: 0

      most programming is pop culture.

      It's fairly pushy too.

  11. 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: 0

      Unless, of course, the sites purpose isn't about content consumption. Then 80x25 19" green (or is it amber?) screen goes to shit.

    2. 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!

    3. 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.)

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

    5. Re:what case? by Anonymous Coward · · Score: 0

      HTML was supposed to cover that 'works across all browsers' already.

      Everytime I come across a page that doesn't at least tries to display the content with Javascript disabled, I come across a page made by someone who has no business doing webdesign.

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

    7. Re: what case? by Anonymous Coward · · Score: 0

      You, dear monkey, exactly espouse what's wrong with the 'web and "web design"er monkeys.

      You've heard a few buzzwords, but completely misunderstood what the thing was designed for. Of course, the design itself was muddled and sir webinventor has recently again shown himself a muddlehead with the DRM approval. But the idea was that the thing convey content regardless of presentation. Different presentation on different platforms wasn't a bug, it was a feature.

      Enter web designer monkeys chasing the platonic ideal of uniform representation, to the point of disregarding content. Instead of using the technology to make that one thing called content more accessible, you pile oodles and mountains of crud on top of it to chase the semblance of showing off, serving something quite but not entirely unlike content instead. And you still do, carefully couching your rationalisation in percentages this and justifying your hate for content with percentages that. Complete with utter tossery like putting the executive summary on the bottom, as a kick in the behind. "I could've put it on top but made you skip my drivel first."

      And with that, dear monkey, did you and your arrogance nicely make my point once again.

    8. Re:what case? by Anonymous Coward · · Score: 0

      Get a IBM T221. 9.2 million pixels in 22" is enough for everybody. You won't be able to pick out individual characters at un-scaled 80x25. Then curse at the industry when you learn the display was released in 2001 and we still don't have anything better today. You can hack an old T60 laptop part of the way there... Everyone programmer needs one.

    9. Re:what case? by Anonymous Coward · · Score: 0

      lol....No you come across a page that cares more about the application functioning than about a stupid static page.

    10. Re: what case? by Anonymous Coward · · Score: 0

      No JavaScript... no page... sorry but if you donâ(TM)t want the JavaScript then go elsewhere. As a developer and an artist I design applications to look and feel a specific way and I will not cater to users who âjust want the contentâ(TM).

  12. Fuck Javascript by Anonymous Coward · · Score: 0

    This framework fashion show has ruined professional programming. Thanks Javascript.

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

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

  15. 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.
  16. 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?

  17. Welcome to 2018 by fahrbot-bot · · Score: 0

    When /. posts ads and press releases for stuff as stories. Any bets as to if the "anonymous reader" that submitted this is actually Laurie Voss, co-founder and COO of npm - citing herself? /cynical

    --
    It must have been something you assimilated. . . .
  18. frameworks suck. write vanilla by Anonymous Coward · · Score: 0

    Demo with jquery and then rewrite in vanilla to optimize. Preact isn't bad for file size but, like React, the only good things about it are buzzword compliance and that Angular / Vue / Backbone etc are enormous steaming piles of busywork.

    1. Re:frameworks suck. write vanilla by Anonymous Coward · · Score: 0

      Oh get fucked. Name one big project that uses vanilla JS for routing/templating and does it well? All the gumby coders coming out of their hidey holes.

  19. Careful . . . you might trigger the MRAs! by Anonymous Coward · · Score: 0

    Laurie Voss, co-founder and COO of npm - citing herself? /cynical

    A quick Google search reveals that Laurie Voss is male:

    https://www.crunchbase.com/person/laurie-voss

    I don't know anything about him, since I don't pay much attention to Javascript in general, but I just want to prevent a huge whine-fest here on Slashdot, with dozens of victimized MRAs sobbing about how unjust it all is, before it happens.

  20. Re:Fuck Frameworks and NPM by Anonymous Coward · · Score: 0

    So, the old style programmers who were very happy to have written frameworks that saved them having to write windowing code for the IBM 300 (IIRC, it's not my work, and it's been a bit), so that they could deal with the functional parts, and so that they could optimize the framework, so that they could save a quarter K of program space in the framework, to free up 4K per module that plugged into the framework over having it separated were wrong?

    A framework, much like the basic framing of a house, can be good or bad. But also much like it, if you don't have that basic framing, it is far more involved to get the same results, and while you might be able to make a more bespoke, efficient product, it takes far longer, and there is much more importance in what is built on that framework, unless it's terrible (like a lot of these programming frameworks are).

    So, deride the poor quality frameworks, and the programmers who can't do anything but stick bits of them together, but don't ignore the craftsmanship that goes into a good framework, or the utility from a well made one.

  21. "Good frameworks" by Anonymous Coward · · Score: 0

    good framework

    There is no such thing. All of them are high-overhead shitheaps.
    Abstractions on top of JavaScript are bad enough as it is, throwing these horribly written libraries on top makes it even more painful.
    None of these fucking developers seem to understand the very foundation of how JavaScript works and how to optimize their libraries for that. Scope-abuse in libraries is rife, which is one of the slowest things in JS. Next is usually the DOM that gets abused by most libraries that interact with it.

    JavaScript can run incredibly fast if you actually steer clear of deeply nested enclosures.
    It's the reason Gmail got slow all of a sudden years back. It's the reason Google Maps got insanely slower on older devices the other year when they shat out that disgustingly inferior version.
    It's the reason Facebook is hilariously slow on what was considered a mid-tier gaming machine of 5 years ago. Their templating engine is so slow. Go figure they have the worst apps as well.
    And if you are interacting with the DOM, cache everything and do bulk writes. Real-time updates of the DOM are so incredibly slow it boggles the mind as to why browser vendors haven't tried to fix it since the damn thing is used all the time. (same goes for enclosures!)
    It's the single reason that good complex web-apps aren't possible because uploading loads of page geometry at once simply cannot be done well.
    This is why more and more developers are moving apps behind Canvas because it has NONE of the overhead the DOM has. Canvas can run UE4 for crying out loud. The DOM can barely handle a complex spreadsheet even by a good developer.

    Library developers are of the mindset "lol throw more cores at it!". That's the kind of people they are.
    They are the kinds of people that can barely make an online FPS game run over multi-megabyte down and up without horrible lag whereas good developers could make FPS games run on 56k!
    This is the kind of people that have taken over our industry. They have ruined it with their shitty code.
    The massive flood of Indians in recent years certainly hasn't helped. They take courses on how to search Stackoverflow for solutions. I shit you not. It's a joke.
    They are also the reason Windows 10 is so awful, none of them know how to fucking code which is why they hacked a new UI on top of Windows to abstract away from the "antiquated DLLs". It's why Win10 has such a horribly inconsistent, redundant interface. It's legit shit.

    1. Re:"Good frameworks" by Anonymous Coward · · Score: 0

      Thank you. I have my own small libraries that I guess are sort of like frameworks but I agree with everything that you said. So much of the web is unusable these days for no good reason. Some monkey just tosses together 40MB of jQuery that worked with Chrome 99++XP and fuck anybody on yesterday's browser or a residential ISP. It's maddening.

  22. Re:Addendum vs. BOGUS downmods (Fact)... apk by Anonymous Coward · · Score: 0

    You triple posted the same BS of course they'll downmod you if you spam

  23. Said it before: Javascript = bs & why by Anonymous Coward · · Score: 0

    See subject: Clientside script defeats client-server model logic (running script clientside raising your powerbill). CGIBin/WinCGI does same serverside (ISAPI/NSAPI libs/dlls too) NOT RAISING CLIENTSIDE POWERBILL (sucking up YOUR cpu cycles, RAM & other forms of I/O doing so).

    Clientserver is ALL ABOUT THAT (making it better for you as the client the important consumer of info). Idea being a client ONLY ASKS A QUESTION (nothing more) to GET BACK ANSWERS from servers (web/db).

    * Javascript's rampantly abused to deliver malware & tracking!

    APK

    P.S.=> I block 3rd party scripts via APK Hosts File Engine 10++ SR-1 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/ (works long before NoScript "script src" tag parse & does more MORE efficiently blocking script source in faster kernelmode (vs. slow usermode layering on browsers increasing messagepass overhead))

  24. Re:Done 'correctly' = TRUE client-server model by Anonymous Coward · · Score: 0

    Wow.. dude, you're a fucking twit. You're the kind of old coder that gives the rest of us a bad name. Be rational about all of the positives and the negatives, and stop trying to justify your choice not to learn something new.

  25. Re:Wow.. WebDOUCHE, you LOSE, lol... apk by Anonymous Coward · · Score: 0

    Get help man.. go socialise with people more and stop sounding like a narrow minded fuckwit like most of the people in the news and on the internet.

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

  27. Speak for yourself "expert of life" wannabe by Anonymous Coward · · Score: 0

    See subject: Tossing names @ me & you not proving my points wrong is all I need to dust your sorry ass, lol - & you know it.

    * Thanks for proving what I wrote is truly, unassailable...

    APK

    P.S.=> I'm also like NOBODY you've ever met on the internet (especially vs. MOST around here (there ARE exceptions that actually DO good things, very few though))... apk

  28. Aurelia.io by Anonymous Coward · · Score: 0

    Another quite powerful framework that is ECMAScript6 compatible and uses very little boiler-plate code .... similar to VueJS is : Aurelia.io.

    Just want to mention it as that team has done a very nice job on the framework.

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

  30. "Opinionated frameworks" by Anonymous Coward · · Score: 0

    Stuff like Ember.js. You have to write code their way: Don't wander from the narrow path otherwise it'll bite you in the ass.

    Used Ember on a couple of projects and it was the most frustrating experience I think I've ever had with a JS framework. Bearing in mind that doing any JS framework builds in the last couple of years should come with a free pass to a psychiatric hospital.

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

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

  32. Re:Fuck Frameworks and NPM by Anonymous Coward · · Score: 0

    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!

    If { glibc, the Linux kernel, GCC, clang } was stable, it wouldn't be updated literally every day!

  33. Dear UNIDENTIFIABLE anonymous whimp by Anonymous Coward · · Score: 0

    See subject: You don't LISTEN do you? Told you I won't LET you block me (try it I just repost, you lose) https://developers.slashdot.org/comments.pl?sid=11574857&cid=55876787/ & until ANYONE validly disproves points I made in that link I just posted (same one you keep "downmod hiding" out of fear)? You WILL keep losing vs. me & PROVING I am correct!

    (So much so you had to 'downmod hide' my post which exposes your CROOKERY!)

    *... & you KNOW it...

    LOL - your DUMB ASS tried to effetely 'downmod hide' THIS VERY SAME POST TOO (I defy you, dumbass, easily) -> https://developers.slashdot.org/comments.pl?sid=11574857&cid=55876855/ chump!

    APK

    P.S.=> WebDOLTS - you're ALL the same & VERY EASY to outsmart (proof of it is your downmod hiding my posts YET YOU'RE UNABLE TO PROVE MY POINTS WRONG in the posts you downmod hide, lol) - thanks - you make me all the more correct in your whimp actions (it's all you know as it's ALL YOU ARE, whimps) & I, unlike most ac posters, can keep it up ALL DAY LONG w/ out end (no limits here overriding your 1 effete useless 'weapon' - the bogus downmod, lol) ... apk

  34. Done correctly = TRUE client-server model by Anonymous Coward · · Score: 0

    See subject: Correctly for END USERS by NOT pushing costs onto users/customers/consumers in higher powerbills + malware via javascript - period.

    * YES - That's from a CONSUMER viewpoint (& we're ALL consumers - yes, even business owners pushing their powerbill being higher via CGIbins/WinCGI (or NSAPI/ISAPI) done serverside onto USERS having THEM BEAR THE COSTS (albeit distributed across millions of users vs. the business themselves shouldering the load)).

    Is TRUE clientserver webside "bad" for companies? Yes. See the above (higher power consumption cost running all work serverside vs. distribution to users (violating GOOD clientserver design)).

    I see advertisers FINALLY trying to do it lighter as you describe (or they will die & my last post shows ME helping that happen in its termination via my work for GOOD reason (the ABSOLUTE GOOD as we're ALL consumers)).

    They are STILL failing for what I have noted in violation of SOLID good clientserver design... for "the HOLY dollar" (which I do understand also from their POV as business owners trust me (I own my own business)).

    Lastly U FAIL trying to 'downmod hide' last time I posted this https://developers.slashdot.org/comments.pl?sid=11574857&cid=55876361/

    APK

    P.S.=> BET you're a "web developer" & how do I know it? You try 'champion' a model that ultimately HURTS users on many levels noted (yes U included & u KNOW it but u profit by it by the same token - I understand UR motives) I don't blame u if it's your livelyhood but ur motives = suspect!

    I spent DECADES as a client-server dev business side on INTRANET business app in-house usage cross-platform to IBM midrange & mainframe systems from MSVC++, Delphi or VB to do so often to ORACLE, IBM DB/2 or SQLServer DB's (not much diff. vs. webdev except WE ACTUALLY BUILD PROGRAMS & we were TOLD client merely ASKS A QUESTION & server DOES WORK (best for users)) via StoredProcs (keeps work serverside for reasons noted FOR THE GOOD OF USERS - not other way around as webmasters espouse for MONEY))... apk

  35. Addendum vs. 3 BOGUS downmods (Fact)... apk by Anonymous Coward · · Score: 0

    I've been UNJUSTLY DOWNMODDED 3x for truth/facts https://developers.slashdot.org/comments.pl?sid=11574857&cid=55875603/ & https://developers.slashdot.org/comments.pl?sid=11574857&cid=55875663/ + MOST IMPORTANTLY https://developers.slashdot.org/comments.pl?sid=11574857&cid=55876507/

    You give away I'm correct - Who are you fooling?

    Webmasters including the owner here do NOT want you knowing this (if you can't figure it out yourselves minus me telling you) & WHO REALLY "RUNS THE SHOW" HERE?

    Google!

    Google = whipslash's BIGGEST financier!

    I also know who comes here too that also do NOT want my truths seen:

    Webdevs/webmasters on a 'payroll' of GOOGLE'S ADS!

    (... & of them a good 50% are GOOGLE shills keeping truths from you all - especially what's in THIS POST nigh constant downmods of my posts hiding behind their UTTER deceit as advertisers)).

    APK

    P.S.=> Truer words were NEVER spoken & you know it (Via bogus downmods of my posts FACT + TRUTH so powerful it scares you so you try 'hide' it - I won't let you)... apk

  36. Wow.. WebDOUCHE, you LOSE, lol... apk by Anonymous Coward · · Score: 0

    You're a NOOB that gives the rest of us a bad name. I was rational about all positives (BUSINESS side reaming clients online via javascript serving malware & using their electricity to do it violating clientserver design logic & efficiency FOR USERS) & negatives (rips off clients who are ignorant of javascript delivering malware + raising powerbills on them), & stop justifying your POOR LIMITED SKILLS choices not learn WHAT I SAID (which is PUREST TRUTH/FACT) vs. your BUSTED TO SHIT "something new" that's utter garbage & a businessman's DECEITS!

    HOW CAN I SAY THAT?

    ABSOLUTE GOOD is for ALL consumers (we are ALL that, even businessmen, advertisers, webmasters) & javascript hurts ALL consumers as I noted. Exactly thus.

    *... & I am a business owner myself, but I do NOT operate like THAT (bogusly).

    APK

    P.S.=> Lastly - I guarantee I was doing programming (REAL coding as MINUS PROGRAMMERS LIKE ME OF APPLICATIONS YOU DON'T HAVE A BROWSER TO MERELY SCRIPT doing 'webdouche crap' a kid can learn) & I did even "webchump" bullshit BEFORE YOU WERE BORN probably (easy text formatting & placing images, lol, in tags & @ MOST closest you come to 'coding' is executing scripts against DB's HOPEFULLY stored in a variable & if done REALLY RIGHT executed vs. a stored procedure precompiled for more speed DB side (god knows your SLOW javascript CRAP needs it)_... apk