Introduction and thesis
So should you use Ruby on Rails or should you use JavaScript for your next SaaS application? Let's find out. Hey, what's up everybody? My name is Don. I am a software developer and independent consultant and freelancer based in the United States of America. On this channel I teach people how to start, survive, and thrive in the world of freelancing and software development. Today's topic: I'm going to be talking to you about why I feel that you should use Ruby on Rails over JavaScript for creating a new SaaS-based application. So let's go ahead and hop into it. Let's go through the pros and cons of both. I'm going to preface this by saying that I have built applications in both Ruby on Rails as well as Node.js and React and Vue and all these other ones, so ultimately I have experience in both.
JavaScript: ubiquity and strengths
Number one, let's just start with JavaScript. One of the pros of JavaScript is it's everywhere. If you have a Chromebook you can learn directly on your Chromebook. There's tons of online tutorials which you can learn from. It's a dynamically typed language which allows you to just easily start coding right there in your browser or online through any of the online platforms. You can code and it just kind of easy to get going. It just works. You can see it work in real time; that gives you a lot of confidence at the end of the day. Furthermore, there's a package for everything in the JavaScript world, so you can use npm if you've installed Node, and at that point in time you can install image recognition, file manipulation, image manipulation, ML—different kinds of stuff is all done in JavaScript and it's everywhere. You can run JavaScript on the backend with Node.js, you can run JavaScript on the front end with React or Vue or etc. You can build full-stack applications simply through JavaScript alone, so it's everywhere. JavaScript is a big blank canvas. If you only want to write scripts you can write scripts; if you want to write applications top to bottom you can do that too. And furthermore, if you want to benefit also from static typing, you can use something like TypeScript which compiles down to JavaScript and will give you static typing inside of your JavaScript or TypeScript files which then compile to JavaScript. So there's tons of options out there. Again, if you need a library for anything you're wanting to do most likely that library's already been developed.
JavaScript: drawbacks and complexity
What about the cons of JavaScript? JavaScript is JavaScript, and if you've ever worked with JavaScript long enough you eventually grow to have a disdain for it because there's just these weird things about the language that sometimes don't make any sense. How are you going to work with numbers? Can you parse this number? Can you do this? Is that a one? Is a string? Is that considered truthy or not truthy? There's a whole mess of things. Is this a number, not a number? You can get in the whole wild situation. It's a very particularly weird language at times; some of the things that it does don't make sense, and that can be very confusing for someone who's new to it—especially if you're not using newer versions of it and you're not used to the scoping and you don't know how to properly write good JavaScript. That kind of leads to the fact that JavaScript's not really an object-oriented language. Now yes, of course you can have objects, but it wasn't built to be an object-oriented language initially; it does support these things as it's matured, but if you think about it it's mainly a functional style language. I'm not going to call it a full functional language, but it does have a lot of functional concepts: you can write everything as a function, you can pass functions, you can do a whole bunch of stuff, so it's a very functional-style language. If you're not used to the functional language it's going to be a little bit confusing. Again, as a benefit JavaScript's a blank canvas—now the problem with it being a blank canvas is there's nothing stating this is how you should do websockets, this is how you should connect to file systems, this is how you should write out to S3. Anything you might do in a web application there are a number of options, and because of that blank canvas you do what you want. That can be very frustrating because you can run into a humongous thing of analysis paralysis where you don't even know what to use. You'll do that a lot; it's just how these things kind of end up working out because it's confusing when you don't have any guidance. If you're new to this it can be very confusing. TypeScript I mentioned is a benefit, but it's also kind of a real pain in the butt if you've not used it before. You'll run into weird situations and I still do to this day of how TypeScript works in one situation and doesn't work in the next. Overall I can find myself finding TypeScript as much pain as I'm benefiting from it. That can also be a major downfall as well. Lastly, because there's no guidance inside of building the applications, there's ten different ways to do ten different things or ten different ways to do the same exact thing, so finding that right balance is really difficult and can put you in a tremendous amount of pain through analysis paralysis.
Ruby on Rails: conventions and built-in features
Now let's juxtapose and talk about Ruby on Rails. What are the benefits of Ruby on Rails? Number one is the speed of development. Once you have Ruby on Rails installed, Ruby is very convention over configuration. If you follow everything that Rails has to do—say if you do the Rails way—you're going to connect to a database this way, you're going to write your database migrations this way, you're going to query the database this way using the models, you're going to do all of your response handling in controllers, you're going to do your relationships and your models validation and your models—this stuff is built into the framework. It seems that the developers of Rails have thought about almost everything that speeds up your development significantly. You can simply say I have a database; here's what the schema looks like or I have this new table. It will generate the controllers, the models, which then allow you to just directly connect to the database and say, 'Hey, I need all my person records' or 'I have all my user records: User.all.' I have all my user records. User.where firstname equals done—boom, I have all the users whose first name equals Don. That's built right in. Maybe I want to do websockets—okay cool, now I'm using Action Cable. Maybe you want to store files in S3 or Google Cloud or DigitalOcean—I'm using Active Storage. Maybe I want to use text with a nice WYSIWYG editor—I'm using Action Text. Maybe I want to build a chat application—I'm going to go back to using Action Cable. This stuff's built in. Maybe you want to send email—that's easy; there's mailers built in. I want to log—loggers are built in. I want to use SendGrid—configure it with the SendGrid API key or use SMTP or the gem for that. It also has a bunch of other gems you can use to connect to other things. The underlying connection is basically a bunch of adapter patterns: say you want to send email—follow this adapter pattern and you can send Postmark or SendGrid or Amazon SES or anything like that. Overall, when you want to build a web application and you build it on Rails, as long as you follow the Rails way your speed of development is insane. You want to add a new application that has user login? Use the Devise gem, and in minutes you have full user authentication with sign up, lost password functionality, emailing new user signups and authentication all within your controllers in a couple of minutes. That in itself can take days to write in something like JavaScript if you're not familiar even with the best JavaScript packages you can't be that fast to set everything up. On top of that, Ruby on Rails just allows you to be productive, and when you're able to be productive and not focus on the plumbing it becomes much more enjoyable. That's ultimately the thing: I get to enjoy building my software business because I'm not fighting the technology to do what I wanted to do.
Rails: trade-offs and scaling considerations
It's not all roses. There are some cons to Ruby on Rails as well. Ruby can be considered kind of slow. It's not going to be as fast as Go or Node.js. Node is going to be a little bit faster at times because it is doing a little bit more underneath the hood. It can consume a lot of RAM and a lot of memory, and so depending on what you're doing you might need to be careful and tune your queries or tune your application so it doesn't consume so much memory. If you're using something like Action Cable and you're using live chat and live websockets and there's a ton of connections and it's driving up your memory usage a lot, you might need to take some time and replace that with AnyCable which uses a Go-based version of Action Cable—or whatever you might want to use that's much faster and much more memory efficient so you can handle that. There are options out there. It can be considered a little bit slow at first and a lot of people will look down on that, but you have to realize what you're building your application for. Is your application only going to be used by 100 to 500 people a day to log in and check their billing? Do you really need the throughput of a million users every ten minutes? Probably not. So that really doesn't matter. You have to know your use case, and for most use cases Rails is going to perform just fine. If you think Rails can't handle load, look at Shopify—Shopify is a Rails app. So is GitHub. There's a ton of them out there that get a ton of traffic, so it can handle it; you just have to know how to tune it. Next is Rails is not seen as a hot new thing anymore. It's not the brand new language or the brand new web framework that everybody wants to use. It's been something built to be productive and joyful to use since its inception and continues to be that way, but it's not the new hot thing that everybody wants to use. Lastly, queries and Rails can be a little bit hairy if you're not used to doing these nested queries through your models or using Arel queries inside of Rails; they can be very challenging if you're not used to them, so it does take a little bit of a learning curve.
Personal story, recommendation, and conclusion
That's the pros and cons. What I want to do now is tell you the story of what really set this whole thing in stone for me. I've built applications with Ruby on Rails and Node. I've built multiple Node applications with front ends. I've built many applications which is Express, Angular, and Node. Those have shipped, but my most recent experience has been with Node.js with Express as an API and the front end being React with JavaScript and TypeScript. I've done this twice, and both times what I have found is every time I'm developing the application and it has an API and it has a client application, I'm actually building two applications. I'm building the client application and I'm building an API which is its own application. They communicate over HTTP through the API, so I'm actually building two applications: one for the client, one for the back end. Anytime I need to make a change in the back end, I then have to go make the change in the front end and make sure the integration still works. That works; that works a lot of the time in how most companies work through integrations and so forth. However, when you're a small company and you're a startup or you're just a single person and you're starting your SaaS application, you don't want anything to slow you down. You want to be as nimble and as quick as you can be because if you're not making any money or barely any money the last thing you need is something else to slow you down. Having two applications is going to slow you down. I had this example from a couple of years ago: I built an application, had the API, had the client, and about eight weeks in I felt that I was moving too slowly. Every time I had to build something it took forever. I time boxed myself: I'm going to give myself three days; I'm going to try to rewrite this in Ruby on Rails. Within three days I rewrote 80% of the application in Ruby on Rails, took about two or three more days and I finished up the rest of the application in Ruby on Rails. So about five to six days overall total days of work, I replaced eight weeks of work that I had done in Node.js and React and I moved it all over to Ruby on Rails. Of course that went from two applications, which was a Node API and a React application, into one big monolith Rails application. This was a SaaS application that was going to be used by hundreds of people at most, and I was then able to make changes, adapt quickly to my market, and respond to anything that needed to happen inside the application much quicker than having to update two different things in the application. While that might work when you have a larger team and you have funding, when you're small and you're starting off you need to think about what's going to work for you. How can it be more nimble? What's going to be more effective? In my opinion Rails is going to give you that flexibility, that speed of development, so you can change, make updates, and just give you a lot more bang for your buck when you're building a SaaS application. There's so many things built into it that you can just build features faster and validate out in the market. When you're building your SaaS application you need to be quick; you need to get it out there. The last thing you need to be doing is building more stuff and taking more time to develop and finding additional frameworks or idiosyncrasies. If you follow just the Rails way of doing things you're going to be able to develop applications quicker, and that's ultimately what this comes down to: how can you develop your SaaS quicker? Use a tool that's going to allow you to develop your application as fast and as effectively as you can. You might say, 'Hey, I am really fast at Node and React and I've built my own framework for it.' Okay, that's fine—then use that. But for me, based on my experience of shipping multiple SaaS apps in Ruby and multiple SaaS apps with JavaScript with Node and React, hands down Ruby on Rails is much faster and much more reliable to build SaaS applications from the ground up, and that's what I'll be using going forward. Hope that helps you make your decision of which way you would like to go. I'm going to use Ruby on Rails. Let me know in the comments below which one you've decided to go with or if you have any questions and I'll do my best to help. Thanks for watching and I'll catch you in the next video. you
