Introduction to Hotwire/Turbo

by about , ,

Turbo is the evolution of turbolinks Rails library, done to make your web app navigation faster. Giving the performance of a single-page application (like Reac) but with much less complexity and much cheaper development costs in money and time.

We can decompose Turbo in several parts:

  • Turbo Drive: avoids full-reloading of HTML page, just replacing the <body>, giving a clean sense of navigation. It intercepts usual HTTP requests and use fetch for server calls. It also manages full browser history with advance/replace/restore actions.
  • Tubo Frames: It decompose your page in parts using <turbo-frame> tag, which can be replaced by copies received by the server, just locating and replacing them thanks to identifiers.
  • Turbo Streams: Also decompose your page in <turbo-stream> parts with will be fetched to Websocket channels, so they will be replaced on change with no user action needed. Thanks to the broadcasting of Websockets, through ActiveCable channels connected to your clients’ browsers.
  • Turbo Native: Brings these capabilities to the Android/IOS development world, just developing your native mobile application from your web server, avoiding long and onerous upgrade processes in marketplaces. Note that you will use native APIs, you are reusing the view and HTML fragments parts.
  • Turbo Rails: Is the gem which simplifies views programming in Rails backends, including helpers like turbo_frame_tag or turbo_stream_from.

Enjoy the invent!

SPA Javascript Frameworks pros and cons

by about , ,

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

by about , ,

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.