4 ms·
An important role of developers is knowing which tools exist and what can be used to provide value. To use Lodash, a developer needs to know what is available
by whstl 4y ago
An important role of developers is knowing which tools exist and what can be used to provide value.
To use Lodash, a developer needs to know what is available there in the first place. You're taking it for granted, but everyone, you included, had to study its documentation and memorize which functions were there, even if it was only to "look it up" later.
Someone like you could have said a few years ago about Lodash: "why do I need this stupid library, I will just use for loops everywhere, like I learned in college. They get the job done and my role is to provide value, not to care about libraries or code reusability".
With this website, it's the same thing: it's there to teach you which things in Lodash aren't needed anymore and which are. Then it is up to the developer to use what's best. Not everything in the internet is prescriptive.
Blind dogmatism shouldn't have a place in our profession.
- Zetice 4y agoThat's kind of my point, though? Caring about "blind dogmatism", one way or another, is not required to be a highly effective software dev. For example with lodash, the process for deciding to use it could be, "Hey this looks like it could save me time, let's try it." That's it. You don't have to go on this large, multi-hour/multi-day journey discovering every little thing about it first. I'm arguing here that highly effective developers are able to use software to solve business problems favoring efficiency over correctness. And I'm not sure it's efficient to care much about whether or not lodash could be rebuilt internally.
- whstl 4y agoYou say "one way or another". What is the "another" way, and who's advocating it? This page is NOT an invitation to rebuild lodash on every single project. It is not a prescriptive website. It is teaching material. This page is here, for example, so that people who only know about Lodash can know how it's implemented. If they ever start working on a no-Lodash project, they might not need to import Lodash. This is not a call-to-arms to uninstall Lodash from all projects and replace with hundreds of functions. Why would it be?
- Zetice 4y agoThen this page could be replaced by looking at lodash's source code. In fact this page is harmful as it does not represent, precisely, what lodash is actually doing and should not be used to understand lodash. Further, I'm not responding to the page itself, but the discussion here around the page. A lot of developers are using their emotions (e.g. disgust, fear) to navigate their professional role, and I'm suggesting that this need not be the case. You can set all of that aside and be a highly effective developer. You don't need to care about any of this, and I'm seeing a lot of devs here who think they have to care in order to be effective.
- whstl 4y agoIt couldn't be replaced by looking at Lodash's source code, because A LOT of the alternatives here are built into Javascript, and the Lodash code is significantly larger. Check flatten in this website: array.flat(); Versus Lodash: function baseFlatten(array, depth, predicate, isStrict, result) { predicate || (predicate = isFlattenable) result || (result = []) if (array == null) { return result } for (const value of array) { if (depth > 0 && predicate(value)) { if (depth > 1) { // Recursively flatten arrays (susceptible to call stack limits). baseFlatten(value, depth - 1, predicate, isStrict, result) } else { result.push(...value) } } else if (!isStrict) { result[result.length] = value } } return result } About your point: sure, nobody has to care about all of this. But I don't see why we should give people a hard time because they do on their free time.
- boredtofears 4y agoIt's not that hard to do a basic cost benefit analysis of adding a package before you throw it in your package manifest. It usually takes minutes, not hours (and certainly not days). Skipping this step doesn't gain you major efficiencies and definitely doesn't make you a better developer.
- Zetice 4y agoIf you're unsure why this must be said, you've never worked in a large corporate environment. People will spend weeks on decisions like this.
- watwut 4y agoHowever, going into such multi hour/day journey once in a while is very effective way to learn. And writing down that journey is also very effective in forcing you to really go through and really learn.