When you’re stuck on ExtJS literally anything is better. Not trying to knock Ext but as a front end developer it becomes a hinderance when you can’t use real CSS, HTML, and have to resort to monolithic class building to accomplish the simplest of things. Granted we are stuck on Ext 3.4 and I imagine newer versions are better but we have accrued significant technical debt. We have 2 full time front end developers(including me) and the position of front end developer is only less than a year old.
Not every story(what we use to call a unit of work), but most, has some sort of user interface component but with only 2 front end developers we cannot do everything. This means we needed to come up with a solution that allowed us to accomplish what we wanted architecturally but did not force our full stack developers to have to learn something new. Not saying they aren’t capable but it’s quite an ask and one we felt like we could avoid and solve. However that meant that Angular, React, Ember, Backbone, and anything of that nature were immediately out. Great libraries, built by smart people, but they are very opinionated and when you’re not building from scratch things become difficult.
We had already come up with a technique to create an AMD loading container that extends Ext’s BoxComponent. This allowed us to interface the Ext world with an empty container. Now we needed to put something in said container.
We evaluated KnockoutJS and it was a no go. The templating was just plain annoying. Having to toss everything into data-bind rather than a classic mustache/handlebar double/triple curly brace closures. Further more it forced additional DOM elements to accomplish the binding. Yes there was the special knockout comments that could have been used but talk about ugly! Coming from Ext where the DOM is abused to create a simple button we could not continue where that would be a pattern. I’m exageratting a bit but to render text I don’t always want a span or other inline element I just want to output text.
That’s where Ractive comes in. Keep in mind our ultimate goal was to accomplish a more modular, flexible architecture while making it an easy transition for every other developer that would touch the front end. That came easy with Ractive. Two way data binding, enhanced mustache templating, custom components, decorators, data observers, scoped events emitting from templates, SVG + transitions, etc. The API could be written on a napkin. The main premise is give Ractive your data, give it a template, modify your data and your rendered template will intelligently update!
Access to the data through (your instance).data or (your instance).get(‘keypath’). Keypaths are . separated strings that tell Ractive how to traverse your data to get the value you want. This goes the same for setting data with (your instance).set(‘keypath’, value). However the caveat here is that calling .set will cause the DOM to update so doing so in a loop may be inefficient. However it’s fairly simple to get the data, modify, and call (your instance).update(‘keypath’) to propagate things out to the DOM. That is if your arrays aren’t in magic mode.
The point being is that everyone knows how to manipulate data in some way. No longer do we have to manage the DOM we can always assume it’s rendered in a way that represents the data. Modify the data and the DOM magically updates. Modify some input values (text, checkbox, textarea, selects, etc) and the data will update to match.
Before getting too technical and in depth into the inner workings of Ractive I implore you to check it out at http://www.ractivejs.org/ and examples at http://examples.ractivejs.org/. The documentation is a tad weak but in my free time I’m working on making it better. Ractive supports IE8 but I sincerely hope you don’t have to support IE8 (we do for now). The library is built by @Rich_Harris who is a fantastic developer working at The Guardian. So check it out, use it, test it, submit an issue, or even help out with a pull request.