One programmer broke the internet by deleting left-pad (2016)
qz.com
qz.com
I'm saying this as someone that hasn't used either.
Auditing is nearly impossible.
The complete lack of a standard stdlib means always relying on community packages.
Also, not a complaint directly against node directly, but for the ecosystem and developers. There is not a culture of compatibility, further fueled by the fact that multiple versions of the same dependency can be included in the same code base by different dependencies.
Coming from any other language were it is a goal to keep external dependencies down, nodejs is nightmare fuel.
After all, if I love Java but hate AbstractSingletonProxyFactoryBeans, I'm probably going to hate being a professional Java developer.
Some would see the left-pad incident not as an isolated oddity, but as representative of the entire NodeJS ecosystem - showing a weak standard library, a culture of pulling random, unaudited code from the internet, and rats-nest dependencies.
If your first thought is a library, whether you wrote it yourself or not, then you're doing JS badly.
Go seems to have done a better job with a lot of utilities found in its standard library. But, it also has a mindset that it's better to just copy code than to add a dependency. Another factor there was of course that dependency management was a bit painful and fragmented until a few releases ago, unlike NodeJS which had NPM and its ecosystem not long after it came out.
One of the big constraints we have in front end development is that every added feature adds to the bundle size of code we have to send down the wire to the end user.
When I worked in mobile app development third party libraries tended to be very large with many many features. Only a tiny fraction of that library ends up matching your use case. However when you build you end up bundling up the whole thing into your app.
JavaScript has more of a culture of many many small hyper focused packages. The logical conclusion being single function packages like left pad.
This has two benefits. One - you have less dead code in your final build. Two - if one of your dependencies is already using leftpad you essentially get to use it "for free".
If everyone did what you are suggesting you would find multiple instances of leftpad. One version you wrote. One version your dependency wrote. One version your dependency's dependency wrote etc.
Surely there have to be tools to process dependency libraries to strip out any unused code.
A good example: There is a library called Moment for handling dates. Due to the way the interface was built it basically can't be tree shaken. It's an excellent library but it's on the heavy side. For a while now people have been moving to libraries like Date-Fns which are collections of individual functions. This library can be tree shaken as it's obvious which functions you are using and which you are not
The problem is Invented Here syndrome and coddling. https://en.m.wikipedia.org/wiki/Invented_here
The reason this exists is due to a lack of leadership in the front end space. More specifically, a need to hire untrained entry level developers and deliberately not train them whether due to insecurity elsewhere and a complete inability to write documentation.
> If everyone did what you are suggesting you would find multiple instances of leftpad.
It was about 8 lines of code a child could write that you probably don’t need in the first place.
However if the threshold for not including a package is that it's 8 lines of code that would rule out using most of the functions in Lodash and Underscore.
If the threshold is not importing code a child could write that would rule out using Babel which was in fact literally written by a child.
> This has two benefits. One - you have less dead code in your final build. Two - if one of your dependencies is already using leftpad you essentially get to use it "for free".
This culture has really backfired in practice.
What we now have is a proliferation of packages which do the same thing. The problem is that it is less likely that your dependencies are going to be using the packages, even though desired functionality is the same. For example, if you have two dependencies which need to do HTML encoding, chances are that they choose different packages for that job. So now as an app developer you have to pay for both.
This combined with a culture which loves Semver but doesn't mind breaking backwards compatibility ("just update the major version!") gives a huge mix of packages which can't be fixed by tree shaking.
Our society cannot stand the immutability yet.
Our build process shouldn't relies on somebody else's server over the Internet for each minor deploys to the web server.
I hate to point it out, but we already have immutability. If you add something to, say, the Bitcoin blockchain, it'd take erasing the entire blockchain to destroy that information. That's a tall order.
Actually, I think Bitcoin blockchain has accumulated enough illegal data so just a fool-proof visualization tool is enough to make authorities serious enough to prohibit the Bitcoin. It's more of a presentation than technical though.
I think content-addressing is a good solution to this problem: it separates the identification of a thing from the retrieval of a thing. In this example, software can depend on '<cryptohash>-left_pad-1.2.3', without having to know or care where that comes from (NPM, bittorrent, IPFS, sneakernet, etc.). Build tools can try to fetch these dependencies from a bunch of different sources, including caches on the local machine, on a company intranet, on well-known mirror services, etc. and verify that it got the correct file by matching the hash.
A nice aspect of this is that it's resilient for things that people want to host (like left_pad, for example), but nobody is under any obligation to host everything. Mirrors are free to ignore/delete anything with illegal/malicious/spammy content.
Also, breaking some javascript code on the web is hardly "breaking the internet".
In another industry this would be used an example failure for training new engineers. But people seem to have an aversion to formal training and prefer on-the-job training. But that means you can easily end up with an engineer who simply "got lucky" for 5 years by not following any kind of good practice. Do you really want him to learn these lessons with your data/time/money?
If one of your dependency is deleted from GitHub, your project breaks, and you may never find your missing dependency again.
"American Airlines" is rightfully trademarkeable, but "AA" should not be (and in fact can be understood to mean all kind of things, even in aviation)
"Lego" is a trademark for plastic bricks, but the London Electric Guitar Orchestra should be able to use "L.E.G.O" or even "LEGO" as an acronym - they make music, not construction toys.
Unfortunately, there is no indication in the article what kik (as in the developers package) stood for, but if the package had nothing to do with Kik, the service, I think it should not be a trademark violation.
Trademarks are only valid in the domain you operate in. If you had a football school called kik there is no infringement, but there is an Internet company called kik hence this infringes.
That doesn't sound too much like the package to deal with social media to me. Arguing that they are in the same domain because of both of them being internet-related seems like American Airlines trying to sue Alcoholics Anonymous for an AA trademark violation, for both pilots and recovering alcoholics sometimes use roads.
Whoah there. I think perhaps it might be time to take a step back and revise your basic knowledge of how trademarks work.
Trademarks get registered in classes (goods and services are divided into 45 classes - 1 to 34 for goods and 35 to 45 for services). Not only that, but you can register for parts of a class, not necessarily an entire class.
Trademark registration rules state that you should only seek registration in classes (or part-classes) for which you have actual business activities. This is because of the fundamental "use it, or lose it" rule that applies to trademarks (failure to use your trademark for a period of five years since it has been registered could lead to it being vulnerable to cancellation by a third party on the grounds of non-use).
Coming back to your LEGO vs LEGO, if you take a moment to look at the LEGO (toy) trademark registrations, you will note that they hold trademark registration for the word "LEGO" in the following classes:
- 6 with the following selection: Key rings and key fobs included in Class 6, all made wholly or principally of common metal.
- 17 with the following selection: All goods included in Class 17 (Unprocessed and semi-processed rubber, gutta-percha, gum, asbestos, mica and substitutes for all these materials; plastics and resins in extruded form for use in manufacture; packing, stopping and insulating materials; flexible pipes, tubes and hoses, not of metal. )
- 26 with the following selection: Buckles and textile smallwares, all included in Class 26; tie-tacks, tie-pins and badges, all for wear, and cuff links, none of precious metals or coated therewith.
- 28 with the following selection: Toy models and sets of parts for constructing such toys, all made of rigid plastics, ornaments and decorations for Christmas trees; all included in Class 28
- 35 with the following selection : Publicity, advertising and public relations services; shop window dressing and arranging of displays in shops, stores, exhibition halls and trade fairs; the setting up and operation of promotional shows; compilation and analysis of business statistical information; conducting business appraisals and marketing studies; transcription services; all included in Class 35.
- 40 with the following selection:Printing services, Binding services; services for the finishing and/or treating of plastics and of articles made wholly or principally of plastics; all included in Class 40.
- 41 with the following selection: Educational advisory services; arranging and conducting workshops; amusement park services; theme park services; all included in Class 41.
- 42 with the following selection: Computer programming; rental of computers; computer services.
- 43 with the following selection: Hotel, boarding house, tourist house, holiday camp, motel, restaurant, cafe and canteen services; food preparation services; travel agency services for booking accommodation; arranging and conducting of exhibitions.
- 44 with the following selection: Sanatoria, rest home, convalescent home services.
"Protection" indeed.
Kik: Give us your package name
Azer: No im using it
Kik: not being a dick, but give it to us or we will start legal action
Azer: That is being a dick..
Kik: (ccs npm) we will compensate you
Azer: it will cost 30k because you are being dicks
Kik: (ccs npm) he is breaching your terms by calling us dicks, please give me the package name
Npm: Here you go kik, have the module name.
Kik: Thanks npm.
Azer: ?????
To clarify, they had NO RIGHT to the name. At the time, their trademarks did not cover the relevant category [1], it wasnt until a MONTH AFTER the dispute that they registered in a category that could even potentially cover its prior use [2]. NPM just gave it to them because they felt like it, not because they were obliged to. NPM even made a statement to this effect at the time. NPMs choice of course (well, Isaacs at the time) - but lets not pretend this was about trademarks - this was corporate bullying.
[1] https://tmsearch.uspto.gov/bin/showfield?f=doc&state=4802:u683la.2.31 (sep 2015)
[2] https://tmsearch.uspto.gov/bin/showfield?f=doc&state=4802:u683la.2.32 (apr 2016)Some said, node ecosystem was a bit too exagerated to relay on very tiny library like that.
On other side having on a good number of dependencies on your package.json is a good sign, because you have a strong structured ecosystem to relay onto.
Keep in mind a singular angular app has about 1Gb of node_modules dependencies whereas a java spring boot app is hardly so big :)
What's "strong structured ecosystem" supposed yo mean?
If i want some services, code or programs i have created gone i want the power to MAKE them gone for good.
The more i think about the possibilities the less i like the idea...
NPM had every right to republish those packages. Koçulu gave full consent when he originally published them as OSS.
If this bothers you, then maybe you should reconsider your licensing choices.