RoR + other languages

I am new to RoR as a scrum master and I am not sure whether RoR alone is okay for our web dev projects. The company I work for uses RoR already but I keep receiving proposals from web dev vendor teams on using other languages (Node.js, React.js, Laravel, Vue.js, Python). Is it fine to use RoR exclusively and dismiss the other languages for this company?

1 Like

With the exception of python, everything you listed is a framework. Including RoR. Nodejs, react, and vue.js can all be used with RoR as a front-end.

Not exactly sure what you’re asking here. I think you may be a bit confused.

Hi @iancaesar23,

Thanks for joining us here.

Quick answer. RoR is more than enough for web development. If you have clients that are accessing your services over the Internet, and are using a Browser or a native app to do it, you can use Ruby on Rails to achieve your goals. There are plenty of teams, including my team that are running a large stack of technologies and languages, but use Ruby on Rails for web.

Laravel is a different framework that is close to Ruby on Rails. I am not going to enter into details about benefits and drawbacks. Laravel comes from the PHP community which is a vibrant and live community that has given a lot to the internet as we know it. I will still choose Ruby on Rails every time over Laravel. Now, there is a saying, that the best thing you should write a platform is on the framework you know, and the second best thing is on the framework you would like to learn. If you have a lot of knowledge of PHP and Laravel in your team, as a scrum master you are kind of responsible to take the right decision, given all the information from the stakeholders as Scrum dictates. My personal recommendation here is to dedicate some time to learn and start projects in Rails.

Node.js, React.js, Vue.js are something different. They come from another community that thinks in different ways than the RoR community.

React.js and Vue.js allow you to move much of the logic of your app to the client and to have a really heavy “client” doing a lot of things in the browser and really thin servers. Truth be told - I am almost certain that React.js is not for you. React.js is a great project solving an issue that should not exist in the first place. How to manage a rich client. How to manage logic in the browser that is complex and that is difficult. Think FB and all the things that are happening on a FB page. Think if you are facing the same problems as FB. Do you really need to have a chat while you browse groups and live feed of stories at the top while the feed is updated and many other things happening that should be pushed from the server to the client without a client interaction.

Before React.js and Vue.js took the stage there were and still are other very good frameworks. If you’ve seen Trello as a product you know that there are a lot of things happening in the browser. Trello is based on backbone js. Check it out. It is a simple framework for managing the state.

So if you have the requirement to do so much heavy lifting on the client side you should definitely look at React.js and Vue.js.

That being said. “Reach.js is dead, long live StimulusReflex” (don’t quote me on this). I would advice you to do as I do when you are leading an engineering team. We have a RoR platform. Quite large I must say. We have one page that uses React. I thought that we should know what React is and how it could help us and we should try to use it in real live scenario. I allowed the team to add React to one page for 2 progress bars. React is not forbidden in our team. I welcome React. But after the amount of work spend on this two progress bars to work with React, nobody is now talking about using React in our team. People just saw that it is not for us and for our case and that it does not pay of.

I will do the same thing with StimulusReflex. We do not use it, but we have just talked about it today and we would try to use it for one page, to see how it feels, what it is, and how could it help us and we help it.

React.js and Vue.js are huge. RoR could work with both React.js and Vue.js. I personally prefer Stimulus. It is the JS framework I’ve always missed and now that we have it, it is completely OK for me, my team and our clients.

Python is something else. Python for web development is used with Django. Django is similar to Rails and Django is great. You know instagram (of course you do). It is build, or at least was build with Django. I am not sure what their stack is now. In my organization we use python on the server side for server side processing. The only reason we use python is that we had 3-4 very convenient libraries developed in python that were doing exactly what we were looking for back then when we made these decisions. But it could have easily been ruby or java. It is python because of the existing libraries for this specific problem.

Now comes Node.js. This one is very tricky. The holy grail of software development is Node.js. Here is why: To deliver any functionality to run in a browser you need Javascript. That is a fact. It is not a suggestion. It is a fact of the industry. I know people will now say - “but what about WebAssembly and Rust” to which I say “I hope, I really hope that we could have more than one well supported and practical ways to deliver logic to the browser. I hope it will become a reality soon and I can see that we are not far from it”. But for now we are Javascript. So there it is. We must know Javascript. There is no way around it. So if we know and use Javascript, if we have the tooling and the knowledge and the infrastructure for Javascript and we are delivering our features to the browser, than why can’t we just use the same tools, infrastructure and knowledge to develop the server side? And this is it. You have the same code base (theoretically) that could run on the server or the client. This is where Node.js come in. It allows you to run JavaScript on the server.

Node.js vs RoR could be a difficult choice. Should you run Javascript Server + Javascript Client or should you run RoR Server + Javascript Client. I would still choose RoR because it comes with exactly what I need, but this is because of the problems I am solving.

Node.js is a little easier. My experience is that more than decade ago Java EE was “too complex” and we wanted to try RoR. I have seen people that now say “RoR” is too complex and they try Sinatra, or even go to Node.js, Go, Closure to implement their features.

I don’t have much to conclude. I hope my experience could help you. I personally like to give my team enough freedom to try a new technology every month or two, I dedicate the time for this, organize a process with scope, and demo at the end, even put some of this on production, but I never forget that at the end the client does not buy the technology, but the service we are providing.

update: mainly typos

7 Likes

I used Ruby on Rails and Next.js, and found some time, using the same language for frontend and backend is not an advantage. It’s not easy to tell which JS part is running in client, server or both. It could be I’m not as familiar next.js as Rails, but I’m sure I’m not the only one feeling this.

1 Like