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

103 of 161 comments (clear)

  1. 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 K.+S.+Kyosuke · · Score: 1

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

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

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

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

      But is it webscale?

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

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

    9. 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. :-/

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

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

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

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

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

    18. 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!
    19. 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
    20. 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.

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

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

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

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

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

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

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

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

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

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

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

      Indeed - you are spot on!

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

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

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

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

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

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

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

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

      Polyfills are not hacks...

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

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

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

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

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

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

  3. 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 Dog-Cow · · Score: 2

      It’s the extra apostrophe’s killing bandwidth.

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

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

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

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

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

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

    8. 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.
    9. 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!
    10. 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
    11. 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
  8. 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 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!

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

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

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

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

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

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

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

    ... uBlock.

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

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

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

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

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

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

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

    No Fucking Java Script!

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

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