back to article Today's WWW is built on pillars of sand: Buggy, exploitable JavaScript libs are everywhere

The web has a security problem: code libraries. Almost 88 per cent of the top 75,000 websites and 47 per cent of .com websites rely on at least one vulnerable JavaScript library. As described in a recently published paper, "Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web," researchers …

  1. AMBxx Silver badge
    Joke

    Perhaps

    If we just scrapped browser support for JavaScript, then created a plugin to enable rich content without the need to be downloading snippets of insecure script from untrustworthy sources.

    We could call if Flash - saviour of the universe.

    You heard it here first...

    1. Steve Davies 3 Silver badge
      Boffin

      Re: Perhaps

      In the {immortal} word's of Brian Blessed,

      "Flash? He's alive?"

      Sorry, both Flash and this JS crap needs to be consigned to the bin of history. Yet far more sites are relying on things like node.js.

      I guess we are trying to push water uphill then?

      We are doomed I tell ye, doomed!

      1. wolfetone Silver badge

        Re: Perhaps

        "In the {immortal} word's of Brian Blessed..."

        In the more immortal words of Brian Blessed....

        "CALAMITY! I could've farted that in!"

        Brian Blessed giving some commentary over a snooker match on Room 101 years ago

      2. chivo243 Silver badge

        Re: Perhaps

        @Steve Davies 3

        I guess we are trying to push water uphill then?

        Just try nailing jelly/jam to a tree...

    2. Charles 9 Silver badge

      Re: Perhaps

      "If we just scrapped browser support for JavaScript, then created a plugin to enable rich content without the need to be downloading snippets of insecure script from untrustworthy sources."

      Serious question. What do you propose as an alternative to interactive websites? Anything else you propose is likely to be holier than a wheel of Emmentaler, given we tried this approach in the past. Remember RealPlayer?

      1. bombastic bob Silver badge
        Megaphone

        Re: Perhaps

        "What do you propose as an alternative to interactive websites?"

        a) you don't need JavaScript for an interactive web site

        b) you don't need all of that "cruft" to serve up content

        c) style sheets can give you almost as much control over the appearance as can scripting (and probably better, more efficient, less memory footprint on the client, MUCH lower bandwidth requirement, faster load times, yotta yotta)

        d) if it requires scripting, maybe it should be done server-side instead

        e) if a 'meta' tag can't control refresh rates, you're doing it wrong

        This isn't about interactive web sites, anyway. It' about ABUSE of SCRIPT, and the sheer volume of crappy JavaScript code being used all over the intarwebs.

        Ever since some "bright-bulb" decided that SCRIPTED LANGUAGES within HTML was a *GOOD* thing, it (the script-monster from HELL) has grown into the bakemono that it is today. It's infected everything like a PLAGUE, and it's *EVERYWHERE*.

        It's amazing how good a web site can look with standard HTML, tables, hot links, forms, etc.. And they load a LOT faster. It's also amazing just how "dynamic" content can be if the server does a reasonable amount of the work. But yeah, it's easier for lazy developers to just CRAM IN a bunch of script from 3rd party libraries, glue it together, and call it "a web site", and THEN spare their OWN servers from the extra bandwidth by having those ginormous libraries load from CDNs.

        /me runs NoScript and if I can't read your content, I typically go elsewhere. It's a big intarwebs.

        1. AMBxx Silver badge
          Pirate

          Re: Perhaps

          It was just a joke, not an attempt to start a religious war!

  2. This post has been deleted by its author

    1. sabroni Silver badge

      Re: Lots of shouty, no content

      Follow the link and read the article. Despite being full of language like "Javascript is notorious for security problems" which really doesn't help much they do go into quite a lot of detail about the javascript vulnerabilities they're talking about. I've only scanned it but it looks like it'd be worth a proper look at some point!

      1. Displacement Activity

        Re: Lots of shouty, no content

        I've just scanned it as well, but I can't find anything of any value. It even explicitly states "Note that the focus of this paper is not measuring the security state of specific JavaScript libraries. Rather, our goal (and primary contribution) is to empirically examine whether website operators keep their libraries current and react to publicly disclosed vulnerabilities". The technical content on vulnerabilities appears to be zero.

        1. Alan_Peery

          Re: Lots of shouty, no content - because the topic is messy

          The scope of this topic could be described as list of websites -> list of libraries -> library -> list of vulnerable versions -> list of vulnerabilities in each version -> technical details of each vulnerability. The paper only looks at the first four components. If you're looking the details in components 5 & 6, start with the list from component 4 and consult each release note and CVE.

          I'd argue that the list from component #4 (mentioned on page 4, point 4 of the doc) is the most valuable point from a deployment strategy, because it would allow you to check your version(s) against that list and patch. The problem is that the javascript library world is poorly managed, because there are approximately 400 (!) versions across 11 libraries (pg 4, figure 1), so the list is simply too massive to include.

    2. HieronymusBloggs Silver badge

      Re: Almost 88 per cent of the top 75,000 websites and 47 per cent of .com websites

      "Lots of shouty, no content"

      Did we read the same research paper? I found it quite interesting and informative.

  3. Duncan Macdonald Silver badge

    Yet another reason to use NoScript

    NoScript and AdBlockPlus reduce the amount of Javascript executed in the browser thereby lowering (but not eliminating) the chance of encountering a problem.

    1. This post has been deleted by its author

    2. bombastic bob Silver badge

      Re: Yet another reason to use NoScript

      also greatly shortens load times in many cases. if you're doing a 'duck duck go' search, and you end up on what LOOKS like something with the content you want, it takes less time to realize they're just click-baiting you.

  4. Anonymous Coward
    Anonymous Coward

    Backwards compatiblity

    Just like OpenSSL, it's backwards compatibility that's hurting security.

    If you ruthlessly ditch depreciated versions of IE, then what exactly IS jQuery? A 30kB dependency that re-invents document.querySelector and Object.assign

    1. Charlie Clark Silver badge

      Re: Backwards compatiblity

      Please lookup depreciate and deprecate.

      1. Doctor Syntax Silver badge

        Re: Backwards compatiblity

        Normally I'd agree but it's IE that was mentioned so both apply.

        1. bombastic bob Silver badge
          Trollface

          Re: Backwards compatiblity

          "Normally I'd agree but it's IE that was mentioned so both apply."

          IE? then I'd have to add "defecate" to that list of words to look up

      2. Anonymous Coward
        Anonymous Coward

        Re: Backwards compatiblity

        You sound absolutely butt-devastated over my internet typo.

        Secondly, all versions below IE11 have already passed end-of-life. Nobody should be supporting or using them on the web.

        1. Rich 11 Silver badge

          Re: Backwards compatiblity

          Nobody should be supporting or using them on the web.

          Meanwhile, back in the real world...

          1. AMBxx Silver badge
            Facepalm

            Meanwhile, back in the real world...

            I was in an NHS hospital a couple of weeks ago. PC in the corner was XP with IE old. Data was being entered into an app running using Java plugin. I was just waiting for Flash to appear to complete the full set of security vulnerabilities.

            Month previous, I was in the local private hospital. Still very sensibly using paper for all their records!

            1. Charles 9 Silver badge

              Re: Meanwhile, back in the real world...

              "Month previous, I was in the local private hospital. Still very sensibly using paper for all their records!"

              And what if there's a FIRE? Hard to copy paper records offsite, and expensive.

              1. Anonymous Coward
                Anonymous Coward

                Re: Meanwhile, back in the real world...

                "And what if there's a FIRE? Hard to copy paper records offsite, and expensive."

                Yeah, but if there's NOT a fire, then all you need to read the paper record is good vision and sunlight (which more or less happens every day). Oh, and comprehension of the language it's written in. No high-tech stuff there, really. No problems with outdated data file formats, no problems with lack of a tape drive that can still read the records off the reel, no worry about it getting hacked. None of that. It's just info on paper.

                Need a copy for off-site storage? There's a marvelous invention called a copy machine that can make copies almost as fast as you can think about it. There IS some techno there, but the output of said techno just needs eyes and sunlight to be useful.

                1. Charles 9 Silver badge

                  Re: Meanwhile, back in the real world...

                  Which doesn't help when you're in the dark without benefit of a flashlight. As for photocopiers, that means additional paper, toner, and maintenence not to mention malfunctions.

                  1. Anonymous Coward
                    Anonymous Coward

                    Re: Meanwhile, back in the real world...

                    "Which doesn't help when you're in the dark without benefit of a flashlight."

                    If you're in the dark without the benefit of a flashlight (and, I'm assuming, without the benefit of light bulbs and electricity), how the hell are electronic documents better than paper documents? At least the sun will come up in the morning and fix your problem of not having any light to read by. But if you don't have electricity, your computer is just a boat anchor, and your electronic documents are effectively lost.

                    I will give you the point about copier upkeep and maintenance, though.

            2. wikkity

              Re: NHS hospital a couple of weeks ago. PC in the corner was XP

              There are still a lot of XP devices out there, especially in places like hospitals where it is needed to communicate with perfectly serviceable medical equipment manufactured when XP was cutting edge. They do however have restrictions in place and kept off networks unless required and then limited.

              1. Anonymous Coward
                Anonymous Coward

                Re: NHS hospital a couple of weeks ago. PC in the corner was XP

                Wonder what would happen, though, if a device like that requires something open that leaves it vulnerable to pwnage and can't be replaced because to do so will involve a seven-plus-figure expenditure?

        2. Tom 38 Silver badge
          FAIL

          Re: Backwards compatiblity

          Secondly, all versions below IE11 have already passed end-of-life. Nobody should be supporting or using them on the web.

          Spoken like a true zealot. Hey Mr Chinese Man whose company still only uses IE 9, look I really can't accept that huge big bag of cash for accessing our website because AC said you should be using IE 11 already.

          You can nudge, you can poke, you can plead, but the only time you can stop supporting shitty old browsers is when the users of your sites stop using shitty old browsers.

        3. Charlie Clark Silver badge

          Re: Backwards compatiblity

          You sound absolutely butt-devastated over my internet typo.

          Nope, just mildly amused by your lack of erudition and subsequent defensiveness. Why not go with end-of-life in the first place?

          FWIW for my clients I advocate such a policy for all web site development. But I also see, as do others what the real world throws up: IE9 is indeed still popular in China. Furthermore, while it's a good start to use the most recent stable versions of libraries. this doesn't obviate the need for objective security reviews and tests. And as developers we all need to ask ourselves: do we really need this library?

          1. This post has been deleted by its author

          2. Anonymous Coward
            Anonymous Coward

            Re: Backwards compatiblity

            I bet you don't actually do any business with China though. You're using it as a contrived example to support your point.

            China is very insular and overwhelmingly serves it's own markets.

            1. This post has been deleted by its author

              1. HieronymusBloggs Silver badge

                Re: China

                "They're still morons to use IE9."

                There's a difference between being uninformed and being a "moron".

                Over 18% of the world's population live in China, and a little over half of those have internet access. You can't expect every one of those hundreds of millions of people to be as well-informed as yourself.

              2. Tom 38 Silver badge

                Re: China

                So what, AC? They're still morons to use IE9.

                Morons with money. My favourite kind of moron.

          3. Anonymous Coward
            Anonymous Coward

            Re: Backwards compatiblity

            "And as developers we all need to ask ourselves: do we really need this library?"

            And if the answer comes back, "YES, and it MUST be an outdated and always-vulnerable version because any later kills critical functionality, we can't life it because it's copyrighted, and we can't run the site without it, end of."?

            1. Ken Hagan Gold badge

              Re: And if the answer comes back...

              Then you need to ask a different developer. Try looking for one with a fucking clue about software development. The answer you quoted would imply that the existing devs have managed to engineer a hard dependency on a broken feature. You need new devs.

        4. brotherelf
          Headmaster

          Re: Backwards compatiblity

          > Secondly, all versions below IE11 have already passed end-of-life.

          Nope, Vista and its IE9 won't be EOL for another four weeks or so. Yes, we'd all much rather forget that one.

          1. BinkyTheMagicPaperclip Silver badge

            Re: Backwards compatiblity

            Don't forget Server 2008. It's still supported until 2020, and it only supports up to IE9..

  5. wolfetone Silver badge

    The problem are web agencies and freelancers, not the site owners.

    Company X goes to Agency A, "Build us a website". "OK" says the agency. Gets 50% down payment on a £10,000 website, outsources it to India to maximise returns. Agency presents Company X with website to get signed off. Company X, not really knowing what to look for code wise, kicks the tyres and says "Yeah that's great here's the other £5,000 to make it go live". Website goes live. Agency moves on to the next project, Company X moves on to another part of their business because the website is "done".

    Company X will probably never touch the website again for a good 2 or 3 years, at which point they'll either appoint Agency A again or go to Agency B. Either way they'll be charged the same amount of money for a brand new website which is either outsourced or given to the YTS member of the team to bash out in 2 weeks. Rinse and repeat.

    At no point does Company X ever think to ask Agency A to "update" the website when needed to address security concerns. Agency A also either never offer that service, or they do offer it but they want a fairly substantial monthly fee to do so. Company X can't see the point in spending money on something to prevent the worse from happening. That's even if Agency A actually bother doing what they say they're going to do.

    But that's the same with everything. No one wants to spend money on something that might not happen. If the website works, then why bother fixing something that might affect it? It makes more financial sense - for some reason - to fix the problem after it's occured. This goes for car companies, aircraft manufacturers, even councils.

    Also, the above is based on 75% of companies not giving a damn how the website works. They just want it up with their brand and their "message", a way for the customers to see some photos and email them through a contact form.

    1. Charlie Clark Silver badge

      I have to disagree on this: website owners are at fault for not budgeting and contracting for maintenance. This favours cut-throat cowboys over anyone with a proper support policy.

      1. HieronymusBloggs Silver badge

        "website owners are at fault for not budgeting and contracting for maintenance"

        Most website owners are unaware of the need for ongoing maintenance. I'd expect a conscientious web developer to explain it to them.

        1. Blitheringeejit
          Facepalm

          I've tried

          As a "conscientious web developer", I've tried this. But you're telling people something they don't understand, and don't want to hear - while the cowboys are saying "There's no need to spend that extra money, it's all fine, and people who say this sort of thing are just trying to fleece you for extra monthly fees." So who are they going to listen to?

          Also, the site owner rarely gets punished for poor security, because the payload is most often activated on an end-user's computer. The end-user gets their bank account emptied and/or their files ransomewared, but has no idea which site caused the initial malware infection - so there's no little or no incentive for the site owner to secure the site.

      2. bazza Silver badge

        No, the people fundamentally at fault are those who have done so much to push the POS that Javascript is as a standard that all should embrace and rely on, and then abjectly refuse to police it, weed out the dross, etc.

        That's basically the major browser developers, outfits like Google, Mozilla, etc. They claim to have made a runtime environment that's universal and safe, yet it's turning out to be as hazardous as any other client side execution Web technology. "Use Javascript, it's safer than Flash/Java/ActiveX/etc". Yeah, right.

        Automatically running arbitrary code downloaded from God knows where without so much as a first glance, never mind a second glance, is always a bad idea. Anyone trying to convince you otherwise is almost certainly selling snake oil.

        1. Anonymous Coward
          Anonymous Coward

          >arbitrary code

          Javascript can't run arbitrary code though. It can only call APIs.

          Despite the hype, webassembly is even more limited. Arithmetic only.

          1. Anonymous Coward
            Anonymous Coward

            "Javascript can't run arbitrary code though. It can only call APIs."

            But those APIs in turn connect to arbitrary code: lots of which you can't even inspect...

            1. Anonymous Coward
              Anonymous Coward

              All browsers (except the shit one) are open source.

              Chromium source code is well structured, and pretty readable.

              1. LDS Silver badge

                Chromium is open source, but Chrome? I would really like to read *all* the code of Google Chrome...

          2. Arthur the cat Silver badge
            Trollface

            Javascript can't run arbitrary code though. It can only call APIs.

            Despite the hype, webassembly is even more limited. Arithmetic only.

            Paging Herr Gödel and Mr Turing. Herr Gödel and Mr Turing are wanted in the mathematics of computation lecture theatre where Signore Peano is waiting.

        2. LDS Silver badge

          The problem is browser offer an execution environment, but not "system" libraries.

          Besides fashion-driven development that asks developers to change framework every six months, the main issue is browser are offering an execution environment that is powerful enough to be dangerous (despite the sandboxing attemps, but to be useful sandboxes can't be too tight...), but they don't offer the system libraries (and their updates) an OS offers - so developers use a plethora of third party code even for basic functionalities (up to one line functions!) - which is just too difficult to keep up to date.

          Especially if that code is not maintained using proper lifecycle policies, making each upgrade a risk without proper testing and developers availability to fix any issue. IMHO it's time for a "standard js library" - and maybe it's also time for a standard widget set for UIs. Delivered by browser and updated with browser updates. Browsers wants to be sort of OSes? They have to offer the same services.

          Designers and marketing would complain, but if they do, it means it's the right path to follow.

          1. poohbear

            Re: The problem is browser offer an execution environment, but not "system" libraries.

            "IMHO it's time for a "standard js library" " .... I actually suggested more or less that to Mozilla a while back... along the lines of "there are umpteen websites using JQuery/Angular/etc" and everytime a user goes to one they need to download the library again... so why not bundle the popular libraries into the browser, and bypass the fetch. Since browsers are nowadays updated frequently, the user gets the latest version of library, and no wasted bandwidth.

            I accept that in some cases backwards compatibility will be an issue, as well as "custom builds" of libraries, and name-space issues... but if it was a default then these things can be managed/worked around.

            1. LDS Silver badge

              Re: The problem is browser offer an execution environment, but not "system" libraries.

              No, just bundling the popular libraries without any control on their APIs and development is not much different than downloading them from a CDN.

              There should be a *standard* library decoupled from the latest fashionable library, because the problem is not downloading them each and every time, the problem is their stability, maintenance and their use in applications.

              Ensuring security *plus* backward compatibility is important when your application is not the web site du jour, and you don't have the resource of Google or Facebook to maintain it. For many business their web applications (internal or external) are not the business, are just tools to support the business - and the compete for resources and priorities with all the other tools.

            2. Ken Hagan Gold badge

              Re: The problem is browser offer an execution environment, but not "system" libraries.

              "Since browsers are nowadays updated frequently, the user gets the latest version of library, and no wasted bandwidth"

              I refer the honourable gentleman to the post I read some moments ago. If we could rely on everyone to be running a recent browser, a fair number of common JS libraries could be dispensed with altogether. Trouble is, we can't depend on that, or at least we believe that we can't.

          2. Brewster's Angle Grinder Silver badge

            Re: The problem is browser offer an execution environment, but not "system" libraries.

            @LDS "IMHO it's time for a "standard js library" - and maybe it's also time for a standard widget set for UIs. Delivered by browser and updated with browser updates. Browsers wants to be sort of OSes?"

            Both these things exist. HTML/DOM is the standard widget set. And javascript contains a standard library. Both of these things continue to be extended. But it takes a lot of time to sit down and debate how an API should be implemented. There are four manufactures (Apple, Mozilla, Microsoft, Google) each with significant market share and a compromise has to be worked out between them. Stuff has to be implemented and then reconsidered once there's practical experience. It takes time.

            Nor can you standardize on approaches. Those libraries represent different approaches to solving problems. Features that aid in what they are doing are on the way to the core. But every programming language has libraries. That ain't gonna change.

            1. LDS Silver badge

              "Nor can you standardize on approaches."

              So enjoy the balkanization of web development, and its inherent risks. Keep on importing an lpad() function from NPM.

              We can have standards, especially when it comes to basic libraries and UI elements. HTML/DOM is very poor as a UI and innumerable libraries reinvent their own. Having a common ground doesn't limit "approaches" used in different development model - just avoid to reinvent the wheel each time - also leaving a lot of square and broken wheels behind, which will never be fixed.

    2. dajames Silver badge

      But that's the same with everything. No one wants to spend money on something that might not happen.

      Yes, that's a nice succinct restatement of a very large part of the problem ...

      ... but what can we DO about it?

      1. bazza Silver badge

        I don't think there's anything that we can do. But a big outfit like Google could show some leadership and do something and impose it. Very Microsoft. Very evil. Very necessary?

        Google had better get on with it. Their entire empire is built on Javascript, and it's not too far from being deemed to be a massive security hazard. If that actually happens, and the world at large goes off Javascript like they have gone off Java, Flash, activeX, etc, then Google are in deep trouble. "Please run Javascript on our search page, please, otherwise those ads are going to be far less effective! And we'll do a native gmail client soon, honest.".

        1. LDS Silver badge

          Google is perfectly OK with this. Any attempt to tackle this issue would go through more standardization of web development, and that would tie Google hands too. Now it's free to push its own javascript libraries and frameworks - as well as Facebook -, without any restraint.

          Their size means others can do little but accept, so they have the edge (just like MS was able to take advantage first of new Windows features....). Any standardization means they'll lose a good slice of this advantage.

          1. This post has been deleted by its author

            1. Anonymous Coward
              Anonymous Coward

              "I work for an agency that DOES have long-term maintenance contracts with clients, and unfortunately the problem persists. They use their maintenance budgets to add stuff, not for actual maintenance. We tell them their websites are falling apart and need a maintenance overhaul... months go by... nope, they want more frills."

              Did you threaten lawyers at that point for Breach of Contract?

          2. bazza Silver badge

            Google is perfectly OK with this. Any attempt to tackle this issue would go through more standardization of web development, and that would tie Google hands too.

            Google may be OK with this but ultimately it's a big risk for them. No Javascript = big increase in costs for Google. If you take Javascript away, what of Google's empire is left? Android? Web based Google Docs, Maps, Search, Gmail, etc are toast. That's a massive part of their business. Google absolutely need Javascript to be safe and secure.

            We've seen recently that Javascript can be used to unwind the ASLR of the Web browser, meaning that Javascript exploits could be made reliable. This study now shows that the anarchy of the Web can have real consequences. It's early days in the death of Javascript, but these papers highlight that Javascript is potentially hazardous, and no on eis doing anything from improve it.

            If that's not on Google's business risk register, then they're not doing their investors any favours.

            1. Charles 9 Silver badge

              "Web based Google Docs, Maps, Search, Gmail, etc are toast."

              That's why they're now in APPS. What's to stop Google creating a native-desktop program to encompass all their functions in a world without JavaScript?

            2. Tom 38 Silver badge

              Google may be OK with this but ultimately it's a big risk for them. No Javascript = big increase in costs for Google. If you take Javascript away, what of Google's empire is left?

              So if we assume that JS is destroyed and gone, and there is some new super safe way of doing interactive things in the browser, how much would Google be affected?

              Very little. All their apps are written in Dart, which is then compiled to JS. They would simply write a different backend to the Dart compiler to compile to NewFancyLanguage.

              Of all the examples you could use to demonstrate reliance on JS, google is the worst.

              1. dajames Silver badge

                All [Google's] apps are written in Dart, which is then compiled to JS. They would simply write a different backend to the Dart compiler to compile to NewFancyLanguage.

                For NewFancyLanguage to be safe -- to be free from all the exploits that make Javascript such a disster -- it will have to offer less functionality than Javascript, and may well not support all the functionality that Dart requires.

            3. LDS Silver badge

              "Google may be OK with this but ultimately it's a big risk for them"

              There are actually no replacements for Javascript for web applications, being all the others even worse (Java, Flash, Silverlight...). And it's not Javascript itself to be insecure in this case, it's how web application are written and the dependencies managed. For the matter it happens in any language which uses external libraries which are not updated with the OS (for example, lots of vulnerable OpenSSL libraries deployed in Windows....)

              Despite the issue, there's really nothing to worry Google or Facebook right now (the two real web powerhouses). Google moreover controls what has become the dominant browsers, so it's also in a position to drive towards what it thinks suits best its business. Frankly, Google and Facebook are probably the only two companies that could decide to replace Javascript - after all AFAIK Angular already prefers TypeScript.

              These security issue may prompt the two companies to "suggest" they become the library repositories, to "improve" and "warrant" their quality - albeit some antitrust body could object (an EU one, I guess...)

              1. Tom 38 Silver badge

                Re: "Google may be OK with this but ultimately it's a big risk for them"

                There are actually no replacements for Javascript for web applications, being all the others even worse

                Right, but we aren't talking about reality at the moment, someone posited the thought experiment "If JS was to disappear, companies like Google would be up shit creek and they don't seem to acknowledge those risks".

                It's a bad thought experiment because either there is an equivalent language to replace it, in which case a Dart-to-new lang compiler would remove the risk, or that there are no more browser apps possible, in which case Google write a Dart-to-C compiler and deliver native apps.

                1. bazza Silver badge

                  Re: "Google may be OK with this but ultimately it's a big risk for them"

                  @Tom38,

                  Right, but we aren't talking about reality at the moment, someone posited the thought experiment "If JS was to disappear, companies like Google would be up shit creek and they don't seem to acknowledge those risks".

                  It's more philosophical than that.

                  It's a bad thought experiment because either there is an equivalent language to replace it, in which case a Dart-to-new lang compiler would remove the risk, or that there are no more browser apps possible, in which case Google write a Dart-to-C compiler and deliver native apps.

                  The point is that "new lang" would also eventually succumb. The problem is that all interpreters / run-times, browsers, OSes and CPUs are mathematically certain to be flawed in one way or other. We as a species simply cannot generate provably flawless code or hardware, so it's not really an option. For example, until a couple of weeks ago everyone assumed that ASLR was a strong defence, but it got thoroughly trashed by a Dutch research group who showed that it could be unwound. In Javascript. In a Web browser. That's a major calamity.

                  Besides, we like fast-moving, new, dynamic stuff. To be provably secure means slow-moving, mature, never changing stuff. Shiny-shiny wins every time.

                  There's also the point that the introduction of "new lang" would simply expose a whole load of new-out-the-box flaws that will inevitably plague a new pile of code. Just like Javascript did initially.

                  The only sure solution to the problem of dynamic web pages is to forget about client side execution in the browser altogether, and replace it with a Turing incomplete remote display protocol for code running server-side. A bit like HTML used to be. A bit like X server protocol, and (AFAIK) RDP, VNC, etc. We're not very good at implementing such protocols problem free either (buffer overruns, etc), but it's a much easier challenge.

                  If we don't go down that route then we're condemning ourselves to having to re-write the whole Internet every time our latest Web browser client side execution environment becomes too dangerous to use. Based on our experience in trying to expunge Flash from the world, it'd be very hard to replace Javascript.

                  1. Tom 38 Silver badge

                    @bazza

                    You haven't understood either of my posts. I'm not suggesting anyone replace JS, or even think about replacing JS. The discussion was solely, "If JS was no more, what then for Google? Aren't they in shit creek?". Its a thought experiment, not reality.

                    As for not having dynamic web pages, and remote viewing any interactivity... can you give me the number of your dealer, because you are high.

                    1. Charles 9 Silver badge

                      Re: @bazza

                      "As for not having dynamic web pages, and remote viewing any interactivity... can you give me the number of your dealer, because you are high."

                      No, I'm completely sober. In fact, I'm downright depressed because the state of the Web (no, the entire Internet) is such that unless something radical is done, we may well lose it altogether to the next Mirai or a major automated attack on most of the Web. We can't even say our computers are really ours to control anymore. If we don't take back control YESTERDAY, we'll have no chance to get it back because all the avenues will be blocked.

                  2. Charles 9 Silver badge

                    Re: "Google may be OK with this but ultimately it's a big risk for them"

                    "The only sure solution to the problem of dynamic web pages is to forget about client side execution in the browser altogether, and replace it with a Turing incomplete remote display protocol for code running server-side. A bit like HTML used to be. A bit like X server protocol, and (AFAIK) RDP, VNC, etc. We're not very good at implementing such protocols problem free either (buffer overruns, etc), but it's a much easier challenge."

                    And that's exactly what I'm proposing. Leave the interactivity to those protocols built from the outset for it, and since most users would get lost in CLI Land, SSH is not an option unless it's used as a tunnel for X, but VNC would probably be preferable because it's built for more-efficient an adaptable transport.

              2. bazza Silver badge

                Re: "Google may be OK with this but ultimately it's a big risk for them"

                @LDS,

                These security issue may prompt the two companies to "suggest" they become the library repositories, to "improve" and "warrant" their quality - albeit some antitrust body could object (an EU one, I guess...)

                It depends on how they do it. If they do it for free, make it fully available, for the public good, in the manner of a beneficial dictator, then I think the anti-trust bodies would have no interest whatsoever. If they make it so that only Chrome does it and then only for code from Google, then I think the objections would come thick, fast and expensive.

                If Google or Facebook made a case along these lines, I doubt that they'll be able to bring enough of the community with them. The world hasn't been able to fully expunge Flash. There's going to be too much stuff that's important to lots of people that doesn't fit in with a potential Google/Facebook vision of how things should be. We're in this mess partly because there has been poor standards, not much adherence to those standards anyway, and the whole thing is effectively nothing more than one global hack-fest of software putrefaction which somehow has come to be seen as hot, cool and modern. There's a lot of momentum to overcome. Conforming is not in every web-developer's mindset.

                1. LDS Silver badge

                  "for the public good, in the manner of a beneficial dictator"

                  Ehm, no. It never depends on how you do it, when it comes to antitrust laws. It only depends how dominant your position is. There's never a "beneficial dictator" working for the "public good".

                  Monopolies are *always* dangerous - because they always work for themselves first. It didn't matter if Microsoft gave away IE and Media Player for free - and it was also part of the problem because it crushed competition. "Free" is not always "good". Sometimes it's just a decoy to chain you in another way.

  6. Ole Juul Silver badge

    choices

    If the plan is to make good web sites then JavaScript is the wrong solution. If the idea is to make lots of things work quickly and then run away, it is a great solution.

    1. Blitheringeejit
      Boffin

      Re: choices

      "If the plan is to make good web sites then *WRITING YOUR OWN* JavaScript (which does exactly and only what you need it to do) instead of importing some huge and potentially vulnerable 3rd-party Javascript library (just to do a bit of pointless whizzy UI effectery) is the RIGHT solution."

      FTFY

      1. Anonymous Coward
        Anonymous Coward

        Re: choices

        "If the plan is to make good web sites then NOT USING JAVASCRIPT AT ALL (which can end up doing things you didn't intend to do without your knowledge and then pwn your clients' machines) is the ONLY viable solution, and even that won't help much if a malformed graphic file can punch through your browsers' sandboxes and privilege escalate. If you can't run your site without JavaScript, then perhaps you're doing it wrong."

        There, FTFTFY.

        1. Jonathan 27 Bronze badge

          Re: choices

          That's not an option. You can't write modern responsive fancy-looking, slick websites without JavaScript. In fact, a lot of websites are totally dropping support for browsers with JavaScript disabled.

          1. Charles 9 Silver badge

            Re: choices

            Interactivity was NOT an intended design of the Web, though. That's something best left for proper protocols like X over SSH or VNC. So I refuse to consider it not an option. It's ALWAYS an option. In fact, taking the Web passive again should be the ONLY option to save the Internet as we know it.

            1. Orv Silver badge

              Re: choices

              "Interactivity was NOT an intended design of the Web, though. That's something best left for proper protocols like X over SSH or VNC. So I refuse to consider it not an option. It's ALWAYS an option. In fact, taking the Web passive again should be the ONLY option to save the Internet as we know it."

              X and VNC are both horrifically insecure. I would rather maintain a hundred Javascript libraries than let someone connect directly to my server and run a native app with VNC.

              My experience with native apps is they're often buggier than web apps anyway, and harder to keep up to date. The number of people who have been owned by MS Word viruses suggests that it's less secure than Google Docs, not more, in spite of Google Docs' use of Javascript.

              For that matter, in my experience GMail is far more usable and stable than Thunderbird, and Thunderbird was in turn far more usable than passive webmail apps.

          2. HieronymusBloggs Silver badge

            Re: choices

            "a lot of websites are totally dropping support for browsers with JavaScript disabled."

            If they're selling something I'll be buying from someone else. Having to turn on JavaScript to access certain features of a site is sometimes unavoidable, but not working at all without it is usually enough to send me elsewhere.

            1. Charles 9 Silver badge

              Re: choices

              And if they're the ONLY supplier of something due to exclusive contract?

              1. HieronymusBloggs Silver badge

                Re: choices

                "And if they're the ONLY supplier of something due to exclusive contract?"

                That's why I said "usually". If there's a choice I'll go for the least irritating one.

                1. DropBear Silver badge

                  Re: choices

                  In my experience, the exact same <whatever it is I'm shopping for> is never sold on more than a handful of sites that I'm actually able to buy from, and absolutely every single one of them does precisely nothing on any click without JS running. There is no such thing as a "href" link on a commercial site any more. It's not even a matter of conscious effort any more - JS, or you don't shop, end of. And no matter how cantankerous of a curmudgeon I may be, I'm just not prepared to relocate into a cave just to stick it to JS.

                  1. Charles 9 Silver badge

                    Re: choices

                    "There is no such thing as a "href" link on a commercial site any more. It's not even a matter of conscious effort any more - JS, or you don't shop, end of."

                    And NONE of them have any other form of contact, such as a telephone number, a snail mail address, or even a brick-and-mortar storefront from which you can interact? Is it ABSOLUTELY JavaScript or bust? If so, all I can say is, "Woah." I'd frankly have to wonder if I really NEED that thing at that point. Otherwise, if they have ANY other form of contact, I resort to it and inform them on the strictest terms that it'll be the ONLY way you'll interact with them because you environment is incompatible with JavaScript for security reasons and that it's now a condition of your (and all your technico friends) continued shopping with that site. Few things hone a store's senses like the threat of a defection.

          3. LDS Silver badge

            Re: choices

            If the website mostly displays information only, and doesn't need a sophisticated interactive GUI, there's very little or need of Javascript. But all the user data gathering code won't work without, of course - which is the main reason to need Javascript on many sites....

            1. Charles 9 Silver badge

              Re: choices

              Which in turn makes it the main reason we SHOULDN'T be using JavaScript anymore. It's too much of an information leak. Make those sites that depend on that data starve and go back to the days when you just filled out a traditional web form and all that stuff. I recall even eBay was able to run without AJAX when it first started out.

          4. bombastic bob Silver badge
            Thumb Down

            Re: choices

            "You can't write modern responsive fancy-looking, slick websites without JavaScript."

            WRONG. Just do this: create a PNG file that "looks that way" and use hotspots. So, it does NOT "require" JavaScript for that kind of thing after all, right? Besides, the term "modern" [often used as a pejorative, since it quietly implies everything NOT that is somehow 'ancient' or 'outdated'] is SO over-used, I don't think it carries any weight. Remember, Win-10-nic's look is often called "modern" by its fanbois. And so I rest my case on the use of the term 'modern' to describe "those things".

            "In fact, a lot of websites are totally dropping support for browsers with JavaScript disabled."

            This has more to do with CLICK-THROUGH AD REVENUE than anything else. They don't like non-script-running browsers because they don't get AD REVENUE from them. And ad blockers often behave the SAME way. So _THEIR_ solution, block anything NOT accepting their privacy-violating JavaScript, cookies, whatever.

            /me mutters: there's NO school like the OLD school! standard HTML, no script!

        2. nagyeger

          Re: choices

          Dear AC, I'm very interested in learning how to do a zoomable slippy map without JS. Could you post some pointers?

          1. Charles 9 Silver badge

            Re: choices

            Two ways: native app or a remote desktop protocol like VNC.

            And BTW, to the person who dissed VNC, perhaps you can work on it yourself, given the basics of VNC is open-source. I happen to prefer TightVNC myself, which is GPL. If you don't trust VNC, then you probably don't trust FOSS in general, either.

            1. Orv Silver badge

              Re: choices

              I trust FOSS just fine. The problem is not that I think VNC was written with evil intent.

              I don't trust VNC for the same reason I wouldn't let strangers sit at my desktop machine's keyboard unsupervised. It's far too much access. It also has a significant security history. The authentication protocol is especially bad, and while "forward it over SSH" works very well for sysadmins, app users aren't going to want to try to configure PuTTY. The NOC where I work considers any exposed VNC port a vulnerability.

    2. Orv Silver badge

      Re: choices

      Javascript and the web are popular for apps because they're the only real "write once, run anywhere" platform we have. Java never really fulfilled that promise in a useful way, but it's easy to write a web app that will work on OS X, Windows, and Linux. Native code can't do that, at least not without a huge pile of maintenance-intensive #ifdefs and a recompile for each platform.

  7. Jack of Shadows Silver badge

    We are right back to talking about a nigh on universal industry problem, secure, maintainable systems. It's not any one library, language or individual system that's the problem. It's the whole damned construct.

    1. Charles 9 Silver badge

      So how do we fix it when the only people that can fix the problem are too slippery to coerce?

      1. DropBear Silver badge

        What if this is the Heisenberg principle of coding - you can have complexity or you can have maintainability, but only at the other's expense? Wanna go back to HTML 1.0 and plaintext? Yeah, okay, you first...

        1. Charles 9 Silver badge

          Never went past 3.0 and FRAMES. Can give up the JavaScript in a New York Minute since it was mostly inline cosmetic stuff. Going back is easy for me, how about you?

          PS. Some basic 4.0 stuff I can tolerate like simple style sheets (just no scripts in them).

          1. Orv Silver badge

            Framesets were one of the most user-hostile web features ever. They routinely broke navigation, especially between sites. I remember when nearly every site had to have an "escape from other people's frames" link, to avoid the picture-in-a-picture-in-a-picture effect.

          2. Anonymous Coward
            Anonymous Coward

            Opinion discarded

            Good job revealing your complete and utter ignorance.

            First I don't believe for one second that you write HTML 3.2, a standard from 1997 (HTML 3.0 never made it as a standard). More likely the HTML5 parser is covering for your sloppy-ass markup.

            HTML5 was a cleaning of house more than anything. Removing cruft like overly verbose doctypes. Of course you're free to just not use javascript, but anyone who isn't writing HTML5 is an idiot, and either a hipster or a dinosaur.

            And seriously, inline javascript? Nobody writes that any more. ES6 modules are just around the corner.

            1. Charles 9 Silver badge

              Re: Opinion discarded

              "So, you're suck in the 90's? At this point the web has moved past that point, to being an application-delivery method, for better or worse. "

              Well, it's worse. A LOT worse. In fact, it's a threat to the entire Internet. It's time to nuke it from orbit and start over. If it survives, might as well abandon the Internet.

              "And seriously, inline javascript? Nobody writes that any more. ES6 modules are just around the corner."

              NO! I DEMAND inline script so I can see the code.

              1. Orv Silver badge

                Re: Opinion discarded

                "NO! I DEMAND inline script so I can see the code."

                In Chrome:

                Right click -> Inspect -> Sources

                Go to town. It'll even pretty-print minified code to make it halfway readable.

          3. Jonathan 27 Bronze badge

            So, you're suck in the 90's? At this point the web has moved past that point, to being an application-delivery method, for better or worse. JavaScript has a lot of design issues, but security isn't a big one. It's not inherently insecure and like it or not we don't have another option.

            Everyone's favorite buzzword "HTML5" is mostly a cleanup combined with a bunch of JavaScript APIs and I think it's likely the web will move even more in this direction in the future.

  8. Mark Simon

    Too many dependencies.

    So, does that mean that most web sites are not only bloated but also insecure?

    Many developers are addicted to taking short cuts, even if that introduces overweight dependencies on too many third parties. Each third party is a potential weakness in the design, and if developers are not committed to maintaining the integrity of these dependencies then they should learn to do the job properly themselves.

    • You may not need CDNs
    • You may not need jQuery
    • You may not need Bootstrap

    It’s more work to begin with, but much less stress worrying about someone else’s code.

    1. Sam Liddicott

      Re: Too many dependencies.

      For your boss, and your replacement, your code is someone else's code, and they worry about it.

      1. Anonymous Coward
        Anonymous Coward

        Re: Too many dependencies.

        I'd prefer to audit 3 lines of good javascript than the whole of jQuery any day.

        1. Anonymous Coward
          Anonymous Coward

          Re: Too many dependencies.

          Isn't good JavaScript an oxymoron, though?

          1. Anonymous Coward
            Anonymous Coward

            Re: Too many dependencies.

            Only if you believe javascript is inherently a bad language. Javascript has seen massive improvement in recent years, if you switch on "strict mode", and refrain from using the worst features such as eval.

            Promises have really cleaned up the callback soup, and fat-arrow notation has cleaned up some of the closure mess people get themselves into.

            1. Charles 9 Silver badge

              Re: Too many dependencies.

              No, I believe an Interactive Web is inherently bad. Why don't we push for moving it to a protocol designed for interactivity such as X or VNC? This would also put the onus back on the servers to keep their systems clean because now THEY have to run the code or they can't function.

              1. Anonymous Coward
                Anonymous Coward

                Re: Too many dependencies.

                This forum is interactive. Feel free to fuck off any time.

                1. Charles 9 Silver badge

                  Re: Too many dependencies.

                  But it doesn't really use JavaScript. The page itself is passive. It uses the bog-standard forms and such (though I may take issue with the way the icons are done; the old way was safer), and I don't have much issue with that. But live-update stuff like Discus and Lyvewire? Whole other story.

              2. Anonymous Coward
                Anonymous Coward

                Re: Too many dependencies.

                > "X or VNC?"

                You must be a troll. Or next you'll be telling me you live in a cave because houses have wood in them that somebody might set fire to, or you don't want a car because it might crash. And those new fangled 'sofas' - fuggedabout it because you might loose some money between the cushions.

                1. Charles 9 Silver badge
                  Trollface

                  Re: Too many dependencies.

                  No, whatever happened to Keep It Simple, Stupid (though in this case, a cruder S-word may be in order)?

                  Whatever hapepned to the philosophy of "Do ONE thing and do it well"?

                  Whatever happened to delegating jobs to programs designed for the job?

                  So if I'm a troll, then THIS is my bridge; cross at your own peril. And don't bother waiting for daylight; I'm stocked up on sunblock.

            2. LDS Silver badge
              Joke

              Javascript has seen massive improvement

              Yes, the more notable ones TypeScript and the like...

  9. patrickstar

    Something has gone seriously wrong with technology when the user interface layer itself can be security critical...

    1. Charles 9 Silver badge

      No, it's just a sign of the teetering condition of society as a while when ANYTHING can be rigged into a security exploit.

      1. DropBear Silver badge

        Go file a complaint with Turing. If any task can be handled by a computer, and if even flawless and immutable code, set in stone, can be used for Purposes Remarkably Different Than Originally Intended (look up 'return oriented programming' some day) then... <$logical_conclusion>

        1. patrickstar

          The actual UI layer can be strictly declarative. Or atleast without enough imperative functionality to be Turing complete.

        2. Charles 9 Silver badge

          Look up Return-Oriented Programming, which actually uses bits and pieces of legitimate code to do mischief. So, yes, even perfectly-legitimate code can be used Not For the Purpose Intended. Remember, diesel and AN fertilizer are common tools of the farmer, but Oklahoma City proved they can also be mixed together into powerful ANFO (IN SPITE of denaturants in the fertilizer--they were able to REnature it).

  10. frank 3

    It's like this conversation is happening in outer space

    Because anyone who suggests that you don't use Javascript in a website is in reality denial. I can count on the fingers of one ear sites that don't. Good luck explaining to your customer why NONE of the things they want, work.

    And yes, everything should be constantly patched and updated.

    Good luck explaining to your customer why they should pay for it (in an age where you can get a wordpress site designed and built for under £500).

    The only solution is for it to be fixed at source: for the libs to be secure and the version number to become irrelevant: no local copies and the CDN always serves up the latest version which is *always* backwardly compatible.

    But good luck with that too. Unpaid devs. contributing to OSS in their spare time using version numbering systems that make sense to the community aren't going to change how they work anytime soon.

    There is no solution: you are lumbered with the insecurities.

    1. Charles 9 Silver badge

      Re: It's like this conversation is happening in outer space

      "Because anyone who suggests that you don't use Javascript in a website is in reality denial. I can count on the fingers of one ear sites that don't. Good luck explaining to your customer why NONE of the things they want, work."

      Simple. "Due to the nature of the technologies involved being actively used to infect and take over computers all throughout the Internet, we cannot in good conscience require the use of these enabling technologies. HTML 1.0 was a passive technology, and separate protocols and external programs were the solution to interactivity in the past; therefore, we have no choice but to revert to technologies like VNC to provide interactivity."

      "And yes, everything should be constantly patched and updated."

      What if the patch is usurped with spyware? Or worse, hijacked to inject malware?

      "The only solution is for it to be fixed at source: for the libs to be secure and the version number to become irrelevant: no local copies and the CDN always serves up the latest version which is *always* backwardly compatible."

      Single point of failure. The hackers hijack the developer accounts and inject the malware into the sources, and since they took over the DEV accounts, they also have access to the signing keys.

      "There is no solution: you are lumbered with the insecurities."

      Well, we could always abandon the Internet and go back to the Sears catalog. Oh, wait, the telephone networks can be pwned, too...

    2. HieronymusBloggs Silver badge

      Re: It's like this conversation is happening in outer space

      "Because anyone who suggests that you don't use Javascript in a website is in reality denial. I can count on the fingers of one ear sites that don't."

      The Register works fine here without JavaScript turned on, as do many of the other sites I use. There seems to be an assumption among a lot of developers that JavaScript is always necessary. It isn't.

      1. Charles 9 Silver badge

        Re: It's like this conversation is happening in outer space

        After all, how did we do things BEFORE JavaScript was made? Why can't we go back to those days? There's likely an alternative for anything you can think of.

        1. Ken Hagan Gold badge

          Re: It's like this conversation is happening in outer space

          "After all, how did we do things BEFORE JavaScript was made?"

          In the early 90s you mean? Well, mostly we just did without, but this is a false dichotomy since improvements to things like CSS and SVG mean that a number of popular JS libraries are the "before" technology and the problem is with sites that *are* still "back in those days".

          1. Charles 9 Silver badge

            Re: It's like this conversation is happening in outer space

            To which I respond: they're overrated. What problems did they solve that weren't solved already?

  11. Jonathan 27 Bronze badge

    I'd personally suggest that implementing all your security and business logic in the back-end is the solution here. It's standard practice because you cannot trust anything running client-side. And if you're not loading any 3rd party content that's a solution in itself, it doesn't really matter how security the JS libraries are if only your own JS is running on the browser. It depends what sort of web site you're running, but JS security is much, much, much more important on ad-supported websites that run nasty 3rd party code, than it is on any other type of website.

  12. Tom 7 Silver badge

    Re: implementing all your security and business logic in the back-end

    So easy to implement - aargh managers!

  13. andy 103

    Stop obsessing over JavaScript

    About 10 years ago I worked at a web development agency. They were building an application and some of the developers wanted to try and go down the ajax, js-heavy route, because it was trendy.

    I had a long conversation with them about how the particular application could use absolutely no Javascript at all, and all be done in server side languages. The only caveat was they'd have to have the page reload rather than use ajax to get a "smoother" experience.

    I firmly believe that there's nothing wrong with doing full page reloads and writing sites/applications that use no js at all. It's become relied on for everything from validation (which you can obviously disable, by disabling javascript) to ajax requests (not needed as you can just reload the page) and transitions/effects (which few people actually care about). I honestly don't know why so many people are obsessed with javascript.

    1. Charles 9 Silver badge

      Re: Stop obsessing over JavaScript

      "I firmly believe that there's nothing wrong with doing full page reloads and writing sites/applications that use no js at all. It's become relied on for everything from validation (which you can obviously disable, by disabling javascript) to ajax requests (not needed as you can just reload the page) and transitions/effects (which few people actually care about). I honestly don't know why so many people are obsessed with javascript."

      The only think I can think of is timing-sensitivity, such as an eBay auction where an AJAX action can involve a shorter round-trip and can mean the difference between winning and losing a heated auction. But I can't think of little else that would require something that time-sensitive.

      1. andy 103

        Re: Stop obsessing over JavaScript

        "The only think I can think of is timing-sensitivity"

        I understand what you mean, but I think there's this perception of a need to mollycoddle end-users. For example if you're booking tickets and it says "you have 10 mins to complete this transaction", does a serious buyer really need a countdown? Most people know roughly how long 10 mins is, and if they're prepared to go ahead and complete a transaction (a serious buyer) they will find a way. Why do they need a countdown timer for that? And conversely if it's someone who isn't a serious buyer, they just get an error message if they submit the page, say 20 mins later. But they've been informed at a prior step that that would happen :)

        I build web applications for a living and I'm really against all this js bullshittery, even though it's "the thing to do". If end-users need so much hand holding, they're possibly not the kind of people you want to do business with anyway. Although I accept that's very much a web developer's way of looking at things!

        1. Charles 9 Silver badge

          Re: Stop obsessing over JavaScript

          "If end-users need so much hand holding, they're possibly not the kind of people you want to do business with anyway."

          Unless, of course, they're the BULK of your cleintele, meaning it's cater or them or starve, basically.

      2. bombastic bob Silver badge
        Devil

        Re: Stop obsessing over JavaScript

        "But I can't think of little else that would require something that time-sensitive."

        and if they DID need it, how about a 'meta refresh' tag in the content of an IFRAME?

        Been there. done that. worked really well. got 10fps refresh on a PNG image from a camera that way, for a prototype device control application that used a customized web server to control things _AND_ display on an android slab as HTML, ran as a 'web application'. very simple, very effective. the camera was a big part of it, and had to display LIVE images that were appropriately 'tweeked' and analyzed, frame by frame, and displayed within the 'control' page.

        CAN be done!

        1. Tom 64

          Re: Stop obsessing over JavaScript

          > "got 10fps refresh on a PNG"

          That's lovely for a hobby project. Try scaling that to a million users.

          1. Orv Silver badge

            Re: Stop obsessing over JavaScript

            "> "got 10fps refresh on a PNG"

            That's lovely for a hobby project. Try scaling that to a million users."

            Or mobile phones. They will not thank you for the extra latency caused by all those page reloads. (RTT for some mobile networks can easily exceed 200ms. You *really* don't want extra server requests.)

            Also I don't think I want to watch YouTube at 10 fps. ;)

    2. dajames Silver badge

      Re: Stop obsessing over JavaScript

      I firmly believe that there's nothing wrong with doing full page reloads and writing sites/applications that use no js at all.

      The "accepted wisdom" is that full-page reloads will be slow and impact upon user experience -- but internet speeds are faster now (for most people) than they've ever been and pages can load really fast ... as long as they're not bloated with scripts and forced to wait for script libraries to download from third-party sites.

      Running without scripting does mean that a slightly higher burden is based on the server, but surely that's a small price to pay for the ability to conduct business online without compromising your own or your customers' security.

    3. tiggity Silver badge

      Re: Stop obsessing over JavaScript

      A lot of "slick / responsive" sites are just irritating to many people - JS needlessly (you do not need ***** JS for what should just be a href style link)

      Dynamic scripty content often means that the bookmarked url, if revisited does not have any of the ******* content you were interested in as "dynamic innit" (not a thought given that people may want to revisit certain data)

      A few days ago I was with a dev who was taking the mickey out of an "old school" (3rd party website used to manage hardware from that company) web site, due to its look and feel - I gently pointed out that it did what was required, blindingly fast compared to JS bloat sites that have to pull in script from dozens of locations, it had no need for JS as any "interactivity" was done via form submits.

      Fast, fit for purpose, low bandwidth, only communicating with one web site - what's not to like?

  14. Anonymous Coward
    Anonymous Coward

    "Thus, even if a web developer keeps library dependencies updated, outdated versions may still be included by badly maintained third-party content."

    I'm sorry Mr/Mrs Marketing/Web Exec, we cant implement this social media plugin because it has the potential of shafting our website. I appreciate that it's important to you but when the shit hit's the fan, its me that gets it in the neck, not you.

    1. Tom 38 Silver badge

      I'm sorry Mr Developer, but since you won't perform straightforward reasonable tasks within your area of responsibility within the company, we're letting you go and hiring someone who will.

      1. Fatman Silver badge
        Joke

        'Manglement fail'

        I am sorry Mr Mangler, but seems that you fail to have an effective understanding of the risks that your proposed actions may have on the company.

        It would be in the best interests of the company for us to assist you in finding new career opportunities elsewhere. Like our competitors.

        That assistance begins with the door hitting you in the ass as you exit the company. You have five minutes to collect your personal effects and vacate the premises.

  15. Anonymous Coward
    Anonymous Coward

    C

    https://www.quora.com/How-can-I-make-a-website-using-c-language

    1. bazza Silver badge

      Re: C

      So long as it's running server side, why not!?!

  16. -tim
    Facepalm

    PCI-DSS?

    I have told many clients that their web pages aren't PCI-DSS complaint because of their broken Javascript. It never goes down well.

  17. EnviableOne Bronze badge
    Mushroom

    Language is not the issue

    The issue isn't JavaScript, its the fact that the incompetents who use it to make websites load unverified, possibly unused code, that they dont have a clue how it works or if its current.

    The modern website is no longer an art project needing design, its a piece of software needing built from the ground up, by all means, use other peoples code, but make sure you check it and know what bits do what and what bits you actually need.

    why pull in all of node, angular, etc when all you need is one code section, and you should be able to write it yourself. JavaScript is not hard, its not assembler, its not C, its not even Java!

    The current crop of web designers are Graphic designers who know a bit of code, and you know what they said a bout a little knowledge.

    </rant>

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019