First off, there's just the whole lack of OOP. What do you do if you're coding in an OOP language and the library you're using does maybe 98% of what you need it to do? Oh, you just subclass the class which has the part you want to change, override a property or method or two, and use that instead (presuming the library authors weren't jackasses who abused final). But in JavaScript libraries, there's no OOP so there's no subclassing, and there's a pretty good chance the authors have done something obnoxious like wrap the whole damn thing in JS's weird giant closures anyway, so you can't even do the foo._bar = foo.bar; foo.bar = function() { foo._bar(); //other stuff }; hack. Now another solution could be to just fork the code and hack it and then just use my private fork, but see below.
I'm not sure what libraries you're using where you absolutely
have to extend out an entire class. If you were, that would indicate the library in particular is poorly written. In any language, extending a third-party library class not designed for it is, by all means, a bad idea, and it's going to be the first thing to break if the maintainer updates an internal part of their library that wasn't meant to be touched by the API consumer.
"Extend this class" is not the be-all-end-all for OOP; it is far more nuanced than that. Libraries with good OOP design, especially JS ones, will make use of dependency inversion to separate the library into domains that communicate over interfaces. Good libraries will make it very easy to swap the built-in functionality out as modules, rather than overriding the entire thing.
I'd love to see what libraries you're having trouble with and why, because I don't remember the last time I've had to wrestle one to do what I want. What you are using is either programmed by an idiot, or it hasn't been touched for a dozen years.
Second, Node.js has so taken over the JS ecosystem that I think JS library authors have forgotten that there are people out there who are still only interested in using their code client-side. Instructions will generally start with an npm command, and code samples will start with a few require() calls. Instructions relevant to client-side use are often included as a seeming afterthought if they're included at all, so sometimes I have to try to "port" the Node instructions and code to something I can actually use. It's frustrating. And as it turns out, the "dist" files for client-side use have been transpiled from the Node code, so I can't even tweak the code without installing Node.js and then learning how to code in it, which I'd rather not do. Now this wouldn't be so much of a problem if I were just able to subclass the parts I wanted to change and be able to tweak them with my own standard client-side coding style, but see above.
What this tells me is that you're stuck in the 2000s Javascript development environment. You're missing out on several things by sticking with it:
- compile-to-JS languages, especially TypeScript, which make writing large projects far more bearable
- something actually resembling dependency management
- actually being able to write several files and organise them over a directory structure, without even needing to think about the includes of your html doc
- unit/e2e testing to make sure your stuff still works after changes
- a pipeline to bundle up your several JS scripts into a single .js file, automatically minifying the contents, including your third-party libs, and applying polyfills for various browser quirks in the process
- only actually building what you need, since only the imported parts of a library will make it into a bundled .js
- local build services that reload your changes live
- probably some other things
You don't really need much to learn how to "code" in Node, you already know the language and it isn't too taxing to get an old-school web frontend building through webpack. It's flexible enough that you can make gradual changes here and there until it looks like a typical node project.
Honestly, take some time to figure out how to port something you've written to webpack. It's far nicer than micromanaging a list of <
script src=
I meant it to refer to both the conditional and also the executed code, sort of like:
