May 20th, 2015

When pursuing an idea, it is both encouraging and challenging to recognize that others are taking a similar approach. Encouraging, because it confirms that you seem to be on to something. Challenging, because it asks you to reassess your past decisions as well as where to go next.

In this blog post, I’d like to compare LaxarJS to BladeRunnerJS (BRJS), which is another architectural JavaScript framework driven by the same challenge.

A Common Challenge

First, let’s investigate what makes BladeRunnerJS similar to LaxarJS: Both are frameworks with the goal of making large JavaScript web-applications simple to create and maintain. Both have a concept of isolated, high-level application components (LaxarJS Widgets, BRJS Blades): In both worlds, these components are vertically integrated (containing JavaScript code as well as HTML and CSS) and manage their own resources to provide meaningful functionality to the application user.

Both frameworks have a grouping concept (LaxarJS Pages, BRJS Aspects) for assembling the high-level components in various configurations, and both frameworks support themes to adjust component style for different contexts. And finally, both frameworks embrace Publish/Subscribe (PubSub) for loosely coupled component interaction.

That is quite a respectable set of similarities! Anyone pondering the use of either tool might at least have a glance at the other. That being said, let’s look into what sets apart BladeRunnerJS and LaxarJS.

Apparent Differences…

From a developer point of view, one of the most striking differences between LaxarJS and BRJS is the tooling. BladeRunnerJS comes with a set of Java-based tools, and a development server based on Jetty. On the other hand, LaxarJS tooling is provided by a set of grunt taks (grunt-laxar). Broadly speaking, BRJS comes with a considerable amount of integrated tooling (for app/component scaffolding, dependency management, and build optimization) while LaxarJS tries to delegate as many tasks as possible to existing tools from the npm ecosystem, such as grunt-init, Bower and r.js.

Once you are comfortable with your development workflow, tooling differences tend to fade into the background and what counts is your application. Both LaxarJS and BRJS have a preferred view-layer, and while both frameworks allow to use other MVC/MVVM layers, LaxarJS plays especially well with AngularJS, while BRJS has ties to Knockout.

BladeRunnerJS ships with a swiss-army knife of libraries that are sooner or later interesting for most larger applications (a ServiceRegistry with IoC container, an OOP helper library, a test runner), while LaxarJS tries to focus on two core objectives: load and run widgets, connect them through events.

…and an Essential Distinction

Possibly the most important distinction has to do with the approach to PubSub that both frameworks take. In LaxarJS, event topics are declared through the page configuration, building upon an abstract pattern vocabulary, while BRJS channel names usually seem to be hardcoded into the component implementation.

In our experience, configuring event topics externally allows for a lot of flexibility in the use and recombination of LaxarJS widgets. To prove this point, have a look at the collection of ready-to-use LaxarJS widgets, which can be configured into any LaxarJS application by using the appropriate page topics.

With this in mind, the Publish/Subscribe pattern combined with suitable LaxarJS activities can fulfill the role of an alternative service registry and -services respectively, with the added benefit of exposing all widget communication to inspection and instrumentation through a single interface: the event bus.

Side-by-Side Comparison

Here is a side-by-side comparison of LaxarJS and BladeRunnerJS, by nature focusing on the differences rather than on the similarities.

BladeRunnerJS LaxarJS
Tooling Java/Jetty-based grunt-based
Scaffolding Built-In grunt-init
Dependency Management Built-In Bower
Module Loader Built-In RequireJS
Module Style CommonJS AMD
Service Registry Built-In AngularJS DI, Page Configuration
Main View Technology Knockout AngularJS
Inspection GUI Built-In workbench AxDeveloperToolsWidget
CLI-Tests Built-In Karma/PhantomJS
Component Wiring Imperative (JS-aspects) Declarative (JSON-Pages)

As you can see, BladeRunnerJS seems to be comfortable with the “Batteries Included” approach, while LaxarJS tends to shop around at the Bazaar of open source projects. Of course, comparisons like these are bound to be somewhat superficial and biased by their limited selection of aspects. So, try to think of this list as a starting point for making up your own mind.

That’s it for now, relax and enjoy the code!