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.
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.
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.
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!
>> it's the only realistic way to write code nowadays
That's repulsive.
You could hold that position, if you wanted to, because the world seems that way, doesn't it? But i don't believe even for a fraction of a second, that you are right to say so.
We're discussing React in this thread, are we not? What's the name of that fallacy where you put emphasis on a whole other topic, so that your point still stands?
I was actually talking about code in general but then I threw the wrong card at you, because you had me cornered and I panicked. Please accept my apologies.
But I'm still in the right and you're still in the wrong. Because what you are saying is "my disciples, go into the night and depend on whatever you may, because depending on things is the way, for I will be rich if you do."
Taken to an extreme, this must also mean you only use code you write yourself, since your coworkers will probably not be able to code up to your standards. You are eternally reinventing the wheel, and missing the opportunity to work on the actual feature/app in a timely way.
If this just means being selective about dependencies, I'm sure most of us here will agree.
No, what I mean is, you, good sir or madam, is intentionally straw manning what I said in order to make it OK, in your mind, to have people depend on black boxes ("nmp packages") because that would make your boss happier.
I know this is not exactly what you said, I'm taking it to an extreme to show that relying on third party libs is not that different from relying on code your coworkers write.
Rejecting useful libraries because you "are not in control" means you're constantly reinventing the wheel, which means you're wasting time.
My boss doesn't care whether I use third party libs or my own code, and I bet yours doesn't either. They care about results. You simply cannot deliver if you write every piece of your stack from scratch.
>you are no longer in control of your own software.
In a business setting you have no control over what will happen with your software in the long run, and somebody else will take over for you, so this is an INCREDIBLY weak justification for not using libraries.
One of the major appeals of libraries is that the very fact you can figure out how to use them means that somebody else can. That’s something you can’t say about your own code as easily. If you don’t reuse other peoples code, how can you know the first thing about writing code other people can reuse? Not using other peoples libraries is akin to being a chef that will only eat their own food.
>> you have no control over what will happen with your software
Can you please go directly to your boss's office and tell him that you are not even close to being in control of the objectives he told you at the convention, that you should have, if you want that bonus we've been talking about?
I’m not a software god. I am unable to impose my will upon any codebase I have ever touched for eternity. I admit somebody is eventually going to rewrite and refactor and extend my shit code which was written with the curse of knowledge, minimal review, minimal testing, and never having to handle more than a narrow set of use cases. Code which may have been easier to write and more efficient than the libraries available but that is going to be thrown out when somebody has to maintain my handwritten JavaScript framework replacement and goes “what the fuck”.
Somebody who only uses their own code has awful taste in code.
This is a delightful rebuttal and I applaud you for it. I hereby withdraw any claims I might have made with regards to the topic at hand because you have clearly the upper hand on what is right and what is simply nonsense. I wish your upcoming corporate day to be a blissful one.
No, that last sentence was way to illfull. Sorry for inventing a new word. It means "full of ill".
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).
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.