Node vs. Firebase vs. Laravel vs. Rails

For a long time, I was just a frontend developer. My toolbox was constrained to JavaScript, HTML, and CSS. However, my creativity got the best of me, and I wanted to build more than just interactive UI. I wanted the whole enchilada: user accounts, billing, database storage, automated emails, and more. As an indie hacker, I wanted to build my own products!

A great opportunity arose: my schedule had cleared up, and I had some time to learn backend development. I knew there were a lot of options, so I decided to sample a few of them: Node.js, Firebase, Laravel, and Ruby on Rails.

Node.js

My thoughts on Node

After reading some documentation and watching some videos on Node, I ended up purchasing a short course. I quickly learned that it was like buying a toy that required assembly: there are separate packages for everything from auth to interacting with your database.

Powerful, yes. Great for entrepreneurs? Maybe.

With so many moving parts, I felt that it was a bad choice for me – I barely knew about backend development. It would be like learning to drive in a car you built yourself. Yeah, it would be cool if it worked, but there's a good chance it'll fall apart while you're going 80 miles per hour down the highway.

If I had an application patched together out of multiple components and one of them broke, it might take me days to diagnose and solve the issue. And that's not fair to customers.

The Node learning curve

Since I'm a JavaScript developer, the learning curve for Node started out small. I was able to create a few simple applications – blogs, realtime lists, a small social application with user profiles and post feeds – pretty easily.

However, building a real-world application at a higher level of complexity quickly became difficult, as there were so many moving pieces to wrap my head around. Recurring billing and multi-tenant solutions were a little harder to comprehend in the world of Node.

Firebase

My thoughts on Firebase

Firebase is a backend as a service from Google. Basically, you just call Firebase's functions and it handles the rest for you. Because of this, it's very easy to build Firebase apps: I built a React application with login/logout functionality and connected a realtime database in less than an hour.

Realtime databases are very cool: any change to the database automatically appears on every open application, so you can create realtime chat apps without any config. It's like state management on steroids.

I built a few more practice applications to get my head around Firebase and its different features. However, I noticed that for anything beyond a very simple application, Firebase immediately became more difficult. It was hard to set up recurring Stripe payments, and it was also hard to split the database into multiple tenants (think Basecamp, where one company can sign up as a paid user and let employees create accounts on their site). There was little to no documentation on any of this, and I'm not sure if they plan on moving in this direction in the future.

If it becomes easier to build multi-tenant, subscription SaaS businesses with Firebase, it would be a great choice for me in the future. As well as every other frontend developer.

So far, Node had too little magic, and Firebase had too much.

The Firebase learning curve

Firebase has the smallest learning curve of anything on this list until you need to start working on building an application that handles recurring payments, uses multi-tenant infrastructure, and so on. I couldn't find any up-to-date resources on building a more complex application, and after reading most of the documentation, I realized that I'd need more backend knowledge to understand how to structure my app. So Firebase was out.

Laravel

My thoughts on Laravel

I became a developer by building WordPress plugins and themes. There was a small amount of PHP involved, and I always liked the language. It was easy to read, easy to write, and fun to learn.

So I decided to give Laravel, a PHP framework, a try. Laravel developers really love Laravel. I've seen it recommended countless times throughout online communities.

Laravel was easy to set up, but after several years of writing ES6 JavaScript, PHP was uglier than I remembered. The syntax felt unnatural. I also knew that I was about to work with Ruby around the corner, so I might've been biased. (At the time, I'd heard that Ruby was a beautiful language.)

If you're a PHP developer, I definitely recommend checking out Laravel. The community is ultra-friendly, and there are a lot of resources to help you learn (Laracasts is the big one; it has plans for $15/month or $99/year).

However, if you don't know PHP, you might want to shop around first.

My verdict was that I didn't give Laravel enough of a chance to surprise me. I hit a few bugs in a few outdated tutorials and wrote off a framework because I didn't like the language, and that's not fair to Laravel. After working with it for a few days, I moved on. In the future, I may come back to see why everyone loves it.

The Laravel learning curve

Laravel seems like it has an easy learning curve, especially if you have some backend development and PHP experience and a desire to learn it. Take a look at this thread for some more opinions.

Ruby on Rails

My thoughts on Rails

Initially, I had trouble admitting I wanted to even try Rails. After all, it's 2018 – isn't Rails dead yet?

I'd attempted to learn Rails a few years ago when I was just starting in web development, and it didn't make much sense to me. Back then, it still hadn't clicked after two months. But now that I had a few years worth of development experience, maybe it would be easier.

Setting up my development environment was initially difficult. I got a lot of cryptic errors (due to a corrupted rvm install from a while ago). And for the first few days learning the framework, I had trouble wrapping my head around the Rails magic. Controllers, models, named routes, and migrations were all new concepts. (Especially migrations.)

It seemed weird to me that even just your file names were important to writing a good Rails application. Rails even pluralizes some of your code, so if you create something called "Tenant", you might need to call it "Tenants" elsewhere. At first, this was weird.

But, as I continued, I noticed something that hadn't happened during my time with other frameworks: I was having fun.

Rails was like finding high level armor in the early game. It felt overpowered! Like I had discovered some kind of secret. It took me a few days to start getting comfortable with MVC and migrations, but I made it through thanks to the help of some YouTube videos and blog posts. I built a dozen example applications until I was comfortable scaffolding, migrating, editing routes, and working with views.

My first big breakthrough was running a few commands and realizing that I scaffolded the basics for an entire blog. Within a few minutes, me – a beginner Rails developer – had set up everything from posts with comments to user accounts. It was exhilarating.

I slowly realized that the controller could pass any variables you needed to the view, and it worked with the model to create relationships between database tables. If I was in the Post controller and needed to grab something from the database's Comments table, I could reach into it and get whatever I needed.

Suddenly, working with databases became easier.

Once I understood the "way of Rails", it had blown past even Firebase in ease of use. (This understanding came within two weeks of trying it out.)

The Ruby on Rails learning curve

As a mid-level frontend developer, it took me about 10 days to start feeling comfortable in Rails. Rails has gems, which are like JavaScript's modules, that you can add to your project to do mostly everything you need. In JavaScript, you'd use something like npm i xxx; in Rails, you can use bundle add xxx. With gems, writing a Rails application feels like ordering from a restaurant rather than cooking your own food. There's no need to roll your own auth solution, subscription billing, multi-tenant infrastructure, file uploading, or even "Like" buttons – they've already been created for you. You just have to install the gems.

If you're a complete beginner who has never touched code in your life, Rails will be difficult. There are a lot of concepts: frontend development with HTML/SCSS/JS, backend development with Ruby, and working with databases. I tried to learn it several years ago, and I fell into the trap of believing it would magically "click" without me understanding the fundamentals. (If you're making a go at Rails as a complete beginner, here's what really helped me: understand how the frontend and backend work together from a conceptual level. Learn about the server roundtrip made by Rails during a request. Learn a bit of HTML and CSS. Research the Ruby language and how its classes work. And finally, learn about named routes in Rails. Practice every day, and you can get it in a few weeks.)

After I had more experience, I understood how the frontend, server, and database all worked together, and Rails became a lot easier. I actually think that taking the Node course helped me learn Rails, as I was able to better transpose my JavaScript knowledge into something actionable in Ruby. If I had to start all over again, I would still take that Node course and still progress all the way through to Rails because my knowledge of each framework stacked onto each other.

On top of that, I appreciate a few other things about Rails.

1. Ruby is beautiful, and Ruby devs strive for beauty

I've heard Ruby developers say, How can I make this code beautiful? more than once, and that made a big impact on me – that's something I used to think about with JavaScript.

Ruby's syntax is often much shorter and more expressive than other languages. As a JavaScript developer, I see it as a more minimalistic version of what ES9 might look like.

2. Yes, Rails can scale

Most people shouldn't be worried about scaling. For most apps, a cheap Heroku server will work just fine. However, if you need to scale, you can still do it: Shopify handles 80,000 requests per second on Rails.

Twitch is on Rails. Mastodon is on Rails. Airbnb is on Rails. Zendesk is on Rails. Soundcloud is on Rails. Indiegogo is on Rails. Groupon is on Rails. Kickstarter is on Rails.

If you're having traffic problems, it's a sign that you're doing something right. Then, you can find the resources and manpower needed to either (1) make your application more performant, or (2) move off of Rails onto something like Go. But don't do this prematurely. You probably won't need to, even if you're wildly successful.

3. The community is helpful

The Rails community is quieter than the JavaScript community, but it's still there. People give solid, battle-tested advice. Popular gems are still maintained. The conversations are there – they're just not highlighted as much as those about JavaScript.

4. It lets you build quickly

As a Rails newbie, I can create a simple Reddit-like application in a few days. And I'm anticipating that soon, a few days will become a few hours. That means that instead of creating one application over a few months, you can create multiple applications over the same timeframe.

If nothing else, this raises your chances of financial success.

Takeaways

My conclusion is coming up soon, but here are a few other things I learned within the process of trying these frameworks.

First, when you're choosing a framework, don't get sidetracked by your ego. Just because you can write this finely-engineered, performant application in Framework X doesn't mean you should. If you're a developer-entrepreneur, you should usually pick the fastest option to get your product to market.

Second, simplicity is important. Businesses are tough. You need to handle development, design, accounting, legal work, taxes, set up bank accounts, manage subscription services, network, do business development, and handle customer support. Do you really want to overcomplicate your engineering?

And finally, users don't care what framework you're using – whether it's Node or Rails or Laravel or WordPress or (dare I say it) Weebly – they just want your product to work.

Conclusion

All of these frameworks will work. But if you came here for my opinionated answer, it's Rails.

The only time I wouldn't recommend Rails is if you're already a talented in another backend framework — Node, Laravel, Firebase, etc. If that's the case, stick to what you know because it'll be the fastest way to market.

Most applications just need some variant of CRUD (creating new entries, displaying them, editing them, and deleting them), and that's what Rails excels at. If you're building something like a realtime chat application, or a server for a mobile game, that's where other options like Node start to shine.

I've scratched the surface of what's possible with Rails and the Ruby language, but after I got over the initial learning curve, I dropped into a world of delight. Applications are fast and easy to build, and I legitimately look forward to opening up my text editor and dropping into the application. I haven't felt this since I was learning React.

Indie devs, give Rails a try. It might be older than some other options, but it's extremely elegant, still active, and probably the tool you need.