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.
A Common Challenge
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.
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.
Here is a side-by-side comparison of LaxarJS and BladeRunnerJS, by nature focusing on the differences rather than on the similarities.
|Service Registry||Built-In||AngularJS DI, Page Configuration|
|Main View Technology||Knockout||AngularJS|
|Inspection GUI||Built-In workbench||AxDeveloperToolsWidget|
|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!