Why did we build React? | Hacker News Reader

Why did we build React?

facebook.github.io

65 pointspeterhunt30 comments

React is awesome. This weekend, I rewrote the Khan Academy exercise editor which looks like this:

https://s3.amazonaws.com/uploads.hipchat.com/6574/26709/htv8...

(The right side is a live preview of what's on the left. The editor is open-source https://github.com/Khan/perseus but not yet documented, sorry.)

React made the code about 15% shorter and also made an order-of-magnitude improvement because it's smarter than I was being about figuring out what's changed and when it's necessary to touch the DOM. Of course, I could've made the same perf improvements by hand but it was easier and quicker having a library that just handles everything.

(This comment sounds a little like I'm getting paid to write this. I'm not! Just really hope that React takes off.)

What sort of environment are you using React in, and what process did it replace? (trying to get a better understanding of how it fits into the modern JS app world).

Even after this explanation, I feel I'm just too dumb to understand the benefit. I'm not being negative, but until I see a real use case, I'm just don't see how this fits.

You're not alone. I don't understand the benefit either and the examples confuse me even more. The JSFiddle example[1] brings me back to the days of tightly coupled Views and Controllers which I've spent the last six years trying to keep loosely coupled. The interesting part is that tight View-Controller coupling is touted as a feature.

  > By unifying your markup with it's corresponding view logic

I need to see a real use case as well.

[1] http://jsfiddle.net/fv6RD/3/

So I've used Backbone and now I'm using Angular. I work a lot with D3, creating SVG's in "render"-type functions (still grokking how this all fits in with Angular directives, but that's another story). One benefit from this article that jumps out is the smart rendering that React does.

If you had a scatterplot with thousands of points, being able to add or subtract a couple without re-calculating the whole thing would certainly interest me.

I've been playing with React a little bit, and so far I like the experience a lot.

Rendering is incredibly quick, since React only touches the parts of the DOM that have changed. Components are very lightweight, so you can break down the UI in as many, self-contained parts as you like.

And you can do pretty much anything you like without ever having to use a single selector or DOM manipulation. That means that you only need classnames for CSS.

The only downside I've discovered so far is the extra tooling required to use the embedded HTML, and lacking compatibility with other tools, but I suppose that will become better with time.

I don't get it. Anyone whose created sites with only JQuery and felt that pain has moved to frameworks like angular/ember/knockout/etc. Those frameworks help decouple the html from your js. This seems exactly opposite.

It like developing with JQuery where you had something like:

$('.whatever').append('<div>Hello ' + this.props.name + '</div>');

and now with JSX you can do (minus the React structure around it):

<div>{'Hello ' + this.props.name}</div>

So... looks a bit nicer... less quotes...? But so what. I don't want to tightly couple my presentation to my logic.

Decoupling is not necessarily about using different languages for the different components. Smalltalk MVC was all written in Smalltalk for example and that doesn't mean that the M the V and the C weren't decoupled.

I have no experience with React but using JSX (or Javascript) to manipulate the DOM doesn't necessarily mean your view is not decoupled from your controller or model.

I have been looking at Angular a lot lately and this is another example where view components are constructed from a mix of html(templates), the DOM (directives), and Javascript (the code that implements directives). The model is pure Javascript objects and the controller is also Javascript.

Decoupling is an abstract concept that can be realized in many different ways.

Imagine this scenario:

I've developed my app. Designer gets hired later and spits out a cool new layout and design... No feature changes at all.

similarly...

Then next year, management decides we need to give the app a "fresh new look" for v2.

[If I'm using React or JQuery-only] From what I can tell, this will cause me to have to dive through a whole bunch of JS code where I'm sifting through business logic and imperative code to find JSX/html sprinkled throughout and make the necessary changes. Also, since I'm changing actual code the chances of introducing new bugs in this process is high.

[If I'm using Angular] Go through html. Change html and css. Leave code and business logic alone.

This is not an entirely contrived situation (at least not for me). As I'm working towards a releasable product, one of the areas that go through the most change and flux is the design and layout.

With React, if you've structured your components correctly (i.e. only display logic) it should be straightforward to change the layout. In fact, it should be easier, since React is modular and has clearly defined boundaries and semantics.

Working with React components vs angular directives are pretty similar in terms of difficulty for designers, IMO, but we think that React components are easier to build than directives. Most designers can figure it out if they know html.

If the JSX inline xml looks vaguely familiar, it's probably because they did the same thing with php (xhp [1]).

One criticism about facebook, google, etc is that the greatest minds are being used to make people click more ads. But they're open sourcing some interesting things so it's not all bad.

1. https://github.com/facebook/xhp

    return <div>Hello {this.props.name}</div>

What is this returning? A string, or a var '<div>Hello {this.props.name}</div>'? Never seen js that looks like this

It's JSX: http://facebook.github.io/react/docs/syntax.html

So jSX is a language that compiles down to js? Looks like its supported in Chrome but can't confirm any others. If so, you should make a note in the docs, not sure many devs are familiar with JSX.

ps. looks like a useful project

See also http://facebook.github.io/react/docs/getting-started.html, linked from the previous page, and the subsequent example JSFiddle(s). JSX does and is recommended to be compiled down to JS, or you can directly use the JS syntax it will otherwise compile. Otherwise, if you only want the compile step to be apart of your production toolchain, you can include the JSXTransformer in development environments, which will perform the transformation in the browser -- not just Chrome.

What this actually returns is a lightweight DOM-like structure. The framework then uses that to make modifications to the real DOM. In the case of the first render that's going to mean setting innerHTML of something. After that though, if you re-render this component with a different value for props.name, React won't re-render the <div> in the DOM, but will instead just modify it's contents.

From the article: > The data returned from render is neither a string nor a DOM node -- it's a lightweight description of what the DOM should look like.

Like @thezilch said, the syntax is JSX, which is pre-processed into runnable JS.

Correct me if I'm wrong, but it looks like React reinvents some things that have been in jQuery for years, like cross-browser event handling and DOM utilities. Why not build on top of jQuery?

React does have a little overlap with jQuery but probably not as much as it might appear. jQuery isn't designed for writing components declaratively and then checking what's changed so it wouldn't simplify the React code much at all. (Plus, React is only 55% the size of jQuery.)

So how does one normally do Ajax in a React app? Use XHR directly?

I'm actually not sure. In a side project I'm building with React, we have been using jQuery (Zepto, actually) for XHR only and it would be nice to get rid of it completely.

You're more than welcome to use XHR however you see fit. We don't dictate that choice. For many that will mean `$.ajax` - React plays nicely with jQuery (so long as you don't modify the DOM out from under us). For others that might mean a thin library that does that the same thing.

If you're interested in using jQuery with React, we have an example: https://github.com/facebook/react/tree/master/examples/jquer.... It doesn't use XHR but it should give you some idea of how the 2 can play nicely together.

I don't know about React as a whole, but with one thing I agree with them: I much prefer creating views programatically (with document.createElement) than using templates.

I'm comfortable having one line of HTML in JS, but if it's longer, I want to use a template.

What's your reasoning behind this?

Because its easier to see the html in context of the whole page or partial... because any significant html contains presentation properties (class names typically but also attrs like placeholder, etc) that I would rather not mix with code/logic... because my html typically contains elements whose sole purpose is to assist in layout which (again) i'd rather not mix with code/logic...

We don't think that separating html and code/logic is a productive separation of concerns. They aren't separate concerns. The code that drives the view and the markup it generates are intimately tied and separating them violates the principle of high cohesion (http://en.wikipedia.org/wiki/Cohesion_(computer_science)#Hig...)

I think the reason that most people think this is a good separation of concerns is because they used WYSIWYG editors in the past (which are no longer used in large projects) or because they have PHP spaghetti code hangover from the 90s.

Mixing code and markup isn't evil in and of itself, it's mixin non-display concerns with display concerns which causes issues.

With React, you can use components to separate concerns with finer granularity and in ways that are more tailored to your application.

I'm all for tightly coupled display-logic and its markup; I just don't think it should reside in a JS(X) file unless it's generating a single tag.

While I agree that other MVC frameworks are not great (I've seen many of Angular's pains & weaknesses), I think this was a step in the wrong direction.

http://jsfiddle.net/vla/Cdrse/(from https://medium.com/make-your-own-apps/e71bcedc36b) versus https://github.com/petehunt/react-tutorial/blob/master/scrip...

I'm curious, what do you mean by "generating a single tag"?

I'm confused as well. Sounds a lot like emberjs?

Yes, it's an alternative to the view portion of Ember (and Angular). If you're already using one of those then it probably doesn't make sense to use React in conjunction with them but React does play well with Backbone models, collections, and routers.

Reply on news.ycombinator.com