Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
MrCSharp5418156dNo it wasn't.
EmberQuill1092156dI usually find out about the library first, then try to do it myself. For fun and learning.
Paralax1269156d"When you finish writing your code and don't need to include a dozen useless dependencies" Time well spent
dmoa409155dYou feel so much more sophisticated not using library; "I don't need libraries"
Ximidar1137155dBut now your company doesn't rely upon some stranger's code. That guy might have had the balls to put an exit condition in when it encountered an error instead of just returning the error. You don't want that.
mundo034955154d@SauceBoss the thing about dependencies is that they change and break your code, might not happen today, might not happen tomorrow but it will.
Node shit happen to be a fucking playground so it happens very often but it does happen on any language.
So yes, time fucking well spent
@mundo03 @Ximidar @Paralax I hope you people appreciate how pretentious you look.
"this code has been written by someone else? It's shit and I'll do better"
As for the fallacious arguments I've seen:
#1 the amount of sub dependencies : why do you care? Worst case scenario it'll take a few more seconds to deploy and use a few more bytes on your server.
#2 it'll break: as much as your code.
#3 now I own the code: yay now you have to maintain, document and test it as well!
That said : sometimes it's worth writing the code yourself but it's absolutely not always the case
@Commodore I prefer to write my own code. I learn much more about the internals of protocols and get more under the hood knowledge of whatever problem I'm solving.
But to take on your points:
#1 worst case scenario is the maintainer of a sub dependency of a sub dependency decides to mine bitcoin.. Guess who's website will get featured on hacker rank and publicly shamed? YOURS.
#2 not an argument. I had to spend hours today fixing a deployment issue caused by a dependency. In this case, that dependency broke a perfectly running system.
#3 I wrote my own HttpClient with fluent api style to it. This was 2 years ago... Never had to go back and fix shit. Only add features when I need them. And the same for my IoC container library (Google this one if you only have JS knowledge)
That said, I still use 3rd party Dependencies but I try to keep the number as small as possible. In dotnet land it is more manageable unlike NPM.
@MrCSharp to elaborate : every single point I've seen so far make it looks like you work alone and update your dependencies blindly.
I'm not arguing the value of writing something yourself for educational purposes, I love it. But that requires time, time that you most likely won't have on a actual professional project.
I'm not arguing either that some dependencies are crappy, nor that bugs happen in their code. But if you're able to proof your code, you can proof an update.
What's bugging is how peremptory you all sound.
Ximidar1137154d@Commodore it's not pretentiousness, its experience that trusting a stranger's libraries is just asking for trouble. If it is a popular library with documented success in other projects, then yeah use it. But if it's some random library that Joe Schmo wrote, you had better be prepared to read it in its entirety, or just write it yourself. Because any way you cut it, the moment you add a dependency into your code you are responsible for any problems that arise because of it.
The example I gave above was a real experience I had. I imported a library and someone had wrote an exit(0) if it experienced an error. I've experienced libraries that have busy waiters that cause the processor to Spike to 100% CPU when they don't need to. I've had libraries that don't quite do what I need it to. And I've had giant libraries that I just want a single function out of. I am not the best coder in the world, but I am the one who is responsible for the integrity of the code I write.
@Commodore I don't work alone but I might have sounded like that.
You read my points and can't counter them so you make assumptions about me personally. Quite funny.
I agree that for professional work and client, time is Important and to save time you rely on Dependencies. However, keep in mind that for every dependency and sub dependency you add, you're increasing your technical debt. And all the time you saved by including that tiny dependency will be lost when said dependency misbehaves or causes other issues or incompatibilities. Best case :spend hours to fix it. Worst case : rewrite parts of the site so they don't rely on it or replace it which means a lot of code needs to be updated anyways if you're not following SOLID principles (Open for extension, closed for modification, and dependency injection). Of course JS as a scripting language doesn't promote those principles so your code will have parts rewritten to accommodate the new replacement library.
mundo034955153d@Commodore i get #1 and #3, but you don't get #2
This is something you have to live to understand.
I agree most of the time a dependency breaks something is trivial to fix, but other times you have to re do the whole thing if the dependency has a serious problem.
What you want to avoid is to import code to use 2-3 functions that are not even long, which is what most lazy assholes do (I am looking at you Node people)
ColdFore2107116dNope. You became a little smarter. Congrats.
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job