Comment by raverbashing
11 years ago
No, no, no
Left padding is (almost in all languages) built-in, even C can do it with printf (edited)
The problem is not having a library that offers that, but having this micro-module thing as a whole NPM module. No other language does that.
If it was inside a string helpers, that's great.
But don't make me one single module for just left-padding (or is-integer-number)
I think there's two points related to that:
1) JS is unique in that it is delivered over the wire, so there is a benefit in having micro-modules instead of a bigger "string helpers" module. Things like webpack are changing that now (you can require lodash, and use only lodash.padStart).
2) JS's "standard" library is so small, because it's the intersection of all of the browser implementations of JS dating as far back as you care to support. As pointed out in sibling, a proposal for padLeft is included in ECMA2016. But we'll still need Left-Pad for years after it's adopted.
Point 1 was addressed years ago by Google Closure Compiler, which used "dead code elimination".
Also, the Haxe language, which compiles to JS, has DCE.
Micro-modules is certainly a solution if you don't want to use pre-processing or compilers. So is copy/pasting, or manually writing your own util libs, which seems safer than relying on third parties to provide one-liners for you.
Eh, to date, a large part of the JS community still recommends including .js files in script tags in HTML. So, while this has been possible for a while, there hasn't been widespread adoption.
I'm not sure dead code elimination works in that situation. Consider:
If a, b, and c are functions, there is not necessarily a way to determine at compile time whether they will be used at runtime.
In that scenario, a, b, and c cannot be eliminated. But it would be worth testing Google Closure Compiler to see what it does in what scenarios.
I've heard ES6 modules solve this problem, but it seems like dynamic access to an ES6 module might still be possible, which would cause the same problems for DCE. Perhaps no one writes code that way, so it doesn't necessarily matter. But what about eval?
There are lots of tricky corner cases. It seems better to use small atoms than a monolithic package.
2 replies →
Javascript must be written specifically to anticipate Google Closure Compiler's dead code elimination.
Since the vast, vast majority of Javascript doesn't work with it, the issue certainly wasn't addressed years ago.
1 reply →
> 1) JS is unique in that it is delivered over the wire, so there is a benefit in having micro-modules instead of a bigger "string helpers" module. Things like webpack are changing that now (you can require lodash, and use only lodash.padStart).
JS isn't even remotely unique in this regard, almost every static language has had dead code removal for decades.
I agree with you, but they weren't saying that JS is unique for having dead-code elimination, but rather for having to be served over a network connection nearly every time it's needed (not accounting for caching and offline apps, etc), which presents an entirely new set of problems that webpack and others attempt to solve.
Which is why it's so unsuited for writing non in-browser applications. JS was made for a purpose. We hacked it and discovered (or at least made popular) the benefit of having a fully async STD lib, of using callbacks to manage incoming connection and so on.
The wise course of action would be to take those very good ideas and bake them in languages designed for web/system programming, and keep improving JS for in-browser tasks.
A in-browser web application requires the left-pad module. Should it include the 500kb library that includes a left-pad function, or import just the 10kb version, which having left-pad function as a module by itself allows?
Yes you can use left-pad module in a browser application using the npm install infrastructure.
> 1) JS is unique in that it is delivered over the wire
Oh, that's unique? What are these magical languages where code is solely delivered via sneakernet or snailmail?
JavaScript much to my dismay has no sprintf. It's one of the most annoying omissions ever for server side work.
The biggest thing I've run into is that there's no built-in `mkdir -p`. There is, of course, a module that is literally just mkdirp.
require('util').format gets you pretty close.
No it really doesn't. It is so far away from even Perl's printf (considered ancient by most JS programmers) that it is not even funny.
es6 has one
No it doesn't. It comes with template strings. Any sprintf type functionality requires you to call functions on the input. It is a tiny tiny step forward.
Uh, no Left Padding is NOT built-in in JavaScript. The proposal to add `String.prototype.padLeft()` was just added to ECMAScript 2016.
JavaScript had a very minimal standard library, it's pretty asinine of you to compare it to C or any other language with a pretty extensive standard library.
C didn't get a standard (or a standard library) until 1989. It had been around for 17 years at that point. Two years after its invention, JavaScript was standardized in 1997. That's almost twenty years ago.
I've never thought of C as being a particularly good example of "extensive standard library."
I wanted to say that it's built-in in pretty much every other language apart from JS
But alas, here we are, talking about the JavaScript language and it's ecosystem.
It's easy to say "I don't see why there's a need for an 11 line module to pad left on a string" when your language of choice has a robust standard library with such abilities built in.