Lodash as an npm module is out of control, file-size wise, and I'm not sure I'm really getting anything for it, other than once a year having to make sure we don't have ten copies of it that can't be deduped (Currently it's occupying 29MB of disk space on my production machines)
As I remember it, Lodash biggest difference was its modular approach also, not all about performance. Lodash also addressed some inconsistencies in Underscore.js.
For many others, the OP's use is common and correct—in a lot of areas.
"They ripped me off" is very prevalent in English speaking countries too, outside of tech.
Having the (almost) same API surface as another MIT library is hardly a "ripoff" but a re-implementation.
Edit: since new evidence has come forward (https://news.ycombinator.com/item?id=27275379) I think we can all agree that Lodash is a fork of Underscore.js, nothing more and nothing else.
https://github.com/lodash/lodash/commits/0.1.0?after=e0971cd...
If they were giving "no credit at all", they would be in violation of the MIT license.
Ok, does that make forks who don't mention where they forked from rips? Huge leap in logic.
> Why should I need to dig into the Git history to find out the creative origin of Lodash?
Well, if you're interested in the origin you either look for information available in threads like this, where other people dig or you dig yourself. Not sure what the problem is. Someone published a library under MIT, another person forked that library and created a new one, also under MIT, and somehow the fork is now a rip? Give me a break
> Based on Underscore.js, copyright Jeremy Ashkenas, DocumentCloud and Investigative Reporters & Editors <http://underscorejs.org/>
They've given precisely as much attribution as is required.
I have no qualms with forks or reimplementations (ie. Android - Java.) I actively support the paradigm.
But in this case, it's pretty shitty to try to erase all evidence of said inspiration. Most forks and reimplementations don't do that. They pay homage to their origin with at least a shout out.
After some digging, it seems like the Lodash website stopped mentioning Underscore.js around 2015 sometime, but even before that, it never had "evidence of said inspiration" as claimed by you.
Here are the versions I looked at:
- https://web.archive.org/web/20120826202523/http://lodash.com...
- https://web.archive.org/web/20130502014523/http://lodash.com...
- https://web.archive.org/web/20140517192947/http://lodash.com...
- https://web.archive.org/web/20150513014815/https://lodash.co...
- https://web.archive.org/web/20160803063412/https://lodash.co...
- https://web.archive.org/web/20170830163720/https://lodash.co...
- https://web.archive.org/web/20180703043557/https://lodash.co...
- https://web.archive.org/web/20190803030353/https://lodash.co...
- https://web.archive.org/web/20200615092636/http://lodash.com...
- https://web.archive.org/web/20210314233141/https://lodash.co...
> A drop-in replacement\* for Underscore.js
You are right though, my memory failed me. No mention of forking.. Shameless!
Inside Macintosh > Macintosh Human Interface Guidelines > Part 2 - The Interface Elements > Chapter 4 - Menus > Tear-Off Menus and Palettes
http://mirror.informatimago.com/next/developer.apple.com/doc...
http://mirror.informatimago.com/next/developer.apple.com/doc...
>A tear-off menu allows users to move a menu around the screen like a window. Tear-off menus save desktop space because the user can place them on top of a document or move them to a convenient position. If you implement a tear-off menu rather than a fixed palette in a window, you allow the user to have a larger workspace in document windows. Users can also choose to leave the menu in the menu bar, or tear it off and close it when necessary. Tear-off menus give the user more flexibility than fixed palettes do.