back to article JavaScript spec gets strung out on padding

ECMAScript 2017, the latest edition of the specification upon which JavaScript is based, plugs a gap left by awkward extinction of some Node.js code last year. In March, 2016, as a result of a naming conflict with instant messaging app Kik, developer Azer Koçulu withdrew more than 250 of his modules from NPM, the service Node. …

  1. aberglas

    What about static typing!

    That is the big one that makes JavaScript horrible to use for non-trivial applications. (With type inference of course.)

    1. stephanh

      Re: What about static typing!

      Who needs static typing?

      http://sixty-north.com/blog/top-four-javazone-2013-talk-the-unreasonable-effectiveness-of-dynamic-typing

      1. no-one in particular

        Re: Who needs static typing?

        So I followed the URL you gave - can't watch video at work, but loved the text:

        > I’m genuinely curious as to why programs in dynamic languages are as reliable as they are ...

        note that doesn't say _how_ reliable they are, just that it is suprising that dynamic typing is even capable of reaching whatever that level of reliablility.

        And continues

        > ... although I confess I don’t yet have many of the answers.

        How about endless hours of debugging and swearing when you finally spot the typo that static typing would've caught at the first attempt?

    2. kolkurtz

      Re: What about static typing!

      Or you know, you could just remember what your variables are for and make sure you don't write bad types into them? It's just like people who rely on spelling and grammar checkers. Not necessary if you are paying attention.

    3. Anonymous Coward
      Anonymous Coward

      Re: What about static typing!

      Early drafts of ES6 (circa 2012) included proper static types and classes. Brendan Eich was behind it. This fine proposal was trashed by whining web designers on Twitter who still can't code JS to this day.

      As for the new padding functions, that ship has sailed. For backward compatibility, wise developers will wait until about 2023 to use them. Or litter their code with more shims.

      Javascript could have been great but now it's dead. Move along.

      1. Anonymous Coward
        Trollface

        Re: What about static typing!

        What's so offensive about my post? The implication that dynamic typing is for sissies?

    4. Jonathan 27

      Re: What about static typing!

      Use TypeScript? I know, I know, it's not the same thing as static typing built into the language. All of the static typing solutions I've looked at for JS aren't very good, but I don't think Javascript's design lends itself to static typing. We'd probably be better off with a new scripting language... and then we get to the problem of people not wanting to change.

      This is definitely the biggest debate in Web development right now... glad I'm not the one who has to decided where we're going.

    5. Anonymous Coward
      Anonymous Coward

      Re: What about static typing!

      Static typing in JavaScript was one thing that Adobe got right in ActionScript.

  2. stephanh

    broken by design?

    I completely fail to see when you could ever *correctly* use padStart/padEnd.

    Basically, these functions apparently simply count length by counting UTF-16 code points. So they don't work correctly if your string contains:

    * Non-BMP characters (e.g. emoji)

    * Double-width characters (Chinese, Japanese etc.)

    * Combining characters (accents etc.)

    * Let alone right-to-left languages like Arabic.

    On the other hand, if you still believe that "all the world is ASCII" you'll be fine.

    The correct way to deal with this would be to style your HTML so that stuff gets left or right-aligned.

    That this makes it into a language standard in 2017 is ridiculous.

    1. Steve K

      Re: broken by design?

      The correct way to deal with this would be to style your HTML so that stuff gets left or right-aligned.

      That won't help if you want to pad with zeroes though

    2. Dan 55 Silver badge

      Re: broken by design?

      I think JavaScript strings are UTF-16 internally. I don't think it could be done any other way.

      1. AMBxx Silver badge
        Joke

        Re: broken by design?

        The sample output is in Courier. Emojis?!

      2. Charles 9

        Re: broken by design?

        "I think JavaScript strings are UTF-16 internally. I don't think it could be done any other way."

        Agreed. It's unfortunate, but not everything can be of uniform length. It's up to the user to handle edge cases accordingly. For example, if the string is expected to use mainly CJK characters, pad with the Idoegraphic Space (U+3000) which is meant for CJK typography. As for RTL languages, the main thing needed is consistency. As long as you keep the text uniform, just use the appropriate padding function. As for combining characters, Unicode already includes many precomposed characters, so this doesn't crop up as often as you think.

      3. bombastic bob Silver badge
        Flame

        Re: broken by design?

        "I think JavaScript strings are UTF-16 internally. I don't think it could be done any other way."

        That may be. I have to wonder, what's wrong with just using UTF-8 for everything? C language 'mbcs' functions handle it just fine... [so the JavaScript engine can just call the C libs, right?]

        And then there's this article quote:

        " the absence of a native method to pad strings makes JavaScript needlessly painful."

        padding strings is easy, if you know your data. I do this in 'awk' all the time. You take a 'substring' of a whitespace string [or 'whatever space'] equal to the right column minus the length of the string you want to pad. You might have to test the string first, and take the right 'n' characters of it. OR, you can smash them together (padding plus string), then take the right 'n' characters of THAT result.

        Simple. probably faster than calling a library, ESPECIALLY when you consider the BANDWIDTH POLLUTION that all of those "trivial shared java libraries" eat up on the CONSUMPTION side, "for the convenience of the programmer" [read: laziness of the programmer]

        The one thing I think SUCKS about Java and Javascript (and similar lingos) is the BASS ACKWARDS MANNER in which you do the right/left/substring/trim thing, typically by turning it into a String object and then calling ".method" [after searching online docs to see what method you have to use, because I don't do this kind of thing every day in Java or JavaScript, but do it a lot in OTHER lingos like C, C++, PHP, awk, or even Python, which deserves its OWN vent-post ]. Pardon my ignorance on the details if Java[Script] tries to fix this, but I've run into this with Android coding and it's irritating.

    3. Anonymous Coward
      Anonymous Coward

      Re: broken by design?

      /"The correct way to deal with this would be to style your HTML so that stuff gets left or right-aligned.

      That this makes it into a language standard in 2017 is ridiculous."/

      People said the same about print formatting JSON, yet people use it. Prettying things is useful in some languages that don't have default Ui mechanisms such as CSS. So, I agree this pad feature is not needed.

      A lot of the problems in Javascript come from the fact that most Javascript scripters (I'm thinking 90%+) have never written anything serious in system languages. I'd say the Javascript section at Stackoverflow is a testament to this. Browse that for 3 minutes and it becomes clear that both form and function are 2nd or 3rd concern. I fear the functional aspects might make things even worse.

      1. breakfast Silver badge

        Re: broken by design?

        The functional side of Javascript is exactly the thing that makes it powerful and perhaps my favourite part of the language, but functional programming is hard to grasp conceptually, hard to learn and - in my opinion at least - harder to write in a way that is easy for other developers to follow.

        Most developers see a language that looks a bit java-like and assume they can write java ( or C or C# ) with it, which is understandable, and then desperately try and squidge the language into their expectations. That makes for cumbersome code that eventually gets the job done and is fairly easy to read.

        Of course as you say most people using Javascript aren't programmers at all by training and just keep poking at the code and pasting from StackOverflow until it works.

  3. Dan 55 Silver badge

    The proposal points out that string padding functions are widely used by a majority of websites and frameworks and notes that the absence of a native method to pad strings makes JavaScript needlessly painful.

    If it were only string padding that made JavaScript needlessly painful.

    1. The First Dave

      What makes JS painful is reading through code written by people who think Java / PHP / C is the only right way to work.

      Learn it _properly_ and its lovely to work with.

      And to answer an earlier comment, the time spent chasing that one bug due to _not_ doing type-checking is more than offset by all the time saved from not having to fix bugs due to unnecessary type-check failures.

  4. Adam 1

    solving the song problem

    The issue here isn't with left pad, it is with dependency frameworks like npm that make it all too easy to consume disparate collections of third party libraries in a way that makes this sort of thing inevitable.

    Should the language have it built in? Probably, but that is going to be years away before you can safely assume any browser hitting your site supports it. The bigger question is what function disappears next for {reasons=null,noticeDays=0}.

    1. Anonymous Coward
      Anonymous Coward

      Re: solving the song problem

      Reminds me of the tweet I saw recently: "Javascript 4K challenge: try to write a Javascript application with fewer than 4,000 dependencies"

  5. Charlie Clark Silver badge

    Gets more like Python with every release

    Except for the fecking syntax!

  6. Anonymous Coward
    Anonymous Coward

    "...the later returns an array just composed of values, ..."

    It also doesn't read the prototype, which is the big part (speed).

  7. DJV Silver badge

    I look forward to using this in...

    ...2027 - when MS finally get around to implementing it years after everyone else (as per bloody normal).

    1. bombastic bob Silver badge
      Devil

      Re: I look forward to using this in...

      "when MS finally get around to implementing it years after everyone else (as per bloody normal)."

      which leaves a few of choices:

      a) do the work on the server end instead [bypassing the browser compatibility nonsense] and avoid all of those massive javascript library downloads, and maybe avoid ALL script entirely!

      b) deprecate micro-shaft browsers and put "this site best viewed with" again, when Edge/IE is detected

      c) one page for IE/Edge, one page for everyone else. "segregate" Micro-shaft (tweeking the SJW's ha ha ha)

      I prefer 'a', but 'b' makes for a nice protest

  8. fobobob

    -gate

    -gate needs to go away; the correct way to accomplish this is to attach it to anything even remotely controversial.

    Regarding left-pad, it's pretty trivial to implement, as seen here.

    https://stackoverflow.com/questions/13859538/simplest-inline-method-to-left-pad-a-string

    function pad(value, length) {

    return (value.toString().length < length) ? pad("0"+value, length):value;

    }

    also seen is this concept, which can be used inline:

    ("0000" + n).slice(-4)

    Developer dependency on copy-pasta node and jquery stuff is a problem that needs to be solved.

    1. Steve K

      Re: -gate

      copy-pasta

      Yes - spaghetti code is a problem wherever you get it from :-)

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