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

161 comments

  1. cease fire stand down by Anonymous Coward · · Score: 0

    it only works if everyone does it.. our kids deserve better from us.. thanks

    1. Re: cease fire stand down by Anonymous Coward · · Score: 0

      LOL rusty sheriffs badge. I'm done. Mod up

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

      Show us links to your code. I'm interested in seeing your enterprise grade vanilla js software. ;)

    3. Re:Vanilla-JS.com by K.+S.+Kyosuke · · Score: 1

      Who builds and maintains "a large scale application" who isn't "a large scale corporation"?

      --
      Ezekiel 23:20
    4. Re:Vanilla-JS.com by Anonymous Coward · · Score: 1

      So does using frameworks. The decay rate on frameworks is roughly 5 years. So if you commit to one framework before it's popular, you might get 5 years out of it. If you commit to it, at it's peak popularity, you will only get 2-3 years out of it.

      As much as I hate jQuery and all the hellspawn it's created, developers need to recognize that if they can't build it in straight javascript, they should not be building it at all. I have never gotten a single thing via NPM to work, and quite frankly the rate that things decay in npm is atrocious, that I would never want to develop anything in any framework.

      If you roll your own, you own any security bugs. But then again, you can also make the app 100 times smaller than using these grossly bloated frameworks.

    5. Re:Vanilla-JS.com by holostarr · · Score: 1

      Believe it or not, there are companies out there that build enterprise apps, and yet they are NOT large enough (or don't see a value) to have internal teams devoted to an in house JS framework. For example, I work for a Telecom and although we have large development teams for building various applications for our customers, our focus isn't building and maintaining frameworks.

    6. Re:Vanilla-JS.com by Moridineas · · Score: 1

      But is it webscale?

    7. Re:Vanilla-JS.com by K.+S.+Kyosuke · · Score: 1

      Telcos are still generally quite large, and I find it implausible that an adequate substrate couldn't be maintained by just a few people who understand the needs well. Of course, skilled people - now that might be a problem since these are generally scarce.

      --
      Ezekiel 23:20
    8. 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.

    9. Re:Vanilla-JS.com by holostarr · · Score: 1

      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. There are also commercial solutions out there that provide frameworks with greater support, for example Ext JS. It all depends what you are doing, but chances are that as a business your product is constantly evolving, and you also want your product to evolve with the technology, otherwise, your product will feel outdated and stale. Also, I don't know why you are having such a difficult time with NPM, I use many packages on daily bases and have had very little problems.

    10. Re:Vanilla-JS.com by parkinglot777 · · Score: 1

      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!

      To me, if a company is already small, there is no "management" team... Thus, there usually is one person who builds/maintains an in-house application using an available framework out there. :-/

    11. Re:Vanilla-JS.com by Anonymous Coward · · Score: 0

      I have never gotten a single thing via NPM to work

      I'd start there...

    12. Re:Vanilla-JS.com by Anonymous Coward · · Score: 0

      I have never gotten a single thing via NPM to work

      This admission of boundless incompetence leaves me breathlessly awaiting more of your profound insight.

    13. Re: Vanilla-JS.com by Anonymous Coward · · Score: 0

      Quote - âoeI have never gotten a single thing via NPM to workâ, that tells me all I need to know right there...

    14. Re:Vanilla-JS.com by hcs_$reboot · · Score: 1

      -1, not enough jQuery.

      --
      Slashdot, fix the reply notifications... You won't get away with it...
    15. Re:Vanilla-JS.com by Junta · · Score: 1

      In my search to explore your comments, the react page touting the vritaul DOM:
      "BTW. I myself managed to create a web page with a source of 5GB+. It wasn’t even that hard.

      Consider a DOM made of thousands of divs. Remember, we are modern web developers, our app is very SPA! "

      These are huge warning signs that the developer has an issue, regardless of whether the environment can handle it.

      All that aside, I think the virtual DOM will be regarded in the near future as a needless over complication. It's trying to workaround a problem that will probably not be a problem a year or so from now. Most of the other facets are either quite sanely doable from Javascript, or else not a concept that you really need and you may be doing your users and fellow web developers a disservice by being overly fancy with something. Using Javascript without a framework is not rolling your own framework.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    16. 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.

    17. Re:Vanilla-JS.com by volodymyrbiryuk · · Score: 1

      The vanilla js solution might be a shitty one, but at least it's yours.

      --
      sudo rm -r -f --no-preserve-root /
    18. Re:Vanilla-JS.com by Anonymous Coward · · Score: 1

      Yea, try building and maintaining a large scale application using nothing more than vanilla JS.

      Been there done that. The client really isn't that big a deal from perspective of programming effort in the grand scheme of things.

      The reason JS frameworks are popular is because they do a whole lot of stuff behind the scenes like variable binding,

      Variable binding on the client? I'll pass.

      efficient rendering of the DOM (for example virtual DOM),

      Efficient rendering of the DOM is literally what web browsers are designed to do.

      implementation of patterns such as MVVM, state management, routing,

      To the extent these things intersect with clients at all trivial matters you don't need no stinking "framework" for.

      and a whole lot more.

      When you list only non-issues and end with "a whole lot more" this really means you got nothing and you know it.

      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.

      Domain specific trumps generalized BS any day. HTML/CSS/JS are high level enough to serve as a suitable foundation.

      You will make something that works, but works badly and perhaps with lots of security vulnerabilities compared to one of the major frameworks.

      Security vulnerabilities in a client JavaScript library? Are these the same libraries people are loading right and left from third party CDNs?

      Where I come given the muted role of the browser this more or less requires intentional malice to pull off. I can see why for those of you accustomed to making serious architectural errors this would be a problem.

      In fact the reason to avoid layers upon layers of general purpose framework bullshit is precisely for security reasons. These "frameworks" are not even reliable let alone defensible from a security POV. Every LOC under our control is our responsibility whether we personally wrote it or not. Global complexity is a BFD.

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

    20. Re:Vanilla-JS.com by holostarr · · Score: 1

      No one is forcing you to rewrite your application using the latest fad framework! If you wrote your app in say Angular 1 and you are happy with it, then don't rewrite it! 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! That is one of the many benefits of open source isn't it? But if you want the latest, most cutting edge features, then you might want to rewrite your presentation layer using a newer framework. And like I said, there are commercials frameworks out there with extended support so you don't have to rewrite every 2 to 3 years...

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

    22. Re:Vanilla-JS.com by Actually,+I+do+RTFA · · Score: 1

      Or you can write a large application in whatever language you want. If you need it to be in the browser, compile down to some horrendous, unreadable, JS mess.

      --
      Your ad here. Ask me how!
    23. Re:Vanilla-JS.com by K.+S.+Kyosuke · · Score: 1

      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.

      I'm a user of GNU Maxima. Its development (under a different name) started around 1968. It's still supported. When I read what GP wrote, I had a hearty laugh.

      --
      Ezekiel 23:20
    24. Re:Vanilla-JS.com by Chris+Mattern · · Score: 1

      our app is very SPA!

      Ha, our app is Spa Fon! We're working on getting it to be Squa Tront, too.

    25. Re:Vanilla-JS.com by holostarr · · Score: 1

      You can laugh all you want, but it doesn't make my point invalid. People like you act like this is a holy war, and only you are capable of seeing the truth. Well NEWS FLASH! Web developers are not STUPID, most of us realize that on the web client development side things move fast, however, that is the nature of the business! Right now there is a lot of innovation going on in this space from lots of big players including Google, Facebook and Microsoft are pushing things towards the cloud. As a result of this push, browsers are evolving fast and a framework that was written 3 years ago with a different web standards in mind no longer make sense.

      The reason why Google replaced Angular 1 with Angular 2 (which is not backward compatible) is because back when the wrote Angular 1, there was still a lot of inconsistency between the browsers and features and there was still a lot of reliance on jQuery. With browsers now incorporating a lot of what jQuery offered natively, it made sense to rewrite the framework with modern browser capabilities in mind. And this is still going on as browsers and standards are becoming more mature and browsers are adding more and more capabilities. You might want to argue that the browser is not the right platform for this, but your opinion doesn't matter, because it is the Googles of the world that decide what makes sense. Fact is development is hard, and as a developer you are constantly required to keep up to date and be open to new technologies. If you can't handle it, then maybe it is not the right profession for you.

    26. Re:Vanilla-JS.com by holostarr · · Score: 1

      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?

      The reason why these frameworks are constantly changing or being replaced is because the browsers and web standards are constantly evolving. Right now there is a major push from big players such as Google, Facebook and Microsoft to move things towards the cloud, and as a result they are introducing more and more features to the browser. As a result of this push, a framework that was written 3 years ago with a different set of capabilities in mind, no longer makes sense.

      And like I said, if for your product it doesn't make sense to adopt a new technology, you are welcome to stick with an older framework, that is why they are open source! If you need official support, then you are welcome to use one of the many commercially available frameworks from Sencha or Telerik.

    27. Re: Vanilla-JS.com by Anonymous Coward · · Score: 0

      Personally, I prefer turdburglar.js...

    28. Re:Vanilla-JS.com by terjeber · · Score: 1

      Why would they? Most enterprise development teams are swamped with doing real, productive work. If we hired two developers more at the utility where I work we certainly wouldn't have them working on a dumb-ass task such as writing and maintaining a framework when Google and Facebook are doing the job for me for free.

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

      What probably should be done is some kind of signing of javascript frameworks. That way major vendors or groups who develop these frameworks could sign them. You could choose to trust them based on the signature, so that way you know nothing blatantly malicious has been added, and can still have a somewhat usable web experience, with all other javascript being disabled.

      A framework signed by google or some other well known group is probably going to be pretty harmless other than bugs discovered, rather than some fly by night web developers framework, or modification of an existing framework to insert god knows what scam of the day/crypto currency miner.

    2. Re:But they all force Javascript on users by K.+S.+Kyosuke · · Score: 1

      Perhaps fixing Javascript in the browser or providing other means to run code would be more useful than destroying all interactivity in browsers. Preferably with imposing some resource limits, though. The current state of interactive web is a travesty.

      --
      Ezekiel 23:20
    3. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      What probably should be done is some kind of signing of javascript frameworks. That way major vendors or groups who develop these frameworks could sign them. You could choose to trust them based on the signature, so that way you know nothing blatantly malicious has been added,

      You're not understanding the problem. It nothing to do with "trust" and there is no "choice" available to the end user.

      Javascript, is a cancer that is destroying the Internet. Not too long ago, you could disable Javascript in your browser and most web pages would work, more or less, at least "good enough". Now, the major browsers don't even allow you to disable Javascript, and, if you do manage to disable Javascript, most web pages are completely broken, in many cases showing nothing but a blank page.

      And all of this is being done so that websites can shove more and more malware-loaded advertising down our throats.

      "Signed" Javascript frameworks changes none of this.

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

    5. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      I'd be willing to bet there vastly more people are using their browsers to do nothing more than read news than all of these shitty single-page apps.

    6. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      I felt the same way as you, back in 2003. However, stuff happened, and it's now a requirement for 90% of the web, so maybe stop complaining and accept reality?

    7. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      That's bullshit. You need to worry about which browser and which browser version. There's at least the same amount of effort needed for version support for websites and programs. I'd argue programs are actually easier since their tooling is far, far superior and you can spend a little more time with managing delivery because the primary development effort will be so much easier.

    8. Re:But they all force Javascript on users by jdschulteis · · Score: 1

      And all of this is being done so that websites can shove more and more malware-loaded advertising down our throats.

      Even for sites without ads, a progressive enhancement site that is usable without JavaScript costs more to develop and test. For many sites it is simply not economically viable to cater to non-JavaScript users.

    9. Re:But they all force Javascript on users by holostarr · · Score: 1

      If you are using web standards, chances are your app will work across all modern browsers. I haven't had to do any browser specific hacks in a long time! Also with the browser, you can target any platform that supports a modern browser, no need to compile your app for multiple platforms, provide installation instructions for each platform, have to deal with platform specific differences on each OS. And no native is does not have superior tooling, with native you have to either wrap all platform specific calls in a function, or use some 3rd party solution like QT (which has it's own problems). Then you have capability differences between each platform to worry about. Let's face it, not everything needs to move to the browser; leave CAD, Photoshop, 3D Max, etc where they are. But for certain applications where there is a server side component to it, the browser makes more sense!

    10. Re:But they all force Javascript on users by Junta · · Score: 1

      This is a good reason for web developers to be trained:

      First and foremost, be mindful of HTML and use it correctly. Doing this fairly simple thing improves experience greatly, and renders accessibility easy.

      Next up, up you want to be fancy, CSS can do almost all the sane visual sprucing up you can imagine, and can play nicely with accessibility.

      If you have a need for Javascript, first consider what the language/runtime can do without a framework. This keeps your application a bit more straightforward to debug.

      Framework should be the last resort.

      Circumstances don't always allow for the no javascript way, but there are more tools than folks realize. For one site, others in my team were pushing for a bloated CMS that messes with daatabses on the fly server side and assembles the pages using javascript in the browser. I ultimately won that one and the site uses Jekyll and no javascript.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    11. Re:But they all force Javascript on users by pjt33 · · Score: 1

      ... but the truth is that there are a lot of people out there who want to do more than just browse static pages.

      That is completely orthogonal to the question of whether or not static pages should render something with JS disabled. The very real existence of pages with no dynamic content which render as white without JS enabled is shameful. I've seen sites which have CSS that sets the body to display: none and then load the real CSS using JS. They're usable in Lynx, but not in any GUI browser with JS disabled. Insane.

      It's reasonable to expect people to enable JS if they want to use Google Maps; but it's also reasonable to expect that a page with no interactive elements whatsoever should render its text with JS disabled.

      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!

      Two things: firstly, just because it's possible to make "web apps" nowadays that doesn't mean that vanilla web pages are not the more appropriate approach for many sites. And secondly, that last sentence is equally true if you replace "app" with "JS-less page". There are arguments in favour of JS, but that is not one.

    12. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      This is where a signature based system where you approve the signatures works. If you're really are that anal, examine the JS code. If it passes your approval add the signature to your allowed to execute white list.

      It will probably never happen, because the common end user is not going to do that. But it would be a way to allow some JS to execute that you have approved while disabling everything else.

      You probably wouldn't even need signatures. just some hashing algorithm which isn't broken. This would probably work well for things like frameworks/libraries. Just add the hash to your allowed to execute white list.

    13. Re:But they all force Javascript on users by holostarr · · Score: 1

      Again you are just complaining why sites don't make their content available when JS is disabled. Fact is there are no laws or standards to require the content to be accessible without JS and since people who favor browsing the web with JS disabled are in the minority, frankly most companies don't give a shit. Like I said, the only reason to complain about JS is if you are paranoid about security, at which point either trust the browser, or run it in a VM.

    14. Re:But they all force Javascript on users by evileeyore · · Score: 1

      a modern framework is capable of serving both... you can provide server side rendering to anyone who has JS disabled. its not going to be the full experience most of the time but that is because the full experience is only available via javascript. Now given it is a actually a very small percentage of tin foil hat people that actually whole sale disable javascript in their browser and that is why most companys don't bother wtih the extra technical debt of making their sites work both with and without javascript.

    15. Re:But they all force Javascript on users by cjonslashdot · · Score: 1

      Hi. Yes, you are right - people do want to be able to run apps. I am just saying that these frameworks are now being used where they should not be. It seems like so many sites now use them, when the site really only has static content; but because a framework is used, I have to enable Javascript, or enter click after click in my NoScript plugin just to see a web page. I would prefer that single-page web app frameworks only be used when one really needs an app . For static content, one should be able to turn off Javascript, especially since Javascript is such a powerful malware vector.

      Truly, there should be a different protocol - not HTTP - for apps. Javascript's architecture was a mistake - mixing static content with apps is not a good idea, because it makes it possible to hide active attacks within all content.

    16. Re:But they all force Javascript on users by cjonslashdot · · Score: 1

      Indeed - you are spot on!

    17. Re:But they all force Javascript on users by holostarr · · Score: 1

      At the end of the day it all comes down to trust. The question is do you trust that your browser vendor's product is reasonably secure? If you are not convinced, then like I said there are other options such as running the browser in a VM or selectively enabling Javascript in sites that you trust.

    18. Re:But they all force Javascript on users by cjonslashdot · · Score: 1

      "tin foil hat" - ROTFLOL. Good to know about being able to provide for non-JS folks - thanks for the info - I am a server side guy so I don't know the Web frameworks like react except at a basic level. About the "tin foil hat" thing though - most people don't realize how vulnerable Javascript makes them. Those who do realize it are not "tin foil hats" - they are prudent. Here's a good article on this: https://blog.plan99.net/its-ti...

    19. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      Every time there is an article about Javascript, there is an individual like you complaining about why Javascript is needed.

      Oh please.

      Go to amazon - it works on any web browser, with or without javascript, plugins, or other BS.

      Why? Because amazon wants you to buy stuff, and they know that if their website doesn't work in your browser, you WON'T BUY STUFF.

      Now, if the purpose of your website is to annoy the user with a dozen slow ad-tracking javascript includes, go right ahead and keep doing what you're doing.

    20. Re:But they all force Javascript on users by cjonslashdot · · Score: 1

      Yes, I have wondered if OSes are going to move to containerization for apps, which would provide that level of protection for the average user who does not know how to run a browser in a VM. There is a product for Windows called Bromium that uses virtualization to sandbox web pages. I think some of the browsers do that to but I don't think they use virtualization - not sure. There is an interesting blog post about how hard it is to write secure web apps: https://blog.plan99.net/its-ti...

    21. Re:But they all force Javascript on users by rjstanford · · Score: 1

      Part of this is simply efficiency. With an SPA loaded, clicking on each link to a static article simply sends the relevant data rather than rebuilding the entire page server-side. That's a whole lot faster and cheaper to do.

      As for JavaScript being a powerful malware vector, is that really a thing these days?

      --
      You're special forces then? That's great! I just love your olympics!
    22. Re:But they all force Javascript on users by WaffleMonster · · Score: 1

      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.

      Hence the reason operating systems allow programs other than web browsers to be executed.

      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!

      This must be why I regularly find myself switching browsers. It's always stupid shit like buttons that do nothing when clicked.

      If you are paranoid and don't trust the browser sandboxing

      Browser sandboxes have proven themselves not to be trustworthy.

      then maybe you should run Qubes OS or browser in a VM, otherwise, perhaps it is best to stick to printed news.

      Or maybe people should stop confusing a document viewer with an execution environment for general purpose software.

    23. Re:But they all force Javascript on users by cjonslashdot · · Score: 1

      Yes, having a whole page reload from each click is very inefficient. Does HTML5 provide a way to avoid reloading a whole page, but without using Javascript?

      Yes, malware is a terrible problem today: if someone wants to hack an organization, pretty much the most guaranteed path to success is to use Web based attacks, by hacking sites that staff of the organization visit. Read this article - it is very worth your time, I promise: https://blog.plan99.net/its-ti.... If you are impatient, skip down to the section "Web apps are impossible to secure".

    24. Re:But they all force Javascript on users by WaffleMonster · · Score: 1

      Part of this is simply efficiency. With an SPA loaded, clicking on each link to a static article simply sends the relevant data rather than rebuilding the entire page server-side. That's a whole lot faster and cheaper to do.

      Not necessarily.

      Once you yank out all of the unnecessary abstraction and complexity in the attempt to create a thick client all of the sudden cost of reloading page vs reloading content is irrelevant.

      Often what really matters with regards to outcomes is round trip delay. If you have a page constantly doing a bunch of piecemeal loads (A practice that seems to be quite widespread) it's going to take longer regardless of how many fewer bytes went over the wire or how many fewer CPU cycles were burned.

    25. Re:But they all force Javascript on users by Actually,+I+do+RTFA · · Score: 1

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

      Being able to run an application when I want, and the version I want, is one of the main reasons I have a computer. I don't want to be forced to update to the latest version that moves buttons around. And I certainly don't want the lock-in and monthly charges (or constant ads) that come with a cloud hosted application. It incurs more charges for the publisher and the only reason they do that is if it's more profitable for them to do so.

      Perhaps most important, I frequently use applications when offline. I'm not sure why people think I always need or want to be connected to the internet. And I certainly don't understand why you think I'd want to be unable to use your app once you pull the switch on the server because of the monthly upkeep costs.

      Even if JS only was used for malicious super-browsers and browser fingerprinting, it'd be pretty bad. But the whole Spectre/Meltdown should demonstrate the flaws in relying on Sandboxing (remember, that was IE6's security model for ActiveX!!). And new bugs found in VMWare this week should demonstrate how stupid "run random code on my computer" is as a default setting.

      --
      Your ad here. Ask me how!
    26. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      I'm sure NY Times has an Android app you can download and use if you don't want to use their web site, but then when there is an article regarding apps for Windows or Android market place, we can find you complaining that there are too many apps, and why does NY Times need an app? In regards to browser switching, I haven't had that problem for a long time, maybe you need to visit better sites! You don't trust the browser sandbox, run it in the VM! And the browser hasn't been a document viewer for at least 15 years, so why don't you get with the times grandpa!

    27. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      Just plain wrong.

      Facebook gets 1.3 billion daily active users.

      Wikipedia gets ~100 million.

      That is an order of magnitude of difference.

      Get out of your bubble.

    28. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      BS.

      No IE11 hacks or polyfills? Either you are wrong/lying or you don't do very serious web dev.

    29. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      Too bad Javascript is such a dumpster fire.

      Created in 10 days and it shows.

    30. Re: But they all force Javascript on users by Anonymous Coward · · Score: 0

      Wikipedia? That's your example? I'll give you Facebook.

      But Wikipedia? That website does not need javascript to function. It's basically a bunch of static pages inside a database.

    31. Re:But they all force Javascript on users by WaffleMonster · · Score: 1

      I'm sure NY Times has an Android app you can download and use if you don't want to use their web site, but then when there is an article regarding apps for Windows or Android market place, we can find you complaining that there are too many apps, and why does NY Times need an app?

      I advocate using the proper tool for the job. Browsers are suitable for viewing published documents. They are unsuitable for executing arbitrary software.

      In regards to browser switching, I haven't had that problem for a long time,

      Why is this relevant to my situation?

      maybe you need to visit better sites!

      I don't have a choice.

      You don't trust the browser sandbox, run it in the VM!

      Less than two weeks ago we received yet another example of why this does not work.

      And the browser hasn't been a document viewer for at least 15 years, so why don't you get with the times grandpa!

      The browser is and has always been a document viewer. Just because you can write a web server in postscript doesn't mean you should.

    32. Re:But they all force Javascript on users by holostarr · · Score: 1

      Polyfills are not hacks...

    33. Re:But they all force Javascript on users by holostarr · · Score: 1

      The browser is and has always been a document viewer.

      Well Google, along with Facebook, Microsoft, Amazon, and millions of other web developers much smarter than you and I disagree with that view...

    34. Re:But they all force Javascript on users by pjt33 · · Score: 1

      Fact is there are no laws or standards to require the content to be accessible without JS and since people who favor browsing the web with JS disabled are in the minority, frankly most companies don't give a shit.

      They should, because of SEO, but that's getting too far off-topic.

      Like I said, the only reason to complain about JS is if you are paranoid about security, at which point either trust the browser, or run it in a VM.

      I'm not sure where you said that, but I disagree.

      Simple benefits for the end user of turning JS off are that pages load faster and on many sites they become easier to read (fewer flashing ads). For the security-conscious user security is a many-faceted thing which can't just be delegated like that: if you want a recent example of the problems of that attitude, see Monero; besides which, running the browser in a VM is not practical on low-powered machines such as smartphones.

      But even without those kind of direct benefits, I would still complain about sites which are completely brain-dead in their lack of graceful degradation, because they offend my sense of professionalism. The very concept of graceful degradation was falling out of favour, replaced by progressive enhancement, long before most of these sites were made, so there's no excuse for deliberately implementing ungraceful degradation.

    35. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      Destroyed? You're either an old school coder or not very informed. The only thing destroying the web is bad practices not javascript. It has vastly improved user experience and given rise to very responsive applications. I wouldnt say NY times, a dying news paper is what people should model their sites after. Not to mention it is one of most bland news sites out there.

      If you are so afraid of JS that you disable it, I question what you visit on a daily basis.

    36. Re:But they all force Javascript on users by Waccoon · · Score: 1

      The problem is that few web developers really understand why the WWW was developed as a document platform, the differences between document-centric design and application-centric design, and how to apply these principles.

      In most cases, replacing documents with apps is work of the ignorant, and is truly a plague. Most sites I know that have converted from static pages to dynamic pages are so broken to the point of being almost unusable, especially with regards to standard browser navigation (shift-click and the like).

      Marketing and hype always win. It may be a losing battle, but that's exactly why people like cjonslashdot and myself keep whining about the massive over-reliance on Javascript.

    37. Re:But they all force Javascript on users by dave420 · · Score: 1

      That link has very little to say about JavaScript - did you mean to post it?

    38. Re: But they all force Javascript on users by yndrd1984 · · Score: 1

      I'd be willing to bet there vastly more people are using their browsers to do nothing more than read news than all of these shitty single-page apps.

      Facebook gets 1.3 billion daily active users.
      Wikipedia gets ~100 million.
      That is an order of magnitude of difference.

      Wikipedia? That's your example? I'll give you Facebook.
      But Wikipedia? That website does not need javascript to function. It's basically a bunch of static pages inside a database.

      I don't think they were giving two examples of SPAs, I think they were pointing out an example of each type.

    39. Re:But they all force Javascript on users by cjonslashdot · · Score: 1

      Well he is referring to the whole Web ecosystem, which Javascript is a big part of, and he makes many points about web pages that try to behave like apps. Indeed, Javascript is not the only problem - HTTP is a horribly flawed system of headers and encodings rules that application programmers should not have to get involved with.

    40. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      > Polyfills are not hacks...

      Oh, yes they are.

      They are kludgey improvised workarounds to make up for missing functionality. That's a hack in anyone's book!

    41. Re:But they all force Javascript on users by Anonymous Coward · · Score: 0

      These vulnerabilities have nothing to do with JavaScript. The culprit is scriptable DOM. Any language able to manipulate the DOM would be able to trigger them.

  4. what month is it? by Anonymous Coward · · Score: 0

    (btw... why don't you page through some submissions, you'll find your answer in a very recent one)

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

      Loading JS libs from an external site is just downright stupid and lazy. Any developer caught doing this should be fired, or a minimum be required to go though some security 101 training. If you don't have it all pulled down to your own site, you are at the whim of the developer to maintain the server is is on, hope it doesn't get hacked and the lib replaced with something nefarious, hope they have the bandwidth that isn't going to impact your site's performance, and also have some kind of control over versioning. If they decide to just make an update to that library, you now have untested code running on your production site with no idea what it might break or introduce.

    3. Re: This one! ;-) by Anonymous Coward · · Score: 0

      Using a common cdn you can improve performance because the users probably have downloaded the library already.

    4. Re: This one! ;-) by Anonymous Coward · · Score: 0

      If you're site is bottle necked by loading some JS library, you have some very serious issues you should probably be looking into.

    5. Re: This one! ;-) by Anonymous Coward · · Score: 0

      But you also need an extra dns lookup so you might actually get worse performance.
      Also any possible extra performance is probably not worth it for reason mentioned by others.

    6. Re: This one! ;-) by Dog-Cow · · Score: 2

      It’s the extra apostrophe’s killing bandwidth.

    7. Re:This one! ;-) by Anonymous Coward · · Score: 0

      It may or may not have been in the article, but I'm the AC (because I can't remember my account login credentials and am too lazy to make a new account) that made a comment about how loading frameworks from third-party sites is a bad idea. I cited the example of the dev who removed all his work from NPM and caused a cascading failure across thousands of sites. The fun bit was, it would be very difficult for a lot of devs to figure out what happened, because the failure could be two or three modules deep.

      https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/

      And just as a kind of wondering aloud... if the EU, or some other country, were to impose accessibility regulations for websites, how many JS frameworks do you suppose would be able to meet them? Assuming they were modeled after accessibility standards used with Windows/macOS or mobile devices. How well do current JS frameworks play with things like screen readers? Hopefully I don't give some ambulance chaser type lawyer any ideas, but I'm surprised there haven't been a rash of ADA lawsuits in the US over current website designs.

    8. Re: This one! ;-) by Anonymous Coward · · Score: 0

      Meanwhile people are still forcing the entire jquery, and other framework to not be cached by affixing ?v=1.2.3.4 etc to it.

      The problem in javascript land is that when these frameworks/libraries and other bullshit get popular, they need to be part of the browser's base javascript so they ruin precompiled. That was Google's answer for keeping flash up to date until it was disabled.

      Webassemly has opened up the god damn pandoras box on useless shit migrating into the web browser, and it's only a matter of time before frameworks become blackbox shit that nobody can figure the fuck out.

    9. Re:This one! ;-) by Junta · · Score: 1

      This is essentially saying "yes, they have changed every six months, but *this* six month flavor is here to stay!".

      Note that at every changing of the guard, a month later there are a lot of people eager to explain why *this* time is different and the change will endure, unlike all those previous flashes in the pan before it. Six months from now we will have people explaing how Vue and React were ultimately flawed concepts somehow and how *new* framework brings enduring sanity to the world.

      Nexus supports NPM so this is an irrelevant problem.

      No, npm is a a manifestation of the problem, the cause is developers looking to offload to upstream for efficiency, and continually assuming that upstream is 100% reliable every time.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    10. Re: This one! ;-) by Junta · · Score: 1

      Pretty much this is the key issue. If Javascript and the browser runtime in general is really so flawed, then steps need to be taken to advance the runtime, rather than making the site code more and more bloated.

      Either the state of browser runtime needs to advance or developers need to learn to work better with the hand they are given. The answer is likely in the middle.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    11. Re:This one! ;-) by Waccoon · · Score: 1

      I always tell my devs not to load from third party sites and to download and install locally instead.

      But, but... that's not cloud!

    12. Re:This one! ;-) by i_ate_god · · Score: 1

      > This is essentially saying "yes, they have changed every six months, but *this* six month flavor is here to stay!".

      yeah I mean it's a fair point. But I see the major difference coalescing around a similar idea, which did not happen before. So maybe 6 months from now there will be the New Framework on the Block (and in the JS world, I wouldn't be surprised if that's its actual name), but I suspect this new framework will just be an iteration over the concepts of virtualdom and data binding espoused by Vue and React, as opposed to being some sort of entirely new concept.

      > No, npm is a a manifestation of the problem, the cause is developers looking to offload to upstream for efficiency, and continually assuming that upstream is 100% reliable every time.

      I really don't understand the hate towards NPM because I don't see how it's so fundamentally different from nuget (c#), pypi (python), composer (php), gem (ruby), maven (java), and so on and so forth. I rarely see people lambasting all these other package managers, even though they are all mostly the same functionality wise. I honestly don't know what makes NPM so different.

      --
      I'm god, but it's a bit of a drag really...
  6. JAF by 110010001000 · · Score: 1

    Clearly the JAF framework is most popular. Followed by jkit and ghostj. They are all a lot easter than wjav, especially wjav 2.0.

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

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

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

      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 but once you get it this is quite powerful, especially if you don't do a lot of long running queries or I/O.

      Big problem is the nightmarish npm house of cards, but really it's been like that with maven and nuget for a while as well.

    3. Re:back end servicesin JavaScript by TheRaven64 · · Score: 1

      Code reuse. If you're validating form input, for example, it would be nice if you can use the same code for client-side and server-side validation. The server-side version protects you against invalid date, the client-side gives more immediate feedback to the user, but both will give the same result. There are basically two solutions to this problem. The simplest is to use JavaScript on the back end, the other is to use something like GWT or similar that lets you write the back end in one language and then synthesises the front end by transforming some of that code into JavaScript.

      The other big reason is that companies have invested a huge amount of developer time in optimising JITs for JavaScript. You're typically not just choosing a language, you're also choosing an implementation of a language. JavaScript may be a pretty bad language in a number of ways, but v8 is a very fast implementation of a language (to the extent that C code compiled to JavaScript and run with v8 is often close in performance to natively compiled code, and sometimes faster).

      --
      I am TheRaven on Soylent News
    4. 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
    5. Re:back end servicesin JavaScript by K.+S.+Kyosuke · · Score: 1

      The latter solution, however, nicely evolves later into running WebAssembly binaries or something similar on client side once WebAssembly or something like it becomes available. With moving Javascript onto your server side, you're apparently stuck with a semi-weird language.

      --
      Ezekiel 23:20
    6. Re:back end servicesin JavaScript by Anonymous Coward · · Score: 0

      universal javascript and the potential for dry'er code. if done right, it can cut costs for certain business segments.

    7. Re:back end servicesin JavaScript by Lunix+Nutcase · · Score: 1

      to the extent that C code compiled to JavaScript and run with v8 is often close in performance to natively compiled code, and sometimes faster

      Proof that v8 runs faster with a real-world application and not in some contrived microbenchmark.

    8. Re: back end servicesin JavaScript by TheRaven64 · · Score: 1

      Not sure about v8, but it's worth noting that JavaScriptCore's intermediate representation for paths that make it to the second-tier JIT is a CPS representation, so I'd argue that JavaScript probably isn't an unsuitable language for writing CPS code: at least then there's less impedance mismatch between the programmer and the optimiser...

      --
      I am TheRaven on Soylent News
    9. Re:back end servicesin JavaScript by Anonymous Coward · · Score: 0

      When you reuse data validation logic, it means one bug penetrates your entire system. It's safer to rewrite security related logic at each level. This is especially true with websites since end-users and directly view the validation checks.

    10. Re:back end servicesin JavaScript by Srin+Tuar · · Score: 1

      Javascript is actually much better for high performance back-end applications than many languages.

      The core event loop and processing model is very much the way you would write a C/C++ process based libevent or similar epoll loops. This is extremely common for high performance programming, especially with interfaces where your process gets interrupted mostly on network or storage. Its far less important for blind batch jobs, but can be very important for response batch jobs.

      so its far easier to write high performance JS than it is to do so in java or python. In fact, I would probably RAD in JS, and only re-implment in C if I absolutely had to squeeze out the most performance from the iron. There is almost no use case for java serverside anymore. Its just too slow.

    11. 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.
    12. Re:back end servicesin JavaScript by Anonymous Coward · · Score: 0

      Code reuse. If you're validating form input, for example, it would be nice if you can use the same code for client-side and server-side validation.

      If your having to worry about different code on server vs client your "doing it wrong" (tm). What would be nice is for validation to be handled for you automatically as an aspect of underlying system.

      The server-side version protects you against invalid date, the client-side gives more immediate feedback to the user, but both will give the same result.

      Type checking data is such a trivial exercise as to be not worth mentioning. Servers often needs to enforce constraints clients are completely unaware of. You simply can't have the same code on both unless your problem is trivial or "your doing it wrong".

      There are basically two solutions to this problem. The simplest is to use JavaScript on the back end, the other is to use something like GWT or similar that lets you write the back end in one language and then synthesises the front end by transforming some of that code into JavaScript.

      What does it matter when the problem described is nothing more than the result of selecting a crummy solution to the actual problem.

    13. Re:back end servicesin JavaScript by Anonymous Coward · · Score: 0

      Javascript is actually much better for high performance back-end applications than many languages.

      [citation needed]

    14. Re:back end servicesin JavaScript by Actually,+I+do+RTFA · · Score: 1

      In some cases (which I cannot divulge), your partners allow any backend solution you want. But all their SDKs are written in JS, and you'd have to start from zero to rewrite it in a real language (and do the SDK updates yourself). It's far easier to allow them to dictate the backend language (if you are a small shop. A large shop can afford to re-write the SDKs.)

      --
      Your ad here. Ask me how!
    15. Re:back end servicesin JavaScript by K.+S.+Kyosuke · · Score: 1

      He probably meant all the bytecode-interpreted, AST-interpreted and token-interpreted ones. There's probably hundreds of those, lots of them with a bus factor of one. It's not a false claim but also not very useful either.

      --
      Ezekiel 23:20
    16. Re: back end servicesin JavaScript by K.+S.+Kyosuke · · Score: 1

      When I said "asynchronous model", I didn't mean exposing raw continuations to people, of course.

      --
      Ezekiel 23:20
  10. Emacs by Anonymous Coward · · Score: 0

    No, Vi.

  11. In search of a problem by Errol+backfiring · · Score: 1

    Express "is the overwhelmingly dominant solution...

    Please tell me. What was the problem?

    --
    Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
    1. Re:In search of a problem by Anonymous Coward · · Score: 0

      For building web applications, writing against the raw Node.js API is a bit cumbersome. TJ Holowaychuk started Express, providing a great framework to the community -- by allowing people to write software a bit easier.

      Really, it's a micro-framework that powers "a bunch" of traditional Node.js applications, and has been getting a lot of new attention, especially with React and Angular dominating newer web applications development mindshare.

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

    3. Re:In search of a problem by Anonymous Coward · · Score: 0

      Jump on board! Come write better code. You can make a difference.

    4. Re:In search of a problem by Anonymous Coward · · Score: 0

      Because the "competent" monkeys won't lower themselves to do such menial work at all.

      Approximately half of all programmers are always going to be below average. What would you have them all do?

    5. Re:In search of a problem by Lunix+Nutcase · · Score: 1

      Approximately half of all programmers are always going to be below average. What would you have them all do?

      Get out of the industry and stop cranking out shitty software that leads to things live massive data breaches of PII.

  12. 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.
    1. Re:NIH Framework by Anonymous Coward · · Score: 0

      What's the "NIH framework"?

      I've never heard of it, and my searching isn't turning up anything.

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

  14. npm is for sodomites by Anonymous Coward · · Score: 0

    If you use npm you do not control your own projects.

  15. Coin miners by Anonymous Coward · · Score: 0

    Everyone is putting in coin miners on their sites these days. Remember, Mozilla was bribed to cripple noscript on Firefox. Join the resistance, use Goanna based browsers instead.

  16. Right now? Or half an hour ago? by Anonymous Coward · · Score: 0

    $SUBJECT says it all: please specify your question.

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

  18. Hold my beer by Anonymous Coward · · Score: 1

    Who the f* cares here on this mammoth graveyard that is Slashdot?

  19. Ember is losing popularity by Anonymous Coward · · Score: 0

    Ember actually is losing popularity, as per Google Trends and a recent survey done. But, yes, React is the framework to learn right now; it's overcoming Angular.

    1. Re:Ember is losing popularity by Anonymous Coward · · Score: 0

      Ember.js, an "Opinionated Framework": You follow the path. You deviate from the path and we take your first born child.

      The message to not use Ember.js is in the learning curve. There are faster and easier ways of achieving the same result now.

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

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

    ... uBlock.

  22. Re:Sadly, this is how we make decisions on framewo by lucasnate1 · · Score: 1

    we need some commercial entities standing behind these things

    Some of these javascript frameworks do have commercial entities standing behind them. I am not sure how much it helps.

  23. 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 ]
    1. Re:NoScript by Anonymous Coward · · Score: 0

      Honestly I find the new UI horrible. Half the adresses are cut of in a way that makes it impossible to find out to what domain they belong and I cannot find a way to resize the window or just scroll an entry sideways.

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

  25. aggression takes many forms by Anonymous Coward · · Score: 0

    yuk yuk phoniness is just one, weaponry is just another, spiritual paralysis etc... all are fatal, thanks again..

  26. See Data for yourself by Anonymous Coward · · Score: 0

    at npm charts: https://npmcharts.com/compare/react,angular,@angular/core,ember-cli,vue

    Frameworks can be useful, but it seems like the framework treadmill is in full swing.

    Here's another view at the data, Brutal Lifecycle of Javascript Frameworks

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

    1. Re:What is NPM? by coolsnowmen · · Score: 1

      npm is the most popular java script dependency manager.

  28. Hipster.js by Anonymous Coward · · Score: 0

    Hipster.js

  29. This month you mean? by tylersoze · · Score: 1

    Shouldn't that be amended to "Which JavaScript Framework is the Most Popular this month?"

  30. 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!!!
    1. Re:Change like their underwear by Anonymous Coward · · Score: 0

      You seem upset...

    2. Re:Change like their underwear by Anonymous Coward · · Score: 0

      You want to be able to put as many keywords as possible on your resume. "Learning" a new JS framework takes about half a day, applying it to an actual working scenario takes another day or two, and then you can add that one to your resume.

      Of course you won't know anything about it, but that's not the point.

      The incentives are all to cock, and we can't really blame the developers for that. They're doing what will enhance their career prospects, just like they've always been advised.

    3. Re:Change like their underwear by Anonymous Coward · · Score: 0

      I fucking heartily endorse this comment! Well said sir.

    4. Re:Change like their underwear by Anonymous Coward · · Score: 0

      Sure, if you want to have a javascript job. Bleh. One has got to be desperate to settle for that.

      crappy_coding_job.js

    5. Re:Change like their underwear by Anonymous Coward · · Score: 0

      I don't want a JavaScript job, and I don't particularly want to use JavaScript for web apps - BUT, that is what I have to do if I want to build things on the web.

      So I settle for JavaScript.

  31. After a while by Anonymous Coward · · Score: 0

    Not even one celebrated the great America shot it down.

  32. 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 caseih · · Score: 1

      Why would you use inheritance to establish a hierarchy of widgets? That doesn't make sense to me. A GUI is by definition a container that contains other widgets. It's a "has a" relationship, not a "is a" relationship. Inheritance to establish this just isn't appropriate. In desktop GUI programming, inheritance is used very rarely, and only when you want to extend a widget in a particular way. So in this regard, reactjs seems to be doing it the right way. The widgets themselves should have precious little by way of business logic. Widget events should bubble up and be handled in control logic that sits above all the widgets. Is this different than your experience? I can only speak for GTK+, Qt, wxWidgets, WinForms in C#, etc.

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

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

    4. Re:Some reactJS problems... by Lunix+Nutcase · · Score: 1

      And we can even go one more level deep with the QPushButton example. QommandLinkButton inherits from QPushButton, which inherits from QAbstractButton, which inherits from QWidget which inherits from QObject. The fact that you said inheritance is rarely used by Qt for GUI programming is just absolutely hilarious.

    5. Re:Some reactJS problems... by K.+S.+Kyosuke · · Score: 1

      But these systems using inheritance is a chicken-and-egg-slash-cargo-cult problem. People parroting other people's bad designs, both in languages and in libraries. So maybe the right thing to say would be "In desktop GUI programming, inheritance is used very rarely if you're not actually being forced to use it by someone else.".

      --
      Ezekiel 23:20
    6. Re:Some reactJS problems... by Lunix+Nutcase · · Score: 1

      How exactly is using inheritance in GUI programming a bad design? It’s a very natural fit and not like a cargo cult at all.

    7. Re:Some reactJS problems... by caseih · · Score: 1

      You and the other commenter are misreading! Sure components themselves have an inheritance hierarchy, but the use of those components certainly involves composition, not inheritance.

    8. Re:Some reactJS problems... by caseih · · Score: 1

      Posting late, but you seem to be misreading what I wrote. I was talking about the use of the widgets, not the widgets themselves. Of course there's an inheritance hierarchy of the actual widget implementations. But that's not what I was talking about! So be careful when you say I couldn't have been more wrong. Because I knew exactly what I was talking about.

      Now it could be I was misreading the original post (I don't see how it's possible for a framework to implement composition with inheritance), but I'm talking about the *use* of the widgets in a GUI. And in that, no inheritance is not used much. It's a problem of composition. It's the "contains" vs "is a" relationships. Surely if you had read over more carefully what I wrote you would have seen that was what I was referring to. Obviously a button "is a" widget. However a dialog box "contains" widgets. That's the difference, and that's what I was getting at.

      Anyway just to clear this up in case someone stumbles upon this post down the road.

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

    No Fucking Java Script!

  34. Catch-22 by Tablizer · · Score: 1

    no laws or standards to require the content to be accessible without JS and since people who favor browsing the web with JS disabled are in the minority, frankly most companies don't give a shit.

    They are monkeys following the shiniest ball. JS is not necessary for the vast majority of content, but humans like eye-candy.

    But even if they realized the trade-off, there's not really a clean choice anyhow; most sites don't offer a non-JS version (or rendition). There's very little benefit to publishers in doing such unless enough readers care, and readers won't care if there's no practical choice. It's a catch-22.

  35. What day is it? by Anonymous Coward · · Score: 0

    Seriously, new ones pop up CONSTANTLY.

  36. Forget the framework... by Anonymous Coward · · Score: 0

    Before you call yourself a JavaScript programmer, read the first volume of "You Don't Know JS" (free ebook). Most people who use a JavaScript framework know only enough JavaScript, say, "Hello, World," to make the framework work but not enough to understand and solve problems when the framework doesn't behave.

  37. ExtJS? by rbrandis · · Score: 1

    It is expensive, but really gets the jobs done. (No, I do not work for them, I just work for a company that uses it)