No, he has an objection to them dropping support for "bower", which is a package manager for javascript files. It does seem like a typo of "browser", so I can see where the confusion would come from.
I think the thinking behind dropping the support is something like this:
I use browserify/webpack/node and npm is great. I wish more libs that I use were also on npm so that I wouldnt have to fork/shim them. How can I force other people to use npm? Maybe if I drop bower support for my awesome lib that everyone uses, other libs will follow suit, or perhaps the users will see the light and stop using bower because it sucks.
Given that there were 14825158 downloads of lodash from npm last month, that implies that there were over 3M downloads from bower. That's a lot of people to throw under the bus.
According to bower stats over the last 7 days lodash was installed 23 times compared to 4 million npm downloads & 181 new npm packages depending on it.
After thinking about it a bit more, the only reasonable conclusion I can come to is the following:
It's the number of times users actually typed
bower install lodash
i.e. adding it to a project that didn't already have it, as opposed to just running bower install on a package which uses lodash.
Would also explain why despite bower itself being installed 37000 times in the last 7 days, the most installed package is only listed as 100 or so times.
Its great with everything. Frontend / backend, etc. When I removed bower from our app last year, adopted Webpack and migrated everything over to NPM it dramatically simplified things.
Ah, that's good to know; I'd been sticking to Bower for Phoenix' front end stuff, might start looking at migrating them to NPM if Brunch support is stable now.
It works a lot like NPM but is specifically intended for use with front-end modules.
Features:
- uses System.js (a polyfill for the future ES6-module-loader spec
- supports CommonJS, AMD, and UMD formats
- has plugins for importing other types (ex css)
- support Typescript/Traceur/Babel out of the box
- uses a flat dependency structure (ie like NPM v3)
- can generate bundles and self-executing bundles (incl tree shaking and minify)
- tracks specific versions of dependencies
Unlike NPM, module installation doesn't depend on packages published to a central registry. It can install versioned modules directly from GitHub and NPM. The registry it uses is nothing but GitHub repo with module-to-repo mappings and compatibility shims.
I loved bower and really preferred it in regard with npm for frontend modules. However more and more packages went to npm-only and we completely switched to npm for all.
Looking back, I am glad since it's just a nightmare to deal with dozens of package managers. Because bower was installed via npm, we had npm installed already and just skipped the bower part.
Not sure if this is a dumb question but I haven't been able to find an answer anywhere.
I currently use underscore 1.8.3. Can I just swap lodash in, or is refactoring involved? I know it's a fork, and I want to move over, but was curious if anyone know off the top of their heads if a lot of work as involved.
If I'm correct, you're showing this as a counter example to prove that the two have incompatible APIs and are thus LoDash can't be used ad a drop in replacement. However, Lodash does alias it's 'forEach' function with 'each', so this wouldn't be an issue?
underscore.each has an optional 3rd parameter (context). lodash.each does not. If you depend on that 3rd parameter, you will be in a world of pain if you drop-in lodash. In fact you'd be better off if there was no alias because you would catch the problem sooner and have to think about the API differences when fixing it.
I haven't looked over the changelog/breaking changes for 4.0.0, so this may not encompass everything there, but there are a few changes you need to be aware of. How hard it is depends on which functions you use currently, but I doubt it would take more than an hour of find-replace work. They are listed here : https://github.com/lodash/lodash/wiki/Migrating The ones that affected me the most were the changes to the overloaded _.first, _.last, etc, but YMMV.
I've done similar refactorings in the past (somehow my fingers only remember `npm install underscore`) and for me it has always been a drop-in replacement. However, as others have pointed out, it does depend on how much functions you are using and from my experience the whole thing should not take long.
Kudos to John-David Dalton for making such an awesome lib and being such a positive force behind it for so long! I've reached out to him multiple times on Twitter and he's always been quick to help!
He should definitely write a post on how he stays productive and motivated to work day-in and day-out on one project. Really inspiring!
Could not agree more. I have opened multiple issues on GitHub and he is always quick to reply. It takes a lot of diligence to maintain an almost always empty issues list on GitHub.
Thanks to him indeed. Thanks for his work (and research) on sandboxed natives, FuseJS, NWMatcher, LoDash and so many more awesome projects. He never stopped pushing that envelope and we're reaping the benefits now.
Agreed. That's why I invited him on the JavaScript Air show. The live video broadcast podcast all about JavaScript and the web platform. He'll be on live on March 2nd: http://jsair.io/lodash
I think it's time to check out a jquery alternative. My recent projects are basically only using deep copies and some semi-complex selectors. lodash + querySelector should cover pretty much everything at this point.
Have you checked out Lea Verou's Bliss.js? http://blissfuljs.com/ It's super minimal and basically relies on querySelector. Give it a whirl and see if it fits your needs.
I've seen projects that use jQuery just for the selector part, nothing else is used. Selectors are a core strength of jQuery. With document.querySelector, I wouldn't even include jQuery in a new project. `window.addEventListener` isn't much different than .on
It's used out of convenience, and avoiding errors. jQuery selectors are stupidly simple to do complex stuff with. I just wish they had a jQuery.selector distribution.
Not to be forgotten is d3, which in addition to selectors allows you to very easily bind data to the DOM. And with the big 4.0 refactor that is underway, you can very easily pull in the selection[1] stuff only.
The whole point of major version bumps (in semver) is to allow of these kinds of breaking changes. When should these changes be made if not during a major version bump?
i wasnt trying to complain about breaking changes, i was saying that i am sad that i have a cod base which cannot use this. I am sure many people are in the same boat
I remember reading sometime ago that the creators of LoDash strived to maintain drop-in compatibility with Underscore, and that if breaking changes between the two libraries were to occur, an announcement would be made. I can't find the initial statement, so I wonder if the developers are still attempting to maintain this?
Feels good to see a JS lib last that long and still be actively maintained, deprecating obsolete features and adapting to the new ways we use our browsers without breaking BC (or else explaining how to migrate).
Coming from Symfony (PHP), this just feels right: keep moving but make it easy to follow along.
Is this a Symphony thing or are external dependencies significantly more reliable in the PHP ecosystem in general? Last time I wrote PHP was 9 years ago and those times everyone I knew just copy-pasted all the external code they found. I know that package managers are the thing now and I'm using nuget for my .NET projects (and npm, which is a must if you do any front-end dev), however, I feel like I'm having more dependency management issues than the good ol'days in spite of using a language with static type checking.
I'm not saying "vendor everything" but maybe some vendoring helps, especially when every package author seems like they've taken the philosophy of "doing one thing, doing it well and breaking everything on every update".
I find external dependencies much more reliable in the PHP world than JS. Most packages try to follow semver. Composer is one of the best dependency manager tools I've used and you can easily lock down dependency versions so you can install from a state which you know works.
People hate on PHP but there are a lot of quality packages out there and Composer is definitely considered best practice by most developers now.
The Symphony team are extremely good at moving forwards while not breaking everything behind them, they also have (frankly compared to nearly everyone) insanely good documentation.
I'm primarily a Laravel user (it's a better fit for the stuff we do) but I have huge respect for the Symfony guys as their components make PHP much nicer to work in.
I would say it is particularly true for Symfony, but other package maintainers, like Tailor Otwell for the Laravel framework, do an impressive job at documenting how to upgrade to newer versions and keeping BC to a minimum.
For instance, I just recently upgraded from Symfony 2.7 to 2.8. The upgrade path was pretty much "Remove all deprecated warnings, upgrade your Symfony package, done". The same upgrade path is used from Symfony 2.8 to 3.0, which makes it really easy to upgrade.
Symfony, as most PHP dependencies, can be installed via the "composer" package manager, which is pretty much the only package manager that is used in the PHP community, it seems. As dchesterton says, it is a very good piece of software.
Was wondering the same, and I can't think of a better reason than the popular adoption of ES6 arrow functions, since the thisArg was mostly used to pass in 'this' as a value.
It was removed because it added extra complexity for method implementations and was used very little. Folks now can use `_.bind`, or `Function#bind`, or arrow functions.
100 comments
[ 4.3 ms ] story [ 171 ms ] threadI use browserify/webpack/node and npm is great. I wish more libs that I use were also on npm so that I wouldnt have to fork/shim them. How can I force other people to use npm? Maybe if I drop bower support for my awesome lib that everyone uses, other libs will follow suit, or perhaps the users will see the light and stop using bower because it sucks.
I avoid bower wherever possible, but removing support does smell a bit like an activist move. There may be more to the story, though.
http://bower.io/stats/
http://npm-stat.com/charts.html?package=lodash
https://gist.github.com/anvaka/8e8fa57c7ee1350e3491/revision...
It's the number of times users actually typed
i.e. adding it to a project that didn't already have it, as opposed to just running bower install on a package which uses lodash.Would also explain why despite bower itself being installed 37000 times in the last 7 days, the most installed package is only listed as 100 or so times.
It works a lot like NPM but is specifically intended for use with front-end modules.
Features:
- uses System.js (a polyfill for the future ES6-module-loader spec
- supports CommonJS, AMD, and UMD formats
- has plugins for importing other types (ex css)
- support Typescript/Traceur/Babel out of the box
- uses a flat dependency structure (ie like NPM v3)
- can generate bundles and self-executing bundles (incl tree shaking and minify)
- tracks specific versions of dependencies
Unlike NPM, module installation doesn't depend on packages published to a central registry. It can install versioned modules directly from GitHub and NPM. The registry it uses is nothing but GitHub repo with module-to-repo mappings and compatibility shims.
Here's the link: http://jspm.io/
Lodash is already included in the registry: http://kasperlewau.github.io/registry/#/?q=lodash
It doesn't cover any of the functionality that JSPM provides and publishing modules as RPM only makes them available to (at most) 1%-2% of users.
JSPM is written in Node and available via NPM. So... it works on pretty much anything out of the box.
Thanks for the tip. I wish my comment wasn't locked in already so I could correct the misinformation.
Looking back, I am glad since it's just a nightmare to deal with dozens of package managers. Because bower was installed via npm, we had npm installed already and just skipped the bower part.
I currently use underscore 1.8.3. Can I just swap lodash in, or is refactoring involved? I know it's a fork, and I want to move over, but was curious if anyone know off the top of their heads if a lot of work as involved.
https://lodash.com/docs#forEach
http://underscorejs.org/#each
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I'm honestly curious why this is being removed?
Lodash v2 was not but offered an lodash.underscore.js build.
Lodash v3 dropped the compat build in favor of using individual lodash modules until you're able to transition
Lodash v4 continues the view of v3
He should definitely write a post on how he stays productive and motivated to work day-in and day-out on one project. Really inspiring!
It clocks at 2.5KB mingzipped, after browserification.
There are probably lighter implementations.
[1] https://github.com/d3/d3-selection
oh no, so many breaking changes that I cant use it!
Isn't that the point of a major version bump? It's not like being mad at 3.11.0 wrecking everything.
They're still mostly drop in though, most lodash differences are extras rather than modifications.
Coming from Symfony (PHP), this just feels right: keep moving but make it easy to follow along.
I'm not saying "vendor everything" but maybe some vendoring helps, especially when every package author seems like they've taken the philosophy of "doing one thing, doing it well and breaking everything on every update".
People hate on PHP but there are a lot of quality packages out there and Composer is definitely considered best practice by most developers now.
I'm primarily a Laravel user (it's a better fit for the stuff we do) but I have huge respect for the Symfony guys as their components make PHP much nicer to work in.
For instance, I just recently upgraded from Symfony 2.7 to 2.8. The upgrade path was pretty much "Remove all deprecated warnings, upgrade your Symfony package, done". The same upgrade path is used from Symfony 2.8 to 3.0, which makes it really easy to upgrade.
Symfony, as most PHP dependencies, can be installed via the "composer" package manager, which is pretty much the only package manager that is used in the PHP community, it seems. As dchesterton says, it is a very good piece of software.
(In any case, this library saves me a lot of manual labour, headache + can write in a functional way without poor performance.)
It seems odd since the `Array.prototype` methods include it.
https://github.com/lodash/lodash/commit/454aca7003e14994e7b9...