Raj is a framework for building JavaScript client applications. It is very small and limiting, forcing applications to be built with good designs and patterns.
Speaking purely of web applications, there are two groups of framework in modern JavaScript.
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.
The functional frameworks Cycle and React, alongside some state management solution, are function-oriented and in most cases internal state is disallowed, preferring a unidirectional flow where data is passed from parent to child and messages are dispatched to some dispatcher which updates the topmost parent. This pattern can be replicated in the above template frameworks but feels very awkward. In these frameworks the JavaScript language is leveraged to build views instead of a secondary language.
We also have the bonus wildcard category, the compiled language frameworks. These include frameworks from ClojureScript, Reason, and Elm. These languages differ from CoffeeScript or TypeScript, enabling much different architectures than those we often approach from JavaScript, building up respectable ecosystems in their own rights. Their frameworks have grown for many reasons to sit on the functional framework side of things. ClojureScript using React in most view solutions, Reason being built by Facebook, and Elm having inspired the Redux pattern that has become the “default” state management solution for React.
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.
For those unfamiliar, Elm is a functional programming language with a simpler type system than Haskell which is completely immutable, disallows internal state, handles asynchronous side-effects for you, that compiles to JavaScript. The community around it is making the best decisions with the best mindset on just about every topic. The keystone of the language is the Elm Architecture, the pattern used to build any application in Elm.
Raj takes the Elm architecture and adapts it to better fit the JavaScript language. These changes are very minor and most people writing Elm already should see the similarities. If you are writing Elm and it is working for you, Raj is not for you.
Raj is an attempt to bring the Elm Architecture to JavaScript for people who do not use Elm. The type system and language itself have a learning curve, but that is not a good reason to not use Elm. The reason not to use Elm is “I need to get things done.” The language’s constraints force you solve problems the right way, but this does not always align with the economics of a project. For example, for notably complex and difficult problems, you will find initial development is hampered by trying to fight to hack something together within Elm’s limitations.
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.
The Elm Architecture transcends any particular language. It plays to Elm’s strengths certainly but has found a home in JavaScript through Redux. Redux too loosely follows the architecture, inventing for itself much more complexity which Raj serves to undercut with a stricter adaption.
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.
Raj is small. Minified it fits into the size of a tweet, one of those 280 character tweets but whatever. If you have time to read and understand the 40 lines of source code, you can be an expert in Raj. If you do not like it, throw it out and replace it. Most of your code must be libraries or business logic because the inversion of control is minimized by using such a small framework. The JavaScript ecosystem will continue to evolve and this framework will not lock you into anything but the JavaScript language.
Raj does have advantages over Elm for those with experience working in JavaScript codebases. In Elm you interact with JavaScript through a strict port system. In Raj use can leverage existing libraries without restriction. The JavaScript community has a much larger community and ecosystem to borrow from to build applications than Elm. Raj is better for React Native because Raj pairs well with React whereas Elm has its own virtual DOM system. With time my hope is that this gap will narrow, but for now the mass of JavaScript that you can leverage alongside Raj is much greater than that in Elm.
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.
Elm is the best thing out there conceptually for building web applications. Although Elm may not make sense to an application’s development today, my hope is that in the future building Elm applications is even more realistic to developers. Following the Elm Architecture in JavaScript will hopefully make a migration to Elm in the future much more straightforward. Until Elm makes sense for you, please consider Raj for your JavaScript development needs.
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.