6 ms·

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

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.

sim0n 10y ago
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 10y ago
  Thanks! So is react the only JS framework you use now (besides jQuery)?
  - sim0n 10y ago
    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 10y ago
  Out of curiosity, what do you usually use on the backend?
  - sim0n 10y ago
    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 10y ago
      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 10y ago
        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 10y ago
        *isomorphic (FTFY) Nice project!
andreasklinger 10y ago
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
- garrincha 10y ago
  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.
  - rukuu001 10y ago
    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 :)
  - ggregoire 10y ago
    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 https://github.com/johnpapa/angular-styleguide [2] https://facebook.github.io/react/docs/tutorial.html https://facebook.github.io/react/docs/tutorial.html
hathawsh 10y ago
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 10y ago
  The virtual dom is an implementation detail, it doesn't make sense to sing its praises here.
  - ZenoArrow 10y ago
    The Virtual DOM is a central part of how React works, so it does make sense to mention it when appraising React.
    - 10y ago
matt4077 10y ago
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 10y ago
  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 10y ago
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 10y ago
  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 10y ago
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.
dcwca 10y ago
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?
- mikevm 10y ago
  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?
- kimshibal 10y ago
  He's a Rails app developer. Not a mobile app developer.
- detaro 10y ago
  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.
kimshibal 10y ago
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 10y ago
  I don't like my peas and taters to touch neither.
oldmanjay 10y ago
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.
neebz 10y ago
I gave a talk on this few weeks ago; The slides can be found here: https://react-redux-presentation.herokuapp.com/ https://react-redux-presentation.herokuapp.com/ Hope it helps

sim0n 10y ago

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 10y ago
Thanks! So is react the only JS framework you use now (besides jQuery)?
- sim0n 10y ago
  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 10y ago
Out of curiosity, what do you usually use on the backend?
- sim0n 10y ago
  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 10y ago
    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 10y ago
      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 10y ago
      *isomorphic (FTFY) Nice project!

andreasklinger 10y ago

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

garrincha 10y ago
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.
- rukuu001 10y ago
  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 :)
- ggregoire 10y ago
  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 https://github.com/johnpapa/angular-styleguide [2] https://facebook.github.io/react/docs/tutorial.html https://facebook.github.io/react/docs/tutorial.html

hathawsh 10y ago

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 10y ago
The virtual dom is an implementation detail, it doesn't make sense to sing its praises here.
- ZenoArrow 10y ago
  The Virtual DOM is a central part of how React works, so it does make sense to mention it when appraising React.
  - 10y ago

matt4077 10y ago

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 10y ago
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 10y ago

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 10y ago
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 10y ago

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.

dcwca 10y ago

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?

mikevm 10y ago
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?
kimshibal 10y ago
He's a Rails app developer. Not a mobile app developer.
detaro 10y ago
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.

kimshibal 10y ago

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 10y ago
I don't like my peas and taters to touch neither.

oldmanjay 10y ago

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.

neebz 10y ago

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