Trails.js and Angular

Posted by Scott Wyatt on Jan 23, 2017

In the the last year, we saw two fascinating innovations. A rivaling Node.js framework named Trails.js launched and Angular broke it's lengthening stagnation and released Angular 2. With Angular's new release came something that full stack javascript developers greatly appreciated — Angular on the server. Many developers were excited and we were no exception. However, with all this new glitz and glam came an extraordinary amount of new tooling, wildly changing documentation, and frustration that cost us considerable time.

Every Innovation Begins with a "Flash of Genius"

With the exciting prospect of server rendered Angular pressing us forward, our team set out to build an experimental "Angular Universal" app, and we choose ourselves as our client. As soon as we put pen to paper, so to speak, we realized everything was different. From the way the routing worked, to how the structure was written and bundled, it was like we were staring at a three headed lava monster.

To start our story of whoa, first we had to make a coin toss on whether to use SystemJS or Webpack, both which were new to us. Luckily, we chose Webpack and that has become the standard at the time of this writing. Then we had to decide between vanilla javascript and using TypeScript, which was also foreign to us. Finally, we had to find the right Node.js framework to handle the isomorphic nature of Angular and the definitions of TypeScript. It seemed that at every turn there was some ingrained process of ours that had to be completely rewritten. Then, like troops at a muster, everything started to fall into place.

The key for us was Trails.js. Trails is small for a Node.js framework and relies on zero magic to operate. For people who have not heard this phrase before, coding magic is where a bunch of systems all work together in a mysterious way which makes changing things nearly impossible. Luckily for us, Trails was written with the intention of doing away with the witchcraft and was already gearing itself for es6. We figured it might make it easy to work with our lava monster TypeScript frontend. To everyone's surprise, it worked great.

Forged from Open-Source

For us though, that wasn't enough, we wanted a complete integration and consistency between the front and backend. With just a few file name changes, a definition module, a fancy webpack setup, and countless cups of coffee, our entire repository was in TypeScript and bundled like pros (we are pros after all). After just a few short weeks, we launched the makeover of Cali-Style.com in all of it's TypeScript, Webpack, Angular, HMR, SASS, Trails glory. We even put together a sample starter pack to show how we did it.

The decision to remake our website into a web app didn't come without some draw backs. We would have to make blogging software, content management, and more from scratch. This is much easier said than done, especially considering the ease of getting a Wordpress site online. This is where our decision to use Trails really started to pay off.

Trails has a really neat plugin system that extends an app with what they call "Trailpacks" or "packs" for short. Trailpacks are easy and fun to write, and they extend functionality at an exceptional close to the metal level. In fact, one thing that makes Trails so small and flexible is that most of it's features come from Trailpacks. With this concept in mind, we made a quick flat file database using markdown documents, and voilà, we had a CMS and blog.

During this whole process, something started to become very clear to me in a way it had never done before. The majority of websites/apps out there are complete overkill and that is a serious problem. For example, a Wordpress site has many enterprise grade tools, and with that, comes Enterprise grade problems and vulnerabilities. This lack of diversification and the fact that a layman can launch a Wordpress site makes the platform beautiful but also a likely target for hackers or botnets, and that is everyone's problem. While this is a scary fact, it's also one reason I've become an impromptu Trails evangelist.

With Trails being so small, I can examine each of it's pieces, and with Trailpacks, I can micro manage dependencies. This results in us building smaller and better software. Even as our Trails/Angular applications grow in complexity, they follow this micro pattern. To tie this back in with Angular, the entirety of one of our applications is in a single language and that allows me to see at a glance all of it's pieces.

All of this was a massive technical challenge. Launching a production application on essentially beta software is never recommended and the breaking changes to Angular were infuriating at times. Still, in the end I would have done everything over again.

The results are incredible and most importantly, we proved to ourselves and our clients our creativity and tenacity. Even now the earth is moving under our feet with all the innovations coming in 2017, and we are excited to say that we are a part of it.