We’ve seen an industry-wide trend towards websites and web applications being built as single page applications for better user experience. This has caused web development to be more focused on the client side of the stack (JavaScript, HTML, and CSS). To support this, a high churn rate of JavaScript libraries occurred where everyone competed to build an MV* (model, view) framework better than the next. In this madness the likes of AngularJS, Ember.js, and Backbone.js were born, all offering similar functionality. These monolithic JavaScript libraries provide you with all-in-one solutions that look attractive, but in our experience the libraries can put your business and app at a significant disadvantage. We’ve avoided using these monoliths - and here’s our thinking why.
AngularJS
The most popular and now almost industry standard, AngularJS is a perfect example of why you shouldn’t use these common monolithic libraries. When you use one framework to build your entire front end, you are placing all your eggs in one basket. These issues became apparent when the creators of AngularJS decided to build a new version of the framework (AngularJS 2.0). As soon as it was released, they told the community that 2.0 wouldn’t be backwards compatible with 1.x.x versions of the framework. If you had used Angular 1.0, you would be left with two options:
- Relearn and rebuild applications you’ve built with 1.x.x
- Keep your application on 1.x.x using an obsolete framework
AngularJS also has other technical issues that arise when building an application larger and more complex than the example 'To Do' list. This relates to the fact that although AngularJS is powerful, it’s not as flexible as some projects may need it to be. Frameworks like these don’t work for the bespoke systems we develop here at Sandfield, as they force their views of “how it should be done” upon you.
Micro Libraries
Libraries like AngularJS may be appropriate for applications that get rebuilt every two years, but here at Sandfield we put great value in building flexible, scalable, and long lasting applications for our clients. We achieve this by using micro libraries that functionally have a single purpose. Using a collection of micro libraries to build a complete system allows us to swap out any piece of the system with minimal effort if circumstances deem it necessary. If a library we chose became unsupported, no longer met the requirements, or a better and more efficient version became available, we’d be able to switch swiftly. Architecting applications in this manner minimises the work and costs involved if libraries were required to be swapped out for any reason. It also increases the longevity of the applications we build due to the flexibility and scalability of this architecture.
Sandfield Libraries
At Sandfield we pride ourselves in building bespoke applications but we’re not here to reinvent the wheel. With the large collection of well-built JavaScript libraries available we pick the best one and run with it. In our recent years of developing single page applications and hybrid mobile applications, we found the need to build our own custom JavaScript libraries. The libraries we have built cover page routing for single page applications and hybrid mobile applications, client side templating using pure JavaScript, and client side localisation.
By building our own libraries, we’ve been able to create industry-leading applications which will stand the test of time. Check out the Mainfreight, New Zealand Thoroughbred Racing, Les Mills, and Wilson Parking apps on the App Store or Google Play, the results speak for themselves.
