Tag Archives: rails

SPA Javascript Frameworks pros and cons

My perspective is Enterprise Applications Development with Ruby on Rails. I am talking about frameworks like AngularJS, Ember, React, Backbone ….

Javascript:

  • Ugly language. Yes, but it was improved since ECMA6. and now you can give structure with Stimulus.js, in order to do it more maintainable.
  • Verbose: we have to make one file and extend one class for each route in Emberjs for example.
  • Give +2 points for the ugliness of the language and the hell of maintenance.

Template engine:

  • Always based on HTML (like handlebars), now we have HAML or SLIM.
  • React is even worse because it has JWS templates mixing JS and HTML

Another Hell is the Authentication layer. Here you have the example with Ember.

Pro Arguments:

  • Smooth and modern fluid feeling in apps, avoiding to reload full page.
  • BTW you are building and testing your REST API. But at the same time you are spending lots of time maintaining horrible JavaScript.
  • You are separating front-end and back-end. But adding one more layer of abstraction you have an MC-MVC architecture instead of a simple MVC architecture. Increasing complexity exponentially.
  • Download all assets once, not overloading the server. Well, always you can scale your systems.

Conclusions:

  • Use Node and Yarn to manage all super-great libraries in the frontend.
  • Use Hotwire/Turbo to provide a modern SPA-feeling without reloadings. Then you can give abstraction to the most complicated parts.
  • Create your REST APIs at the same time in your App but do not lose your time with complicated frameworks.
  • Make your life easier with SASS, HAML or Slim.
  • If a client suggests you these frameworks advise that it will increment dramatically the costs of development.
  • These frameworks are recommended only if:
    • You want to develop a front-end over an API which you are not owning.
    • Your front-end requires complicated images rendering and actions in the browser, like an editor or something like this.

Hotwire/Turbo on Rails saves your money

Here I will demonstrate how you will save more than 50% of you budget using Hotwire instead of JS libraries like React. Having all cool aspects of a smooth modern App.

SPA is acronym for Single Page Application. These are applications which doesn’t reload full page, but only parts of the page giving to the user a smoother feeling, and not losing focus in page. This opens the door to create Mobile Native Apps based on these libraries (like React Native).

Main problem of these SPA modern applications (with React, Vue, Angular…) is that they increase a lot the complexity of web applications by needing a JSON API server and Frontend application, triplicating your systems and human resources.

Rails solves this smartly by sending its traditional HTML partials to be replaced in the browser by Turbo.js, based on the HTML tag information. So you are saving on complexity, development costs and number of developers. And promoting happiness for your developer!!!

Hotwire is divided in two packages Stimulus and Turbo. At the same time Turbo is divided in Drive, Frames and Streams:

  • Stimulus allows you to join the manipulation of HTML views, DOM and third party libraries by creating Controllers. This allows to maintain a better modularized and cleaner Javascript code.
  • Turbo Drive solves the turbolinks approach by replacing the HTML body with the response of GET or POST calls to the server, instead of reloading full page. Giving to Rails views SPA-feeling without any development cost. Also manages gratefully the browser cache problem in SPA applications.
  • Turbo Frames goes a step further by replacing page fragments. The clue here is to generate html partials in server, and replace these in view.
  • Turbo Streams goes further by using ActionCable to use Websockets, creating a live-feeling in your app by broadcasting html partials to different users when info is changed in server.

As you see the key feature is that you are getting HTML from backend, and replacing it directly in frontend. So you don’t need a specific API server, you only need your traditional Rails server. And no need of a huge Javascript Application (heavily implemented with React, Vue,….), so you don’t have to triplicate development costs to have a SPA-feeling app.

Solving this part, you can also use Turbo to create Mobile Native Apps with turbo-android and turbo-ios.