New To Rails - Question

Hello all,

I’m new to the framework; but work as a PM in my full time job using other tech stacks.

What I’m trying to wrap my mind around is the use of ERB in Rails applications. With the wide spread use of SPA front ends like Vue, React, and Angular, it seems like serving html.erb files from the back end is not as common as it probably once was.

Is it more common in 2021 to use Rails as only an API to consume requests from a front end framework? If so, do you utilize the --api mode rather than the standard build?

Thanks in advance for any replies.

Rendering server side is still very relevant today. For many “Rails with JavaScript sprinkles” applications, client-side frameworks such as React or Vue add unneeded complexity. For those cases you can render server side and add SPA-like JavaScript behavior with libraries such as Basecamp’s new Hotwire, see their blog announcement:

2 Likes

Our app is an SPA in react but for admin pages & such, we find it much faster to write pages for server generation (we use HAML rather than ERB). It’s also handy for public pages where SEO is important.

1 Like

Agree with the comments above. FE/BE partitioning is one of the fine arts of coding data/server-based apps. As a Ruby coder, my preference is to concentrate on the data structures and controller functionality and hire a FE guy to make it pretty and vibrant and all the rest of it.

You shouldn’t try to know everything, IMHO. Better to stick to one or the other, rather than being mediocre at both.

I looked into HAML and the syntax is nice. I’ll have a dig a little deeper into it

This is a good point. Makes me think of the phrase, “jack of all trades, master of none”.

I personally agree with that sentiment but it certainly doesn’t preclude said FE dev using server-rendered ERB.

Agreed! That’s in addition to ERB, not in place of. I used to do LAMP with PHP… came to really appreciate the elegance of interleaved code and HTML. Ruby is even better!

An out-of-the-box Rails app will sacrifice some interactivity and performance (not nearly as much as it did a decade ago) in exchange for programmer productivity. If you do things the Rails way, you will be able to rapidly prototype and adapt to change in a cost-effective manner, which is perfect for a start-up or proof-of-concept situation or agile methodology. You can get a working RESTful resource and a UI with rails generate scaffold in a few seconds which will usually be enough to get some user feedback (and may be enough overall for some resources). Then you can focus on iteratively improving front-end experiences with JS on the parts of the app where they add the most value.

Going API only with Rails and heavy into a front-end framework is overbuilt for most interactions and more expensive to build, maintain, change, and test. Time is your most valuable resource.

1 Like

Thank you for this detailed answer.

@MBarberry welcome to the community! As you get to know Rails, I think that it’s important that you understand why Rails is designed the way that it is. You’ll hear references to “The Rails Way”, which is a phrase that refers to features, patterns and choices that Rails makes about how software is developed. One of the core tenets of the Rails framework is convention over configuration – Rails provides a set of sensible defaults for how things work, so that you don’t have to configure them. If you have experience with other frameworks, or have written code from scratch, then you’ll have an idea of what problems are being solved for you, and what decisions are being made on your behalf. If you are new to programming, then you may not understand why those decisions are being made. However, you should still understand what those decisions are and the philosophy that guides them. One good place to start is by reading The Rails Doctrine. That document explains the philosophy of Rails, which is key to understanding the design decisions for the framework.

Once you’ve understood the design philosophy, you’ll be in a better position to understand “the Rails way” – the defaults and guide rails of the framework. The best way to understand those defaults is to use them. Your first project(s) in Rails should use the features that are installed out of the box when you run rails new. These include (among other things) server side rendering with ERB, minitest for testing, and MySQL for the DB. Many rails programmers prefer HAML for templating, rspec for testing, and PostgreSQL for the DB. I would suggest that you don’t concern yourself with those until you understand and can use the defaults.

At some point after you have experience using the defaults, you may find that the out of the box functionality can’t do what you need to. Or perhaps you would prefer another option to the default. At that point you can explore alternatives, armed with the knowledge that the defaults don’t do what you want them to.

My recommendations come from my experience learning Rails. When I got started I would read blog posts about using alternative templating systems (like HAML); everyone was recommending rspec over minitest; Postgres was lauded as better than MySQL; and Angular was being trumpeted as the best thing since slice bread. I listened to all those voices and got lost trying to get all those things setup from the beginning. This seriously slowed down my ability to learn and understand Rails. It wasn’t until I stopped listening to the crowd and started using Rails out of the box did I truly begin to get productive. I was able to complete my first application in a few months. And then I was also able to decide for myself if the out of the box stuff wasn’t good enough.

Another issue that I had was that I got stuck in learning mode, doing dozens of tutorials and courses that didn’t really teach me how to build something. I eventually came across a course on Udemy that focused on building a single application using a pretty basic stack. If you haven’t completed a course yet, I highly recommend that one (Udemy has frequent sales, so you can easily get that course for less than $30). If you have completed a course, then your next step should be to build a Rails app using the defaults.

tl;dr: use Rails out of the box, with all the defaults to build your first application or two. Once you have experience, explore alternatives to the default.

Thanks for your response, Andre.

I read somewhere that the pendulum’s swinging back to the Rails way of rendering pages as SPA isn’t necessarily the best solution for many web based apps. Hence less of a need for stuff like Angular, React & Vue.

Rails 6 has Stimulus and even more recently, hotwire. Personally I like those approaches better as the integration of Angular, React & Vue with Rails felt kludgy to me.

Yes, it’s popular to do SPAs. I am not a fan personally, but you will encounter it a lot.

As others said, we recently got two new options in Rails for staying more on the server-side. One is the Hotwire stack and the second is StimulusReflex (so both use Stimulus as a front-end framework).

Just this week I published a post you might find interesting: Live previews with Rails and Stimulus 2

I also got a good follow-up on how easy is the same with StimulusReflex: Live previews with Rails and StimulusReflex - DEV Community

Stimulus is more than plain ERB and far from doing SPAs in React. It lets you keep ERB files and enhance them as you go.