4 ms·

Comparing is-odd with left-pad is a bit disingenuous. Left-pad had a fairly trivial implementation but that implementation is easy to get wrong, so it's someth

• twexler 9y ago
  > Left-pad had a fairly trivial implementation but that implementation is easy to get wrong, so it's something you want to make sure you have covered by tests ...What? That makes no sense. `left-pad` is trivial to implement and test. There may be edge cases but for most people, writing tests to cover the edge cases they care about rather than pulling in a dependency just to handle something as simple as padding a string. Not to mention, Node's near-complete lack of a standard library is at fault here, not developers, nor the ECMA technical committee.
  • pluma 9y ago
    > `left-pad` is trivial to implement and test There's a tangible difference between `value % 2 === 1` and this: https://github.com/stevemao/left-pad/blob/master/index.js https://github.com/stevemao/left-pad/blob/master/index.js You're not even contradicting me. I said it has a fairly trivial implementation and you concede that it has edge cases. You're just disagreeing on whether that warrants using an external dependency rather than writing it yourself (and writing all those tests yourself too). > Node's near-complete lack of a standard library is at fault here, not developers, nor the ECMA technical committee. So you think String.prototype.padStart should have been a Node built-in module rather than a language feature? Are we talking about the same language that also has String.prototype.italics and String.prototype.bold? There's nothing Node could or should have done about the lack of string padding. Node's "standard library" is first and foremost concerned with enabling network and filesystem IO. JS on the other hand even lacks a built-in way to handle dates properly (the Date class is largely an afterthought based on Java). String.prototype.padStart deserves to be a language feature and it should have been a language feature from the start. Most other languages provide this out of the box. The reason these things end up on NPM is not that JS developers are idiots but that they don't want to reimplement the same basic utility functions every other language would offer as a standard library or copy folders of code around. Yes, this is absurd when it comes to things the language actually DOES offer (or basic maths like `value % 2 === 1`) but for the most part NPM is fulfilling JS developers' need for a standard library -- and that's entirely on not just Node but also the language itself (and by extension TC39). EDIT: It's worth pointing out that left-pad has zero dependencies, as it should. Compare this to is-even (i.e. `value % 2 === 0` as a function) which depends on is-odd which depends on is-number -- all written by the same author and 100% serious.
    • coldtea 9y ago
      >There's a tangible difference between `value % 2 === 1` and this No, there isn't. Both are trivial to write and avoid an external dependency. Besides, the implementation leftpad doesn't have to be this crappy -- one can do it in 3 lines.
    • twexler 9y ago
      > There's nothing Node could or should have done about the lack of string padding. Node's "standard library" is first and foremost concerned with enabling network and filesystem IO. JS on the other hand even lacks a built-in way to handle dates properly (the Date class is largely an afterthought based on Java). That's absolutely incorrect. Now, I might be using a slightly contrived example here, but take RPython and compare it with Python. Both use mostly the same syntax (i.e. ECMAScript vs Node.js), but one is extensively much more feature-filled than the other because it targets general-purpose programming(Python) vs a very specific purpose language, used as a lower level "Framework" if you will (RPython). RPython has no need to implement something like `left-pad` (although because it's a subset of Python, it's sort of already implemented) With RPython, it's intended you build things on top of it (which is how I view ECMAScript), whereas with Python (more like Node.js) you'd expect that to...exist. The fact of the matter is, the language teams in these examples had completely different goals and I personally believe that Node.js should have gone more the Python route and had an extremely strong standard library that would handle mundane tasks like `left-pad` does. It disappoints me that the Node.js team (outside of the ECMA technical committee, which designs the language itself) does not thing it should be responsible for this kind of simple tooling and instead rather passes it off to developers.
    • bjoli 9y ago
      Is that really the idiomatic JS way of creating string? Jeez. Reading the code at first, I thought to myself: "this stinks. There has to be a better way", but apparently not. At least not unless you want to support anything lower than es6.
  • kabes 9y ago
    In this case, You could argue that it's not the lack of standard library but the lack of language features (and thus the ECMA committee). Because in the meantime left-pad has been added as a language feature on the String prototype.
• cztomsik 9y ago
  There is one separate JS context for every tab you have opened right now and every feature has its cost in terms of memory & cpu. That's a major reason why javascript has very thin "stdlib". Also, big stdlibs are compatibility problem so it's definitely better to have as much as possible in user-space. BUT, we really should use few big utility libraries like lodash instead of dozens of helper-function modules.