back to article The power JavaScript: 'Gandalf of JS' Wirfs-Brock on ECMAscript 2017

JavaScript has become the interface to the web thanks to browsers, it's leaked onto servers with Node.js, and is now carving out a small niche in Machine Learning – but JavaScript just wouldn’t be without ECMAScript. ECMAScript is the standard language definition on which JavaScript is based and this summer saw an important …

  1. HmmmYes

    Javascript should have been took out back and shot in the head years ago.

    Its garbage.

    1. Anonymous Coward
      Anonymous Coward

      So, what's YOUR favourite scripting language, HY? Care to share?

      1. HmmmYes

        Python, for everyday scripting of everything.

        Lua for embedding in C + C++.

        Java script is a bad way to drive the DOM and AJAX. Jquery makes it a bit less horrid.Typescript tries to de-fuckup the javascript.

        My jaw drops with running JS on the server - Node and all that. Just because the JS JIT runs fast does not mean you should use JS outside of the browser.

        Ive never seen a Node setup which could nto be done better, faster and safer than using Elixir/ErlangOTP.

        1. Anonymous Coward
          Anonymous Coward

          > "Java script is a bad way to drive the DOM and AJAX. Jquery makes it a bit less horrid.Typescript tries to de-fuckup the javascript."

          This summer I spent a full month re-learning JS (I'm old). You may not be aware that many of the bad things in JS have been corrected or superseded by updates, particularly ES6. A lot of new/old programming capabilities have appeared too, and transpiling allows anyone to use modern JS without having to manually refactor for old browsers. There's even plans to introduce things like 'await' to the language, if you can believe it. So, over time your objections (tho valid) are becoming less and less relevant.

          I'm not saying JS should be in servers because I'm not competent to judge. But Node is, as far as I can tell, not really meant as a server language but as an ecosystem for open source dev tools. For that usage it seems to be more than adequate. Node also has the huge advantage of running in a language known to millions, albeit many with only superficial understanding. It lowers the bar enough that almost anyone can contribute, which has caused an embarrassment of riches regarding tool selection, oy.

          Finally, it ain't going away soon, due to browser inertia. That's why so much effort is spent on improving it. I'm betting in a few more years you won't see that much difference between JS and Python.

    2. Stevie

      Shot in the Head

      Yep, and "Gandalf" is best understood in the context of the annoying NPC from DM of the Rings ->

    3. mrtom84

      I’d guess you have never actually given it a good go. Most people who hold this opinion have always held this opinion (or heard it somewhere) and maybe hacked around with it in the past but tried to treat it like their primary language. Once you figure out which parts are “the good parts” and which parts to stay away from it is a really amazing, or at least interesting, expressive language.

  2. harmjschoonhoven

    I love

    standards and I am happy that there are so many to choose from.

    1. horse of a different color

      Re: I love

      Edit: Argh. Someone got there first. ;(

  3. clocKwize

    Its getting better. Evolution is happening. It has its quirks like every language, but its definitely getting better.

    1. Anonymous Coward
      Anonymous Coward

      Javascript's use case is nearly unique in the IT world. It's almost the only language that has to consider backwards compatibility for many millions of users with older browsers. Those other languages generally don't run in browsers and are mostly free to upgrade quickly.

      So when someone suggests javascript isn't as good as the non-browser languages, it's like saying robots are better than people because robots don't have to use the loo.

  4. Gio Ciampa

    ES2017 lets these workers share binary memory buffers

    Hmmm... like that won't be looked at as a possible attack vector...

    1. Anonymous Coward
      Anonymous Coward

      Re: ES2017 lets these workers share binary memory buffers

      The buffers are shared ... with itself. If normal memory safe JavaScript buffer are indeed safe, then these shared buffers are no more dangerous.

      The only new danger is trouncing your own data, or creating a race condition, which was previously hard to do in single threaded JavaScript.



    Surprised I'm first: xkcd

  6. RyokuMas

    Gandalf of JS

    So basically, you're saying that you need to be some kind of amazing wizard in order to learn Javascript?

    1. Anonymous Coward
      Anonymous Coward

      Re: Gandalf of JS

      It's just a reference to how his daughter described him to somebody.

      1. HandleAlreadyTaken

        Re: Gandalf of JS


        Fly, you fools!

  7. Anonymous Coward
    Anonymous Coward

    Such advanced features

    "ES2016 formalised that into "promises""

    Yeah whatever, more nomenclature buzzword bollocks lingo.

    "we added language mechanisms that let a programmer call a function and asynchronously delay or wait for that function to complete"

    So its basically threading in disguise. *yawn*

    "The other big feature is shared memory."

    Wow, cutting edge stuff! In 1980.

    "It has evolved into the general-purpose programming language that advocates originally envisioned,"

    No, it really hasn't. Its 99.999% client side web with a few deluded webdevs who've been promoted to running servers and only know javascript trying to use it as a server programming language. Meanwhile anyone with a clue uses C/C++, java or python.

    1. tiggity Silver badge

      Re: Such advanced features

      You forgot its main use is breaking web sites - "web devs" - you do not need JS to display test, process a link click - your site should do that with JS enabled

      And the extra delay in loading in all those huge frameworks just to do a bit of DOM twiddling, and (high) chance of some broken JS taht hogs memory and cripples performance.

      There is very little need for lots of web site JS

      And with JS enabled always the lottery of seeing what malware randonm ad js is trying to chuck at you.

      1. Anonymous Coward
        Anonymous Coward

        Re: Such advanced features

        So, the fact that JS gets abused means it's a bad thing?

    2. Destroy All Monsters Silver badge

      Re: Such advanced features

      So its basically threading in disguise.

      No, not really.

      Premises are Good Old Stuff: Promises.

      I really need to check out OCaml a bit more. And for the browser, elm. Now there's a beauty. So much to do, not a minute to spare to dive into the JavaScript fester-dumpster.

      Oh well, Java 9 is out, time to go steady.

      1. Anonymous Coward
        Anonymous Coward

        Re: Such advanced features

        "No, not really."

        Yes really. If a program has more than 1 simultanious execution path its either threads or processes, take your pick. The end result ultimately is the same for the programmer. Sure, "promises" might mean you don't have to fiddle about with mutexes and whatnot but other than that there's no difference. Same wine, different label.

    3. rmullen0

      Re: Such advanced features

      Regarding promises, I think it was supposed to be implemented like the await keyword from C# where the compiler generates a state machine in the background and allows you to program like you are writing synchronous code rather than have to use a bunch of callbacks. Anders Heiljsberg mentioned that awhile ago. I don't know if that is what got into ECMAScript in the end, but, they were talking about it. It is a big improvement over using callbacks IMHO, at least in C#. And asynchronous programming is not the same thing as multithreaded programming. It may use multiple threads or it may basically be cooperative multitasking. One of the points to async is not creating a bunch of threads which consume resources. In JavaScript's case it is at least in part because it never had support for multi-threading. I disagree with your language choices, but, personally, I can't stand JavaScript either. It depends on what kind of app you are developing. Writing a web app in C++ is just stupid if you ask me. Java is a steaming pile. Not interested in dynamic languages like Python.

      1. Anonymous Coward
        Anonymous Coward

        Re: Such advanced features

        "Writing a web app in C++ is just stupid if you ask me"

        Depends whats going on underneath. The client facing browser side is just the icing on the cake, it gets all the attention but there's usually a whole lot more going on below. If you need some fast DB access and industrial strength data processing then there's nothing wrong with using C++ especially since you don't have the VM overhead and memory hogging of Java or C#.

  8. Anonymous Coward
    Anonymous Coward

    I'm posting this anonymously as I still work as a web dev and have for over 12 years.

    I remember in about 2010 I said to a guy I worked with, could you write an entire web app in JavaScript (we were using PHP at the time for most things). He was the sort of, I'll accept any challenge, type of guy and so he did build something...albeit mainly ajax based (still using PHP for server side processes). He now seems to do almost everything in JavaScript, uses Node.js, configures stuff with JSON and just seems really obsessed with it.

    Whilst all of this has been going on, I've ignored JavaScript (other than stuff like jquery). And I still don't know who is right - whether his stuff is now at some genius level, or just the scrawlings of a mad man who's just bodging stuff together.

    I think JS is perceived as "cool" especially to a lot of younger developers. And it's started to make its way on to servers with things like Node, so also appeals to wannabe-sysadmin types who have made an alert on a web page before.

    For me it just seems inappropriate for about 90% of the things it's used for. Or, there are better ways.

    1. Anonymous Coward
      Anonymous Coward

      I believe the future is C/C++ in browser natively.

      Regardless, 6 months ago I dove in using the latest node.js enabling all beta features and all the latest browsers, I wanted the full effect regardless of compatibility. I used zero libraries in the browser and only 2 core libs for node. Here's a short on what you're missing...

      - Node.js

      By core dependancies, I mean as in no depedacies on other libraries. Node libraries have HUGE dependcies on other libs if you don't watch out (look up the lib "Express", it's bloooooated). To be honest, node.js isn't bad as a server language once you stop using crazy libs like Express, but the pratice of intentionally crashing without any trusted way of validating input prior to crash becomes stunting.


      The hype is justified for I believe that the ease of creating interactive widgets makes it tinkery fun. The real drawback is memory usage. I don't care if it's serial, parallel, interstellar or orgasmic... the memory usage of even a simple waveform analyzer after render is large. It all apparently comes down to the broswers' garbage collection, which more times than not, operates in JiT so memory comsumption just seems to linger regardless of what js methods you use on the graphical objects (drag'n drop is ok, just don't drag and drop graphical collections and expect even decent memory usage).

      1. rmullen0

        Interesting that the person promoting C++ for browser apps would be named MyBackDoor. Because that is exactly what you would be getting with C++. Massive security holes. Memory usage-wise you may be right though as far as footprint goes and memory bloat in something like JavaScript. Google had something that was supposed to be native code, but, that had array bounds checking somehow had security built into it. I haven't heard about it for several years. Not sure if they are doing anything with it. Probably they are just on the JavaScript bandwagon now.

      2. HmmmYes

        General Chen, Red Army (intelligence) - Is that you?

    2. Notas Badoff

      "I think JS is perceived as "cool" especially to a lot of younger developers." As it has a very low bar to use on the browser and now on the backend, it is easy to get involved with. Like back last century for me, for enhancing user interactions with lists. (woo)

      "... and just seems really obsessed with it." That enabling immediate response to users can be rewarding and addictive for devs should be obvious. I'm surprised you haven't noticed.

      "Whilst all of this has been going on, I've ignored JavaScript ..." Um... uh... nevermind.

      "For me it just seems inappropriate for about 90% of the things it's used for. Or, there are better ways." Mmm, okay John Henry, don't have a heart attack.

      1. Anonymous Coward
        Anonymous Coward

        "As it has a very low bar to use on the browser...."

        Right there is the problem! jquery users who have no real footwork with memory managemen. Let us generalize that "low bar".

        Have you ever noticed how anything graphically intense rendered by the browser isn't running in js? The bar isn't low, it might be as high as it gets in pure js. In fact, js performs so terribly slow as DOM reflow/repaint is a horrible design (no, I sadly don't have a better solution), they had to invent "workers" to make any real interaction even tolerable. So, maybe the bar isn't low or high, maybe it just doesn't exist.

        "That enabling immediate response to users..."

        Again, a jquery comment. The problem is your just bloating the browers references for what... drop down menus? The heart of interactive js can't be done with jquery (even jquery devs understand that, regardless of the newer native methods). Once you try to do actual interactive designs in js you will understand why strict libraries like ASM.js have arose (and will undoubtedly be replaced by Mozzilla's push).

        1. HmmmYes

          My computer has to behave like it was rendering Avatar recently.

          When I look its always the browser, always running JS stuff. These a proper Sunday school sites, none of your smut stuff.

    3. Destroy All Monsters Silver badge

      And it's started to make its way on to servers with things like Node

      Until something else comes along to keep the hyperactive scriptlers with learning challenges busy and the managers on "muh scale-out, scale-up asynchronous web-scale" hype-drenaline.

      Meanwhile, normal people will do stuff that actually works.

      Using threads, for one.

      1. Mookster

        It's really best to avoid threading on a webserver, otherwise it confuses the code-monkeys. KISS: each caller gets their own thread.

      2. rmullen0

        You have a problem

        You try to solve the problem using threads. You now have two problems.

  9. Dan 55 Silver badge

    JavaScript for AI

    I think we've reached peak bullshit.

    Time to recalibrate the scale.

    1. Destroy All Monsters Silver badge

      Re: JavaScript for AI

      The 21st century will not be able to recalibrate the bullshittometer. It always redlines, whatever you do.

      1. Anonymous Coward
        Anonymous Coward

        Re: JavaScript for AI

        > "The 21st century will not be able to recalibrate the bullshittometer. It always redlines, whatever you do."

        What are you doing out of your cave, Igor?

  10. Anonymous Coward
    Anonymous Coward

    What I don't understand is why put AI the the browser at all, do you intentionally want to slow down your AI? I'm sure the NSA/CIA types and bitcoin pirates love the idea, but for any remote AI work, it's horrible, even for the weekend warrior/project types of people. Just trash really.

  11. Mike 137 Silver badge

    "JavaScript has become the interface to the web..."

    And incidentally the primary vector for client side breaches (regardless of the 'sophisticated' details of what happens after the initial compromise via JavaScript).

    It's fundamentally contrary to basic security principles (and common sense) to download masses of untrustable and unverifiable code onto the client and execute it silently and automatically. It's even more fundamentally stupid to use this technique to accomplish things that can be perfectly well, efficiently and safely be performed using good old HTML (e.g. the increasingly common idiocy of using JavaScript instead of link anchors to enable clickable elements for navigation).

    Unfortunately this fashion for making even static pages into 'web apps' is essentially born of crashing ignorance. For example, I found today an online shop which declared that in the interest of security "our shopping cart runs entirely on the client, so there's no server to hack". Where do they think the shopping cart code resides at rest? What happens if that repository is contaminated by malicious actors?

    Until software development has been raised to at least the minimum standard of a professional engineering discipline we remain at the mercy of fools and ignoramuses. Dunning and Kruger rule!

  12. RegGuy1 Silver badge

    No Script

    There, I've said it.

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

Other stories you might like

Biting the hand that feeds IT © 1998–2022