We haven't forgotten how to code – JS just needs to become a better language
blog.christoffer.me
blog.christoffer.me
1. There should be one or several libraries (like lodash), where the maintainer provides a high level of quality across many core utilities that are needed, rather than all these functions singly collected across many different users which can lead to variable quality - and a maintenance nightmare over time (plus the potential security risks)
2. You should minimize dependencies when it doesn't provide great value (the bar's especially high if many others could/will depend on your library); there are functions like 'is-positive-integer' that should have been written without external dependencies (but had 3 dependencies); realize that dependencies inject cost into your system (and benefits as well), and weigh one vs the other for your use case, rather than blindly defaulting to a mindset that micro libraries are always the best approach
I suppose lodash and others aim for a similar purpose, but clearly left-pad-gate has shown us that they're not quite complete enough.
You'll need both to happen - and that's the benefit of this controversy.
Even so, I think the micro-library dogma might have gone too extreme, without many programmers realizing the cost it injected - and this controversy will likely also help with changing some developers dependency philosophy.
More speculatively, I'll be interested to see if any of this leads to changes in the ECMAScript standard discussions in future years.
I vote for lodash to become the new STL. It's even faster than native JS.
It's almost ironic really, that js has the worst standard library situation of any popular language yet it would benefit the most from having a good one since it would save everyone bandwidth and page load time.
Maybe someone can write an amazing replacement stdlib and we can all agree to include it from the same CDN so it'll be cached on every browser in the world...
EDIT: I see from other comments that lodash functions can be required individually which I hadn't thought about. But the point still stands, every function that you use in a big project that could have been in the standard library is more to download.
Unfortunately, libs that provide function chaining via dynamically extwnding a prototype can't be optimized by tree shaking.
The future :: function bind operator should provide a tree shaker friendly alternative.
A main issue with the current system is that you're pulling in micro dependencies from a variety of different sources, instead of a few potentially highly reputable sources (fairly or not, I'd feel more comfortable with dependencies from the lodash maintainer, than from 50 different people). One solution obviously is a better standard library, but often to get there, the process is for devs to create common libraries - which over time are (partially) absorbed in language standards.
2b. Though this wouldn't fix the left pad issue, mitigating security risks in OS is actually a very interesting topic. Something I haven't seen, but would love to is an ecosystem that allows packages to be code reviewed for security flaws. So users can see that a package (and dependencies) have been reviewed by X people, and Y in their network.
2. This won't solve the left pad issue, at best mitigate it. The main reason this is done in JS libs is to reduce file size of web apps, maintainers brag about it in their READMEs. Babel on the other hand is part of the compilation step, so no need to have that constraint, which it is.
Not mentioned, but this is one way to mitigate security issues, by reinventing the code. Other option is to audit the dependencies.
The issue: developer pulled their package off NPM, which many packages depended on.
The solution: keep all packages in NPM. If the software is open sourced, we can legally continue to redistribute the software even though author may not want us to.
Ecosystems with this issue: Python, Ruby, Go (google it)
Ecosystems without this issue: Maven, Haskell
I respect someone wanting to pull embarrassing or private data, or even just out of spite. In that case the package can be made undiscoverable, but still accessible from direct download.
Non relevant issues: laziness; micro vs standard vs kitchen sink libraries; package security; package quality; package maintainer coordination; ... but the color of the bike shed is just so interesting.
Right, you can legally redistribute the software, but can you ethically do so? Some people have complained about the bad precedent set for allowing left-pad to be reuploaded again after it was deleted, and the reason they complained is because the developer has lost control over the fate of his own package.
These people can't complain too loudly, as the author in question did indicate that he was willing to give ownership of his npm packages over to someone else. But you could easily see a situation where a developer would want his stuff deleted and not be accessed, period. Why should this request be refused?
The idea that the developer has lost all moral rights whatsoever to his/her work just because they attached a LICENSE text document feels wrong to me. Just because a license says you can 'do whatever you want' doesn't mean you should do whatever you want.
If the author then wants to undo this action, that simply will be difficult—more so the more people depend on the package.
If several people depend on the package, then they will try to put it back again, unless they sympathize strongly with the author's intention to unpublish.
That's just open source working as intended. There's no ethical framework that compels people to have that sympathy, in general.
Yes, you can. If you're sharing your code with the world, that entails certain responsibilities. You're telling people that they can depend on your code, and you should not be allowed to violate that. Open Source isn't just about getting attaboys for being such a cool dude—it's about working together to build a library of code. If you don't want to be part of that, if you don't want to take under consideration any of the people who will be using the code you're sharing—then don't do it. Just don't release your code. Find something else to do with your time.
The last time I used NPM, vendoring the code wasn't really a viable option, and it seems that things haven't improved. When googling NPM and vendoring, I learned that this isn't the FIRST time that this sort of issue has bitten the NPM user base. This article from 2 years ago http://www.letscodejavascript.com/v3/blog/2014/03/the_npm_de... makes it clear that the community as a whole hasn't learned. Vendoring still seems much harder than it needs to be and based on my search results is activly discouraged.
The solution: take a cold bath to bring the temperature down.
Addressing the disease, not the symptom, is not bike shedding.
By having a larger std lib, or less dependencies, it only treats the symptom of the disease, which is dependencies disappearing. To treat the disease we need to make sure open source packages are always accessible. This issue runs through a lot of other areas as well, not just package managers, which is why projects like IPFS are exciting!
That's just never, ever a credible assertion, "I've never met anyone who likes X"....then you must not talk to many people. There's a lot of people in the world and a lot of JS developers and PLENTY of them like it.
I do, however, object to the massive amounts of dependency in the Nodejs ecosystem. It's as if no-one learned the lessons of DLL Hell. We already know that dependencies are bad, people!
I don't have any objection to dependencies where they're necessary. But the node culture isn't "where necessary", it's "wherever some code might be vaguely useful". Left-pad is a classic example: this is a one-liner[1] so why the hell are we including it as a dependency?
[1]: ((str,len)=>("0000000000"+str).slice(len*-1))("test",10)
Edit: FWIW, lodash also has _.isInteger(), _.range(), and _.inRange().
Using a python like language greatly eases my pain as a primarily python developer that has to code significant amounts of javascript.
If Javascript string manipulation sucks, there should be a single string manipulation library that fills in the gaps, not 50 different libraries to work around 50 different gaps. Ditto every other class of deficiency.
I am a JavaScript developer and I see this as an opportunity for the community to learn and grow.
If you can't trust yourself to write such a simple function, how confident are you about writing something a little more complicated? Or very complicated? Doesn't it bother you that you feel more confident in 10 simple lines of code written by a complete stranger than you are in yourself?
Although I agree with you about the left pad function. It wouldn't even cross my mind to search for a library instead of just typing out the code.
It does make sense as a function in a larger utilities library though, such as lodash. If you already have that as part of your code base then might as well take advantage, similar to apache commons/lang in the java world.
That's OK, someone did it for you:
https://metacpan.org/pod/Text::Trim
CPAN to the rescue!
That's still a lot easier than writing portable C has to support variations in environment, compiler (w/ varying interpretations of the C standard over several decades), linker, make/build tools, CPU architecture and byte-sex (big-endian vs little-endian vs middle-endian), pointer sizes and alignment rules, integer sizes and alignment rules, incomplete and occasionally broken "standard" headers, and many more inconsistencies.
And that's just for a simple system daemon or command-line tool. If you want a GUI, that's another giant mess for potability.
> it's silly that we web developers should spend time to recreating basic wheels
Of course. There are many solutions to that problem that don't require builds that depend on network resources controlled by 3rd parties.
> JavaScript language itself is fundamentally flawed and the core APIs is a mess
While that's debatable (worse platforms exist), it also misses the entire point. Nobody is saying that sharing the code for left-pad is a bad idea. Wrap it up properly into an extended-standard-library and distribute it with node/etc.
What is conspicuously missing is any discussion at all about the costs of depending on 3rd party libraries. Adding a network, 3rd-party dependency to your build or deploy process is a huge risk that at the very least needs to be justified.
Note that I'm not saying that using 3rd party libraries is bad; I'm saying it has a cost paid in additional risk. You can decide if that cost is a fair exchange for the benefits you gain from the library. Just remember that humans are terrible at evaluating risk, so it might be a good idea to limit how much risk you take on.
So what - every language has places with extra verbosity, unfortunate function names, or other minor annoyances. The correct solution to this type of problem is either 1) just type it the compatible way and move on to a real problem, or 2) use an editor macro such as TextMate's snippet[1] feature or the emacs variant yasnippet[2]. Code templates have been a solved problem for a long time.
And whatever JS includes or doesn't include, he should use ONE bloody library, like Lodash to fill in the gaps, instead of some micro-monstrosity like "left-pad".
The problem is Javascript culture itself. It's culture has directly influenced the way NPM packages are made.
"I see us JavaScript developers as hurdle-runners where every 30 seconds we need to jump over a new obstacle."
That's not a good thing imo.
To not have a check if one string includes another and/or to not have functions for padding is strange in 2016. Fine, let's not have it inside the language. But the dev community should at least agree to use one good package like lodash instead of playing "mine is better than yours" like in the damned highschool. This is a job where people make money and business decisions are made. The tech bros need to learn some professionalism.
ES6 has a bunch of "modern" features 1/3 of which I won't ever use but hell, the committee be damned if they allow string padding functions! :D Or God forbid they make a good use of "use strict" to make the language more predictable and eliminate most of its quirks in it.
That said, the fact that npm's blog [0] indicates that a republished package (with a new version number) mitigated the issue to some degree, and this comment [1] suggesting that the default behaviour is to get the latest minor release, makes me wonder how widespread of a practice that is in reality.
[0] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm [1] http://www.haneycodes.net/npm-left-pad-have-we-forgotten-how...
Now in the wake of leftpad issues, the most common argument I've personally observed, has been "why are you using a library that solves just this one problem? Use a library that provides the full utility around this problem area (strings)".
It feels strangely contradictory but I'm most likely missing some context here. Just wondering what it is :)
ES6 should get us there, and I for one really like coding in javascript.
Giving away a perfect valid package to a company without a legal order was lame. Unpublishing many packages without taking into consideration all dependents was lame. I can't help but think the people involved wouldn't repeat the very same decisions.
Despite any amount of blame tossed around, this is a micro hickup in the thriving ecosystem around npm / Node / Javascript. This statement is backed by data http://npm-stat.com/charts.html?package=clone&author=&from=2...
Thanks to node, npm and amazing OSS devs, we can count on modular packages to get the job done faster on the client and server, and that's really valuable.