It strikes me as the difference between knowing why your role exists and not realizing you deliver organizational value, over engineering perfection.
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.
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.
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?
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.
Check flatten in this website:
array.flat();
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
}
And I'm not giving people a hard time, I'm saying you don't have to care about all of this to be good at your developer job. If this was an obvious point to you, great!
It says so in there: it is "a description of how one would go about doing the same thing in vanilla JavaScript".
> This page is here, for example, so that people who only know about Lodash can know how it's implemented.
But my larger point here is just that you don't have to care about "only importing lodash if absolutely necessary" to be a good dev. You can care about those things, but for the folks who think they have to care, I'm here to say you don't.
Lodash is engineered to deliver “perfection” and performance, to an absolute fault. Try `import {unary} from 'lodash'` and tell me how big the bundle gets. FYI unary should be `fn => x => fn(x)`.
On the other hand, copy-pasting actually-useful utilities like groupBy from some random site defeats the purpose of npm. Luckily there are sane Lodash alternatives like Just:
This doesn't pass the smell test for me, considering how small the library as a whole is, and the many, many use cases that would not involve exposing the code to the user at all.
In fact, I find it hard to think of an effective software dev who does care about 28ms without having specific reason to, due to a niche use case (not a generic web app for Internet things, like a hospital instrument that needs every ms).
Indeed, I guess we just develop different classes of applications. I don't know what a "generic web app for Internet things" is.
And you're on a "generic web app for Internet things". This page loading 27ms slower would not be perceptible.
Personally I've never worked at a product where response time wasn't an important metric.
Using libraries like lodash, instead of adding 12 left-pads of different authors to the dependencies manifest, is an improvement over the status quo.
It's not that your coworkers don't know you can get away with doing a bad job, it's that they're not motivated by the same things that you are.
It's true that in some contexts, throwing npm libraries at the wall to see what sticks is delivering organizational value. In many others, it's negative value.
The folks who don't care about being "successful" are not "good devs", because they're not clear about why their job exists in the first place. You don't really get to define success for your role without your organization's input, and when you overly focus on the engineering to the exclusion of delivering value, you are not acting as a "good dev".
Intrinsic motivation is a real thing. You don't have to let your boss or your parents or your teachers tell you what it means to do a good job. You can decide for yourself.
People who just grab libraries from npm and don't take their imports seriously are not the ones delivering value in the places where I've worked. Far from it. Those are the people whose "work" you have to re-do weeks or months later because it didn't actually deliver value. Often times it doesn't work at all, never worked, never compiled, etc. But those people are long gone because they're busy being "successful" and moving on to other roles, creating negative value in other parts of the organization.
You say that only successful people know why their job exists, and unsuccessful people are blind to organizational value. In my experience, you couldn't be more wrong.
Effective developers know the answers to those questions. What else they do is quite varied, and some effective developers care about things like "should we use lodash or not?" But other effective developers don't.
I didn't say "only successful people" do anything. What I said was you don't have to care about how lodash works or be concerned about importing it vs. rolling your own to be an effective developer.