If you’re reading this, chances are that you’re simply curious about how LaxarJS became what it is now. Looking at the roots of any product also tells you much about why it was built, helping you to judge if your needs match those of the creators. Finally, by tracing back any project to its origins, you get a feeling of where it will be going next.
So, grab a serving of your favorite beverage and indulge me as I take you back in time to where it all started…
Business as Unusual
The traditional approach of server-side web applications with added “rich-client” functionality had always felt like doing everything twice: once for the server and again for the browser. Also, existing UI frameworks on both ends of the wire focus heavily on creating and reusing small, technical components (buttons, date-pickers, carousels etc.), but not on creating reusable solutions for actual user problems (compose an e-mail, find a product, plan a trip). This is fine when creating a few small applications that have little overlap. However, at aixigo we are building and maintaining dozens of larger applications that have a considerable amount of functionality in common.
So, Tobias devised a concept of isolated business components (now called LaxarJS widgets) along with a way to connect these components through application configuration instead of through APIs. This became the LaxarJS event bus.
Now, for a good idea to prove itself it must be turned into a great solution. Over a couple of weeks in late 2012, my teammate Alexander Wilden created the first version of what would later become LaxarJS. The essential parts were already there: the event bus as a working Pub/Sub broker, and a page loader to dynamically assemble and tear down widgets based on JSON page definitions. To connect pages in a declarative manner as well, a flow controller was added. Jonas Pommerening provided initial tooling for asset loading and optimization. Shortly afterwards, the first set of general-purpose widgets was created in a spec-driven approach, and implemented using AngularJS and Bootstrap CSS.
Soon, the new solution was put to the test in two new products that would be delivered in mid-2013. The state of the HTTP back end was represented by a set of JSON resources, with individual widgets manipulating the parts they were responsible for. Updates, validation and user actions were communicated through events. During planning and implementation, a set of collaboration patterns for widgets emerged, which turned out to become the LaxarJS Patterns library.
Our coworkers at aixigo quickly picked up the new set of technologies and enjoyed the much-faster turnaround during application development. Especially the live reloading, the testability of isolated widgets, and the availability of general-purpose widgets were well received.
After the initial in-house success, the next stage of plans was set in motion: Larger projects were to be based on the new platform, and at the same time we started our open-source effort.
In early 2014 the project was still nameless, so our project lead Markus Kemmann made an effort to gather naming suggestions. Eventually, we settled on LaxarJS (from Latin laxare, meaning to relax) because we wanted to emphasize the forgiving nature of the loose publish/subscribe coupling.
This was around the time that I joined the project and we began the restructuring of the code base. Our goal was to open up the project to the open source ecosystem around NPM and Bower and to base as much as possible on existing solutions, while avoiding to pull in any unnecessary cruft.
To achieve this, we repackaged the project into a small set of Bower components (core, Patterns, UiKit), each using a semantic versioning scheme. We started releasing the first
0.x versions of these packages as open source in spring of 2014.
Trial by Fire
The most difficult stages of any software project are often not the first steps, but the pains of growing large. LaxarJS was designed for this from the start, but still we learned a few valuable lessons when actually using LaxarJS to develop large applications in the summer of 2014:
The most important lessons were don’t make your widgets too small and don’t try to be too generic. The essential advantage of the widget-based approach is in reducing the overall complexity of your application by dividing it into smaller but still meaningful parts. However, software developers (myself included) simply love to create tiny, generic components, that can be configured to do anything. This is not the purpose of LaxarJS widgets. If there are more than 10-20 widgets on a page they will eventually degenerate into mere UI-controls, and the page configuration will contain all the complexity that was meant to be divided among the widgets in the first place.
The second lesson we learned is only tangentially related to LaxarJS, and you may already know it: Be careful with AngularJS $digest (or the rendering stage of any framework, really). If you don’t keep an eye on your application performance, it will slowly degenerate. Thankfully, LaxarJS can actually help you there as it allows to performance-test each widget in isolation. We also applied our learnings directly to the LaxarJS core: when creating a LaxarJS+AngularJS application, a minimum number of $digest-cycles will be used during page load. Also, there are profiling helpers that help you to keep track of each widget’s use of AngularJS watchers, and we added support for “angular-free” (plain) widgets.
To summarize: don’t be afraid to create pages containing just a few well-rounded widgets, and let LaxarJS help you to keep an eye on your rendering performance.
Full Steam Ahead
In early 2015 we had successfully applied our lessons learned in another project, and were ramping up for that magic v1.0.0 release. We knew that we would have to get any necessary breaking changes into this release, so we took a page out of A. de Saint Exupéry’s book:
Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.
In this spirit, we got rid of our dependencies to underscore and jQuery in favor of standard browser APIs. We improved our bundling so that all code and widget assets of any LaxarJS application can now be loaded through two requests (one for JS+JSON+templates, one for CSS). The v1.0.0 release notes have the full casualties, but basically we trimmed down whatever we could. Also, users of LaxarJS should not have to write their widgets in AngularJS. We added pluggable technology adapters so that any model/view technology can be used.
Of course, the LaxarJS project is much more than just the few core components: Jonas Schulte put a lot effort into open-sourcing our general-purpose widgets and into creating several demo applications. Dirk Voß who was involved from the start with engineering the themeing mechanics, has been relentless in defining the appearance of every single control, widget and demo application from UX concepts to the last pixel. And finally, the feedback of our fellow aixigo developers, whose patience we have tried time and again, proved an invaluable help in getting the project this far.
If you are curious as to what comes next, make sure to follow the LaxarJS blog. As always, relax and enjoy the code!