www.apress.com

18-2-20

Live, Reactive Templating with Ractive.js

By Alex Libby

Hands up if you can remember the early days of the Internet, surfing pages on dial-up connections that were slow, prone to drop-outs and struggled with anything more than just plain text on a white or gray background? Sound familiar…?

It’s a good bet that the pioneers of the Internet never envisaged that we would use a geeky language such as JavaScript to shop online, play games, or conduct our financial affairs online. Yet some of the world’s most popular companies conduct all of their business online: it would be hard to find a regular user of the Web who hasn’t bought something from the likes of Amazon.

It’s easy to forget though that visual experiences presented by the likes of Amazon require significant effort to perfect; effort which takes time and money to achieve. There is a good reason for this though – I will let you into a little secret: the web is not a great platform for building applications. I should quantify this admission though: it’s great for displaying static content, but when it comes to creating interactive content that responds to our input – well…it can be painful, to say the least!

To put this into context, let me ask you a question: if you had to develop an online display that displayed the number of emails you had, how would you update it? Keep this in mind, as throughout the course of this chapter, I will introduce you to another way of working, and show you – to badly misquote that oft-used saying from Hitchhiker’s Guide to the Galaxy, the answer is not always 42!

Introducing Ractive

Let’s follow up on that question I posed at the end of the previous section – how would you update that display? To keep it simple, let’s assume you have to update this content:

<span>Hello Alex! You have 24 new messages.</span>

As a developer, it’s likely you may come up with one or more of the following answers:

  • Use React, jQuery (or from a more practical perspective, , JavaScript)
  • Target specific elements in the code
  • Make use of a template system
  • Use a sledgehammer to crack a nut

Okay – I must confess: that last option is really in reference to larger libraries such as Angular! These are perfectly valid libraries in their own right, but their complexity makes it analogous to using a sledgehammer to crack that proverbial nut.

If we’ve been using them successfully for so long, why are they not ideal? In short, all of these options require extra work that isn’t necessary. If we take jQuery for example, then mixing template and logic code isn’t good practise; we can change the content, but is prone to error if the code isn’t changed correctly.

Altering our code to target specific elements or to use a template system is an improvement; we still have to deal with extra elements and the performance issues created from disposing of them. At this stage, a developer might consider using a framework such as Angular or Ember to do the heavy lifting, but this is not without cost. Once we get past the simple “Hello World!” demos, the learning curve is almost vertical, and the resulting code is often more complex than it should be. Okay – I might be exaggerating a little, but you get the idea…

So – what can we do? Well, there is an alternative – enter Ractive. Developed by the interactive team from the UK-based Guardian newspaper, this library shares some philiosophies with Angular, but with some notable differences:

  • Ractive only cares about the UI – it doesn’t force you to have to use pre-defined routers or backend functionality, unlike other frameworks.
  • Angular uses “dirty checking”, which checks every watcher if it thinks the view-model has changed; Ractive uses a dependency tracking system which only changes the dependencies of a specific element.
  • Angular (and others) traverse the DOM to set up data-bindings based on attributes set in code. Not only must we deal with non-validating tags throughout our code, it also increases the work the browser has to do to traverse the DOM.
  • Ractive takes a different approach – strings are compiled in the same manner, but a lightweight parallel DOM is set up to manage updates. Allowing the template to be parsed before the browser, allows Ractive to set up everything it needs to update the DOM, before updating the real thing. This makes it more performant, as most of the work is already done before changes are made to the DOM.

Okay – enough talk: let’s move on and turn our attention to more practical matters! Throughout the course of Beginning Ractive.js we will explore how Ractive can be used to create fully interactive applications, but without the excess baggage of other libraries; hopefully this book will show you that we don’t have to always use libraries “because that’s what we’ve done before”, and that Ractive is a worthy contender for your next application.

About the Author

Alex Libby is an A/B testing developer and seasoned computer book author, who hails from England. His passion for all things Open Source dates back to the days of his degree studies, where he first came across web development, and has been hooked ever since. His daily work involves extensive use of JavaScript, HTML and CSS to manipulate existing website content; Alex enjoys tinkering with different open source libraries to see how they work. He has spent a stint maintaining the jQuery Tools library, and enjoys writing about Open Source technologies, principally for front end UI development.

Want more from Alex? Pick up Beginning Ractive.js, now available on Apress.com.