4 ms·

> I would prefer the quality of engineering required in knowing how to do some of these things yourselves. Realistically, a couple of engineers writing a libra

> I would prefer the quality of engineering required in knowing how to do some of these things yourselves. Realistically, a couple of engineers writing a library from scratch isn’t going to be higher quality than adopting a mainstream, battle-tested library that accomplishes the same thing. Writing your own implementations of everything can be fun, but it’s not possible to compete with all of the iterations and reviews that a mainstream library collects over time.

Silhouette 5y ago
Realistically, a couple of engineers writing a library from scratch isn’t going to be higher quality than adopting a mainstream, battle-tested library that accomplishes the same thing. That's true but the vast majority of what you find on NPM is not mainstream, battle-tested libraries. Libraries that do clear that bar tend to be widely useful but that suggests generality you won't necessarily need for any single use case. A couple of good engineers might struggle to beat a well-established open source library at everything it does, but that is rarely what they are trying to achieve. They just need something that is better for their own specific needs at that time, which might be a useful and realistic target.
dimitrios1 5y ago
Once you detach from "I must use a library for every thing" land, you begin to realize you don't need the overwhelming majority of them. Which results in writing cleaner, simpler, more focused code, with less of a surface area for bugs. It's a whole mindset, tbh.
- ModernMech 5y ago
  I appreciate libraries for: - ubiquitous things, like data structures - hard to get right things, like time - implementations of specs, like Unicode - hardware interfaces, like CUDA For everything else, I'll take the above and roll my own solution.
  - dimitrios1 5y ago
    except for the last one, all of those should be part of the language you are using, and well thought out + researched. I guess I should have been more specific: third party dependencies.
    - scotttrinh 5y ago
      In this specific case (Elm vs. JavaScript) We're talking about JavaScript here, so: > - ubiquitous things, like data structures There are a few basic data structures in JS, but almost everything else is in user-land. > - hard to get right things, like time Date is a notoriously bad API in JavaScript. - implementations of specs, like Unicode We just get a String type in JavaScript which is UTF-16, so...
      - dimitrios1 5y ago
        > We're talking about JavaScript here, so: Well, no, we aren't. We are talking about the Elm language, which compiles to JavaScript. There are also other excellent languages that target JavaScript that have these things.
  - alephu5 5y ago
    What about something tedious and ubiquitous, such as swapping between camel and snake case?
    - PhineasRex 5y ago
      This is exactly the case where you don't need a library. This is a single function (or two) and you can easily translate an existing code example into the language you're using in a few minutes and be done with it.
k__ 5y ago
But...! I've also seen many developers for years adopting mainstream libraries and frameworks wrongly. The atrocities I've seen built with Ember, Rails, Angular, and the like. Often these people built their own (albeit less powerful) libraries and could work much better with them.
- KronisLV 5y ago
  > Often these people built their own (albeit less powerful) libraries and could work much better with them. In my experience, if someone fails at using mainstream libraries, they will also likely fail in creating their own, at least if it is to later be used and maintained by anyone else successfully.
  - k__ 5y ago
    I don't know about that. The problem with mainstream libraries is to grasp the mental model of their creators. I met a bunch of developers who understood software design patterns as they are taught in the GoF book, but couldn't see them when applied in a framework/library. Often this was because the design patterns weren't used 1:1 or framework creators simply used the wrong name for a pattern.
aszen 5y ago
This is a common argument i have seen devs make when evaluating building from scratch vs adoption, here's what building from scratch gives you, a leaner more understandable piece of code that does what you want and nothing more. An open source library is necessarily generic and has to be battle tested to make sure it fulfills all use cases, while the library you write only has to cover your own needs that makes it easier to understand, extend and debug
- xupybd 5y ago
  Not to mention when the language you are using updates and you have to update the code. If the 3rd party library is no longer maintained you have to upgrade the library yourself. It's much nicer if it's a small bit of code you wrote with only the use cases you need.
aszen 5y ago
as an example i made a firebase auth client in elm using their api and json decoders in elm. honestly i feel it's much better than the official js client for the app i was building because it's so focused, minimal and exactly suited to my app's architecture
pkolaczk 5y ago
Often you don't need to reimplement 100% of functionality of a library but just a 1% of it. Then, a talented team can usually make that 1% higher quality just because they are not limited by the complexity and tradeoffs added by the remaining 99%. Also many "battle-tested" libraries are not really very high quality - they all have bugs, unnecessary complexity and technical debt. Higher degree of testing they get is often offset by the higher number of feature requests, and more features means more complexity and more bugs. And in reality I saw it many times when a niche library written by a solo developer is of a higher quality than a super popular behemoth written by hundreds of developers over 10 years.

Silhouette 5y ago

Realistically, a couple of engineers writing a library from scratch isn’t going to be higher quality than adopting a mainstream, battle-tested library that accomplishes the same thing. That's true but the vast majority of what you find on NPM is not mainstream, battle-tested libraries. Libraries that do clear that bar tend to be widely useful but that suggests generality you won't necessarily need for any single use case. A couple of good engineers might struggle to beat a well-established open source library at everything it does, but that is rarely what they are trying to achieve. They just need something that is better for their own specific needs at that time, which might be a useful and realistic target.

dimitrios1 5y ago

Once you detach from "I must use a library for every thing" land, you begin to realize you don't need the overwhelming majority of them. Which results in writing cleaner, simpler, more focused code, with less of a surface area for bugs. It's a whole mindset, tbh.

ModernMech 5y ago
I appreciate libraries for: - ubiquitous things, like data structures - hard to get right things, like time - implementations of specs, like Unicode - hardware interfaces, like CUDA For everything else, I'll take the above and roll my own solution.
- dimitrios1 5y ago
  except for the last one, all of those should be part of the language you are using, and well thought out + researched. I guess I should have been more specific: third party dependencies.
  - scotttrinh 5y ago
    In this specific case (Elm vs. JavaScript) We're talking about JavaScript here, so: > - ubiquitous things, like data structures There are a few basic data structures in JS, but almost everything else is in user-land. > - hard to get right things, like time Date is a notoriously bad API in JavaScript. - implementations of specs, like Unicode We just get a String type in JavaScript which is UTF-16, so...
    - dimitrios1 5y ago
      > We're talking about JavaScript here, so: Well, no, we aren't. We are talking about the Elm language, which compiles to JavaScript. There are also other excellent languages that target JavaScript that have these things.
- alephu5 5y ago
  What about something tedious and ubiquitous, such as swapping between camel and snake case?
  - PhineasRex 5y ago
    This is exactly the case where you don't need a library. This is a single function (or two) and you can easily translate an existing code example into the language you're using in a few minutes and be done with it.

k__ 5y ago

But...! I've also seen many developers for years adopting mainstream libraries and frameworks wrongly. The atrocities I've seen built with Ember, Rails, Angular, and the like. Often these people built their own (albeit less powerful) libraries and could work much better with them.

KronisLV 5y ago
> Often these people built their own (albeit less powerful) libraries and could work much better with them. In my experience, if someone fails at using mainstream libraries, they will also likely fail in creating their own, at least if it is to later be used and maintained by anyone else successfully.
- k__ 5y ago
  I don't know about that. The problem with mainstream libraries is to grasp the mental model of their creators. I met a bunch of developers who understood software design patterns as they are taught in the GoF book, but couldn't see them when applied in a framework/library. Often this was because the design patterns weren't used 1:1 or framework creators simply used the wrong name for a pattern.

aszen 5y ago

This is a common argument i have seen devs make when evaluating building from scratch vs adoption, here's what building from scratch gives you, a leaner more understandable piece of code that does what you want and nothing more. An open source library is necessarily generic and has to be battle tested to make sure it fulfills all use cases, while the library you write only has to cover your own needs that makes it easier to understand, extend and debug

xupybd 5y ago
Not to mention when the language you are using updates and you have to update the code. If the 3rd party library is no longer maintained you have to upgrade the library yourself. It's much nicer if it's a small bit of code you wrote with only the use cases you need.

aszen 5y ago

as an example i made a firebase auth client in elm using their api and json decoders in elm. honestly i feel it's much better than the official js client for the app i was building because it's so focused, minimal and exactly suited to my app's architecture

pkolaczk 5y ago

Often you don't need to reimplement 100% of functionality of a library but just a 1% of it. Then, a talented team can usually make that 1% higher quality just because they are not limited by the complexity and tradeoffs added by the remaining 99%. Also many "battle-tested" libraries are not really very high quality - they all have bugs, unnecessary complexity and technical debt. Higher degree of testing they get is often offset by the higher number of feature requests, and more features means more complexity and more bugs. And in reality I saw it many times when a niche library written by a solo developer is of a higher quality than a super popular behemoth written by hundreds of developers over 10 years.