When it comes to using external libraries, sometimes you can't find exactly what you need, and there comes a question: should I write my own lib? I...
For further actions, you may consider blocking this person and/or reporting abuse
While I agree with the arguments brought up by the others, let me play the devil's advocate here.
There's oftentimes drawbacks to these external libraries and those are rarely on the board when it comes to comparing solutions:
In any case, you should make your decisions and reasons transparent and document them, just in case you have to answer the question why something now takes longer than expected - especially if you are driven by deadlines rather than finished features.
Very good points, thanks Alex! I'd say it's wise to consider all of those when you choose a lib to use, and not just pick a random one.
This is a general problem these days. Our abstractions have become very good at hiding the complexities of the tasks but few developers have really kept up with keeping track of this.
This is primarily a performance issue, but it can also lead to (albeit less severe) over-complicated program design.
Ideally, libraries wouldn't even need any DCE at all. In the case of JS, I think es6 modules are what will one day get us there.
I have seen production examples of abstraction overuse to hide unnecessary complexity, which became maintenance and performance hell rolled into one pandemonium. The key issue of unnecessary complexity is that it's hard to separate from necessary complexity.
Also, ES6 modules are really helpful, but to get all the way, we need libraries made up from composable primitives and wrappers and/or modifiers. I'm currently preparing a post about this exact topic, so stay tuned.
That will be a lot easier if and when decorators make it into the language.
Decorators will offer some semantic sugar for wrappers, but that shouldn't stop us from employing the pattern already in order to get better tree shaking results.
@darkwiiplayer decorators just reached Stage 3, reddit.com/r/javascript/comments/t... so we can you it already with babel, of course
Yea, I already saw that the other day. They had to get rid of the whole metainformation thing and put that into a different proposal, but tbh. that's probably for the best. And from the transcript of the presentation, it seems like there's going to be a bit more feedback from the browser side in the future as well. Who knows, a first implementation in chrome might be right around the corner :D
Use Typescript if you want to work with decorators already
There is also a babel plugin if you don't want to use TS for whatever reasons.
In any case, decorators are just semantic sugar around the wrapper pattern.
Write own external open source library is great idea, and worth in long term, because even when do not use anybody it is great piece of your resume. For example I created this one and it is work well under my job searching process: react-troll
True! That can strengthen your portfolio and show your code style to potential employer, especially if you are a beginner and don't have a solid employment history yet
Starting an open source project is really hard work. The community is not waiting for you: "hey look: there is a new project on github...". Github is filled with millions of insufficiently maintained projects that somebody posted for some reason years ago. So it get´s harder and harder every year to gain some interest for your work - regardless how valuable it is. As long, as you are not google or facebook.
For a possible user it is even harder to find usefull tools in a pile of dirt, so it is maybe not the best idea to publish every line of code you did under an open source library.
Very generally speaking:
For work: Only after thinking it over a lot and maybe consulting some coworkers for their opinions.
For private: Absolutely yes! Re-invent the wheel often enough and we'll eventually drive flying cars :D
Always boils down to a single question:
Do I have the time, skills and resources to make my own tomato soup?
I don't want to be a buzzkill, but I think it's a good idea to look at this from multiple perspectives.
I would discuss this with the Manager/CTO to understand the potential ROI (Return On Investment) of that effort.
Building something doesn't cost you anything, but it's costing your company (since you do get paid).
I would also schedule a meeting with colleagues from other teams, to find out if they would use those components, or if they would like to build their own instead.
Maybe do a small POC and see if folks would actually use it or not?
Lots of developers are doing Résumé-Driven Development, doing things that would look good on their CVs, but that are not actually helping their companies or colleagues in any way. Don't fall in that trap.
If I would be doing something for "pure fun", I wouldn't do it on company time.
Most of all those big companies that contribute to open-source projects are also doing it for Marketing purposes (and obviously, they wouldn't publicly admit that, they're not that dumb).
"If you are in a rush to keep up with deadlines, it's always better to use a well-documented external library." 100 times this.
I'm in a situation where a previous developer developed internal libraries, including one for state management, then bounced. The stuff works, but it's a bit unconventional. I think we would've been better off from a DX standpoint of just using one of the many well documented, well tested state management libraries that exist.
Oh, that's a "good" one, state management is not smth you can easily replace 🤦🏼♀️
I feel your pain: Nobody has an idea how it works, but we still dragging it around carefully not to break it, because we don't have time to cut it out 😢
Great post!
My personal greatest consideration when thinking about starting a new library (or any other side project, for that matter) is the time it takes to get something meaningful out of it versus how much free time I currently have - I often find myself willing to start something new when I don't even have a fraction of the time needed for it (and not surprisingly, my few attempts at those were not successful 😅).
It's also easy to underestimate the amount of work required, on the library itself and its peripherals (docs, tests, etc.).
That being said, there's a unique type of fun you get from working on your own ideas and bringing them to fruition. And even more so when other people start using it, e.g. in open-source libraries!
Finally, it's only semi related, but there's a methodology called InnerSource, the essence of which is bringing open-source ideas and best practices to inner organization tools. It's not always possible to affect the "working culture" of an organization by a lot to properly make use of it, but it's still a beautiful (and novel!) paradigm.
Thanks, Nitzan! Timing indeed is very important, I rarely can finish a small side project if I don't do everything in one go 😂 which is rarely the case. So yes, it's a grate idea to properly estimate it before you start!
InnerSourse seems like an interesting paradigm! Thanks for sharing 🙂
Don't use the company's project as your playground. For generic packages, don't reinvent the wheel unless you can maintain it for a long time. In more cases, based on the existing package, according to the company's business and development efficiency needs, we should encapsulate some business logic using the open source package . But sometimes this kind of encapsulation is unnecessary, and additional code will be introduced, which is not conducive to troubleshooting fundamental problems, and the granularity of open source package encapsulation is sufficient.