Part 1 | Part 2
Reason contributor and Reason Association member Patrick Stapfer (Lead React Developer at Tag1) came on the Tag1 Team Talks show for a wide-ranging episode with Michael Meyers (Managing Director at Tag1) and your host Preston So (Editor in Chief at Tag1; Senior Director, Product Strategy at Oracle; and author of Decoupled Drupal in Practice) about the competitive advantage Reason confers upon architects of mission-critical applications that require a high threshold of resilience and stability. We spoke about some of the unique features of Reason and why many developers are adopting it in droves. In this two-part blog series, we'll cover the most salient aspects of Reason and why you should consider it for your own enterprise applications.
What is Reason?
The Reason toolchain
In Reason, modules expose a manifest of functions, types, constant values, and other items key for other portions of the application. Reason modules can also contain submodules, whose nested values can be accessed through namespaces separated by the dot operator (e.g.
Module.Submodule). Though Reason supports class-based hierarchies, and object orientation is a feasible approach in Reason, the technology has a strong preference for module-based, functional paradigms.
For developers who wish to leverage solely a certain set of functions, it's possible to include a module as a dependency and then override the functionality of it. Alternatively, developers can also define an interface of a module as a module type signature and annotate the module with which the signature should comply. This means that in Reason, structurally shaped module types that are compliant with interfaces are usable. But Reason also gently nudges developers to write functions, and specific syntactic features make it easier to compose functions together than in class-based inheritance. With Reason, there is no need to create a subclass and invoke the
super() function, since you can use functional composition instead.
Fast-ED, an application for first responders that allows paramedics to assess stroke symptoms in patients, features a decision tree with certain recommendations of how paramedics should act. Such an important tool is something where an "undefined is not a function" error is impermissible. In addition, it is critical for developers to ensure that all cases in the decision tree are handled without any errors. In order to implement a similar application in TypeScript, additional steps would be necessary: a type construct of Tagged Union types, object shapes each with a type attribute for specific cases, and conditional statements to ensure proper processing.
Sotheby's is another Reason user whose online bidding app for high-value products such as fine art requires a mission-critical approach. In situations with live bidding, there can be no glitches in the user interface while inserting dollar amounts, as this would translate into blank screens while losing out on the auctioned piece. As you can see, while the tolerance for such errors or issues would be lower for applications with lower stakes, many architects with risk aversion or particular business needs are now taking a closer look at Reason and similar approaches to application development through functional programming.
Special thanks to Patrick Stapfer for his feedback during the writing process.
Part 1 | Part 2