My pet project for the past 10 years has been writing a web application system authoring toolkit (wasat) using PHP, HTML, CSS, SQL, and ECMAscript (javascript), primarily, to write cross-platform compatible business applications in which software and services can be used by FreeBSD, GNU/Linux, Mac OS, and Microsoft Windows clients, and can also be served by all the above platforms, excluding Windows. At first I tried to support multiple popular browsers for the client end of things as well, including Chrome, Firefox, Internet Explorer, Safari, and Opera. At first I would write software to run on either Firefox or Safari as the model browser, and then test and debug the same software until it would also work as well on the other 4 browsers. This final phase of testing and debugging quickly became my biggest problem area, particularly regarding deployment on Internet Explorer (IE), and I soon realized that I was spending more time trying to support all these less-than-fully-compatible browsers than I was spending on writing the software itself, so, after a month or three, I eventually abandoned support of all browsers other than Firefox. I continue to support Firefox only.
Mainly out of curiosity, and perhaps, arguably, some small degree of masochism, I recently tried installing and using Chromium on FreeBSD, strictly as an end-user, and with no great ambition towards supporting it as part of the wasat project, but quickly abandoned that effort too. It was problematic at best, and if Google doesn't care enough about FreeBSD to assist in porting their version of that browser to the FreeBSD platform, then I see no reason why I should care very much about using their browser either.
As a programmer I care as much about stability over extended periods of time as I care about cross-platform compatibility. Long before starting the wasat project, it was apparent to me that Microsoft was a destabilizing influence against software development. Since that time I've come to view Google as an impediment to software stability as well.
The last time (last October) that I tested my software on a Windows 10 client, I noticed that Firefox was still a slow starter on that platform, just as it was when I tested it on Windows XP 10 years ago. I haven't noticed the same problem on other platforms, only on Windows. Firefox starts in an acceptable amount of time on all the other systems I've tried it on.
Using ECMAScript, and particularly the XMLHttpRequest API, are essential to writing smoothly-running and network-efficient web applications, in my opinion, and in my experience with the wasat project. I don't know of any way to implement drag-and-drop or dynamically-changing drop-down list features without it. When not being used, my ECMAScript objects are quiet and/or entirely absent, and consume no resources either in the client browser or in the server. The resource-saving features of ECMAScript far outweigh whatever resource-usage they entail. Contrarily, the ZDNet link in the opening post of this thread uses ECMAScript to drive and animate adverisements extensively, so can I can easily see why sometimes ECMAScript is viewed negatively, but, like any good tool, it's all about how it's used, and why it's used, so I'm not going to remove ECMAScript from my toolkit.
Buggy ECMAScripts are a nightmare, and can be as bad as, or worse than, resource-greedy, advert-driving ECMAScripts, but none of this is the fault of ECMAScript per se.