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."
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."
http://vanilla-js.com/
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.
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.
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.
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)
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.
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
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.
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!
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.
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!!!
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".