Home > Architecture, Patterns and Practices, Programming, Web Development > In search of a client-side templating solution

In search of a client-side templating solution

After a long time I am posting a technical entry. I am in search of non intrusive client-side templating solution. The following are the requirements

  • Non intrusive Should not require something like

ko.observable, ko.mapping and then tableMetadataViewModel.name(), tableMetadataViewModel.name(‘Employees’)

Ember.Object.create, tableMetadataModel.get(‘name’), tableMetadataModel.set(‘name’, ‘Employees’)

The problem with these kind of solutions is that these solutions are no longer Plain Old JavaScript Objects. They introduce a tight coupling with the templating library / framework which is implicit.

  • Is reactive / supports ‘Live Templates’ To Quote from Wikipedia

For example, in an imperative programming setting, a := b + c would mean that a is being assigned the result of b + c in the instant the expression is evaluated. Later, the values of b and c can be changed with no effect on the value of a.

In reactive programming, the value of a would be automatically updated based on the new values.

A modern spreadsheet program is an example of reactive programming. Spreadsheet cells can contain literal values, or formulas such as "=B1+C1" that are evaluated based on other cells. Whenever the value of the other cells change, the value of the formula is automatically updated.

In this specific context, when I update the name of the table object by setting an alias like

table.alias = ‘e’

It should automatically update in the UI.

  • Two-way data-binding

when I update the name of the table object by setting an alias like

table.alias = ‘e’

It should automatically update in the UI.

And when I update the alias in the UI, it should update the object model.

  • Model as the single-source source of truth In this specific context, when I update the name of the table object by setting an alias like

table.alias = ‘e’

All the places in the UI where table is rendered as a view should be updated.

Reactivity and Two-way data-binding go a long way in helping Model as the single source of truth.

  • Modular
  • Supports defining templates in external files and plays nice with requirejs text plugin.

  • Performs efficiently
  • Supports r.js optimizer & requirejs text plugin

For example splitting the application into small modules that have a single responsibility requires writing many modular templates. But i may result in poor performance if we make many calls to load them from the browser. Bundling them with the r.js optimizer for example can reduce this performance hit.

Granular re-rendering

Reactive templates should not mean the whole template is re-rendered every time model changes.

For example modifying an item, adding an item or deleting an item in a list should not re-render the whole template and instead just re-render / add / delete the concerned item nodes and the whole list or worse the whole template.

No dirty checking

    For example angularjs uses dirty checking that impacts the performance negatively.

Read this to see what I mean http://stackoverflow.com/a/18381836

  • Plays nice with other legacy frameworks / libraries
  • Recently I tried my hand with Polymer Web Components Stack. I ran into a hard to identify issue. Finally the issue was joint.js(+jquery) which I was using in conjunction with polymer was walking the DOM tree and made an assumption that the root node is the document node. Which is not true when it comes to shadow dom.

  • Fits well with Nicholas Zakas’s Scalable Application Architecture
  • Can I find the templating solution that fits well with Nicholas Zakas’s Scalable Application Architecture? Time has to tell.

http://www.youtube.com/watch?v=vXjVFPosQHw

object.observe, web components based?

    Some sort of a dom based templating solution based on object.observe on the modern browsers and an object.observe polyfill in other browsers which do not support object.observe should be good. But looks like knockout, ember etc are not taking up the object.observe route yet. May be I will end up forking knockout and implement one myself.

A build-time two-step transform view?

    Taking a hard dependency on a single templating solution, esp. for a product does not seem right.
    Are there any adapters / abstractions available that help one switch templating solutions over the same Model?
    Any suggestions comments would be welcome.
Advertisements
  1. September 22, 2014 at 12:08 am

    Did you manage to get jointjs working inside polymer, and how?

  2. September 22, 2014 at 12:08 am

    Did you manage to get jointjs working in polymer and how?

    • September 30, 2014 at 8:41 am

      Hi Jaka,
      I managed to work around it using polymer light dom if remember right.
      But in my scenario, I needed Shadow Dom as well, so I left Polymer and moved to knockoutjs.

      Regards,
      Sendhil

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: