In the live talk, Sophie also discussed how Javascript classes are difficult for machines: minifiers aren't able to shorten the names of methods (because it's apparently hard to work out all the ways that the method could be invoked), and they cause stability problems with hot code reloading. So there are benefits beyond ease of use for humans.

(Also, I'm pretty fluent in Javascript and I still forget to bind event handlers all the time, which suggests to me that it's a counterintuitive pattern even if I know "how it works" on a technical level. And you either have to put a bunch of "this.handler = this.handler.bind(this)" in the constructor, or rely on class properties which are an unstable syntax feature, both of which are suboptimal.)

It may have been on purpose (came off as a sincere mistake), but Dan Abramov forgets to bind them in this talk while giving an example. It's a very common problem, even for the authors of React itself :)

It did come off as a sincere mistake, but remember, they had a dry run of the talks a day or so before. So could have easily been staged. But was hilarious anyway.

> because it's apparently hard to work out all the ways that the method could be invoked

Simple example case of a statement that makes it impossible to minify function names:

    class Test { static func() { /* function code */ } }
    test[prompt('function to call')]()

Doesn’t that example also make it impossible to minify the names of anything? Perhaps other than JavaScript modules, since AFAIK the popular module builders like Webpack do compile-time module importing (I believe that even the dynamic import function is recognized at compile time and doesn’t support throwing in a prompt).

No, that issue is unique to class/object property names. You can't dynamically reference a variable in a scope by name supplied by a variable in the same way (except by using `eval`, which does in fact cause minifiers and javascript engines to disable a bunch of optimizations in the scope it's used).

Of course it's unintuitive. I see dev veterans make the mistake all the time.

JS was so poorly designed. An implicit (not passed as an arg), dynamic this parameter. You couldn't be more cheeky than that really.

something like console.log.bind(console.log) is beyond silly. It's what we're stuck with but I will minimize the occurences of that kind of crap any single time I can.

You can just do `onChange={() => this.handler()}`.

This would create a new inline function on every render though, which potentially might cause rendering performance issues.

The Hooks way creates a lot of inline functions on every render.

Hardly ever.

>A framework shouldn't be designed around the fact that people don't know the language they are using, right?

No, but it could be designed around the fact that some of the language features are confusing or crap.

At the end of the day, the framework that allows people to get more done with less thought is going to win the most mindshare.

That is unfortunately not true. The framework with the best marketing will win.

That's why frameworks like angular and react are so popular. Both are designed to work well in large teams that work on huge codebases. Most of us probably would came along with much much simpler solutions.

So are you telling me Facebook has a serious marketing budget for React? If so, that means tech has gotten way way crazier than I could ever have imagined.

There's a complexity angle that needs to be appreciated. I love Rails, I think it's the best solution to the problem it tries to solve for the people it wants to solve that problem for. But it's been called overly-complex and magical. But less-complex, less-magical frameworks just don't solve the problem as well. Just try building something big with Sinatra and you'll see what I mean.

I'm not terribly familiar with Angular, but React, when you remove it from its ecosystem and treat it as just a library-framework, does a great job at facilitating the building of user interfaces. The abstractions and underlying paradigm are somewhat hard to grasp, but once grasped, a competent architect can lay down patterns that juniors can implement.

A lot can get done in a small amount of time with React. The people that managed to do this in the beginning are the ones who christened React the Son of UI Development. People listened, and now we have the Church of React, with the Redux Reformation now upon us. Facebook had nothing to do with it, that was all us.

Another great option to bypassing the limitations of functional components is using a higher order component library like recompose[0]. Does have somewhat of a higher learning curve, but I personally consider it a must have tool on all my projects.

[0]: https://github.com/acdlite/recompose

FYI. https://github.com/acdlite/recompose/commit/7867de653abbb57a...

To be fair, JavaScript has been a moving target and things like classes are quite new. Then again, it doesn't make sense to avoid features just because they're new.

I think the point is that they want to provide two ways to do simple things: classes and functions. Functions have better performance, classes are more flexible.

>I think the point is that they want to provide two ways to do simple things: classes and functions.

At the risk of seeming like an old man complaining about new things, what problem would "classes" solve in javascript that the existing object syntax, which allows for inner functions and variables, doesn't?

Prototypal inheritance, and scope controls more refined/easier to work with than IIFEs. In the end the class notation is "simply" syntax sugar giving the object syntax the benefit of Function.prototype and IIFE closures, without having to resort to layers of either/both.