The template frameworks Angular, Vue, Ember, Can, and Marko which are object-oriented and compartmentalize structure by view components with more or less internal state and coordination between views to allow data-binding and message passing, providing a secondary language for associating these models with rendered HTML.
This is a simplification as there are compiled languages such as Dart, which do not necessarily fall on the side of functional paradigms. There are over a hundred specific frameworks and decoupled view layer and state management combinations that have not been mentioned. In fact, the whole above is a simplification of the current landscape. I digress to talk about what in particular inspires Raj.
I have been programming for a decade and have worked with or researched all of the above at one time or another. Elm is the best one. If you have not tried Elm, you are a big dumb idiot. Seriously, try Elm.
The Elm community rightly accepts that Elm is not ready for everyone’s particular use case and prefers the slow and steady approach to its development. At worse, come back to Elm when it has what you need because anything that is not well-reasoned will not be added.
I want to use the Elm Architecture for all my client applications, not just when Elm makes sense, so I created Raj.
Putting aside the question of whether you should be using Elm, I will make the arguments for why you otherwise should be using Raj.
Raj has a limited scope. Raj does not have hundreds pages of documentation for thousands of features that will be eventually removed. Raj does not force you to use any particular view library, although virtual DOM solutions work best with the architecture. Raj does not pollute your data which special properties or methods or introduce any hacks that pervert the language. Raj does state management and handles side-effects and that is all it will ever do for you.
Those are the features particular to Raj, but we also get the features of the Elm Architecture. Everything we write is testable. This is the most important feature of the architecture to me. Application states can be tested without having to touch views and vice versa. Side-effects and asynchronous functions can be tested without using the application state or views. Debugging is incredibility easy because we can time travel through every single state of the application. Development follows very consistent and repeatable patterns allowing us to focus on building our applications, not building around framework deficiencies. We do not need to think about the framework in day to day application development.
Does Elm make sense for you? Does Raj make sense for you? I can help you decide and even help you build your next application. Please reach out to me or visit my team’s website to see if we can help you build your project or train your team.
Raj is not a product I am trying to sell. I believe it is the right tool for building client applications. I am excited to build applications with Raj and Elm, please join me. Thank you for reading.