Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't React

staltz.com

Post reply on HN
Print view View original

111–120 of 131 posts

Re: Don't React

#111

Post by nwienert »

woah wrote: post #109
nwienert wrote: post #99

React really doesn't give you any way to handle communication between components besides going downwards, which is fine because that solves a lot of problems. You can very easily implement his 'subscribe' scenario in React. In fact, in 0.14 they are planning on having observe[0] to help you do just this. Now, for my little plug. I've been working on Reapp since launch building a couple real-world apps and I agree tha…

Reapp looked awesome, the issue is that the 'back-swipe' on my iPhone 5c was noticeably less smooth than the real thing... are you guys going to have to resort to some more exotic techniques to fix that?

At launch that hadn't been optimized, which it has been quite a bit since then.

We do need to optimize it further. It's actually React that is getting in the way here, but we don't want to cheat and break out of React because that would mean so pretty major disadvantages. We're thinking about building out either a separate animate() pipeline that works differently from render and just lets you use refs to animate things. Or, just optimizing further as there is some stuff we can do.

Re: Don't React

#112

Post by kodablah »

jaked89 wrote: post #47

It's worth mentioning Elm, a (truly) functional-reactive language, based on virtual-DOM. http://elm-lang.org/

While mentioning other tech, I have found Scala.js with Scala.Rx [1], ScalaTags [2], and some glue [3] a great way to actually do reactive DOM updates based on state change. I find this way cleaner than building and diffing entire DOM trees (even if they are just AST's in JS). Mixed with ScalaCSS [4] you have a nice type safe solution.

1 - https://github.com/lihaoyi/scala.rx 2 - https://github.com/lihaoyi/scalatags 3 - https://github.com/rtimush/scalatags-rx 4 - https://github.com/japgolly/scalacss/

Re: Don't React

#113

Post by dwg »

EugeneOZ wrote: post #106
dwg wrote: post #95

I recently finished building a small-ish web app for a major federal Government customer in react.js. They are very happy with responsiveness and quality of the product. I'm very happy with how easy and cost-effective it was to build. To get an idea of the size of the app, it has about 20 components. However, some of the components could (and probably should) be broken down. My hunch is that with refactoring the fina…

"Other frameworks", but React is not a framework, just UI lib :) Sorry to be pedantic, but framework gives much more often.

Quite alright—I'm usually very precise on these matters as well.

Nonetheless I disagree with the point. My opinion after actually having used React.js is that it is more than a UI library. I've used other UI libraries and React.js is more "comprehensive." I do grant, however, that React.js alone will not suit most needs. You will generally want to add a few other pieces. In my case I also used refluxjs and react-router. I also used store.js as an abstraction for browser storage.

Re: Don't React

#114

Post by vuldin »

balls187 wrote: post #102
dwg wrote: post #95

I recently finished building a small-ish web app for a major federal Government customer in react.js. They are very happy with responsiveness and quality of the product. I'm very happy with how easy and cost-effective it was to build. To get an idea of the size of the app, it has about 20 components. However, some of the components could (and probably should) be broken down. My hunch is that with refactoring the fina…

As is covered ad naseum else where, ReactJS is just a way to do Views. What did you use to manage state, data flow, communication to servers, etc?

It's worth mentioning that this was not an issue the author even brought up, I assume since React doesn't claim to handle any of these other concerns in an application. Saying React doesn't handle these functions is like complaining about a screwdriver not being able to hammer a nail very well.

Re: Don't React

#115

Post by EugeneOZ »

staltz wrote: post #86

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-matte... 2. Apart from the core ideas, the surfacing API has its problems: synchronous render (a problem for serve…

Well, not sure about first point. We already have FlightJS (https://flightjs.github.io/) couple of years, which is event-driven also (even templates looks similar to React UI).

Re: Don't React

#116

Post by nogridbag »

I've used Flux now on a few toy microprojects and I found that while Flux's unidirectional data flow is initially appealing (and I naturally tend to write unidirectional code for very complex UIs in past apps),it makes the simple cases much more tedious and error prone.

For example, given the simplest case of a Flux store handling events from a single ajax call, I find I have to write code like this:

  onLoad() {
    this.loading = true;
    this.errorMsg = null;
    this.data = null;
    this.condition1 = null;
    this.condition2 = null;
    this.something = null;
  }

  onSuccess(data) {
    this.loading = false;
    this.errorMsg = null;
    this.data = data;
    this.condition1 = data.blah === 'Hello';
    this.condition2 = data.blah2 === 'World';
    this.something = data.something;
  }

  onFailure(errorMsg) {
    this.loading = false;
    this.errorMsg = errorMsg;
    this.data = null;
    this.condition1 = null;
    this.condition2 = null;
    this.something = null;
  }
If for some reason I was feeling crazy and I wanted the store to handle a second Ajax call, the store code becomes much more cumbersome so I avoid this.

Even with some of the slicker Flux implementations, I still have tons more boilerplate than a traditional MVC app which for the simple UIs makes the code more difficult to reason about. For example, I find that in my store, I frequently forget to "reset" some property thus making the state "invalid". I've come up with this type of pattern, but it just feels... odd:

  resetInitialState() {
    this.loading = false;
    this.errorMsg = null;
    this.data = null;
    this.condition1 = null;
    this.condition2 = null;
    this.something = null;
  }

  onFailure(errorMsg) {
    this.resetInitialState();
    this.errorMsg = errorMsg;
  }

Re: Don't React

#117

Post by balls187 »

woah wrote: post #105
balls187 wrote: post #102

Earlier quoted context omitted.

As is covered ad naseum else where, ReactJS is just a way to do Views. What did you use to manage state, data flow, communication to servers, etc?

You can actually do a lot of that stuff with JavaScript, it turns out.

So you end up with an unmaintainable pile of javascript?

Or are advocating reinventing the wheel and writing a bunch of boiler plate javascript to marshal data, update state, etc?

----

One major reason to use a JS framework is to enforce good design and coding practices to allow for more maintainable code.

You can certainly implement these patterns yourself in Javascript, but you are reinventing the wheel, which is an antipattern in pretty much all but the edgiest cases.

Re: Don't React

#118

Post by EugeneOZ »

I never understand people who claims "Don't use X" (about software). If you don't like X - don't use X and calm down, don't be a bigot crying "you all are doing it wrong" - let people make mistakes. Maybe some of them will find right solution on the next step, just don't stay on their way.

Re: Don't React

#120

Post by balls187 »

vuldin wrote: post #114
balls187 wrote: post #102

Earlier quoted context omitted.

As is covered ad naseum else where, ReactJS is just a way to do Views. What did you use to manage state, data flow, communication to servers, etc?

It's worth mentioning that this was not an issue the author even brought up, I assume since React doesn't claim to handle any of these other concerns in an application. Saying React doesn't handle these functions is like complaining about a screwdriver not being able to hammer a nail very well.

It's also worth noting that this sub-thread is in response to another commenter, not the original article.
Post reply on HN