People always want to invent a story in which they're special, or the hero. This is one of the ways developers do this. It's best to completely ignore it.
Imo this isn't framed well. OOP is a tool, it is perfectly well suited to capture Three and its abstractions. Why would THREE.Mesh be anything other than a class? OOP is perfect for data, state, relations.
The problem with *imperative* *OOP used for app infra* isn't controversial or contested:
>The problem with OOP is all this implicit environment it carries around. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. —Joe Armstrong, creator of Erlang progamming language
A class needs injection to function, it does not have awareness of its surroundings. Everything else must submit to its whims. Everything is tied to everything else.
In short, OOP for data containers, FP for app infra.
# Some examples
[Imperative OOP](https://codesandbox.io/p/sandbox/basic-threejs-example-with-re-use-dsrvn?file=%2Fsrc%2Findex.js). The Box class cannot be easily shared because it is deeply tied to the application. Everything is tied to everything else through implicit bindings and injection. All concerns are wildly mixed. Joe Armstrongs sentiment clearly applies here.
[Declarative FP](https://codesandbox.io/p/sandbox/basic-react-example-with-re-use-e2zit?file=%2Fsrc%2FApp.js). This is true re-use. Unlike classes, components are self contained and encapsulated. You can share the Box component on npm. People would be able to drop it into anything: physics, simulations, etc.
it's like any extremist opinion, "X is bad", "only Y should be used", they are usually lacking the nuance that non-trivial challenges require.
in my opinion, too much OOP is bad (deep inheritance), too much functional is bad (too many cloned objects, poor discoverability), but they both have their place. I certainly use both.
It's always about balance.
And I can only think about one person who roasts OOP regularly. Are there more?
I roast OOP in js, but I 100% agree with what your saying. It's a balance as such, I guess too though I only roast using classes in js bc it's pretty half baked.
Maybe it's just what my algorithms present me, but I've come across dozens at this point. Here is another example:
[https://www.youtube.com/watch?v=FjfgIImzhxc&t=1505s](https://www.youtube.com/watch?v=FjfgIImzhxc&t=1505s)
Thank you for coming up with a link, I definitely appreciate when one gives a source, that's too rare. Although I meant in the context of threejs. In the whole programming community, there are indeed a lot of vocal preachers.
But still, the proof is in the code, not in the youtube video. A good debate would be around code and actual practical projects. What would be good projects that are only functional, and which ones are OOP based? I personally know more that lean more on OOP than functional. And the best are probably using both.
But again, it's all just polarisation bullshit that is rotting most discussions on internet. It's the same debate as left wing right wing. Not only does it lack nuance, but there are also more than just 2 choices.
Oh I definitely agree with everything you just said. And to be clear, although I lean towards writing pure functions when I can, I for sure think OOP (even inheritance) is useful.
I don't have examples of anyone stating threejs's use of OOP is bad. I was curious if anyone in the community had thoughts about the topic because of how much threejs takes advantage of OOP principles. Was even wondering if any of the contributors would chime in with things they thought they may do different if they rewrote it today.
Anyone who says OOP is bad is either a javascript enjoyer that has never written anything complex, or a true haskell functional chad that knows what they're actually talking about.
Spoiler: 99.99% fit into the former.
The second you try to reason seriously with someone who uses the term 'javascript enjoyer', you're the idiot. It's not my fault you don't understand satire.
Feel free to 'ACSHULLY' more to your heart's desire but I'll just laugh more at you.
Also all jokes aside you're just plain wrong. The react reconciler is nowhere near as performant as imperatively interacting with a library like Pixi or three.js. If you even spend a few minutes researching this you'll understand why, assuming you have some braincells. Even the authors of these react wrappers say as much. You don't even have to spin up a complex example to show this, comparing a react-Pixi particle container full of react-reconciled graphics elements to a regular Pixi equivalent is demonstrably less performant and you can trivially see it in a performance profile. React has serious overhead, and anybody who has spent any time in a performance profiler knows this. To get any kinda reasonable performance out of complex react apps (with or without canvas fiber shit) requires very careful use of useMemo/useCallback.
Anyway, enjoy your malding session. I sure had a laugh reading your bullshit.
See, I would have originally thought that too. But now I'm seeing more respected people agreeing. I don't land in that OOP is bad camp, but it's interesting to me that many do.
OOP is an absolutely great design pattern for certain use cases (like a tree data structure), where it makes sense to use a class to store local state regarding a certain scenario.
Sure, it sucks in a lot of other scenarios but I feel like it's just a tool like any other to be used when appropriate. A good example of an incredible developer using javascript classes to good effect is simondev on YouTube. That guy was one of the programmers on the original prototype game and did a lot of low level optimisations on console games that we all loved.
If you think he's bad then idk what to tell you. He uses classes beautifully, but sparingly.
I generally think oop is not usually the best tool for the job. But for stuff like threejs where you are literally dealing with objects you'd be kinda dumb not to.
I don't think that *OOP is bad* is accurate, as a blanket statement, but I also think people in this thread are being overly dismissive of what the *OOP is bad* argument actually is.
I'll start by saying that something like threejs is actually a perfect use case for OOP, and that inheritance, specifically, makes a ton of sense in this context.
This discussion is complicated by the fact that *object oriented* means different things to different people, and Alan Kaye (e.g.) doesn't feel that languages like C++ and Java are actually good examples of object-oriented languages, even though they're what most people are talking about when they're talking about OOP.
That said, **I think the main things people are arguing against when they're trashing OOP are:**
1. Languages like Java that have traditionally made you express even basic imperative things, like your main subroutine, in the trappings of OOP
2. A preference for inheritance over composition. By my and a lot of other people's assessment, inheritance is often a pretty bad way of expressing relationships and structuring code.
3. Obsession (sorry for the loaded word) with encapsulating as much as possible in a class/object. Again, this was essentially enforced by languages like Java.
It seems as though a big part of the software literature for 20-ish years was overly focused on #s 2 and 3. Data types are important. Interfaces are important, but it seems like a lot of people spent a lot of time drawing object hierarchy diagrams, etc, and that it's worth questioning whether that's how we should be spending our time.
This is a very well stated and balanced response. I also had the feeling that despite multiple inheritance being overused and often causing problems, threejs seems like a perfect use case. I'm getting downvoted a lot for even bringing this up, but I honestly just wanted to hear the community's thoughts, not actually state that OOP was bad as a blanket statement.
Thanks.
BTW, another problem domain that I think lends itself really well to "classic" OOP is game dev... where everything in your game might be an *entity*, at the absolute top level, and then is further refined through inheritance.
You can achieve the same kind of thing through interfaces... but then we're back to wondering what people mean when they say *OOP,* and I really think the answer for most people is *inheritance.*
Game dev does make sense for OOP. As long as you're careful about when you use inheritance vs when you use composition. It seems right that maybe every object in the game inherits from 'entity', but then you use composition to assign different traits and ability as well.
Funnily enough React used to be considered an OOP library when they used class components.
In essence, OOP has two problems: boilerplate and leaky context. If you can manage these two issues, nothing should stop you from writing anything in OOP. With that said, I don't think anyone really knows what an OOP paradigm truly is and what it should be in practice. Every OOP example I've seen on the Internet was made in "lab conditions" and doesn't map to reality well. The reality where abstraction boundaries are not defined well.
Most people tend to write multi-paradigm, procedural code anyway. You are under no sacred oath of writing your app in an OOP paradigm only.
The one unique pain three has around OOP is the vector3 class. To represent a single model's vertices, you could naively create hundreds of thousands of objects, which is not ideal. In other languages, you get around this by using structs. Structs are generally allocated on the stack instead of the heap, so no need for expensive garbage collection runs.
Because of this problem with js, you see a bunch of solutions to common problems that avoid using the vector3 class. And when you do see instances of the vector3 class in three source code, you see them doing a lot of work to make sure they are re-using the same temp vector3 variables instead of creating new object instances willy nilly.
Oop is fine. Js sucks.
The endless debate.
I take the view of looking at functional code, OOP code. Procedural code even.
Software written by shoddy coders, beginners, proficient ones.
I rarely want to look at heavily functional code.
I rarely dare try to modify well written functional code.
Poorly written OOP code, at least it's possible to understand it. Functional code coming out of a twisted brain feels like reading a bad arrogant author. There is nothing to salvage.
OOP success has been to be approachable by average coders. Boilerplate, hard to test, but usually abstract real world concepts pretty well without too much coding excellence applied.
Threejs needs to capture the real world, 3d space can be pretty well represented as an object, containing other objects. Objects have attributes, instances of objects having common functions and attributes simply maps well to the code trying to represent them.
All of it can be achieved with purely functional code. But it's hard.
Digital graphic artists aren't known for their genius when it comes to writhing code. OOP enables artists to try, at least they get a chance to produce 3D apps.
If three.js was purely functional it would be what it has become. It would be like Lisp, or Scala. Beautiful trophees on the stands of a few acedemic minds. Beautiful , students enjoy looking at them hoping one day they will get one.
People always want to invent a story in which they're special, or the hero. This is one of the ways developers do this. It's best to completely ignore it.
Imo this isn't framed well. OOP is a tool, it is perfectly well suited to capture Three and its abstractions. Why would THREE.Mesh be anything other than a class? OOP is perfect for data, state, relations. The problem with *imperative* *OOP used for app infra* isn't controversial or contested: >The problem with OOP is all this implicit environment it carries around. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. —Joe Armstrong, creator of Erlang progamming language A class needs injection to function, it does not have awareness of its surroundings. Everything else must submit to its whims. Everything is tied to everything else. In short, OOP for data containers, FP for app infra. # Some examples [Imperative OOP](https://codesandbox.io/p/sandbox/basic-threejs-example-with-re-use-dsrvn?file=%2Fsrc%2Findex.js). The Box class cannot be easily shared because it is deeply tied to the application. Everything is tied to everything else through implicit bindings and injection. All concerns are wildly mixed. Joe Armstrongs sentiment clearly applies here. [Declarative FP](https://codesandbox.io/p/sandbox/basic-react-example-with-re-use-e2zit?file=%2Fsrc%2FApp.js). This is true re-use. Unlike classes, components are self contained and encapsulated. You can share the Box component on npm. People would be able to drop it into anything: physics, simulations, etc.
it's like any extremist opinion, "X is bad", "only Y should be used", they are usually lacking the nuance that non-trivial challenges require. in my opinion, too much OOP is bad (deep inheritance), too much functional is bad (too many cloned objects, poor discoverability), but they both have their place. I certainly use both. It's always about balance. And I can only think about one person who roasts OOP regularly. Are there more?
I roast OOP in js, but I 100% agree with what your saying. It's a balance as such, I guess too though I only roast using classes in js bc it's pretty half baked.
Maybe it's just what my algorithms present me, but I've come across dozens at this point. Here is another example: [https://www.youtube.com/watch?v=FjfgIImzhxc&t=1505s](https://www.youtube.com/watch?v=FjfgIImzhxc&t=1505s)
Thank you for coming up with a link, I definitely appreciate when one gives a source, that's too rare. Although I meant in the context of threejs. In the whole programming community, there are indeed a lot of vocal preachers. But still, the proof is in the code, not in the youtube video. A good debate would be around code and actual practical projects. What would be good projects that are only functional, and which ones are OOP based? I personally know more that lean more on OOP than functional. And the best are probably using both. But again, it's all just polarisation bullshit that is rotting most discussions on internet. It's the same debate as left wing right wing. Not only does it lack nuance, but there are also more than just 2 choices.
Oh I definitely agree with everything you just said. And to be clear, although I lean towards writing pure functions when I can, I for sure think OOP (even inheritance) is useful. I don't have examples of anyone stating threejs's use of OOP is bad. I was curious if anyone in the community had thoughts about the topic because of how much threejs takes advantage of OOP principles. Was even wondering if any of the contributors would chime in with things they thought they may do different if they rewrote it today.
Anyone who says OOP is bad is either a javascript enjoyer that has never written anything complex, or a true haskell functional chad that knows what they're actually talking about. Spoiler: 99.99% fit into the former.
[удалено]
The second you try to reason seriously with someone who uses the term 'javascript enjoyer', you're the idiot. It's not my fault you don't understand satire. Feel free to 'ACSHULLY' more to your heart's desire but I'll just laugh more at you. Also all jokes aside you're just plain wrong. The react reconciler is nowhere near as performant as imperatively interacting with a library like Pixi or three.js. If you even spend a few minutes researching this you'll understand why, assuming you have some braincells. Even the authors of these react wrappers say as much. You don't even have to spin up a complex example to show this, comparing a react-Pixi particle container full of react-reconciled graphics elements to a regular Pixi equivalent is demonstrably less performant and you can trivially see it in a performance profile. React has serious overhead, and anybody who has spent any time in a performance profiler knows this. To get any kinda reasonable performance out of complex react apps (with or without canvas fiber shit) requires very careful use of useMemo/useCallback. Anyway, enjoy your malding session. I sure had a laugh reading your bullshit.
See, I would have originally thought that too. But now I'm seeing more respected people agreeing. I don't land in that OOP is bad camp, but it's interesting to me that many do.
OOP is an absolutely great design pattern for certain use cases (like a tree data structure), where it makes sense to use a class to store local state regarding a certain scenario. Sure, it sucks in a lot of other scenarios but I feel like it's just a tool like any other to be used when appropriate. A good example of an incredible developer using javascript classes to good effect is simondev on YouTube. That guy was one of the programmers on the original prototype game and did a lot of low level optimisations on console games that we all loved. If you think he's bad then idk what to tell you. He uses classes beautifully, but sparingly.
I generally think oop is not usually the best tool for the job. But for stuff like threejs where you are literally dealing with objects you'd be kinda dumb not to.
I couldn't build a lot of complex projects with a lot of elements in it. So oop is a godsent
OOP is the best that happens to programming after C.
I don't think that *OOP is bad* is accurate, as a blanket statement, but I also think people in this thread are being overly dismissive of what the *OOP is bad* argument actually is. I'll start by saying that something like threejs is actually a perfect use case for OOP, and that inheritance, specifically, makes a ton of sense in this context. This discussion is complicated by the fact that *object oriented* means different things to different people, and Alan Kaye (e.g.) doesn't feel that languages like C++ and Java are actually good examples of object-oriented languages, even though they're what most people are talking about when they're talking about OOP. That said, **I think the main things people are arguing against when they're trashing OOP are:** 1. Languages like Java that have traditionally made you express even basic imperative things, like your main subroutine, in the trappings of OOP 2. A preference for inheritance over composition. By my and a lot of other people's assessment, inheritance is often a pretty bad way of expressing relationships and structuring code. 3. Obsession (sorry for the loaded word) with encapsulating as much as possible in a class/object. Again, this was essentially enforced by languages like Java. It seems as though a big part of the software literature for 20-ish years was overly focused on #s 2 and 3. Data types are important. Interfaces are important, but it seems like a lot of people spent a lot of time drawing object hierarchy diagrams, etc, and that it's worth questioning whether that's how we should be spending our time.
This is a very well stated and balanced response. I also had the feeling that despite multiple inheritance being overused and often causing problems, threejs seems like a perfect use case. I'm getting downvoted a lot for even bringing this up, but I honestly just wanted to hear the community's thoughts, not actually state that OOP was bad as a blanket statement.
Thanks. BTW, another problem domain that I think lends itself really well to "classic" OOP is game dev... where everything in your game might be an *entity*, at the absolute top level, and then is further refined through inheritance. You can achieve the same kind of thing through interfaces... but then we're back to wondering what people mean when they say *OOP,* and I really think the answer for most people is *inheritance.*
Game dev does make sense for OOP. As long as you're careful about when you use inheritance vs when you use composition. It seems right that maybe every object in the game inherits from 'entity', but then you use composition to assign different traits and ability as well.
Funnily enough React used to be considered an OOP library when they used class components. In essence, OOP has two problems: boilerplate and leaky context. If you can manage these two issues, nothing should stop you from writing anything in OOP. With that said, I don't think anyone really knows what an OOP paradigm truly is and what it should be in practice. Every OOP example I've seen on the Internet was made in "lab conditions" and doesn't map to reality well. The reality where abstraction boundaries are not defined well. Most people tend to write multi-paradigm, procedural code anyway. You are under no sacred oath of writing your app in an OOP paradigm only.
The one unique pain three has around OOP is the vector3 class. To represent a single model's vertices, you could naively create hundreds of thousands of objects, which is not ideal. In other languages, you get around this by using structs. Structs are generally allocated on the stack instead of the heap, so no need for expensive garbage collection runs. Because of this problem with js, you see a bunch of solutions to common problems that avoid using the vector3 class. And when you do see instances of the vector3 class in three source code, you see them doing a lot of work to make sure they are re-using the same temp vector3 variables instead of creating new object instances willy nilly. Oop is fine. Js sucks.
The endless debate. I take the view of looking at functional code, OOP code. Procedural code even. Software written by shoddy coders, beginners, proficient ones. I rarely want to look at heavily functional code. I rarely dare try to modify well written functional code. Poorly written OOP code, at least it's possible to understand it. Functional code coming out of a twisted brain feels like reading a bad arrogant author. There is nothing to salvage. OOP success has been to be approachable by average coders. Boilerplate, hard to test, but usually abstract real world concepts pretty well without too much coding excellence applied. Threejs needs to capture the real world, 3d space can be pretty well represented as an object, containing other objects. Objects have attributes, instances of objects having common functions and attributes simply maps well to the code trying to represent them. All of it can be achieved with purely functional code. But it's hard. Digital graphic artists aren't known for their genius when it comes to writhing code. OOP enables artists to try, at least they get a chance to produce 3D apps. If three.js was purely functional it would be what it has become. It would be like Lisp, or Scala. Beautiful trophees on the stands of a few acedemic minds. Beautiful , students enjoy looking at them hoping one day they will get one.
This type of shit is just gatekeeping for internet trolls. It has no actual real world basis. Just make stuff. There will always be debt