Have you ever connected lodash, or any other library, using a single function from it? Wouldn't it be easier to write that function myself, especially if I solved this problem on vanilla JS?
First of all, if you are looking for one, there is no definite answer to this question. In each case, you need to take into account many factors, starting with the nature of the code and ending with the launch conditions, i.e. where and how the program is launched. We will talk about this later.
On the one hand, the size of the code is almost irrelevant. Plus or minus a megabyte, or even ten megabytes, doesn't solve anything at all. Modern software has enormous resources, the weight of which is much larger than the size of any library. Even so, a library with simple functionality takes up a lot of space.
On the front end, everything is a bit more complicated, but now it all comes down to how the library is organized. If the export is properly configured, the final version (for example, built by a webpack) will contain only those functions that are used. And this is very little.
Dependencies:
Some developers minimize the number of dependencies (third-party libraries) in their code. Small functions are no longer enough here, complex projects can have their solutions with many ready-made tools.
There's not much to say here. Dependencies are good if they save developer time and allow you to spend more time on application logic than infrastructure tasks.
What are the advantages?
Not all libraries are equally useful. There are often several basic problems that are poorly implemented in the programming language itself. These include working with collections, working with dates and times. In addition, various more specific parts need to be extended. In these cases, the library must be added as a dependency even for a single function.
As a rule, where one function is needed, another soon becomes necessary. Without realizing it, one person will write one function, another will write it elsewhere, and there is no certainty that they are aware of each other's already written solutions.
This situation quickly turns from "too early" to "too late" when there are many functions in the code available in each library.
Moreover, when programmers move to other projects, the same thing happens there. As a result, standard functions scattered across different projects, written by different people, contain bugs, lack documentation, and are usually poorly or not tested at all.
Your code will not be as thoroughly tested and documented as in popular libraries. Try opening lodash and see how extensive the documentation is. This is another advantage of such libraries. Since the library is so widely used and standardized, most developers know how to work with it.
This means the project code will be more understandable for everyone who works with it.
There is another interesting but not obvious advantage of using such libraries.
Libraries contain many functions that are difficult to understand on their own. By using these libraries, developers can increase their level of knowledge and learn how to solve most standard problems with a minimum amount of code and correct abstractions.
Of course, these functions need to be reviewed periodically. Students regularly reinvent the wheel because they don't know about standard solutions. In addition, when we say that only one function is needed, it turns out that there are actually several, and the developer may simply not be aware of them.
For other rare libraries, the situation is more complicated and it's not always clear whether to pull with the library. The key to making such a decision is realism, not completeness.
Top comments (9)
I like to write a script called
common.jsorcommon.hor whatever, and then import it as I need to use a function. This way, there's less clutter, and the miscellaneous functions are in one place (sorted in some way).Certainly! Using a common script file like common.js or `common.h" is a great strategy. It simplifies your codebase, promotes reusability, and helps in maintaining a clear structure. Just ensure your functions are well-documented so their purpose is clear, and organize them logically for easy access.
I don't know if I'm actually practicing this, but I aim to invent lubricant instead of reinventing the wheel.
In JS, I create libraries and define common function development and coding conventions in Java.
The ultimate goal is to reduce the amount of code written, improve readability, and improve performance if possible.
Your approach in JavaScript and Java to create libraries and define common functions, along with development and coding conventions, is indeed a forward-thinking strategy. By focusing on inventing 'lubricant' instead of 'reinventing the wheel', you're streamlining the development process. This method not only reduces the amount of code you need to write but also enhances readability and can potentially improve performance. It's a smart way to maintain consistency in your coding practices and ensure efficient, effective development across various projects.
Modern build tools make it easy to remove all redundant and unused code out of your production code. Maintaining one more dependency is not a problem at all.
I think it's a matter of personal preference.
I have a very popular Gist that replaces a depending library: gist.github.com/vladignatyev/06860...
The only reason why this gist still alive and people used it is a bad design of libraries providing similar functionality. They basically either a swiss knife or hard to customize for your need.
But get some time and think before you make a final decision. Would the library you want to skip provide any additional features that will be needed in a meantime when codebase evolves? If answer is no, feel free to put your bicycle or snippet into your codebase and remember to cover it with tests. Every piece of your own code put a responsibility of maintaining this code in future onto your neck.
Absolutely, it boils down to personal preference. Modern tools streamline managing dependencies, so using your own code or an external library is a matter of choice and project needs. Keeping in mind future requirements and maintenance responsibilities is key in this decision.
Is writing code that reads like shakespeare a good strategy? Could you give an example of such code in JS
it's generally not a good strategy for practical programming. Code is meant to be clear, maintainable, and understandable by others (and your future self).