No need for @bind and ::this.method. We already have short function syntax. about preact HOT 4 CLOSED

True, I guess that avoids the external dependency. I like the @bind syntax for performance reasons (the bound method is more easily garbage collected), but for demos it is unnecessary.

Do you think the class property syntax for methods will be understandable for people? I guess we could add a note with a link to an explanation if need be.

from preact.

Personally I find it more attractive and people should use it too. It's on stage-1 as far as I know.

What is your opinion about GC with this code transpiled? https://goo.gl/Dux8xW

If everything is ok with it - I think we should insist on using this syntax so we would teach newcomers more about es2015-2016

And propose linkState as not salvation from bind problem but as useful tool, which helps binding without addChangeListener etc or activating something via actions.

from preact.

My GC comment was mostly about the transpiled code (creating a closure within the constructor) - I'm not knowledgable enough about the 2016 spec to know if the actual implementation in engines would be significantly different.

On one hand its nice because you use a single shared closure to scope the context for N arrow functions (ideal). On the other hand, while Function.prototype.bind() has worse runtime performance than creating a closure, it pushes the problem into the JS engine, which will always get faster over time. Since .bind() internally creates functions that are not quite the same as regular JS functions (like a lightweight proxy), I've always pictured the internal implementation being something like a Weak Map (I may be wrong on this?), which is more easily garbage collected than a closure.

That said, since my reasons for liking @bind are mainly style and opinion, I don't want to force that on anyone. We can certainly start switching the examples over to use class property arrows in place of @bind(). Perhaps I'll even take to doing it in my own work ;)

As for linkState(), I'd like to reword some of the documentation to be more along those lines - it's a way to create event handlers declaratively, anything else is basically sugar.

Cheers

from preact.

@idchlife I'm migrating this to developit/preact-www#7 since that's where the PRs will go.

from preact.