When I use classes, when I don’t, what I do instead and why

https://blog.kentcdodds.com/classes-complexity-and-functional-programming-a8dd86903747

by galfarragem • 9 years ago

131 93 9 years ago

blog.kentcdodds.com

sshine• 9 years ago

TL;DR: Read JavaScript: The Good Parts.

Veen• 9 years ago

That book was written in 2008. JavaScript classes were introduced with ECMASCRIPT 2015.

ealexhudson• 9 years ago

That doesn't really matter, this complaint about "this" predates the use of classes.

thinkxl2• 9 years ago

JavaScript classes are syntactic sugar, the class type doesn't exist in ES2015; everything still works with prototypical inheritance.

So, I'd say that this book is still relevant Today. If you don't understand how inheritance work behind the scenes, you don't understand JavaScript.

acdha2• 9 years ago

It seems odd to read something written in 2017 about the confusion from using `this` which only mentions arrow functions briefly in passing. A fairly high percentage of discussion on that issue could be replaced with “use an arrow function, it works the way you expect”, and browser support should be basically the same as ES6 classes – doesn't work in IE11 but multiple tools are available for backwards compatibility.

supergreg3• 9 years ago

Do arrow functions get added to the prototype or the instance of the object? Can they be created directly in the class body or have to be added inside the class constructor?

jwdunne• 9 years ago

Since I last checked it was still experimental, albeit available in Babel, but there is work on syntax for property initialisers in class bodies e.g:

  class X {
    id = (x) => x;
  }

See here:

https://github.com/jeffmo/es-class-fields-and-static-propert...

martin-adams3• 9 years ago

My understanding is that arrow functions aren’t used as part of a class definition, but for things like anonymous functions in callbacks, preserving the ‘this’ context when something else is invoking it.

E.g. el.onClick((e) => {this.doSomething();});

In that case something else will invoke the onClick callback but we want the ‘this’ context to the same as when we set up the onClick.

iEchoic• 9 years ago

Agreed - I don't find the usage of "this" to have any cognitive load, as long as arrow functions are used everywhere. "Arrow functions only" isn't a tough standard to maintain.

spion10• 9 years ago

`this` is hard to learn.

No it isn't. Its a function argument that is implicitly passed "left of the dot". Whatever object that function was attached to when you call it? Thats the object thats gonna become the `this` argument.

Normal arguments, you pass them like so: `someFunction(normalArgument1, normalArgument2)`

The argument `this` you pass it like so: `thisArgument.someFunction(normalArgument1, normalArgument2)`

From this it immediately becomes clear why you can't pass that function away by itself. When whoever got it calls it, its going to have nothing "left of the dot" to call it with.

Done, `this` explained.

katastic• 9 years ago

Yeah, if you can't grasp 'this', good luck figuring out delegates. (Note: Some/many languages call these "Closures") 'this' is just a context pointer.

classes don't actually store their functions (except virtual ones).

    class A{ 
        int data; 
        void method1(int input){data = input;}
        }
    A my_instance;

is actually

    struct A {int data;}
    method1_for_struct_A(A *context, int input){ context->data = input; } //normal local function
    A my_instance;

and this:

    my_instance.method1(3);

becomes this:

    method1_for_struct_A(my_instance, 3); 
    //send a pointer to the class we're operating on

And once you understand that, delegates are easy, because they're just... sending the context pointer around. So in D:

    //note: global function, NOT apart of any class.
    delegate void my_function(int input)
        {
        data = input; //where is data coming from?
       // the surrounding context.
        }

    void my_test_function()
        {
        int data = 2;
        my_function(3); // is a delegate and gets implicitly sent the context 
        //pointer for my_test_function, and now, it can access data.
        // Note this is a RUN-TIME adjustable function. Delegates can be passed
        // around. 
        }

and internally my_function is actually (note the pattern):

    void my_function(context_pointer, int input)
        {
        context_pointer.data = input;
        }

and the compiler implicitly sends the context with it:

    my_function(3) becomes
    my_function(my_test_function_context, 3);

So basically, delegates are just an extension of what classes already use under-the-hood. Delegates are "fat" function pointers. Function pointers point to a function, and the "fat" pointer includes an additional "context" pointer to the surrounding data frame so you can dereference it to access the surrounding data. You can do all of this in plain C if you don't mind writing all the boilerplate code yourself.

Virtual functions are similar to delegates. The class actually contains the function pointer / delegate instead of re-writing it at compile-time. Which allows them to be overridden at run-time. Whereas "this" usually means you can figure it out statically, at compile-time, so the function call is a pure function call and doesn't incur the penalty of looking up a pointer for the virtual call.

I bet I'm probably missing something or slightly off here or there, so someone feel free to chime in and correct me. Consider the code pseudo-code. I might have flipped something from memory.

toomim• 9 years ago

It's not that simple. You've mentioned only one of the possible meanings of `this`: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

In the global execution context (outside of any function), this refers to the global object whether in strict mode or not.

    // In web browsers, the window object is also the global object:
    console.log(this === window); // true

    a = 37;
    console.log(window.a); // 37

    this.b = "MDN";
    console.log(window.b)  // "MDN"
    console.log(b)         // "MDN"

Inside a function, the value of this depends on how the function is called.

== Simple call ==

Since the following code is not in strict mode, and because the value of this is not set by the call, this will default to the global object, which is "window" in a browser.

   function f1() {
      return this;
    }
    
    // In a browser:
    f1() === window; // true 
    
    // In Node:
    f1() === global; // true

In strict mode, however, the value of this remains at whatever it was set to when entering the execution context, so, in the following case, this will default to undefined:

    function f2() {
      'use strict'; // see strict mode
      return this;
    }
    
    f2() === undefined; // true

So, in strict mode, if this was not defined by the execution context, it remains undefined.

== The bind method ==

ECMAScript 5 introduced Function.prototype.bind. Calling f.bind(someObject) creates a new function with the same body and scope as f, but where this occurs in the original function, in the new function it is permanently bound to the first argument of bind, regardless of how the function is being used.

    function f() {
      return this.a;
    }
    
    var g = f.bind({a: 'azerty'});
    console.log(g()); // azerty
    
    var h = g.bind({a: 'yoo'}); // bind only works once!
    console.log(h()); // azerty

== Arrow functions ==

In arrow functions, this retains the value of the enclosing lexical context's this. In global code, it will be set to the global object:

    var globalObject = this;
    var foo = (() => this);
    console.log(foo() === globalObject); // true

Note: if thisArg is passed to call, bind, or apply on invocation of an arrow function it will be ignored. You can still prepend arguments to the call, but the first argument (thisArg) should be set to null.

No matter what, foo's this is set to what it was when it was created. The same applies for arrow functions created inside other functions: their this remains that of the enclosing lexical context.

== As an object method ==

When a function is called as a method of an object, its this is set to the object the method is called on.

In the following example, when o.f() is invoked, inside the function this is bound to the o object.

    var o = {
      prop: 37,
      f: function() {
        return this.prop;
      }
    };
    
    console.log(o.f()); // 37

Note that this behavior is not at all affected by how or where the function was defined. In the previous example, we defined the function inline as the f member during the definition of o. However, we could have just as easily defined the function first and later attached it to o.f. Doing so results in the same behavior:

    var o = {prop: 37};
    
    function independent() {
      return this.prop;
    }
    
    o.f = independent;
    
    console.log(o.f()); // 37

This demonstrates that it matters only that the function was invoked from the f member of o.

Similarly, the this binding is only affected by the most immediate member reference. In the following example, when we invoke the function, we call it as a method g of the object o.b. This time during execution, this inside the function will refer to o.b. The fact that the object is itself a member of o has no consequence; the most immediate reference is all that matters.

== "this" on the object's prototype chain ==

The same notion holds true for methods defined somewhere on the object's prototype chain. If the method is on an object's prototype chain, this refers to the object the method was called on, as if the method were on the object.

== "this" with a getter or setter ==

Again, the same notion holds true when a function is invoked from a getter or a setter. A function used as getter or setter has its this bound to the object from which the property is being set or gotten.

== As a constructor ==

When a function is used as a constructor (with the new keyword), its this is bound to the new object being constructed.

While the default for a constructor is to return the object referenced by this, it can instead return some other object (if the return value isn't an object, then the this object is returned).

== As a DOM event handler ==

When a function is used as an event handler, its this is set to the element the event fired from (some browsers do not follow this convention for listeners added dynamically with methods other than addEventListener).

== In an in–line event handler ==

When code is called from an in–line on-event handler, its this is set to the DOM element on which the listener is placed:

    <button onclick="alert(this.tagName.toLowerCase());">
      Show this
    </button>

The above alert shows button. Note however that only the outer code has its this set this way:

    <button onclick="alert((function() { return this; })());">
      Show inner this
    </button>

In this case, the inner function's this isn't set so it returns the global/window object (i.e. the default object in non–strict mode where this isn't set by the call).

spion10• 9 years ago

So theargument has a default value when in non strict mode， and like all other arguments you can partially apply it with bind. Got it.

Everything else, still explained by ”argument passed left of the dot at call time“

Oh yeah and arrow functions dont have a this argument so whatever this was already in scope is the binding.

munificent• 9 years ago

No it isn't. Its a function argument that is implicitly passed "left of the dot".

That is true in JavaScript, but not in other languages that also have "this" and closures. So the confusion comes from two issues: 1. JavaScript is inconsistent with other languages, and 2. It's not at all clear that JavaScript's semantics are actually good.

In other languages where "this" is not loosely bound, there is next-to-no confusion around them and no problems, so the evidence is there that the semantics JavaScript chose aren't user-friendly.

The reason JS has those semantics is because it (at the time) had no way to distinguish between a method declaration (where this should be dynamically bound) and a function declaration (where this should be lexically bound). Other languages with class syntax don't have that problem.

JavaScript does have class syntax now, but changing the semantics of how this works would have been very difficult this many years later.

spion10• 9 years ago

All languages have different semantics. Otherwise they would've been one language.

Python has an explicit self that is unbound. Other languages have it implicit and bound... Etc

xaedes• 9 years ago

C++ also needs something like std::bind. To have to use some bind mechanism is reasonable for me. In JavaScript you could do this since quite some time with currying.

ryanmarsh2• 9 years ago

Crockford says he doesn't use `this` and classes were the worst thing that could have been added to JavaScript.

azangru• 9 years ago

The title would benefit from the word javascript :-)

thinkxl2• 9 years ago

I don't know why, but just by reading the title my mind implied JavaScript, and I noticed it doesn't have that word only after reading your comment.

Weird.

stochastic_monk• 9 years ago

I thought of C++, but I have never written any JavaScript in my life. It's worth considering that even in C++, there are times when inventing a class to simply perform a function is excessive.

graycat• 9 years ago

I don't have a sushi knife because I don't need one because I don't eat sushi.

I was in a project in rule based programming, but I left that project and f'got about such programming because I don't have any rules I want to program.

I was in a high end project for object-oriented programming and another for object-oriented data definitions (OSI/ISO CMIP/S) but f'got about those because I don't have any objects to program or use for data.

In my current project, I have defined a few classes, but it's not really object oriented programming because I do next to nothing with methods, never use inheritance, and usually allocate only one instance of each class.

So I use classes as really just versions of structures as in C and, much better than C, as in PL/I where the structures are terrific and in execution time much more efficient than objects. For fast program to program communications over TCP/IP sockets, I do like class instance de/serialization.

Basically, net, to me, object oriented programming is a solution for a niche problem I don't have, have never had, and likely never will have.

Also the OP illustrates more of why I don't pay attention to object-oriented programming: The syntax of that example is tricky gibberish I want nothing to do with.

Object oriented programming seems to have helped a lot with Microsoft's .NET. Okay, I use .NET. But I'm not writing .NET classes!

Sorry guys, I don't eat sushi and in my code don't see any real need for object-oriented programming.

More generally, I've been programming for a long time, and it all looks much the same to me: (A) Define places for the data need to store, (B) manipulate the data with assignment statements, if-then-else, do-while, call-return, and occasionally allocate storage(I let Microsoft's garbage collection handle freeing the storage), and (C) use some .NET classes.

I could use a sushi knife if I ate sushi, but I don't. I could use all that stuff about objects if I had objects in my programming, but mostly I don't.

To borrow from the old movie The Treasure of the Sierra Madre, "Objects? What objects? We don't need no stinkin' objects!"

supergreg3• 9 years ago

The case would be solved if they added some syntax to bind a function to the class. Something like

    class Foo {
      bind function bar() {
        console.log(this);
      }
    }

So behind the scene it would do `this.bar = this.bar.bind(this);`

spraak• 9 years ago

That'd be awesome. Submit a proposal! https://github.com/tc39/proposals

supergreg3• 9 years ago

Looked around and there's a proposal for an easier way to bind `this` and some discussion about extending that to class methods: https://github.com/tc39/proposal-bind-operator/issues/39

Using arrow functions at the class level would also solve this without adding new syntax. Edit, this is a thing already: https://babeljs.io/docs/plugins/transform-class-properties/

martin-adams3• 9 years ago

Interesting, that would mean you would have confusion if someone used your class like:

foo.bar.bind(somethingElse);

How would the callee know that this would potentially conflict?

abiox• 9 years ago

that would mean you would have confusion

does this confusion not exist now?

always_good3• 9 years ago

Already exists.

    class Foo {
      bar = () => {
        console.log(this);
      }
    }

Has to be compiled with Babel, though.

bramen• 9 years ago

There's already a proposal for field declarations, where you can do the following:

  class Foo {
    bar = () => {
      console.log(this);
    }
  }

This basically puts `this.bar = () => console.log(this)` in the constructor, and since it's an arrow function it captures the correct context.

See https://github.com/tc39/proposal-class-fields.

nulagrithom• 9 years ago

Understanding 'this' in JavaScript is simply table stakes at this point. You and anyone else who touches your JS code should have a decent grasp on 'this'. Citing "complexity of this" while using React is just absurd in my opinion...

You Don't Know JS: this & Object Prototypes cleared it up nicely for me.[0] Love the series in general too.

Also -- and I'm not sure how it's typical done when taking a functional approach -- where do these functions "live"? What if we want to use a Person in another module/component/whatever? Do we basically just have a collection of "static" functions on a helper class that we're going to be using? I'm not sure that's a real gain. Would rather see the functions available on the Person itself (though maybe that's just my OOP ways talking).

And then there's the "pure function" part. Without explicit documentation and no other knowledge of this individual's functional predilections, I would be surprised when the setName function actually creates an entirely new Person and then sets it name.

I don't know. I really do enjoy functional approaches, but I don't think avoiding 'this' is a good reason, and I feel like the example given isn't the best scenario to illustrate.

[0] https://github.com/getify/You-Dont-Know-JS/tree/master/this%...

k__2• 9 years ago

Also, if you only use arrow functions you don't even have that problem.

moron4hire2• 9 years ago

Then you had different problems. You don't always want to capture `this`.

RSZC2• 9 years ago

Nonsense. It's not a question of whether you understand `this` or not, it's a question of whether thinking about the different cases of `this` is really a good use of your time. Alternately: `this` is poorly designed and gets in your way.

Here's an example of a recent production bug:

  async.timeout(server.close, 60000)(exit)

And one way to fix:

  async.timeout(cb => server.close(cb), 60000)(exit)

In case the problem is non-obvious (that's the point!), the first line loses the binding to the specific `server` in question. Lovely. `this` in JS forces the consumer of a module (in this case `server`) to have knowledge of how the module represents its state in order to use it. That's not a good pattern.

lucideer2• 9 years ago

In case the problem is non-obvious (that's the point!),

I think what the gp was saying is that the table stakes for JS is this being obvious. I guess whether it is is subjective, but I have to agree. Your example is glaringly obvious to me. Any assignment of a method on an object, or passing of one as an argument (i.e. any passing/assignment that includes a dot before a method) stands out. This doesn't involve any cognitive overhead if you actually know what `this` is.

`this` in JS forces the consumer of a module (in this case `server`) to have knowledge of how the module represents its state in order to use it.

No it doesn't... It requires the method to have access to the module it's defined on, which means you can't pass (i.e. reassign) the method on its own. In your example, the module (server) is not being consumed, only one of the modules methods is consumed on its own; the module is left behind and not consumed (i.e. `this` is left behind)

jtchang• 9 years ago

The more I learn JS the more I am worried that I am not using 'this' right.

I swap back and forth between javascript/python and with JS it always feels like I am one step away from disaster if I accidentally forget to bind this.

gcoda• 9 years ago

I feel you, but sometimes, I am using

    var that = this

just to be sure

exclusiv• 9 years ago

Sounds like you are using it right but yeah you can setup the bindings or do an arrow function.

I've been preferring just setting up the bindings in the constructor over arrow functions.

So for the author's example I'd just do: constructor (){ this.increment.bind(this); }

Then the template can stay cleaner with just onClick={this.increment}

nickbauman• 9 years ago

The Gambit he's claiming is straightforward. Given type X, calling object of type X, a's method a.doit() is just sugar on the fundamental doit(a). The way you get the former is to introduce JS concept of _this_ which is accidental complexity that doesn't pull its weight. I tend to agree.

baron816• 9 years ago

If anyone is interest, you can write stateful React components without 'this' or 'class.' I explain how here: https://medium.com/@baronmaximilianwilleford/react-without-t...

I've been doing it for a while and haven't had any problems and have really enjoyed doing it.

samfisher83• 9 years ago

Why Can't JavaScript just have c++/java/c# type classes? At least it makes it easy to identify what you class variables are and what your class functions are.

saas_co_de• 9 years ago

Yeah I was just thinking, why can't javascript be easy and simple like C++?

dlbucci• 9 years ago

What bugs me about the class syntax more than anything is that it encourages prototype classes, which in my humble opinion, are just worse than the Crockford module pattern. C Modules solve this/binding issues, and give you privacy. Maybe they use more memory (in theory), but I never thought that was a great argument unless you actually measure usage and it's noticeably worse. You're basically creating those functions anyway when you call bind, so I wouldn't be surprised if there's not a big effect for most applications.

southpolesteve• 9 years ago

I also find `this` is terrible for linting. Most tools won't be able to figure you what you attached to `this` at runtime. It's a grab bag object ripe for bugs.

seasonalgrit• 9 years ago

If you're going to go with a functional approach (which he introduces in the section "How to avoid 'this'"), instead of creating a brand-new function for each particular piece of data (e.g., setName, setGreeting) -- which will result in a ton of extra code -- just use a simple, generic assoc function.

"Inventing a class with its own interface to hold a piece of information is like inventing a new language to write every short story." -- Rich Hickey

deckar01• 9 years ago

I actually have to maintain a js codebase that uses a generic “addProperty” function at its core to generate getters and setters. It is terrible to debug. Properly encapsulated class methods are much easier to read and debug.

This problem has been solved for a long time. Some data doesn’t need a class, but when it does, don’t roll your own.

pshc• 9 years ago

I use classes to bind a data structure to a group of functions. That's mostly it.

Inheritance, overrides, super calls? The less I use those, the less I miss them.

dboreham2• 9 years ago

This is in fact what classes are.

wellpast4• 9 years ago

This post is painfully confusing the important concepts of complexity & "complecting"/coupling.

Javascript's this semantics may be confusing and hard to reason about but that is a different charge than the complecting/coupling sort of complexity which is the _much, much_ bigger problem in the world of building software systems.

The much bigger problem with a Person class is not to do with this or that programming language vagaries vis a vis the this keyword. The bigger problem exists in all programming languages: ADTs like Person classes introduce unnecessary coupling of information -- and this is what really matters: this is what hurts productivity.

It sucks that I have to learn the finicky vagaries of this in Javascript, but once I do, I'm fairly good going forward. However, no amount of learning on my side is going to help me when I need to add new pieces of information to some people data -- your ADT has decided for and _requires_ me to jam my knowledge and facts into an unnecessary rigid categorization in order to evolve your ADT-ridden data processing system.

This post's refactoring of class hasn't changed that game for me. You've just moved this to each function's first parameter and called it "person" -- so while you've saved me momentarily from having to learn about this semantics[1], you haven't gotten rid of the truly offensive bit: the whole notion of the "person" classification itself and the rigid, upfront, unnecessary, and likely-to-be-wrong-in-the-future assumption that only its members can be given these things called names.

[1] Which I should have learnt anyway being a Javascript programmer.

s4vi0r2• 9 years ago

What do you mean by ADTs introduce unnecessary coupling of information? ADTs allow you to clarify and safely handle otherwise vague data. Maybe I'm misunderstanding, but your comment reads to me like you're in support of stringly typed programming.

wellpast4• 9 years ago

ADTs allow you to clarify and safely handle otherwise vague data.

This is false. You can program with clear, strong, safe semantics without needing to taxonomize/classify your business domain/entities with ADTs.

In most business applications, ADTs hurt you: they are used to pre-classify the world in ways (unnecessary ways) that very frequently collide with future system evolution & future use-cases.

ryanmarsh2• 9 years ago

Code should be written first and foremost for humans to understand, and incidentally for compilers to understand. https://mitpress.mit.edu/sicp/front/node3.html

If we can all agree about that then we have to ask ourselves if encapsulating data and behavior at the granularity of classes makes the most sense for human comprehension. In naive OO examples (Animal -> Cat) it does. In practice however, it's debatable (at best).

I highly recommend this video by Brian Will who does a much better job explaining this problem than I could. https://www.youtube.com/watch?v=QM1iUe6IofM

Douglas Crockford also does a good job of explaining some of the trouble with classes. https://www.youtube.com/watch?v=bo36MrBfTk4#t=28m50s

Veedrac• 9 years ago

In naive OO examples (Animal -> Cat) it does.

An inheritance hierarchy consists of three things: a taxonomy, behavioural inheritance and structural inheritance. The first is only useful on occasion, and the last two don't even apply to Animal → Cat; "animal" is not a behavioural constraint, and a cat certainly doesn't have a platonic ideal of an animal hidden somewhere inside its gut.

Waterluvian• 9 years ago

I avoid classes as a default behaviour, using them when they're clearly a good fit. The ease of testability that functions give me is worth its weight in gold.

I love how much I can do with JavaScript without classes. Same with Python! You'd be surprised how often you don't need them.

connorelsea• 9 years ago

A lot of the typical use cases for classes in a language like Java are replaced by the user's choice of module format in JavaScript (ES6, commonjs, etc.). Though, I don't think "this" was that hard to learn (See: YDKJS) and classes/prototypes definitely are an important tool in the JavaScript toolbelt.

dboreham2• 9 years ago

This unfortunately is one of those cases where the fact that someone has taken some time to write a nice looking article about a subject does not signal that they have something interesting and valuable to say.

cdevs2• 9 years ago

What about the cognitive load on someone reading person1 person2 person3. Now I have to realize person 3 in your code is person2 and person2 was person1, person1 and person2 are now dangling and will never be touched again hopefully. I love the idea of pure functions but I have always thought there was a missing piece in functional programming.

Anderkent• 9 years ago

No sane language makes you write person1 person2 person3. Immutability doesn't mean you can't reuse names; only that the reassignment is in lexical scope, and doesn't impact any other references to what you saw as person1.

cdevs2• 9 years ago

Rust calls it shadowing and throws this example: fn main() { let x = 5; let x = x + 1; let x = x * 2; println!("The value of x is: {}", x); }

Sure this is a syntax example and you shouldn't be creating Immutable variable x and then adding +1 to it for no reason. If you did have a reason you should add it to the variable name so it's more likely developers say let xPlusOne = x + 1; Or a kitchen example: Let cream = getRefridgeratorItem(cream); Let whippedCream = blend(cream);

So you reply no sane language makes you do this but why didn't the author show that? His goal was to make things more readable but lets be honest functional programmers would judge you all day for making a promise and then copying over that promise with something else. You may do it at work but the purist trolls hate reading it.

zamalek2• 9 years ago

A few years back I wrote an JS+async to JS compiler. I made a very real attempt to forget everything I knew about statically typed languages.

I organically found a very compositional form. The parser created a tree containing objects such as, for an if statement, { if: { ... }, accept: () => ... }. The next stage would decompose that into more compositions, maybe by adding a block and condition property. While it probably had garbage performance, the power of dynamic languages finally clicked.

I used to be an aspiring game developer; writing a component entity system in C# (my weapon of choice) required absurd amounts of carefully crafted code. Statically-typed languages have a ton of front-loaded overhead if you need something outside of their formula.

You can approach problems any way that you please in dynamic languages (such as the functional approach in the article) and, while they still really aren't for me, I completely understand why people use them.

weberc22• 9 years ago

It's not clear to me what you mean by the power of dynamic languages. I'm inclined to think your perspective on static languages is limited to C# or some other OOP static languages. In particular, your example doesn't seem very novel for a statically typed language. Heck, I just built a reasonably elegant parser framework in Go and it doesn't even have generics. This makes me wonder if you're not attributing your OOP frustrations to static typing.

zamalek2• 9 years ago

I really did mean to say OOP - I have been attempting a real project in Go and I'm smitten.

Still, even Go has a prescribed way of approaching problems; as unusually broad as it is for a statically typed language. As a very relevant example, there is far more syntactical overhead in Go if you wish to fake FP (e.g. `func Foo(a A) func(b) func(c) func(d) e` to allow currying); where-as in JavaScript you simply bind or apply.

I've yet to see an article gushing over how natural functional is in Go (which is fine, Go isn't designed for that). This must be the 20th article I've seen on HN about functional in JavaScript.

jryan49• 9 years ago

Too bad avoiding this just looks like a spaghetti mess with no cohesion. If you're going to be using a language, you might as well learn how it works instead of avoiding it with strange hacks. I'm also confused how the 'pure' version is less complicated than the class version. I see it the opposite?

ES2048• 9 years ago

" Usage of class is not bad. It definitely has its place. If you have some really “hot” code that’s a bottleneck for your application, then using class can really speed things up. But 99% of the time, that’s not the case. And I don’t see how classes and the added complexity of this is worth it for most cases (let’s not even get started with prototypal inheritance). I have yet to have a situation where I needed classes for performance. So I only use them for React components because that’s what you have to do if you need to use state/lifecycle methods (but maybe not in the future). "

Why would classes have any inherent performance benefits (and over what) ?

rhinoceraptor• 9 years ago

Since classes are just sugar over prototypes, their performance is just about the same for instantiation. I assume the article is comparing them to functions that return an object literal with methods.

Here is a simple example of equivalent code in a class, function with a closure, and a prototype:

  class FooClass {
    constructor (bar) { this.bar = bar; }
    getBar () { return this.bar; }
    setBar (bar) { this.bar = bar; }
  }

  function FooClosure (bar) {
    var _bar = bar;
    return {
      getBar () { return _bar; },
      setBar (bar) { _bar = bar; }
    };
  }

  function FooPrototype (bar) { this.bar = bar; }
  FooPrototype.prototype.getBar = function () { return this.bar; };
  FooPrototype.prototype.setBar = function (bar) { this.bar = bar; };

When instantiating a lot of objects, the prototype and class are practically the same, but the function closure pattern is a lot slower. On my machine, instantiating one hundred million of the class or prototype each took about 500ms, but the closure function took about 3s.

adityapurwa• 9 years ago

I don't see why would I want to assign my bound class methods to external variable, and if you do that, you are responsible to bind the method to an instance. The reason it is a class method is because it operates on that class, taking it out and using it externally is against the purpose of it's existence.

When I use classes, when I don’t, what I do instead and why

Related Stories