7 ms·

> Don’t use (almost) any libraries I will not hire someone who holds this view, straight up. It's the only technical belief (aside from crazy things like don'

> Don’t use (almost) any libraries I will not hire someone who holds this view, straight up. It's the only technical belief (aside from crazy things like don't care about quality) I can think of that would instantly disqualify a candidate in my mind. Everything else feels negotiable and perspective-relevant, but not this. It's such a massive waste of time to try and rewrite functionality that already exists elsewhere, and an inability to trust other people is a huge, bright red flag when it comes to working with others on the team. Being very selective of which libraries you use? Sure, fair. We can talk about various lines and where to draw them, but categorically denying library use? That's unacceptable.

nkozyra 4y ago
Plus "Most libraries are crap, they are written by junior developers." is nonsense and cannot be validated. I definitely agree with being conservative about what you use but writing almost everything yourself is a disaster waiting to happen.
- asaph 4y ago
  Sturgeon’s Law[0] states that “90 percent of everything is crap.” [0] https://en.m.wikipedia.org/wiki/Sturgeon%27s_law https://en.m.wikipedia.org/wiki/Sturgeon%27s_law
andrewmcwatters 4y ago
Most React development is comprised of using React and Fetch.
- eyelidlessness 4y ago
  Weird. From my perspective most React development is comprised of finding the most expressive way to use Algebraic Effects where the language wasn’t designed for it
  - Gravyness 4y ago
    Don't worry there's a library for that. Probably. And it might or might not have performance issues and odd behavior but that's for the next developer to solve.
- kupopuffs 4y ago
  surely not. how do you bundle it?
  - andrewmcwatters 4y ago
    In the before time, the long long ago, developers didn't need to bundle everything. Mythical, I know.
    - kupopuffs 4y ago
      no. they had to link it with standard libaries/binaries which were... bundled with your OS
kreeben 4y ago
I'm not a junior, I also wasn't born yesterday. To all juniors out there, I would lovingly want to tell you this: Don't ever work for jerks. Yes, sure, it might seem like it's a great way to further your career. But then, one blissful corporate day you find that you've been working for the dark side all along and you'll soon regret it. Don't ever work for assholes. Don't ever work for people who thinks depending on crapware is a good thing. These are not good people.
- smt88 4y ago
  I would tell juniors not to work for people who refuse to use libraries in JavaScript. You just can't do that and be productive. You'd have to build a standard lib from scratch, including unit tests. There are lots of bad JS libraries but there are also some good ones that are mature, well-tested, and supported. Refusing to use them is a waste of time and money. In the context of security, it's also professional malpractice.
  - BigJono 4y ago
    This thread is the biggest crock of shit. It's a blog post about React, he's obviously not saying "don't use literally any libraries whatsoever". The vast majority of libs that sit on top of React are completely useless time wasters that cost you more in dev time in the long run than writing it yourself. Just React, CSS and the Chrome dev tools is more "power" than like 99% of dev environments that have ever existed. The fact so many garbage front enders think you need to pile 80 more dependencies on top of the bog standard stuff is a joke. Avoiding libraries as a default and knowing when to make an exception is the most important part of being a front end dev these days. Reaching for libraries as a default solution to any problem (which is what 90% of FE devs do) is a great way to fuck up every project you're on.
    - rozap 4y ago
      There is a huge class of people that aren't capable (either they're too junior or lack the ability or motivation) of writing core functionality themselves, and are only able to stitch libraries together. Is the stuff they create painful to use? Generally yea. Does it create enormous technical debt for the rest of the team? Yep. But does it tick feature boxes that people pay money for? Also yea. I think for those folks, "prefer writing your own 'ReactFlyout' module" is literally not a path forward. Like it or not, those folks make up a large portion of the work force. There are software organizations that live by a "prefer renting and buying over building it" tenet, for the same reasons that outsourcing made sense to the MBA types. But when you all of a sudden need to render a button differently, or a service goes down, they refuse to take any responsibility for the mess.
eyelidlessness 4y ago
As someone who spends an inordinate amount of time actually vetting libraries I might use actually reading their source and getting a sense of their activity and response to feedback, and by seriously considering whether I’d be better off duplicating their efforts: I agree wholeheartedly. For folks who don’t agree wholeheartedly, I’d highly recommend spending the time to read through libraries you’d instinctively reject. It’s incredibly eye opening. The stuff you’d reject anyway is almost always easy to spot. The stuff you’d make an exception for is almost always an educational experience about the complexities of what the particular library solves, and may give you insight into its domain or a very sound warning you don’t have or want to wander into its domain.
- kreeben 4y ago
  I disagree with you, wholeheartedly. One of the problems you are facing is code quality, which you've eloquently solved by code review (LOL), but the other, more burning matter is, you are no longer in control of your own software. -- hey now, I DID actually read all the code we brought in I mean, sure, that's a possibility. I don't believe you, but that's besides the point. The point, being, and here's a news flash for you corporate peps out there who love to "manage my team of peps using stuff I learned from someone I talked to at a bar"... Nothing is free in this world, not even code. The shortcuts you are making aren't really shortcuts. Instead, they will become your doom.
  - eyelidlessness 4y ago
    > you are no longer in control of your own software I don’t own any software. To the extent I ever have, I rescind my copyright. There. No more problems!
  - EddySchauHai 4y ago
    How do you find work when you only use your own bootstrapped language on your own OS using your own FPGA board? And do you find difficulties getting your colleagues to use your own VCS? /s In all seriousness I get your point, code supply chains are volatile beasts that can blow up, but it's the only realistic way to write code nowadays. You can reduce external libraries and tools as a tradeoff for time/cost or you can fork tools to host yourself, etc... These are all tradeoffs that shouldn't be seen in black and white!
lmeyerov 4y ago
default-deny of libraries is probably a good rule of thumb for writing maintainable react code. i'm not sure we'd reject hiring someone who doesn't understand why, but it's something senior folks should learn after maintaining enough oss code in the relevant oss ecosystems, and if someone hasn't, we'd catch+teach as part of standard SDLC. tools like snyk.io overviews of most packages show why so many are landmines you're planting, not time savers. if you've never felt that pain... that's interesting. it's odd to not be hit by their issues when things like major upgrades happen (every year or two, right, else you're outside of LTS windows!), routine scans+penchecks, and other aspects of writing code that isn't going to destroy your customers safety + team's productivity.
EddySchauHai 4y ago
> (almost) Seems like you agree with their view?
nickstinemates 4y ago
Also funny that it's posted in an article about.. a library?
sa46 4y ago
The author did not make his point well because he immediately contradicts himself. > we don’t use libraries. The only libraries we use are where [...] I know the library will continue to be maintained. I interpreted his point more charitably as "be very selective about introducing libraries". I've had the most success with framework-agnostic, foundational libraries (tables, date-time) and with best-in-class framework libraries (state management, calendars).
rajangdavis 4y ago
From my experience with React and Next.js, limiting the amount of dependencies can make things easier as far as updating React versions without being locked into an older major version because of a dependency. I've been burned by a couple of libraries namely because they didn't handle hooks properly or were creating bugs that I couldn't understand. The conclusion the author makes (only use libraries that are well maintained by a known team) is a pretty good heuristic for which libraries to choose.
karlshea 4y ago
Especially if they want to write a custom form library. Everyone thinks this is a good idea. It's never a good idea, there are so many different features and states forms can be in, and your homebrew thing is going to be a mess.
tracerbulletx 4y ago
Even if one had a good reason to use fewer libraries in a product, his reasoning that "most libraries are written by junior developers" is a ridiculous and somewhat insulting justification.
pcthrowaway 4y ago
See: Not Invented Here syndrome (https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here)

nkozyra 4y ago

Plus "Most libraries are crap, they are written by junior developers." is nonsense and cannot be validated. I definitely agree with being conservative about what you use but writing almost everything yourself is a disaster waiting to happen.

asaph 4y ago
Sturgeon’s Law[0] states that “90 percent of everything is crap.” [0] https://en.m.wikipedia.org/wiki/Sturgeon%27s_law https://en.m.wikipedia.org/wiki/Sturgeon%27s_law

andrewmcwatters 4y ago

Most React development is comprised of using React and Fetch.

eyelidlessness 4y ago
Weird. From my perspective most React development is comprised of finding the most expressive way to use Algebraic Effects where the language wasn’t designed for it
- Gravyness 4y ago
  Don't worry there's a library for that. Probably. And it might or might not have performance issues and odd behavior but that's for the next developer to solve.
kupopuffs 4y ago
surely not. how do you bundle it?
- andrewmcwatters 4y ago
  In the before time, the long long ago, developers didn't need to bundle everything. Mythical, I know.
  - kupopuffs 4y ago
    no. they had to link it with standard libaries/binaries which were... bundled with your OS

kreeben 4y ago

I'm not a junior, I also wasn't born yesterday. To all juniors out there, I would lovingly want to tell you this: Don't ever work for jerks. Yes, sure, it might seem like it's a great way to further your career. But then, one blissful corporate day you find that you've been working for the dark side all along and you'll soon regret it. Don't ever work for assholes. Don't ever work for people who thinks depending on crapware is a good thing. These are not good people.

smt88 4y ago
I would tell juniors not to work for people who refuse to use libraries in JavaScript. You just can't do that and be productive. You'd have to build a standard lib from scratch, including unit tests. There are lots of bad JS libraries but there are also some good ones that are mature, well-tested, and supported. Refusing to use them is a waste of time and money. In the context of security, it's also professional malpractice.
- BigJono 4y ago
  This thread is the biggest crock of shit. It's a blog post about React, he's obviously not saying "don't use literally any libraries whatsoever". The vast majority of libs that sit on top of React are completely useless time wasters that cost you more in dev time in the long run than writing it yourself. Just React, CSS and the Chrome dev tools is more "power" than like 99% of dev environments that have ever existed. The fact so many garbage front enders think you need to pile 80 more dependencies on top of the bog standard stuff is a joke. Avoiding libraries as a default and knowing when to make an exception is the most important part of being a front end dev these days. Reaching for libraries as a default solution to any problem (which is what 90% of FE devs do) is a great way to fuck up every project you're on.
  - rozap 4y ago
    There is a huge class of people that aren't capable (either they're too junior or lack the ability or motivation) of writing core functionality themselves, and are only able to stitch libraries together. Is the stuff they create painful to use? Generally yea. Does it create enormous technical debt for the rest of the team? Yep. But does it tick feature boxes that people pay money for? Also yea. I think for those folks, "prefer writing your own 'ReactFlyout' module" is literally not a path forward. Like it or not, those folks make up a large portion of the work force. There are software organizations that live by a "prefer renting and buying over building it" tenet, for the same reasons that outsourcing made sense to the MBA types. But when you all of a sudden need to render a button differently, or a service goes down, they refuse to take any responsibility for the mess.

eyelidlessness 4y ago

As someone who spends an inordinate amount of time actually vetting libraries I might use actually reading their source and getting a sense of their activity and response to feedback, and by seriously considering whether I’d be better off duplicating their efforts: I agree wholeheartedly. For folks who don’t agree wholeheartedly, I’d highly recommend spending the time to read through libraries you’d instinctively reject. It’s incredibly eye opening. The stuff you’d reject anyway is almost always easy to spot. The stuff you’d make an exception for is almost always an educational experience about the complexities of what the particular library solves, and may give you insight into its domain or a very sound warning you don’t have or want to wander into its domain.

kreeben 4y ago
I disagree with you, wholeheartedly. One of the problems you are facing is code quality, which you've eloquently solved by code review (LOL), but the other, more burning matter is, you are no longer in control of your own software. -- hey now, I DID actually read all the code we brought in I mean, sure, that's a possibility. I don't believe you, but that's besides the point. The point, being, and here's a news flash for you corporate peps out there who love to "manage my team of peps using stuff I learned from someone I talked to at a bar"... Nothing is free in this world, not even code. The shortcuts you are making aren't really shortcuts. Instead, they will become your doom.
- eyelidlessness 4y ago
  > you are no longer in control of your own software I don’t own any software. To the extent I ever have, I rescind my copyright. There. No more problems!
- EddySchauHai 4y ago
  How do you find work when you only use your own bootstrapped language on your own OS using your own FPGA board? And do you find difficulties getting your colleagues to use your own VCS? /s In all seriousness I get your point, code supply chains are volatile beasts that can blow up, but it's the only realistic way to write code nowadays. You can reduce external libraries and tools as a tradeoff for time/cost or you can fork tools to host yourself, etc... These are all tradeoffs that shouldn't be seen in black and white!

lmeyerov 4y ago

default-deny of libraries is probably a good rule of thumb for writing maintainable react code. i'm not sure we'd reject hiring someone who doesn't understand why, but it's something senior folks should learn after maintaining enough oss code in the relevant oss ecosystems, and if someone hasn't, we'd catch+teach as part of standard SDLC. tools like snyk.io overviews of most packages show why so many are landmines you're planting, not time savers. if you've never felt that pain... that's interesting. it's odd to not be hit by their issues when things like major upgrades happen (every year or two, right, else you're outside of LTS windows!), routine scans+penchecks, and other aspects of writing code that isn't going to destroy your customers safety + team's productivity.

EddySchauHai 4y ago

> (almost) Seems like you agree with their view?

nickstinemates 4y ago

Also funny that it's posted in an article about.. a library?

sa46 4y ago

The author did not make his point well because he immediately contradicts himself. > we don’t use libraries. The only libraries we use are where [...] I know the library will continue to be maintained. I interpreted his point more charitably as "be very selective about introducing libraries". I've had the most success with framework-agnostic, foundational libraries (tables, date-time) and with best-in-class framework libraries (state management, calendars).

rajangdavis 4y ago

From my experience with React and Next.js, limiting the amount of dependencies can make things easier as far as updating React versions without being locked into an older major version because of a dependency. I've been burned by a couple of libraries namely because they didn't handle hooks properly or were creating bugs that I couldn't understand. The conclusion the author makes (only use libraries that are well maintained by a known team) is a pretty good heuristic for which libraries to choose.

karlshea 4y ago

Especially if they want to write a custom form library. Everyone thinks this is a good idea. It's never a good idea, there are so many different features and states forms can be in, and your homebrew thing is going to be a mess.

tracerbulletx 4y ago

Even if one had a good reason to use fewer libraries in a product, his reasoning that "most libraries are written by junior developers" is a ridiculous and somewhat insulting justification.

pcthrowaway 4y ago

See: Not Invented Here syndrome (https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here)