Tuesday, March 2nd, 2010

Fin: self updating template language

<p>Marcus Westin has created a new templating language called fin. It is an interesting beast, and he gave us a run down:

Since this past November I’ve been working on a realtime templating system I call “fin”. I’d love to get some eyes on it, and hope that you’ll find it exciting. There is no demo, but quite a bit of information and if you’re on OS X it’s trivial to get the system set up on your own machine.

The basic idea is this… Rather than describing your data, you describe how you want your data to be viewed. Fin takes it from there in terms of persisting new data as it gets created. In addition, all views of any piece of data is globally synchronized. If one computer makes changes to a user’s name for example, then those edits are reflected for anyone viewing that user’s name as well, keystroke by keystroke. The way you create value views and input views goes like

  1. <div> User name: (( Value user.name )) </div><div> Edit user name: (( Input user.name )) </div>

More detailed examples can be found here.

You can also chain references to items, for example (( Value user.friend.name )). Now, if user.friend.name changes, then the Value view is instantly updated. Even cooler, if the user’s friend reference changes to a new friend, then the value view will accurately reflect the new friend’s name.

To get started on OS X 10.6 is as easy as

git clone git://github.com/marcuswestin/fin.git
cd fin
sudo make install-node
make deps
make run-couchdbx

And voila! Just navigate to localhost/path/to/fin/examples/from-html.html and you’re good to go.

Related Content:

Posted by Dion Almaer at 11:35 am
2 Comments

++---
2.3 rating from 29 votes

2 Comments »

Comments feed TrackBack URI

Its at beginning stages, so I don’t want to be too critical. Take this with a grain of salt. Its definitely a neat concept, and I love data binding, but I just don’t see this scaling past toy examples.

To start with there’s the problem of having a templating language that seems pretty shallow. Without more ability for abstraction, more complex examples would be pretty difficult. That can be solved with more work, though.

Beyond that, there major fundamental problem I see is that I don’t know how far you can go with such an ad hoc model. Great for prototyping, and certain subsets of applications, I suppose, but there is something to be said about a more structured approach, or at least something with the flexibility to allow more structure. Or perhaps I’m just lacking the proper foresight of the nosql future and what it will mean.

Comment by genericallyloud — March 2, 2010

Also, did the whole separation of concerns thing stop mattering?

Comment by genericallyloud — March 2, 2010

Leave a comment

You must be logged in to post a comment.