Your last paragraph was supposed to be my contribution to the discussion, almost verbatim :)
Maybe it is also a somewhat good analog for writing your own tools. At first you are so happy with your solution. It's elegant, robust and foolproof. But then you discover an edge case that has to be handled. And then business asks for an extra feature. Maybe you are time-pressed, so you take a shortcut in implementation. Then you have to add documentation, because a new developer is joining. In the end of the day (year?), you have duplicated the library you tried to avoid, only slightly worse. And without an OSS community around it.
That said, I wish you all a profession where you can write bleeding edge custom code all day, every day :)
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
Many developers come to the same conclusion, I remember a few years back when I would have fully supported the sentiment of this post. Because the ideal is, for a better word, sexy. But one day it hits you, there are hidden wins and ways to achieve your goals that might feel like a sacrifice, but they are a damn sight faster. Fixing up something like a library or wrapping it in abstraction is tantamount to managed risk, we can choose when it is a good time to take action later on in development.
There are one or two exceptions, libraries that are misguided in reimplemented native APIs, which the author failed to check existed, libraries that don't announce self redundancies and libraries that abstract simple tasks that are overengineered, all those cases are things I really don't like.
I myself am a new developer in my job and I can tell you this much, if my predecessor had not chosen to implement a library for core features I would be far more helpless.
The benefits of libraries are obvious. I don’t think we consider the negatives that can arise from choosing a library enough. It seems like the de facto solution for JavaScript engineers is to install an npm package for everything. There are times the custom solution is more responsible, performant and user friendly than adopting a library. This isn’t just about the ideal of using the latest browser API.
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
10 plus years* active enterprise development experience and a Fine art degree 🎨
I think this issue transcends any language specific developer. This is business driven culture practices (it depends where you work). Although I have never come across a developer who actually pulls in a dependency per ticket, I suppose such a developer might exist.
Your point about consideration, I keep reading over the internet about JavaScript engineers for some reason having been lumped with a hive mind reputation, it just doesn't equate to fact. We are all individuals and just developers. But yes people do use npm. No Npm is NOT a good package manager. One of the reasons why the Deno project exists I suppose?
It comes down to this, you and your team are maybe a handful of people. For instance you want to create a greenfield product that uses typescript, state machine architecture, and JSON schema, you have 6 months to do it. Several epics are created and over that time you expect a couple of new hires to join you. At this point I would install the Typescript compiler, I would not use Deno or write my own because... You can see why and that's a easy one, what about a state machine architecture? Okay this is a tough call, on the one hand overengineering is a real and present threat, xstate is great, tested to death, more so than I could in 12 months of unit and acceptance tests, sure some switch statement would work too but this isn't really my applications focus, plus xstate is well documented and we'll optimised, great for those new hires who will appreciate the autonamy. Okay schema driven forms, let's see, could I impliment this myself? Yes, are there any good solutions that work with typescript or better yet, generate from typescript? I don't know, let's timebox this for maybe 4 hours... 4 hours later (true story) mine mostly works.. the next day, there's a bug here, several weeks and new tests and bugs fixed, I decide to quickly Google a JSON schema form library, oh there are 3, and they are quite well contributed too, I use that, and improve my own so that one day I can atleast compare them.
Thanks for reading and please, we may agree to disagree (somewhat, because I think I agree with you depending on how my day is going 🏠🏚️).
If a library works and doesn’t negatively effect the production bundle, has a developer friendly API, integrates cleanly with your environments, and has a shallow learning curve go ahead, use it. When there are several options available but none of them provide those things, code your own implementation. Sounds nice but there really aren’t any hard and fast rules. As others have pointed out, it’s case by case. There doesn’t have to be a greenfield project though to implement something custom.
True story. I tried to use a plugin for a thing. It did what I wanted but found a nasty side effect that meant I couldn’t use it. I try another package that does a similar thing, but no way to integrate cleanly. I diagnose the bug and create an issue in the repo, author responds promptly. I dig in deeper while figuring out if I could just submit a pull request. I find a bunch of unnecessary code that would effect performance. Is it worth my time arguing with the author? I took a hour to learn how to develop the plugin and wrote one that did the same thing but with far less code, implementation was more performant. A few minutes later after testing it out, I npm publish and integrate the new plugin with my project. Done in less than two hours. Yes, I’ll be on the hook for maintenance, but there is hardly any to speak of. Oh well. In my opinion, we need more of that kind of mentality in web development, but in my experience engineers with a “can do it” attitude are few and far between.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your last paragraph was supposed to be my contribution to the discussion, almost verbatim :)
Maybe it is also a somewhat good analog for writing your own tools. At first you are so happy with your solution. It's elegant, robust and foolproof. But then you discover an edge case that has to be handled. And then business asks for an extra feature. Maybe you are time-pressed, so you take a shortcut in implementation. Then you have to add documentation, because a new developer is joining. In the end of the day (year?), you have duplicated the library you tried to avoid, only slightly worse. And without an OSS community around it.
That said, I wish you all a profession where you can write bleeding edge custom code all day, every day :)
Many developers come to the same conclusion, I remember a few years back when I would have fully supported the sentiment of this post. Because the ideal is, for a better word, sexy. But one day it hits you, there are hidden wins and ways to achieve your goals that might feel like a sacrifice, but they are a damn sight faster. Fixing up something like a library or wrapping it in abstraction is tantamount to managed risk, we can choose when it is a good time to take action later on in development.
There are one or two exceptions, libraries that are misguided in reimplemented native APIs, which the author failed to check existed, libraries that don't announce self redundancies and libraries that abstract simple tasks that are overengineered, all those cases are things I really don't like.
I myself am a new developer in my job and I can tell you this much, if my predecessor had not chosen to implement a library for core features I would be far more helpless.
The benefits of libraries are obvious. I don’t think we consider the negatives that can arise from choosing a library enough. It seems like the de facto solution for JavaScript engineers is to install an npm package for everything. There are times the custom solution is more responsible, performant and user friendly than adopting a library. This isn’t just about the ideal of using the latest browser API.
I think this issue transcends any language specific developer. This is business driven culture practices (it depends where you work). Although I have never come across a developer who actually pulls in a dependency per ticket, I suppose such a developer might exist.
Your point about consideration, I keep reading over the internet about JavaScript engineers for some reason having been lumped with a hive mind reputation, it just doesn't equate to fact. We are all individuals and just developers. But yes people do use npm. No Npm is NOT a good package manager. One of the reasons why the Deno project exists I suppose?
It comes down to this, you and your team are maybe a handful of people. For instance you want to create a greenfield product that uses typescript, state machine architecture, and JSON schema, you have 6 months to do it. Several epics are created and over that time you expect a couple of new hires to join you. At this point I would install the Typescript compiler, I would not use Deno or write my own because... You can see why and that's a easy one, what about a state machine architecture? Okay this is a tough call, on the one hand overengineering is a real and present threat, xstate is great, tested to death, more so than I could in 12 months of unit and acceptance tests, sure some switch statement would work too but this isn't really my applications focus, plus xstate is well documented and we'll optimised, great for those new hires who will appreciate the autonamy. Okay schema driven forms, let's see, could I impliment this myself? Yes, are there any good solutions that work with typescript or better yet, generate from typescript? I don't know, let's timebox this for maybe 4 hours... 4 hours later (true story) mine mostly works.. the next day, there's a bug here, several weeks and new tests and bugs fixed, I decide to quickly Google a JSON schema form library, oh there are 3, and they are quite well contributed too, I use that, and improve my own so that one day I can atleast compare them.
Thanks for reading and please, we may agree to disagree (somewhat, because I think I agree with you depending on how my day is going 🏠🏚️).
If a library works and doesn’t negatively effect the production bundle, has a developer friendly API, integrates cleanly with your environments, and has a shallow learning curve go ahead, use it. When there are several options available but none of them provide those things, code your own implementation. Sounds nice but there really aren’t any hard and fast rules. As others have pointed out, it’s case by case. There doesn’t have to be a greenfield project though to implement something custom.
True story. I tried to use a plugin for a thing. It did what I wanted but found a nasty side effect that meant I couldn’t use it. I try another package that does a similar thing, but no way to integrate cleanly. I diagnose the bug and create an issue in the repo, author responds promptly. I dig in deeper while figuring out if I could just submit a pull request. I find a bunch of unnecessary code that would effect performance. Is it worth my time arguing with the author? I took a hour to learn how to develop the plugin and wrote one that did the same thing but with far less code, implementation was more performant. A few minutes later after testing it out, I npm publish and integrate the new plugin with my project. Done in less than two hours. Yes, I’ll be on the hook for maintenance, but there is hardly any to speak of. Oh well. In my opinion, we need more of that kind of mentality in web development, but in my experience engineers with a “can do it” attitude are few and far between.