Why Hyperloop

Hyperloop is an integrated, distributed Ruby stack for rapidly building Web Applications. Historically web apps have been designed and developed in two parts - the server-side or back-end, and the client-side or front-end.

Hyperloop breaks down the client-server barrier and lets you think about your application as a single integrated whole. Hyperloop allows for the major functions of your application to be distributed across all the clients running the application.

Hyperloop is not the first stack to take this approach, but what makes it unique is that you write in Ruby (instead of Javascript) and that your code interoperates easily with existing Rails applications, React components, and other Javascript libraries.

Traditional client-server applications use a Model-View-Controller structure. Models sit on the server, Views sit on the client, and Controllers provide the interface between the Models and Controllers.

Hyperloop replaces the three MVC elements with five elements: Stores, Components, Actions, Models, and Policies (or SCAMP for short.)

Stores, Components, and Actions are the same elements found in the Flux architecture. Stores maintain the reactive state of the application, Components display the state, and Actions orchestrate activities of the application.

Models conceptually are Stores plus Actions that are automatically distributed across all clients and are persisted on the central server. Hyperloop uses ActiveRecord as the base for Models so that in most cases persisting data and integrating with existing Rails applications is straightforward.

Finally, Policies define the regulations that govern who has permission to do what across the distributed application.

So what makes Hyperloop better?

First, there are almost no boilerplate, API transformations between client and server, or redundant code. Hyperloop strives to make every line of code be directed towards the problem being solved, not towards wiring up the system.

This keeps your Hyperloop applications short and sweet. How short and sweet? The standard Todo benchmark application written with React-Redux for example, comes in at 369 lines of code versus less than 100 in Hyperloop. And the Hyperloop app has persistence and multi-client data synchronization built-in. Adding these to the Redux app might add another 200 or more lines.

Second, there are no back-end or front-end developers in Hyperloop. Hyperloop treats your application as a unified whole, and so developers are free to align themselves with the customer, instead of with their role in the system.

Third, your Hyperloop code is written in one language. While it's true that any good developer can switch between languages, those context switches just add to the workload and increase the chance that multiple versions of the same function will have to be written.