Rails vs React: What are the differences?
"Rapid development", "Great gems" and "Great community" are the key factors why developers consider Rails; whereas "Components", "Virtual dom" and "Performance" are the primary reasons why React is favored.
Rails and React are both open source tools. React with 132K GitHub stars and 24.5K forks on GitHub appears to be more popular than Rails with 43.6K GitHub stars and 17.5K GitHub forks.
Airbnb, Uber Technologies, and Facebook are some of the popular companies that use React, whereas Rails is used by Airbnb, Twitter, and Instacart. React has a broader approval, being mentioned in 3224 company stacks & 3094 developers stacks; compared to Rails, which is listed in 2322 company stacks and 799 developer stacks.
I'm looking to build up my own Auto Deployment tool for internal purposes (example deployhq.com, deploybot.com). I'm confused as to what tech stack I should use for the entire platform. My primary concerns are running parallel and concurrent builds to different targets (servers).
I have been researching and thinking of using Rails as backend and React as front-end (both deployhq.com and deploybot.com are built on these stacks).
If the goal is to have a system that is purely to be used within your company, then it would be a good idea to have something scrappy. However, lot more has to be considered if you are planning to offer it as a SaaS or PaaS.
In either situations, the first factor I would consider is Return of Investment. You can build a really fabulous system, but if it is only going to help you little bit in the overall scheme of things, it may not be worth the effort. In other words, you can build - job management, scheduling, progress tracking, auto recovery, maintaining container state etc all by yourselves, but it may be worthwhile not reinventing the wheel when these solutions are already available (Jenkins or Team City for example).
If I were you, I will offload majority of the features like triggering jobs (build jobs), monitoring progress, errors etc to Jenkins. Every deployable unit can be dockerized, so that you get an uniform interface to validate whether the service is up and running.
You can build a thin vanilla UI on top of Jenkins' apis using React, or simply jQuery or Svelte. My personal preference would be Svelte.
If Jenkins is not a viable option, Go is the perfect backend for anything related to devops. You can use any Golang frameworks (Gin or Beego for instance) and have a front end in React / jQuery / Svelte. Hope this helps.
I guess the bigger question is why are you building your own auto deployment tool for internal use? Assuming that is a good idea, I think this depends on how quickly you can develop what you need in a language and framework that you are comfortable with, choose that over everything at this stage. You could build what you need using rails easily and anything that needs to run as a backend process for builds etc can be farmed out as a job somewhere and can be as simple of complex as you like. You can even have those jobs spooling up docker tasks with an entire rails stack in to to do what you need. In summary, have your front end create jobs with enough data in to go build stuff, then queue up those builds with something job like. The jobs can be simple rake tasks or entire docker containers doing anything you like. Perhaps take a look at rails, shoryuken for queueing on AWS, AWS Elastic Container service for actually doing the jobs.
I don't think you can achieve parallelism with rails as I know ruby also got GIL similar to python. I'd recommend going with system languages, I'd some luck with Go to auto deploy scrapy scrapers. Or try java even though it's slow compared to other system languages but it's robust.
Currently working on my company's new saas, the main goal is to manage content and user. I'm familiar with the rails framework and how it is easy to code and deploy. The thing is I'm the only dev on the project, and in terms of the tech stack, there is no preference. However, because Node.js is everywhere and there is enough dev on the market, I am stuck between choosing Rails or Node.js. I don't mind implementing Vue.js or React on the frontend, but I need a solid argument to explain to people that aren't necessarily tech-savvy as to why we should choose Rails over Nodejs.
I'd use the following metaphor to non-technical people. Rails is like a prepackaged toolkit, which can get most of the common tasks done fairly with ease. Whereas, node.js with whatever backend framekwork of choice, is like a DIY toolkit assembled by mix-and-match different tools in a large tool shop. Of course, at times DIY toolkit can do better on specific tasks. Given that you are the only dev on the project, I'd assume that the resource is fairly limited. And looks like you are not building some next-gen super duper fast smart application. So Just go with the prepackaged toolkit then. Rails is a very opinionated framework, there're pros and cons to it. But thanks to that, many of the gems are coded with it in mind. For example, they are all designed with same naming convention. Many will work well together out-of-box, for example devise and cancancan. Besides, many stuff are built in the framework. For example, logging utility, csrf protection, session encryption, etc. Yes, many of those stuff may not be useful or necessary at the beginning of the project life-cycle. However, down the road, there is a good chance you will need some of those. And the moment you realize that you already have it, it's so delightful. In addition, it's usually easier to debug a rails app than a node app in my experience. Personally, the cases where I would pick node.js over rails would be projects either require a) high-performance, or b) certain core functionality that has been implemented by some node packages but not by any ruby gems. In term of performance, node has a clear advantage over any other major web frameworks, except the ones built with go. It's simply a language feature. Node allows developer to easily write code that runs db query, external api calls, or other stuff of that nature in parallel. And that is THE MOST COMMON performance bottleneck of web applications.
I hate to admit it, because I loved my time with Rails (and I still love the framework), I have a hard time justifying new Rails applications these days. Core team has made some tragic design decisions, and developers just don't perceive it as being "cool" any more. The latter is a terrible metric for which to base a technology decision, but I think you'll find it more difficult to recruit additional engineers if you choose Ruby on Rails.
Without knowing too much of the details, Node/Express (ideally with Typescript) seems like a better solution here, given you'll be building out the front-end in Vue or React. It might be worth looking at NestJS, as it's the closest I've seen to a well-formed opinionated framework on the Node side of things. We're also fans of Objection ORM.
I hope that's helpful!
Rails is currently a very mature and feature complete framework.
It's the ideal one if you're the only dev for your project because you get so many things already baked-in the framework that you'd only need to deeply care about specific stuff.
And you know? In the early stages of any project we have to validate it first with real users/customers. With Rails you can get to production real quick and fast.
I'm going to mention some of the features you get from day 1 when you run
rails new app_name:
- File uploading with Active Storage
- Rich text editor with Action Text
- Emailing with Action Mailer
- ORM, migrations, validations with Active Record
- Web sockets with Action Cable
- Modern frontend stuff with Webpacker
I suggest you to go with Rails because is a good choice, gives you less things to worry about and it's a very good and mature framework.
I need a solid argument to explain to people that aren't necessarily tech-savvy as to why we should choose Rails over Nodejs
Hi Max, it sounds like that you are proficient in both stacks and probably have a higher expertise in Rails (correct me if I am wrong) and since you are the only dev on a project, a good argument that comes to mind is probably the velocity and maturity (enterprise grade, battle tested in production) that Rails provide with proven success stories in the tech industry such as Airbnb, Stripes, Shopify to name a few. You can also make the argument that Rails is great to run the backend and React+Vue (and nodejs for tooling) is ideal for the front-end development (see or find companies example that use both). You can also build and show a prototype using both and share your experience which could help you find and forge the selling points to those non tech savvy folks, why not.
Eventually, are you going to have other developers on your project? if yes then you will need to take in account, onboarding and ramp up to contribution time when they are hired.
IMHO, I am not a fan of the debate Rails vs Nodejs, they are just tools at the disposal of the developer it's just a matter of figuring out what makes the most sense.
Let me know if you wanna discuss further, happy to help out!
ps: markdown preview on stack share... no good.
What is the best MVC stack to build mobile-friendly, light-weight, and fast single-page application with Spring Boot as back-end (Java)? Is Bootstrap still required to front-end layer these days?
The idea is to host on-premise initially with the potential to move to the cloud. Which combo would have minimal developer ramp-up time and low long-term maintenance costs (BAU support)?
React might be a good option if you're considering a mobile app for the future, because of react native. Although, Vue.js has the easiest learning curve and offers a better developer ramp-up time. Vue.js is great to build SPAs, very clean and organized and you won't have a lot of long-term maintenance problems (like AngularJS, for example). Bootstrap can still be used, but with flexbox there's no need anymore.
I recommend React because of less memory occupant compare to Angular, but this will depend on your organisation flexibility. When you use React you need to import different libraries as per your need. On the other side angular is a complete framework.
Performance-wise I vote for react js as it loads up quickly and lighter on the mobile. You can make good PWA with SSR as well.
If you are new to all three react will be a good choice considering, react-native will be useful if you want to build cross platform mobile application today or tomorrow. If you are talking about bootstrap styling framework than it's a choice you can style ur components by ur self or use bootstrap 4.0 framework. The complete stack mentioned above is platform agnostic u can run it anywhere you want be it cloud or on-premise.
I have created an app with react(context-api) on front-end and ruby on rails on the back-end by using chakraUI and Formik libraries. It is actually fun to use these different stacks combinations.
Have a look at it and let me know about your thoughts.
It was easier to find people who've worked on React than Vue. Angular did not have this problem, but seemed way too bloated compared to React. Angular also brings in restrictions working within their MVC framework. React on the other hand only handles the view/rendering part and rest of the control is left to the developers. React has a very active community, support and has lots of ready-to-use plugins/libraries available.
It is a very versatile library that provides great development speed. Although, with a bad organization, maintaining projects can be a disaster. With a good architecture, this does not happen.
Angular is obviously powerful and robust. I do not rule it out for any future application, in fact with the arrival of micro frontends and cross-functional teams I think it could be useful. However, if I have to build a stack from scratch again, I'm left with react.
Sign up to add or upvote prosMake informed product decisions
Sign up to add or upvote consMake informed product decisions
What is Rails?
What is React?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
The first live version of Leanstack was actually a WordPress site. There wasn’t a whole lot going on at first. We had static pages with static content that needed to be updated manually. Then came the concept of user-generated content and we made the switch to a full on Rails app in November of last year. Nick had a lot of experience with Rails so that made the decision pretty easy. But I had also played around with Rails previously and was comfortable working with it. I also knew I’d need to hire engineers with a lot more experience building web apps than I do, so I wanted to go with a language and framework other people would have experience with. Also, the sheer number of gems and tools available for Rails is pretty amazing (shout to RubyToolbox ).
I don’t see us ever having to move away from Rails really, but I could be wrong. Leanstack was built in Rails 3. For StackShare we decided to upgrade to Rails 4. Biggest issue with that has been caching. DHH decided to remove the standard page and action caching in favor of key-based caching (source)[http://edgeguides.rubyonrails.org/caching_with_rails.html#page-caching]. Probably a good thing from a framework-perspective. But pretty shitty to have to learn about that after testing out your new app and realizing nothing is cached anymore :( We’ll need to spend some more time implementing "Russian Doll Caching", but for now we’ve got a random mixture of fragment and action caching (usually one or the other) based on which pages are most popular.
Before two weeks ago or so, it used to be Backbone views and models, and everything was on our main store app, and our mobile web app, but actually, we just switched our mobile web app to using ReactJS for the interface. So it’s using Backbone models but ReactJS front-end components. Really, it was borne out of the frustration with how the Backbone model-view bindings worked, and it wasn’t especially performant for large views, and we had to do lots of tricks to make it performant. But swapping that out with React views meant that it could be both simpler and faster without having to spend a lot of time on that.
One other interesting thing about that is, since React actually works okay with the Backbone models and the Backbone router and stuff like that, we didn’t have to rewrite the mobile web application and update it to ReactJS. Rewrites are almost always a bad idea. We were able to upgrade pieces of it at a time, move on to React, and now the entire thing is using React and just has the Backbone router and models and stuff like that that we already had, so it's a lot faster.
We use Rails for webpages and projects, not for backend services. Actually if you click through our website, you won't notice it but you're clicking though, I think, seven or eight different Rails projects. We tie those all together with a front-end library that we wrote, which basically makes sure that you have a consistent experience over all these different Rails apps.
It's a gem, we call it Karmeleon. It's not a gem that we released. It's an internal gem. Basically what it does is it makes sure that we have a consistent layout across multiple Rails apps. Then we can share stuff like a menu bar or footer or that kind of stuff.
So if we start a new front end project it's always a Rails application. We pull in the Karmeleon gem with all our styling stuff and then basically the application is almost ready to be deployed. That would be an empty page, but you would still have top bar, footer, you have some custom components that you can immediately use. So it kind of bootstraps our entire project to be a front end project.
At the beginning of last year, Netflix UI engineers embarked on several ambitious projects to dramatically transform the user experience on our desktop and mobile platforms. Given a UI redesign of a scale similar to that undergone by TVs and game consoles, it was essential for us to re-evaluate our existing UI technology stack and to determine whether to explore new solutions. Do we have the right building blocks to create best-in-class single-page web applications? And what specific problems are we looking to solve? Much of our existing front-end infrastructure consists of hand-rolled components optimized for the current website and iOS application. Our decision to adopt React was influenced by a number of factors, most notably: 1) startup speed, 2) runtime performance, and 3) modularity.
React has exceeded our requirements and enabled us to build a tremendous foundation on which to innovate the Netflix experience.
Web-frontend programming prior to React: like banging rocks together. With React: Like wearing fusion powered underwear. Gives you a nice warm feeling. Using React for Cloudcraft.co allowed us to create a beautiful UI in record time (1 month start to launch), with virtually no bugs popping up during development. The functional approach to just rendering your component given a state just makes so much sense, with React figuring out the delta between your current and desired representation. It's the future kids!
React is choice number 1 when it comes to JS development at Kurzor. We choose React because it solves many issues with web applications in a elegant way. Writing an app in components is useful for coordination and isolation of concerns. React forces you to abandon state and use vertical passing through props instead. And having as many Pure Components as possible helps to write cleaner code.
With React we usually use: Redux, React Router, React Toolbox, Styled Components.
Web has always been in Rails from the beginning, so we used Redis for caching our items, which we had, from the beginning. Rails is kind of what we were comfortable with, and we knew we wanted the front end to be really, really snappy, so we de-normalized all the item attributes into Redis, and that's how it got served out.
This is the best component framework and API available today for building modern web sites and apps. I really enjoy how minimal it is, and powerful at the same time. It removes opinionated development and replaces it with logic and data philosophies, which has in turn fostered a robust and lively code and support community.
Rails 5 (beta 3) provided a nice structure for rendering responses, linking to front-end assets (compiled previously via Webpack), handling sessions w/ tailor made login links via an email button/token, background jobs, and creating an admin behind basic auth to allow managing of users and purchases.