31–40 of 77 posts
Still, perhaps we'll learn more about the roadmap and goals of the team at the React conference this week.
Hmm. Feels like big changes too early. While it is more idiomatic, i can't see any substantial gains here. Simply looks like more work to me until es7. Especially binding each method manually, That shit's wack! And im actually kinda scared to see OOP features being embraced so quickly. Hopefully a changelog could ease my mind.
Hmm. Feels like big changes too early. While it is more idiomatic, i can't see any substantial gains here. Simply looks like more work to me until es7. Especially binding each method manually, That shit's wack! And im actually kinda scared to see OOP features being embraced so quickly. Hopefully a changelog could ease my mind.
I agree, I really don't like having to bind all the methods manually, and I'm not sure I agree with the argument of causing confusion. Being used to having to bind and finding out it's being done automatically in React is just a sweet surprise. And besides, I'm sure we'll only see more and more automatic binding in future projects?
Something like,
this.handler = new Handler(window, "mouseup", () => this.whatever());
// later...
this.handler.detach();
I'm disappointed to see this prioritized over, say, a focus on reduced library size or simply getting to a stable 1.0 release. I'm not sure how this moves React forward, though I'm sure it's a "nice to have" for some people. Still, perhaps we'll learn more about the roadmap and goals of the team at the React conference this week.
Also, is 40kb gzipped really something to lose sleep over? Especially when the mere act of moving from old jQuery/Backbone soup to React reduces the size of my real code by a far greater amount.
Like classes matter. JS doesn't even have them, not in ES6, not in ES7. It's all just sugar for prototypal inheritance, which has nothing to do with OOP. I don't see any future for OOP in JS land. They'd be better off investing time in reducing side-effects, and the enormous size the library sports.
In fact, they're doing the opposite: deprecating proprietary pseudo-OOP `React.createClass` helper and let people use whatever they fancy. This makes it easier to write React components using idiomatic constructs from different languages, whether it is TypeScript, ClojureScript, CoffeeScript, or whatever. Also lets you use any mixin system, if you need it at all.
React's stance on inheritance: https://github.com/facebook/react/issues/613#issuecomment-29...
“Minimal API surface area”: http://www.youtube.com/watch?v=4anAwXYqLG8
Earlier quoted context omitted.
I think what you are looking for is called auto-lifting. That is, automatically lifting functions into reactive streams. While it sounds like an awesome idea, things get crazy really fast. It's hard to explain briefly, but make it explicit and clear to the programmer which things are reactive streams and which are simply values makes it much easier to predict what the program is doing.
In my opinion, the current way of doing things with reactive mechanisms really doesn't make it clear what the program is doing. There's lots of things happening at the same time, and also glitches can occur (variables rapidly changing after eachother), and also non-optimal efficiency (things being recomputed unnecessarily). If my program just gets re-evaluated in an optimal way (without any other side-effects) then t…
Check out Adapton though, which is trying to bridge the gap.
Personally I don't see why I would go back to using classes. IMHO, classic OOP doesn't fit to modern JS. I guess it's good to have the option though.
"Modern" JS simply didn't have classes, so classic OOP couldn't fit. People still tried a million different hacky ways though (eg; `React.createClass`). I'm disappointed with the implementation in this case (no mixins??) but the idea of going to classes now that we finally can makes sense.
The point is moving mixin handling to userland (and eventually some sort of standard?), if I understand correctly. It's not really React's concern.
See also: Minimal API Surface Area http://www.youtube.com/watch?v=4anAwXYqLG8
Earlier quoted context omitted.
Maybe off topic but I've been wondering whether many people are finding spending time on TS worthwhile? Given the improvements in ES6, the fact that the JS community in general is so active, and the fact that I've seen some truly awful TS code (mainly where the devs want to pretend the web doesn't exist) I've been put off exploring TS too far much (beyond looking at the basic language features). I'm not sure if I sho…
After quite some consideration I chose to convert my ActionScript3 project to TypeScript. I knew I had to move away from flash for a while, and personally I really prefer to code big framework-like projects with static typing, so I gave it a go and it I have to say it has been really enjoyable. My code looks really neat, and unlike many other comments here, my code is very much targeted at the web and bound to how js…