7 ms·
I don't understand the continuous backslash against such a useful tool like lodash, we add 4kb and have all the utility functions that we will ever need, what's
by vfc1 7y ago
I don't understand the continuous backslash against such a useful tool like lodash, we add 4kb and have all the utility functions that we will ever need, what's wrong with that?
I feel that most people repeating this "you don't need lodash" meme are just saying it because they read it somewhere, and think that bashing on lodash makes them sound cool and looking like they know what they are talking about, much like it happened with jQuery.
There is way too much focus on micro-optimizations like handwriting/copy/pasting common utility functions each time to save 3.5kb in a bundle.
It's just one more of those many examples of engineering perfectionism gone counterproductive, which is, unfortunately, an attitude that is pervasive in this profession and that it rarely gets called out.
- thecleaner 7y agoOut of curiosity is jQuery really that bad ? I am not exactly sure why I would not want to use jQuery and prefer SPAs. What is actually missing in jQuery lodash handlebars combo ?
- dymk 7y agoManaging anything more complicated than only a slight enhanced page quickly becomes a big ball of mud when you use jQuery and handebars (fancy string interpolation) for state management and UI updates.
- deleted 7y ago[deleted]
- thecleaner 7y agoI see. What do you use and why ?
- dymk 7y agoReact+Redux. I can focus just on what the structure of the UI should be and not the nitty-gritty of actually updating it (React handles that). State management through Redux so I can consolidate where application state is held, and testing it is straightforward and a feature of the library.
- ChrisCinelli 7y ago8 years ago I was using jQuery and good self contain JS objects. Each of them had responsibility over specific part of the DOM. The beauty of that is that in that why you can keep thing simple and updates already well optimized by default. I understand that by default with JS you can write code that in one place touch every part of the page. But no framework or language protect you from bad code practices and bad abstractions. They may avoid it at a specific abstraction level but unless you are disciplined and you know what you are doing, you are still screwed beyond that. Component libraries like React did not invent encapsulation, abstractions, separation of concerns, loose coupling and high cohesion, they just enforce them at their level of abstraction but let you paying the "unoptimized" recalculate all by default. In fact I saw a bunch of code written in React that are big balls of mud communicating together without a good abstraction logic. Redux, in the React ecosystem, is pretty good at keep the state in one place but pretty bad to hide implementation details to those component that should not be concerned with them... result? Refactoring a reducer can results in refactoring a lot of smart components. And the verbosity of using Redux has always been off the chart. The best part of React documentation is here:https://reactjs.org/docs/thinking-in-react.html https://reactjs.org/docs/thinking-in-react.html - Especially in steps 3 and 4. Learn that and use it with the framework of choice or just vanillaJS... You do not use that and you will be in trouble with React or any other framework.
- bobthepanda 7y agoAll your template-based logic is in one place. Rather than listen to events and then executing actions using a mishmash of selector-fu, you can have a self-contained template that doesn’t care about other parts of your page. It hides a layer of nitty-gritty from the developer.
- protonimitate 7y agoI think it mostly stems from the meme that "pure JS is best JS" and anyone who relies on "unnecessary" libs is somehow a worse dev than those who implement everything by hand, regardless of if its required or not. For personal projects, self education, or fun - go ahead and implement the entire lodash lib by hand! But in a business setting a 3.5kb reduction in bundle size and 10 hours spend refactoring the lodash code out of your project is probably a waste of time and money. I'll agree with the advice that you shouldn't add dependencies until you need them, but saying "you never need lodash" is bad advice IMO. Absolutism is a bad quality to harbor, especially when it's over trivial things. I know jQuery fell out of favor with the JS community and now is treated like a sign of incompetence but - just as everything in programming holy wars - at the end of the day everything is a tool, and you need to pick the right tool for the job. If the job is "get an MVP up as quickly as possible" and lodash/jQuery/underscore helps you do that, why wouldn't you use it?
- gmanley 7y agoPersonally one of the biggest red flags for me is when a developer doesn't use libraries and writes everything themselves. That opensource project with many contributors, that has been around for years is probably going to be better than what you can write in couple passes. There are obviously times when you need to do it yourself or the library truly is badly written but those times are rare. This gets a bit weird in the JS optimization world because it is true that each library and parts of the library you don't use are going to be extra useless bytes the user has to download. With tree shaking removing the parts of the library you don't use I think this becomes less of an issue.
- delinka 7y agoThe JS ecosystem has gotten so large that I can't possibly keep track of all the libraries that I could use to save myself trouble. This isn't helped by the fact that few tools & libs in that ecosystem state succinctly the problem they're attempting to solve.
- zawerf 7y agoI think the current meme/trend is to drop as many dependencies as possible. Which is probably the overcorrection of the previous trend of using single utility function libraries like "leftpad". I do agree with this specific instance though, that you should drop lodash. Historically lodash/underscore was written for a time before a lot of syntax/standard libraries were added. The new javascript features obviously had lodash in hindsight so they are pretty good at making common things syntactically easier to do or just straight up taking the good functions and standardizing it (e.g., spread operators, arrow functions, Object.assign, Array.flat, Array.flatMap, etc, etc)
- wnevets 7y ago>I feel that most people repeating this "you don't need lodash" meme are just saying it because they read it somewhere, and think that bashing on lodash makes them sound cool and looking like they know what they are talking about, much like it happened with jQuery. I feel like this happens for a lot of topics in this industry, positively and negatively. e.g TypeScript has been on the receiving end for both.
- _the_inflator 7y agoI take these "You don't bla" repos with a grain of salt. JavaScript evolves and if there are methods that are now (almost) natively covered by the language why not use them? Also, if you only need a few methods it makes sense to spare the 4kb and simply rely on a native implementation. Such collections then come in handy.
- chmod775 7y agoCase in point: "_.compact". When I see stuff like const cleanInput = _.compact(input); I have no idea what the fuck just happened. I have to open the damn documentation of lodash (or whatever else kind of library the author chose to use) to figure out what's going on. Now if that was const cleanInput = input.filter(elem => !!elem); I could've gotten on with my day and saved some time. This does not need any documentation or comment. This might seem like a small issue to you, but damn, I spend a lot of time debugging random projects on GitHub, and the inability of the JavaScript community to write readable code really trips me up every time. Instead of just writing 2-3 lines other people can parse in a second or two, they spend 5 minutes looking up the relevant library function (which doesn't do what they expect half the time) to produce one shitty line of code other people will also spend 5 minutes on trying to decipher it.
- ceejayoz 7y ago> This does not need any documentation or comment. Sure it does. You've just already read the documentation for filter. (And frankly, I just had to look up what !! does, despite years of writing JS code.)
- chmod775 7y ago> (And frankly, I just had to look up what !! does, despite years of writing JS code.) It's literally just 2 NOT operators chained together. I won't fault you for never having seen it, but it is curious considering how common it is. In any case. Looking that up just made you a more knowledgeable JavaScript developer, while looking up some random lodash function won't buy you much at all.
- lhorie 7y agoMy job involves overlooking hundreds of internal codebases and I see people doing `import {range} from 'lodash'` every once in a while. One offending line and tada: 70k+ bundle size for no good reason... I'd say that any argument for/against lodash can go both ways: if one argues that it is a micro-optimization to handwrite `range`, another person could argue that it's also a lazy devexp micro-optimization to use lodash. `range`, for example, can be implemented with a one liner in like 5 mins and tested thoroughly with a couple of asserts. Maybe one could argue that some of the more compositional stuff is not so trivial to write (e.g. cond and friends), but if one's using those over normal small procedural functions, who's really engaging in engineering perfectionism gone counterproductive?
- tlrobinson 7y agoI think all else being equal (e.x. assuming sufficient browser support or polyfilling), people should prefer using standard / built-in functions, many of which have been added to JavaScript since Underscore was popularized. However, I don't necessarily agree with this approach of providing snippets for functions which aren't implemented natively. Underscore and Lodash likely have better implementations and much more testing. If you're concerned about bundle size, use tree shaking or individual function imports. I think one exception to this is if you are writing a library and want to keep dependencies to an absolute minimum.
- mcphage 7y ago> people should prefer using standard / built-in functions I get that, but that's not what this list is: this list is re-implementing lodash / underscore using built-in functions. They're not a 1-for-1 replacement, they're complex implementations which may or may not be correct or efficient. If their solution for replacing _.chunk(...) was some built-in Array.chunk(...) or something, that would be fine. But instead, it's this: > const chunk = (input, size) => { > return input.reduce((arr, item, idx) => { > return idx % size === 0 > ? [...arr, [item]] > : [...arr.slice(0, -1), [...arr.slice(-1)[0], item]]; > }, []); > }; That's definitely worse than using lodash.
- tlrobinson 7y agoThat's exactly what I said in my second paragraph...
- mcphage 7y agoAh, you did. Sorry about that, you’ve caught me running my mouth off before I finish reading.