[garrincha]

I'm a Rails developer. I work on pretty standard web apps for a living. Some more complicated than others, but still, web apps.

I still haven't found a person that was able to give me a concrete reason why someone like me should invest time and resources into learning React and using it in my projects.

This is an honest question, I'm not trying to be sarcastic. It's just that there are so many frameworks that come out that it's very hard to know where to invest your time.

[hathawsh]

I understand your dilemma very well. I have experience building server-rendered web apps, web apps enhanced with jQuery, Angular apps, and React apps. I resisted React for a while, but I'm glad I finally tried it out. Compared with jQuery or purely server-rendered apps, React elevates what you can accomplish within a short time frame. A complex web form with async validation, client side calculations, and multiple branches can be a real pain to code as a server-rendered web app or using jQuery, but React uses a different abstraction that makes a lot of code easier to reason about.

React achieves that with the virtual DOM concept. On the initial render, the virtual DOM concept is nearly equivalent to the kind of HTML templating you're familiar with; you simply render a document with some substitutions. It's what comes next that's interesting: when you need to change something on the page (for example, when you need to display validation feedback for a form field), you don't add code that finds the DOM element and changes it. Instead, with a virtual DOM, you re-render your components with new data, and the virtual DOM figures out what changed and applies the changes. Event handling is much simpler.

React has only a few concepts; once you get it, there's only occasionally a need to read the React documentation. Angular is also powerful, but Angular has many concepts and I found myself referring to the documentation for every little thing. That may have changed with Angular 2.

EDIT: I should also point out that React adheres to the idea of putting HTML tags in code, rather than putting code in HTML tags. For simple templates, it doesn't really make a difference, but for some of the whopper HTML templates I've written before, putting HTML in code (aka JSX) would have been a major benefit. There are plugins for editors like Sublime Text that make JSX smooth.

[bostonvaulter2]

The virtual dom is an implementation detail, it doesn't make sense to sing its praises here.

[inimino]

React only needs a render method, not a render method and an update method for every state transition. Without the virtual dom this would destroy performance, so it is a rather key detail in understanding React's appeal.

[ZenoArrow]

The Virtual DOM is a central part of how React works, so it does make sense to mention it when appraising React.

[danabramov]

FWIW we are trying to avoid "virtual DOM" in the new docs. The thing you create in render() and that describes the tree has been called "a React element" for many versions by now. "Virtual DOM" was more of a marketing term and I find it misleading because it doesn't make sense with e.g. React Native, and also makes React seem like a performance trick. React is not a performance trick. That elements get compared by React DOM renderer is its implementation detail. React is abstraction for dividing UI into predictable pieces, not a performance optimization.

[hathawsh]

Thanks for pointing that out. The term "DOM renderer" does seem much clearer than "virtual DOM".

[ZenoArrow]

> "React is abstraction for dividing UI into predictable pieces, not a performance optimization."

Why can't it be both?

[danabramov]

Performance is baseline. If something isn't performant we won't use it. But that's not the point of React.

React wouldn't exist if it wasn't performant. But the reason React exists is not performance.

[hathawsh]

If I wanted to do what React does, but without React, I might start like this:

document.innerHTML = myComponent.render();

That way, I can write components similar to React components and it can render very quickly. However, this strategy would work only on the initial render, because this naive strategy would destroy implicit DOM state like scroll positions, focus state, and cursor selections. The React DOM renderer (formerly known as the virtual DOM) lets me apply this rendering strategy without ruining implicit state.

The DOM renderer does not give me components or performance, since I can already achieve those things with raw Javascript. What it gives me is the ability to use a simple, clean rendering strategy without destroying the DOM state. That's why the React DOM renderer is not just an implementation detail.

[sim0n]

For me, once I started declaring my UI as a series of components that simply render what they are provided (the common `v = f(d)` expression), it was hard to go back to the Backbone/jQuery way of mutating things all over the place and manually updating DOM nodes to try and reflect the current app state.

[garrincha]

Thanks! So is react the only JS framework you use now (besides jQuery)?

[sim0n]

For view/UI, yes (if you can call React a framework). I personally do not use jQuery anymore as there is not much need to deal with the DOM directly when using React and when there is, I just use vanilla JS.

Since React only deals with UI, I use it alongside a bunch of other great libraries such as Redux (for state management).

[garrincha]

Out of curiosity, what do you usually use on the backend?

[sim0n]

The backend where I work (Airbnb) runs on Rails but most of my projects use node on the backend since they usually just expose a REST API.

Since it only cares about UI, React is obviously not opinionated about your backend/server environment unless you're trying to do server rendering (then you need something in your stack capable of executing JS).

[tmzt]

I've spent some time looking at the 'needs a JS runtime' part and am prototyping an isometric framework in rust which renders with natively compiled code on the server and generated JS on the client, both generated from the same source template and logic. The JS can also be cached and served statically.

The server-rendered page is then instanced in the browser and differential rendering can be performed. I have been interested in doing this concept using React but have decided to prototype with a simpler implementation called Incremental DOM.

My project is at github.com/tmzt/incrust.

[supergreg]

Nice. I was always wondering why no one was trying to do isometric stuff in other languages since every language and their mother seem to have a compile-to-js feature.

[rounce]

*isomorphic (FTFY)

Nice project!

[andreasklinger]

the obvious case:

consider a complex submission form with updating state

eg you want to show uploaded images while editing parts of it etc

the realistic case:

if you have a rails app and do frontend "interactive stuff" you end up w/ some js frontend framework - let's say backbone - or even if it's just jquery send as ejs - you will have some sort of dynamic updates, maybe even frontend duplication of templates, you will add classes to places and interact with parts of the page, other people will add more features, some parts of the feature gets removed, that part of it moved to another site, to keep it working you need a certain setup on the page, etc et

pretty soon this gets complex - this is where react shines

reasoning about the frontend is easy because you think in components and in state. not in ui and the interactivity with it over time.

tl;dr: react can help for either a by design complex part of your frontend or your frontend becomes complex over time

it does not help for fast prototyping or small apps imo

[arstin]

"it does not help for fast prototyping or small apps imo"

I can understand this sentiment---React really is meant for serious apps. There is a decent learning curve. There is small overhead. And though it now only requires just a tiny bit of setup thanks to create-react-app, it might easily require a very significant change to workflow habits. (And the fact that CSS is still held by some as an ideal way of maintaining UIs rather than a temporary requirement given what browsers can consume in 2016 is a testament to how how hard habits can be to change. But I digress!) If you're not already knee-deep in it, React is almost certainly overkill for a marketing page or a mostly static form-y interface for some rails backend.

But just to give an alternative opinion: I think React is great for prototyping. The big reason is that React allows you to easily build and use custom abstractions. When you get down to it, that's sorta the whole point of the library.

If you need to do something---maps, a text editor, a flipping clock---there's a decent chance a catalog like js.coach will already have a React component for it. And at just a single line import away, unlike old jQuery "imports" which typically required more setup which then was more fragile once you wanted to make a change somewhere else (like, you know, renaming an id).

And over the years, like many others I'm sure, I've evolved my own toolkit which happens to be perfect for prototyping. I can vertically align <Rows /> and <Columns /> just by passing "center". I can add a modal simply by typing <Modal isOpen={isProfileVisible}><Profile /></Modal> right next to the button which opens it. I can add data persistence and real-time updating mostly just by typing <FirebaseWrapper /> and tweaking some config for the new app. I could go on and on. And these are just little personal things which make life a little easier. There's also projects like react-flip-move which smoothly animates transitions in a line of code, react-sortable-hoc which gives, in a line of code, a sortable with pretty good touch support and essentially infinite lists......

Obviously in principle you can get these benefits in other frameworks. But React is one place where lots and lots of people are actually contributing to the ecosystem.

[garrincha]

Thanks a lot. This was already very helpful.

I'm still somewhat scarred from the time I invested a ton of time into Angular.

Not sure you would be able to answer this, but is React something that works well with Rails out of the box? For instance, I found that Angular (when I was learning it) required a fair bit of shoehorning to get it to work well with rails.

[ggregoire]

Angular and React are like black and white when we talk about time of learning.

Simply because :

- Angular is a full framework including html templating, directives, components, controllers, services, router, xhr abstractions ($http and $resource), dependency injection, two-way data binding by default, one-way data binding if you want (to fix performance issues) and the list can continue. Plus, you need to set and learn a style guide [1] and some good practices because, if you have 2 developers, none of them will code in Angular in the same way.

=> it took me weeks to learn, and months to master.

- React is just a library to build views. You code 90% of your time in basic JS and 10% in React APIs (basically: states, props, lifecycle methods and that's it).

=> it took me 1 hour to learn, and 1 week to master.

If you want to learn React, you just need to read the official tutorial [2].

---

[1] https://github.com/johnpapa/angular-styleguide

[2] https://facebook.github.io/react/docs/tutorial.html

[verletx64]

This is pretty misleading as a comparison, yes you can learn React itself very shortly, but the ecosystem around it will probably bring you much closer to Angular learning times, and that's also without the AngularJS documentation which is top notch.

I prefer React to AngularJS but I don't think it's fair to tell half the story when comparing them.

[bostonvaulter2]

But the downside to learning react is learning the react ecosystem, redux, other flux frameworks, etc.

[davedx]

I'm working on an app for work that's a Rails API backend with a React front end. This stack is a pleasure to work with, once you get past the initial bits of setup.

With React I use Redux for state and ES7 bits for async and await. Productivity is high.

[kwood]

I was in quite the same situation, Angular 1.x was quite hard to grok at first. But React just "clicked" instantly.

For integration with Rails, I found https://github.com/reactjs/react-rails to be quite useful. It integrates the Babel transformer for JSX into the asset pipeline and brings a couple of helper functions, so no additional setup needed.

You start writing your components, "mount" them via the helpers in standard .erb templates (or even without the template directly from a controller action), done.

[rukuu001]

React in its basic form is pretty simple, you'll grok it in a couple sessions of playing with it. And since it's 100% view, you can fit it over pretty much anything.

This is assuming you're prepared to do rendering in the browser. If you want to do server side rendering I think you'll be doing more shoehornig :)

[zodiac]

Personally I use my backend (rails, flask, etc) just to expose an API and react in the frontend, it's a pretty clean separation

[dcwca]

When you separate the web app from the server and build it as a stand-alone React codebase, you can create applications that run in the browser, iOS, Android (via Cordova / reapp) and cross-platform desktop operating systems (via Electron).

Now wait a minute, you're going to say, I can do all of that with my server-side web application. And faster too. Sure, but does your application work when the user is offline? Does it have access to the client runtime's local storage for data persistence? Can it access client hardware like the camera, GPS, and accelerometer? Can it be distributed through Google Play and the Apple App Store? Can it be installed as a desktop application?

[kimshibal]

He's a Rails app developer. Not a mobile app developer.

[mikevm]

How do you use the same codebase across web, mobile, desktop when your app is going to access camera/gps/accelerometer which aren't available on desktop?

[detaro]

Is reapp still a useable thing? The demos on their homepage are broken and the GitHub repo doesn't seem to have been updated for months.

[matt4077]

There are some impressive numbers (from google I think) about conversion/retention/bounce rates in relation to page load times. I believe it was about a 50% reduction for every extra second.

Page loads are mostly download (bandwidth-limited) and layout. For many actions, you can reduce drastically reduce data transfers if only the actual data that changes is transferred (no markup/images/content already loaded). Similarly, only a small part of the layout may change. That can result in anything from doesn't really matter (newspaper) to "this project wouldn't make any sense without it" (google docs).

[virtualwhys]

Given that SPAs tend to have payloads in the MBs, high conversion rates must be based on the end user having a very fast broadband connection. They probably wouldn't stick around for the initial page load otherwise.

Modern browsers are very good at caching resources. For server-side apps the browser is often just downloading the html for the page and nothing else. Compare that with downloading json from the server and applying changes to the virtual DOM. The difference is neglible wrt to speed and is, IMO, oversold.

[john_gaucho]

Thanks for asking this question. I'm also a Rails dev, pretty much in the same situation. Some people are mentioning that if you want to do some server side rendering then things can get a bit more hairy.

Well I don't want my backend app to be just an API and the frontend to be a client. I'm not trying to argue whether or not that is the correct way to build web apps, but I don't want to do all the rendering on the frontend. The reason is that I think this would make smaller projects a good deal more complex. Maybe you can convince me I'm wrong. Again, I can imagine that if you are a big company this might be the way to go. But for building small to medium web apps I think Rails (and the Rails way of building apps) works well. What I'm trying to figure out is if I can incorporate React into my toolbelt and have it work well with standard rails apps.

Apologies for my grammar.

[kimshibal]

You are not wrong if it just you or very small team. Because this new movement with npm and built tools. Things can get messy.

If you want to deploy 1 app. Develop in 2 folder(front end and rails backend). Built front-end js file and paste the asset in rails/public folder.

[qudat]

It really depends on what kind of apps you are building. If it's a complicated CRUD application that can be created without much heavy lifting javascript, then you'll probably be fine with vanilla js. However, once you start getting to the build where your front end application code gets larger and more complex, something like React will scale very well.

[neebz]

I gave a talk on this few weeks ago; The slides can be found here: https://react-redux-presentation.herokuapp.com/

Hope it helps

[oldmanjay]

If you don't have your own reason to learn react, and you don't care to learn this stuff for fun, then you shouldn't bother.

[kimshibal]

I'm a Rails developer too. I always use Turbolink for everything with jQuery. If the app requires mobile and web, I'll just work on the rest api on rails. The client site will be another app. This way doesn't mix ugly js files with rails files.

What you need is Vue.js. Other frameworks are waste of time. Angular 2 is complex and slow. React has it's own drama(jsx, react router).

[Rapzid]

I don't like my peas and taters to touch neither.