Hacker News Reader

Comment by devjab | Hacker News Reader

I think it’s more a matter of how the JS community has grown in general. The whole “class” thing is something a lot of us brought into it when we came from other OOP languages, but in 2023 it is very rare that it is “better” to build a “class” than to simply build the functions you need.

As far as I know you can still trundle on with some of the old react, but at the same time, things change. It’s not like you’re coding C# similar to how you were 10 years ago either. I know that having been away from it, it was interesting to see everyone using “var” instead of types as an example.

View on HN

I dunno... when you're building a hierarchical tree of nameable components and several, ahem, instances of each nameable component might exist, and these need to respond to signals, that seems like a case when it's non-crazy to use classes.

But that’s not ever what you had in React even when using JavaScript class components.

I believe OOP is generally overused (no, you don’t need a zero-member class to provide related functions; static class members are a code smell; etc.), but I don’t follow what you’re saying. From my perspective as someone who is just learning React recently but has a decade’s experience in C, C++, and Rust, the programming model doesn’t make any sense to me. The functional paradigm used by React has the same fatal flaw as OOP does: rather than making state management simpler, it attempts to hide it (OOP hides by “private” variables, React chooses to hide it in “hooks”). Both seem absurdly complicated to me. There’s no need for classes with trivial setX() methods, and there’s no need for hooks either, to perform what is essentially a variable assignment. They make the code more complicated to read and write, and increase cognitive load, IMO.

A component that has some state associated with it, such that manipulating that state causes certain side effects, seems almost custom-fit for OOP. The functional style does not seem to fit the domain.

Classes and types and methods exist for a reason. They're not "old" you don't "grow beyond them" anymore than you "grow beyond" functions, constants, threads, or files.

Try stepping outside of JavaScript for a while, broaden your experience.

So you're just gonna ignore that whole "the JS community" bit then, ok.

Is this what $200/hour consultancy looks like?

Try writing some code in not just JavaScript but also C, C++, Java, and others. Classes aren't some relic. You use prototypes in JavaScript every single day.

You're still just blowing past "the JS community".

To fill you in on the context of the thread you inserted yourself into, classes have fallen out of favour _in JS_. It's pointless to say "but they're still used in other languages!" because we're not talking about other languages, we're talking about JS.

I, too, am talking about JavaScript. Everything in JavaScript is prototype-oriented whether you ignore it or not.

You can choose to write functions for everything, but you're still always using object prototypes.

There are several large popular libraries in JavaScript which do not orient themselves around functional object orientation, too. So you might work in one corner of JavaScript where all you experience is functions, but that's not the case everywhere.

They haven't "fallen out of favor," whatever that means.

I think we may be talking a little bit in two different directions, because when you write this:

> Classes and types and methods exist for a reason.

What that reads like to me is actually the exact explanation as to why the JS community has fallen out of love with things like classes. Because JS doesn't have static types, and without those, well... Classes don't actually exist. At least not in the way they do in other languages like C++. You can pretend you're working in a regular OOP language, and use the prototype object like you would a C# or Java class but since you don't have static dispatch at compile time, you're frankly playing this part of JS as a weakness instead of a strength.

Which is why the JS community has been "growing beyond" classes.

If working with classes in JS is more comfortable for you, then I think you should do so, but ultimately a JS class is just a function. Once you grow comfortable with working with modules and functions, you're very rarely going to be writing classes when working with JavaScript. You're still going to do so from time to time, when it makes sense, but often its both unnecessary, less efficient and harder to maintain something that is build like a C++ class rather than than a JavaScript function. While working with JavaScript, being a key part of it. This is not an attack on OOP in general, just an explanation as to why the JS community has "moved beyond" pretending JS is an OOP language the same way Java is an OOP language.

> Try stepping outside of JavaScript for a while, broaden your experience.

I do so regularly.

A JavaScript class is syntactic sugar for prototypes, not functions.

JavaScript is a prototype-oriented language.

> A JavaScript class is syntactic sugar for prototypes, not functions.

Again you're basically speaking into exactly what I'm trying to say. Because what are JavaScript functions? It is also a prototype. I'll try to put it a different way. The JS community has "moved beyond" classes because they are functions. Both classes and functions are prototypes, but functions are often easier to work with, more maintainable and more efficient.

I'm not trying to say that you should never write another JavaScript class in your life. I write them myself when it's prudent to build things in a structure that resembles classical OOP. The reason I don't personally use that sort of coding style, if I can avoid it, is because it's an act. It looks like classical OOP, but everything is mutable at any time which means it's very easy for consumers of the code to break it by accident. This is less of a problem when you build things as isolated modules, based on individual functions, because there simply isn't any complexity to "misuse".

This is sort of similar to why the virtual DOM became so popular in frontend JavaScript. Because it's harder to work directly with the DOM itself. It's not necessarily better to use functions, it's just "safer", because they come with less risk of someone doing something bad by accident down the line.

…no a function is a function and a prototype is a prototype.

Uhh yes, classes in JS is just function, but it forces you to make a strict definition on how the set of functions will behave, in opposite of defining functions and tied them up individually.

If a thing need properties and methods to operate, defining it as class won't make it harder to maintain than cleverly do it with functions and object.

> but it forces you to make a strict definition on how the set of functions will behave

This would be true if JavaScript had static dispatch, but since it doesn't, everything you do with your class is mutable all the way up the prototype object chain. One of the reasons this is harder to maintain, is because the "strictness" you think you build into your code isn't actually there unless everyone who works on your code after you follows the same rules you did. I'm sure we'd like to live in that world, but I doubt we will.

It's slightly more now with private members, but still prototype based inheritance and definitely not the same. Composition will still usually perform better all said.

If you want something more, better to use TypeScript or step to something like Rust+Wasm.

Yeah. Functional components are right sized. You can still decompose & hack off pieces nicely, into helpers or hooks.

Just because CS has heavier weight classical structures we can apply doesn't mean they're better. And underneath a lot of those ideas were more lambda-calculus ideas that correspond somewhat with functional components.

OOP was invented to capture patterns already widely used in assembler and C and other old languages.

Reply on news.ycombinator.com