Can we change the link to the video instead of the slide deck? https://www.youtube.com/watch?v=9QObt0SGriI&feature=youtu.be
Slide decks are (mostly) meaningless without context.
Don't React
81–90 of 131 posts
Re: Don't React
#82It's becoming rather frustrating how often people are misinterpreting "reactive programming", the author included.
Re: Don't React
#83I agree with others that the author seems to be missing the point of React. Whether or not it is "reactive" or doing things the way you're supposed to do them is irrelevant. It's a tool, and it either helps you fix your problem, or it doesn't. IMHO React helps a lot.
I've built a few non-trivial apps with React this year (e.g., https://github.com/robmclarty/barss), and after years spent building and maintaining apps made with backbone, angular, jquery, and other libraries (considering the domain of React => the view) I can easily say that React has saved oodles of time, allowed me to greatly understand my apps as a whole much more clearly, and enabled me to think less about propping up a structure for my app and focus on actually designing my app.
The point is, it's not about what's passive or reactive or [insert enlightened path to programming here]. It's about what works; what keeps the ball rolling; what gets your app online and in front of users.
When it's snowing outside and I'm making a decision about what I should cover my feet with, I'm concerned about "what will keep my feet dry?". When I'm moving across town into a new apartment, I'm concerned with "what will have enough volume to transport all my junk?". When I'm making an app, I'm concerned with "what will make this design in my head work in a browser?". Whether I wear boots or shoes, whether I use a diesel truck or a gasoline van, or whether I use React or Whatever; that's not what's important.
I like that React doesn't drag me into event-listener hell where stuff is firing from somewhere that I don't know where. I like that React compartmentalizes templates with the behaviours that manipulate them. I like that React passively alters itself based on state changes.
When it comes down to it, an app is, simply, an interface for mutating and presenting data. It can be in one of many possible states at any given time. React just presents a view of the app that is based on its current state of data. With React, all I have to worry about, conceptually, is "what's the data?" and my app reconfigures its presentation accordingly.
TL;DR At the end of the day it doesn't matter what's right or wrong, it matters what realizes your intentions as a programmer (and as a human). The way React works makes my job easier, more productive, and faster. It doesn't suck at all.
Re: Don't React
#84With all the hype going around for React, I wouldn't mean getting the opinion of some other fellow front-end peers to see what their 2 cents are with this. I will say I honestly haven't looked into React enough to make a good call if this slideshow holds up or not. React does seem to be riding the hype train pretty fast, though.
I haven't formulated exactly why, but I think all this talk about "hype" is somewhat toxic, and if not toxic, then excruciatingly boring. Who cares? What do we gain by talking in such terms? As soon as a new thing arrives that people seem to enjoy using, is it a "hype train"? No—it's just people making decisions! That whole popularity contest discourse makes me enjoy Hacker News less, because I feel like my opinions will be interpreted in terms of imaginary hype.
Re: Don't React
#85I actually look forward to the day when React is not engulfed in hype, so people will stop complaining that it's just going to go away when the hype dies. Programmers love to make things. When you make something, you want to bash the thing that you are "better" at. This comes will all kinds of blindfolds though (you may be on the right track, but you need to be aware of these blindfolds). There are so many examples a…
Some of the criticisms the author points out still hold. For example, criticism that React doesn't give a place to plug in to do post-processing on nodes is valid, and is even a point that David Nolen makes in the video you linked to.
The author is probably wrong to dismiss React because of all the other benefits, and the community/platform aspects you brought up, but him complaining about these issues (the subset of his issues that are valid, that is) still provides a lot of value to the community.
Re: Don't React
#86Presentation 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-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), 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 and 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
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
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 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.
Re: Don't React
#87"There are only two kinds of languages: the ones people complain about and the ones nobody uses" - Stroustrup
Its kinda make sense in this context.
Re: Don't React
#88[deleted]
Re: Don't React
#89I actually look forward to the day when React is not engulfed in hype, so people will stop complaining that it's just going to go away when the hype dies. Programmers love to make things. When you make something, you want to bash the thing that you are "better" at. This comes will all kinds of blindfolds though (you may be on the right track, but you need to be aware of these blindfolds). There are so many examples a…
Some of the criticisms the author points out still hold. For example, criticism that React doesn't give a place to plug in to do post-processing on nodes is valid, and is even a point that David Nolen makes in the video you linked to. The author is probably wrong to dismiss React because of all the other benefits, and the community/platform aspects you brought up, but him complaining about these issues (the subset of…
That's definitely true, it's great to see parts where React doesn't allow people to play with something. It would be a lot more constructive though to build on top of React so we could more easily see the point. Additionally a lot of these problems are well known so before building your own framework, it's worth engaging the React community to see what we are thinking about them.
Re: Don't React
#90For anyone else who, like me, didn't realize it - there's a little triangle on the bottom right to let you go through the presentation.
[deleted]