3 ms·
Presentation author here. I didn't publish this to HN myself, it was just discovered by someone among my repos. Some important things I want to make clear: 1.
by staltz 12y ago
Presentation author here. I didn't publish this to HN myself, it was just discovered by someone among my repos.
Some important things I want to make clear:
1. React is revolutionary. I really like the core idea inside it, which is basically just this
https://joshaber.github.io/2015/01/30/why-react-native-matters/ https://joshaber.github.io/2015/01/30/why-react-native-matte...
2. Apart from the core ideas, the surfacing API has its problems: synchronous render (a problem for server-side rendering https://github.com/andreypopp/react-async https://github.com/andreypopp/react-async), mutable API (setState) etc, and most of my presentation. I've spoken to others in the industry (would not like to mention names, but top experts anyway), and they both love React and agree it is contaminated with a bit of bad API.
3. React probably doesn't have the perfect API for the "UIs as pure function of state" approach. It can be improved https://github.com/facebook/react/issues/3398 https://github.com/facebook/react/issues/3398 and https://twitter.com/sebmarkbage/status/543660526908088320 https://twitter.com/sebmarkbage/status/543660526908088320
4. This presentation was given at a small meetup and I made it provocative on purpose just to have some fun with friends. The type of stuff you talk about in a small circle, not meant to publish on HN for the whole world https://www.youtube.com/watch?v=9QObt0SGriI https://www.youtube.com/watch?v=9QObt0SGriI
5. Cycle.js is not _better_ than React, it is my personal ongoing exploration in how to make React (or React's ideas) better. It is work in progress, and I'm breaking it apart whenever I find a better way of doing stuff. E.g. https://github.com/staltz/cycle/issues/99 https://github.com/staltz/cycle/issues/99
6. Cycle.js is not an antagonist to React. I am currently experimenting with Cycle.js + React Native. https://github.com/staltz/cycle/issues/91 https://github.com/staltz/cycle/issues/91 If React's API would be a bit less restrictive, I would use it for the web too. But virtual-dom by MattEsch is lighter and less restrictive, so I use that.
7. Don't be so harsh on HN as if I would be intentionally shouting to the whole world that React sucks.
- EugeneOZ 12y agoWell, not sure about first point. We already have FlightJS (https://flightjs.github.io/ https://flightjs.github.io/) couple of years, which is event-driven also (even templates looks similar to React UI).
- danabramov 12y agoFlight is not like React at all. I see DOM manipulation all over the place in Flight examples.
- EugeneOZ 12y agoMaybe that's the reason why it didn't take off the ground :) But their main idea is event-driven design, so I still think it's common idea for React and for Flight.
- jlongster 12y agoI feel bad for my comment now. I got lured in the typical HN response. Sorry! I hate just seeing slides from a presentation.
- mjackson 12y agoCo-author of ReactRouter here. With regards to #2, I used to think that a fully sync render function was a limitation of React, but have come to appreciate the fact that React tries to restrict its concerns to a very small, but significant piece. We've been working on solving the async data fetching use case in the router over the past few months, working with the Relay team as well, and we're starting to converge on some ideas and patterns that we think will help. But it's my personal opinion that sync render isn't a problem.