Single Page Applications (i.e. SPA’s) have taken web development by storm. The first Frontend Frameworks appeared around 2010 and developing web applications has never been the same since. However, for most Startups and small businesses these Frameworks are largely unnecessary. Here’s why!
Requirements change fast when building new products!
Requirements often change very quickly when building out a new product. Shipping new features quickly is paramount when building something new, and it’s a lot easier to stay flexible when you’re using only Ruby on Rails. Ask a Rails developer to add a new feature and it can often be completed and tested in a fraction of the time it would take to do the equivalent feature in a SPA. There’s just so much less overhead to deal with!
Which nicely segue’s into your team’s overall performance…
Managing Multiple Frameworks will slow down your engineering team!
When you have a SPA, you essentially have two projects: Frontend and Backend. This means that coding a new feature often will require changes to both projects. Any Rails developer can add a new resource very easily and ship the changes in a fraction the time it would take to coordinate the same thing with a SPA.
SPA Architecture is often a Premature Optimization
Before you think I’m just writing a hit piece on SPA’s, please hear me out. SPA’s do have a place, but we believe that the benefits of a SPA’s are often massively overstated and don’t apply to most situations.
SPA’s do look nice, however. I love Gmail, Trello, Clubhouse, and all sorts of SPA’s. The transitions are nice, but is it really worth all the overhead just to shave off 100 milliseconds every time someone clicks. I’d argue a Hard No especially if the app is for internal use only or if the app is the first version for a new startup.
SPA’s also reduce server load because they do not have to reload the same resources every time a page is refreshed or a link is clicked on, however this benefit is often massively overstated as it relates to Assets. In a standard Rails app, the Asset Pipeline and/or Webpacker (Rails 6) utilize processes whereby CSS, JS, & Images are optimized for use on a Content Delivery Network or to be cached by your web browser. The truth is that every modern browser is smart enough to not download the same file over and over again when it’s already sitting in its cache.
SPA’s can be infuriating to Users because it’s often difficult to Bookmark a page or share a link that will take a user to the exact same place. Frontend apps often maintain their own internal state which is difficult to transfer over to a new tab or to a colleague via a single URL. Rails apps are stateless by default.
SPA’s add complexity to your development and will make it harder over time to hire and find teams that can work with your app! Rails is a single framework and any Rails developer can pick up another. When a SPA is involved, it is quite a different story. Yes, a SPA may have a Rails backend – but the project is no longer just a Rails app – its a Rails + Frontend Framework app. Not all Rails developers know the ins and outs of all the various Frontend Frameworks and no these frameworks are not the same thing. They’re all quite different! When a SPA is developed, it locks in multiple technologies onto a single project – and that lock in will make it more difficult to hire talent in the future. Everything may be fine now, but all teams inevitably have to deal with personnel changes. As a startup, reducing complexity and using a minimal amount of technology will help ensure these transitions are smooth and easy.
There’s a case to be made for SPA’s, however most of the time they’re unwarranted. If you’re building a new web app, stick with something simple like Ruby on Rails. Ruby on Rails will allow you the flexibility you need while you’re growing, all while providing a strong foundation to handle scaling should that come sooner than expected.
LD Studios is always available to determine what architecture is best for your project. Please reach out and get in touch with us and we’d be happy to review your existing app or help guide a project that has yet to start.