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

Comments

FALSE

[Anonymous Coward]

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?

Re:FALSE

[fluffernutter]

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

Re:FALSE

[jlowery]

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.

The more important question:

[Gravis Zero]

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.

Re:The more important question:

[Gravis Zero]

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.

Re: The more important question:

[Gravis Zero]

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?

a case for frameworks

[fluffernutter]

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.

Re:a case for frameworks

[fluffernutter]

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.

Re:a case for frameworks

[Shados]

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.

what case?

[Anonymous Coward]

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.

Re:Fuck Frameworks and NPM

[murdocj]

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.

Re:Frameworks or Limitations of Javascipt?

[murdocj]

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.

Re:Fuck Frameworks and NPM

[Waccoon]

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.