Because I think in objects (non-strictly related groups of data and methods) and it’s natural to how my business processes work. Light OOP creates neither translation nor maintenance layers to it. See https://news.ycombinator.com/item?id=41808034
I'm guessing JS wasn't your first language
Good intuition. My first language was basic, 8080 asm, x86 asm, pascal, C, perl, python, haskell (most useless), lua, objc. Js/ts is only a recent addition, so I might have missed some fashion ideas.
Tongue in cheek aside, if you’re an old dev, there’s nothing you have to listen to because you can see whether you have a problem yourself and decide for yourself. You can be your own advisor. I see both “classes” and “just functions” ways clearly and can convert my current codebases in my mind between these two. Nothing really changes for the latter, apart from bulky import sections, lots of * as ident imports, context-arg passing and few dispatch points. Objects (non-strictly related groups of data and methods) still exist and hold refs to event/callback emitters. So my reasoning isn’t why, my reasoning is why not. I have a tool, I have a business logic, pen pineapple apple pen. Don’t overthink it is my main principle.
Do I need to introduce composition? Do I have it already? How is it better than what I’m doing? Is it? What am I missing? What are they missing? What if they don’t? What if we speak of different things? These are the questions of a restless butt that cannot find rest on any stool. Instead it should ask: Do I have a problem?
Thanks, this added to my standard low-level experiments in a new language. The most interesting (or should I say well thought-through and at the same time tricky) part of js is how prototypes and properties work. Rarely a language has a similar complexity at that level, but I started to respect it the second I’ve got an overview, cause it addresses well the pain points that simpler designs usually have.
That said, for me it’s hard to buy into his arguments, in a sense that it doesn’t matter that much, if at all. instanceof doesn’t work for different realms and is nuanced for direct prototyping and Object.create(), but I never use or care about these in my code, by design. There’s no way that such value could appear in a false-negative instanceof comparison, so. A similar thing happens in COM/OLE integrated runtimes, where you have to be careful with what quacks like a date or a string but is neither due to a wrapper. But that’s expected.
I believe the real issue here is that iframes/etc usually get served as “some values aren’t, so use X, be careful” rather than “guys it’s an effing wrapper to an effing different runtime, which we found to be an overall anti-pattern many years ago”. Browsers and webguys normalized it, well, they normalized many crazy stuff. Not my problem. There’s no need to learn to balance on two chairs when it’s not what you do when sober. I still use Array.isArray(), but only because every linter out there annoys you to hell into it.
Tldr: classes are neat you can pry them from my cold dead hands.
The only thing to care about with classes is to not fall into the inheritance trap, and not for the reasons of instanceof. Inheritance is a tree of ladders attached with a duct tape, you have to know what you’re trying to do to your design before thinking about it. Most sane use of inheritance is one-off from a library to a user (two separate developing agents agree on an implied behavior, “I implemented it for you to randomly extend and pass back” mode), or for helping type inference. Otherwise, a way to go is to eject a common behavior into a separate class or a couple of functions (aka composition).
Hello JS was my first language and I use classes because sometimes it seems like the obvious way to model things.
Looking through the source of Replicache, here are some classes we use:
- KVStore
- DAGStore
- Transaction
I mean ... I can of course model these w/o classes, but encapsulating the state and methods together feels right to me. Especially when there is private state that only the methods should manipulate.
We use composition all over the place and rarely use inheritance so I don't think it's just some deficiency of knowledge .
Pre JS classes, the js community emulated classes w/ the prototype chain and that's what I'd have done for these classes if real JS classes weren't available.
Honestly, all this “emulated with prototypes” meme is misleading. Prototypes are an implementation of what they’ve called “binding” before (some may recognize “early” and “late” in this context). That’s how classes work and what classes are. The fact that some gears got exposed to a user [to stick their fingers into] doesn’t change much.
So no, javascript didn’t really “add classes”. It just had a very annoying lower-level syntax for them from the beginning and fixed it after a while. It wouldn’t survive the pressure if it had no classes at all cause this idea is fundamental to programming and to how we think: you-do.
One may pretend to not have classes through closures, but technically that’s just classes again, cause you have a bunch of functions with a shared upvalue block. You just hold it the other way round lexically, by a method instead of a context.
I believe this common idea of alienating classes stems from the general OOP stigma since the times of “design patterns”.
I'm guessing JS wasn't your first language
Good intuition. My first language was basic, 8080 asm, x86 asm, pascal, C, perl, python, haskell (most useless), lua, objc. Js/ts is only a recent addition, so I might have missed some fashion ideas.
Tongue in cheek aside, if you’re an old dev, there’s nothing you have to listen to because you can see whether you have a problem yourself and decide for yourself. You can be your own advisor. I see both “classes” and “just functions” ways clearly and can convert my current codebases in my mind between these two. Nothing really changes for the latter, apart from bulky import sections, lots of * as ident imports, context-arg passing and few dispatch points. Objects (non-strictly related groups of data and methods) still exist and hold refs to event/callback emitters. So my reasoning isn’t why, my reasoning is why not. I have a tool, I have a business logic, pen pineapple apple pen. Don’t overthink it is my main principle.
Do I need to introduce composition? Do I have it already? How is it better than what I’m doing? Is it? What am I missing? What are they missing? What if they don’t? What if we speak of different things? These are the questions of a restless butt that cannot find rest on any stool. Instead it should ask: Do I have a problem?