3 ms·

It's almost funny how he starts off the article by saying he doesn't use libraries, then shows you a function for an API call he wrote that is ~100 LOC. Had thi

It's almost funny how he starts off the article by saying he doesn't use libraries, then shows you a function for an API call he wrote that is ~100 LOC. Had this guy pulled in something like react-query, he could have written that entire hook in about 5 LOC. I'd rather write 5 lines of code using a library that I might have to replace later than write 100 line of code to future proof my function from the start.

rtsil 4y ago
And when I have to modify the code a couple of years down the road, after working on completely different codebases, I would hate my past self if he left me 100 LOC that I have then to decypher by having to remember all the context instead of the 5 lines of a well-documented library.
maxxk 4y ago
However, these 100 LOC probably could be split into an internal library function which won't change until necessary. If you use an external library (especially in JS and especially in frontend), you or your successor will have to update all these 5 LOC entries all over the code every 1-1.5 years in a non-trivial way when a new major version arrives. For example, the migration guide for react-query: https://tanstack.com/query/v4/docs/guides/migrating-to-react-query-4 https://tanstack.com/query/v4/docs/guides/migrating-to-react...
- bartaxyz 4y ago
  That's why you can use fixed library versions to make sure nothing changes. If you need to update something in the library, you can apply a patch and keep going.
serjester 4y ago
It’s funny he mentions most libraries being written by junior developers looking to beef up their resume. Even if we assume this is true, you’ll get some other junior developer writing the same functionality at your company. Except now they have no tangible incentive to write maintainable code.
drainyard 4y ago
Are you suggesting that 100 LOC is a lot to maintain? If the implementation was something like several thousands it would be a different story, but 100 LOC is a few functions as seen in the article. I think there is a lot of merit to not using libraries. It might be a bit too strong to have a principle to never use libraries, but there are many libraries that provide way more than most projects need. Also, who cares about future proofing for some unknow future. Write what solved the problem and then if another problem arises in the future - solve it then.

rtsil 4y ago

And when I have to modify the code a couple of years down the road, after working on completely different codebases, I would hate my past self if he left me 100 LOC that I have then to decypher by having to remember all the context instead of the 5 lines of a well-documented library.

maxxk 4y ago

However, these 100 LOC probably could be split into an internal library function which won't change until necessary. If you use an external library (especially in JS and especially in frontend), you or your successor will have to update all these 5 LOC entries all over the code every 1-1.5 years in a non-trivial way when a new major version arrives. For example, the migration guide for react-query: https://tanstack.com/query/v4/docs/guides/migrating-to-react-query-4 https://tanstack.com/query/v4/docs/guides/migrating-to-react...

bartaxyz 4y ago
That's why you can use fixed library versions to make sure nothing changes. If you need to update something in the library, you can apply a patch and keep going.

serjester 4y ago

It’s funny he mentions most libraries being written by junior developers looking to beef up their resume. Even if we assume this is true, you’ll get some other junior developer writing the same functionality at your company. Except now they have no tangible incentive to write maintainable code.

drainyard 4y ago

Are you suggesting that 100 LOC is a lot to maintain? If the implementation was something like several thousands it would be a different story, but 100 LOC is a few functions as seen in the article. I think there is a lot of merit to not using libraries. It might be a bit too strong to have a principle to never use libraries, but there are many libraries that provide way more than most projects need. Also, who cares about future proofing for some unknow future. Write what solved the problem and then if another problem arises in the future - solve it then.