> i don't have to rewrite major swaths of code because somebody else decided to change the abstraction.
You also could solve this concern by using an existing library, then simply not upgrade when new versions come out. After all, if you can write it all yourself, surely you also could fork from your starting version if you ever need a change?
I look at it similarly to how I buy a bicycle. Sure, I could buy all the individual parts and assemble my own bike. Or I can buy a complete bike that is close to what I want, then update a part here and there as needed. After all, the goal is to ride the bike, not spend all my time tinkering with parts in my garage.
Same with code - sure, I could write it all myself. Or I can use existing work to skip all that, and focus on just what my product needs. And still dive deep and make changes when the business needs the change.
It's going to depend a lot on how the library is designed and how much of its functionality I need.
I am very skeptical about adopting a library because of all the reasons you listed but I am quite happy to adopt one when I see it's been stable and designed well.
What I'm looking for is a well tested library with a clean interface that doesn't look impenetrable when I look at its source. If the source looks a bit like something I might write, then at least I feel confident I can figure out an issue on my own when I hit a wall.
It's a judgement call, it just depends on where you draw the line. You're not writing ALL your code with just vanilla Typescript.
I use Ruby, I don't write all my code in vanilla Ruby.
But I definitely agree that blindly pulling in a library just because it looks like it makes your problem simpler RIGHT NOW, is a bad instinct.
I've done a little of both, first learning to write raw HTML in Perl and then (a long time later) becoming a frontend-focused JS dev. I loved Angular 1 (it was kinda like an early Next.js without the SSG), and for all the hate it gets here, I learned to love the actual Next.js later on too.
I've worked on a variety of small code bases, and one hard truth I've come to learn is that everybody loves their own homebrewed code, and hates everyone else's.
The thing about the big frameworks is that they at least follow some basic testing & documentation procedures, which homebrewed stuff very rarely does in the real world. Homebrewed code can be a real headache for anyone else to maintain unless you go very far out of your way to abstract its functions and document the hell out of everything (in which case, really, you're just writing another framework).
If you don't do that and just code like a regular person (i.e. make a website for your own one-off use instead of for long-term maintainability by other people who you'll never meet), it gets tricky for anyone who inherits that. It's fine if you're a founder-operator of your software company and plan on sticking around for a while and can guide newbies around your codebase. But every job I've gotten was because someone else quit their job, leaving behind a messy codebase that I was tasked with maintaining (and usually rewriting in whatever the popular framework of the day happens to be). Something like that takes days of reverse engineering to even begin to understand how it works (especially if they invented their own routing/templating/caching/building system, or even worse, if they decided to tackle state on their own, by injecting things into `window` or modifying the DOM with data attributes and such). Along the way I'll often find a mix of clever hacks, ugly hacks, and just plain mistakes that they made because they thought they were being clever. And mind you, I'm not an especially good dev, just a mediocre one who's had a few decades of experience. Newbies and juniors especially struggle with a codebase like that.
By contrast, the main advantage of adopting a popular framework isn't necessarily that it saves you a bit of time over writing your own abstractions (which it does), but that it's really easy to get new devs started on it. There are standard conventions for most basic things, and when in doubt, they can look up the documentation and examples on their own. A relatively junior dev can find the right file in a few minutes, start editing it easily since all the built-in functions are documented and tooltipped (either in Typescript or JSDoc), there's built-in tests and warnings and a preview server with hot reload, etc. The devex is usually far superior (nowadays, at least... wasn't the case 5-6 years ago certainly), especially compared to a bunch of homebrewed code that's separate from the local hosting environment, whose creator gave no thought to reproducible hosting/local dev environments.
I also don't agree that frameworks are shorter-lived than web standards. I've been a web dev since the 1990s, and have never seen web standards really be, well, standards. They've always just been mere suggestions/guardrails at best, and it's the big browser makers who dictate what works and what doesn't. Back then, we had IE and Netscape and Phoenix, ACID tests for CSS, and various incompatible frontend languages (VBScript, Javascript, JScript, Java, Shockwave, ActiveX, etc.) These days we have CanIUse and polyfills, but the bleeding-edge stuff is still incompatible, with Chrome basically dictating what is "real" and Safari and Firefox playing catchup eventually, sometimes, but not always... like WebGPU, JPEG XL, or WEBP/AVIF a while ago. The frameworks account for things like that (among other things) and transparently polyfill them and provide higher-level abstractions. And keep in mind that the standards body itself was completely abandoned: the W3C, after many failed attempts at improving web standards, gave up and went on to more esoteric things like the semantic web, leaving the "real" de facto standards to be dictated by... well, the browser makers (via WHATWG). So we're right back where we started, with browsers dictating what works and doesn't work on the web, and each browser having their own interpretation.
By contrast, how long has Wordpress been around now? Or MediaWiki? I was paid to maintain Drupal just a few years ago. jQuery is still popular, despite whatever ECMAScript version we're now on. Rails is still around in that long tail of smaller company backends.
I would 100% bet on popular frameworks sticking around longer, being easier to maintain, and and usually being easier to upgrade later, than some individual or organization's homebrewed code.
> i don't have to rewrite major swaths of code because somebody else decided to change the abstraction.
You also could solve this concern by using an existing library, then simply not upgrade when new versions come out. After all, if you can write it all yourself, surely you also could fork from your starting version if you ever need a change?
I look at it similarly to how I buy a bicycle. Sure, I could buy all the individual parts and assemble my own bike. Or I can buy a complete bike that is close to what I want, then update a part here and there as needed. After all, the goal is to ride the bike, not spend all my time tinkering with parts in my garage.
Same with code - sure, I could write it all myself. Or I can use existing work to skip all that, and focus on just what my product needs. And still dive deep and make changes when the business needs the change.
It's going to depend a lot on how the library is designed and how much of its functionality I need.
I am very skeptical about adopting a library because of all the reasons you listed but I am quite happy to adopt one when I see it's been stable and designed well.
What I'm looking for is a well tested library with a clean interface that doesn't look impenetrable when I look at its source. If the source looks a bit like something I might write, then at least I feel confident I can figure out an issue on my own when I hit a wall.
It's a judgement call, it just depends on where you draw the line. You're not writing ALL your code with just vanilla Typescript.
I use Ruby, I don't write all my code in vanilla Ruby.
But I definitely agree that blindly pulling in a library just because it looks like it makes your problem simpler RIGHT NOW, is a bad instinct.
in large apps with tens of thousands of users per day, one of two things will happen with the library:
it's being used in part of the app no one updates, so the old version of the library will continue being used for years
it'll get immediately updated to the new version, and folks will continue building features on it
Do you have a template or boilerplate for new projects?
Looking at this one at the moment:
https://github.com/CreativeTechGuy/ReactTemplate
A contrary opinion:
I've done a little of both, first learning to write raw HTML in Perl and then (a long time later) becoming a frontend-focused JS dev. I loved Angular 1 (it was kinda like an early Next.js without the SSG), and for all the hate it gets here, I learned to love the actual Next.js later on too.
I've worked on a variety of small code bases, and one hard truth I've come to learn is that everybody loves their own homebrewed code, and hates everyone else's.
The thing about the big frameworks is that they at least follow some basic testing & documentation procedures, which homebrewed stuff very rarely does in the real world. Homebrewed code can be a real headache for anyone else to maintain unless you go very far out of your way to abstract its functions and document the hell out of everything (in which case, really, you're just writing another framework).
If you don't do that and just code like a regular person (i.e. make a website for your own one-off use instead of for long-term maintainability by other people who you'll never meet), it gets tricky for anyone who inherits that. It's fine if you're a founder-operator of your software company and plan on sticking around for a while and can guide newbies around your codebase. But every job I've gotten was because someone else quit their job, leaving behind a messy codebase that I was tasked with maintaining (and usually rewriting in whatever the popular framework of the day happens to be). Something like that takes days of reverse engineering to even begin to understand how it works (especially if they invented their own routing/templating/caching/building system, or even worse, if they decided to tackle state on their own, by injecting things into `window` or modifying the DOM with data attributes and such). Along the way I'll often find a mix of clever hacks, ugly hacks, and just plain mistakes that they made because they thought they were being clever. And mind you, I'm not an especially good dev, just a mediocre one who's had a few decades of experience. Newbies and juniors especially struggle with a codebase like that.
By contrast, the main advantage of adopting a popular framework isn't necessarily that it saves you a bit of time over writing your own abstractions (which it does), but that it's really easy to get new devs started on it. There are standard conventions for most basic things, and when in doubt, they can look up the documentation and examples on their own. A relatively junior dev can find the right file in a few minutes, start editing it easily since all the built-in functions are documented and tooltipped (either in Typescript or JSDoc), there's built-in tests and warnings and a preview server with hot reload, etc. The devex is usually far superior (nowadays, at least... wasn't the case 5-6 years ago certainly), especially compared to a bunch of homebrewed code that's separate from the local hosting environment, whose creator gave no thought to reproducible hosting/local dev environments.
I also don't agree that frameworks are shorter-lived than web standards. I've been a web dev since the 1990s, and have never seen web standards really be, well, standards. They've always just been mere suggestions/guardrails at best, and it's the big browser makers who dictate what works and what doesn't. Back then, we had IE and Netscape and Phoenix, ACID tests for CSS, and various incompatible frontend languages (VBScript, Javascript, JScript, Java, Shockwave, ActiveX, etc.) These days we have CanIUse and polyfills, but the bleeding-edge stuff is still incompatible, with Chrome basically dictating what is "real" and Safari and Firefox playing catchup eventually, sometimes, but not always... like WebGPU, JPEG XL, or WEBP/AVIF a while ago. The frameworks account for things like that (among other things) and transparently polyfill them and provide higher-level abstractions. And keep in mind that the standards body itself was completely abandoned: the W3C, after many failed attempts at improving web standards, gave up and went on to more esoteric things like the semantic web, leaving the "real" de facto standards to be dictated by... well, the browser makers (via WHATWG). So we're right back where we started, with browsers dictating what works and doesn't work on the web, and each browser having their own interpretation.
By contrast, how long has Wordpress been around now? Or MediaWiki? I was paid to maintain Drupal just a few years ago. jQuery is still popular, despite whatever ECMAScript version we're now on. Rails is still around in that long tail of smaller company backends.
I would 100% bet on popular frameworks sticking around longer, being easier to maintain, and and usually being easier to upgrade later, than some individual or organization's homebrewed code.