WTB Unobtrusive Binding Framework!

[Alex Robson]

TL;DR

I believe a big obstacle to wider adoption of RESTful application stacks is the availability of unobtrusive binding frameworks for the client side (especially in Javascript).

Why It Matters

The popularity of server-side web stacks that participate in or handle rendering some or all of the views has done several things to web development in general:

1. Delayed the need for powerful client side binding

2. Makes REST an obstacle rather than a compliment to app development

Moving Towards REST Alone

I want the ability to write web applications that basically look like REST services and static content provision. The client-side payload would be responsible for interacting with the RESTful portion. The upside I'm searching for is removing the distinction that usually exists between the web application and RESTful services the end up creating two entry points into my system. Really this exists for many reasons historically, but I believe it exists today because of habit rather than necessity. The power of newer javascript engines and lighter server stacks should enable us to write out applications with a RESTful "gateway" that the client talks to.

Binding As I Understand It Today

I am not saying the current approaches are bad or that they can't produce good results, but there are significant drawbacks to all of the popular frameworks I am aware of.

1. A designer could not "own" template creation and maintenance.

2. There's a disappointing lack of convention over configuration.

3. The framework APIs have such an immense foot-print that it appears a re-write of the app would be required if I wanted/needed to change out the binding framework.

Wish List

1. I want a web designer to be capable of creating and managing the templates without having to know much, if anything, about the binding system.

2. I want the framework to leverage the wealth of contextual metadata in order to determine intent (where possible) and not require a great deal of setup.

3. I should be able to change binding frameworks without rewriting my entire client application. This isn't unreasonable, it just means the framework needs to be decoupled and careful about the APIs surface area.

In summary, I've left parts of this a little ambiguous to (hopefully) stimulate further discussion, questions and keep it at a readable length. I've been toying around with some of these things but I've never written anything this involved in javascript before so I'm having to learn quite a bit more about the DOM than I would like and don't have high hopes of achieving anything that meets all 3 of the characteristics in my wish list.

[Kevin Swiber]

On Thu, Sep 1, 2011 at 5:38 PM, Alex Robson <asro...@gmail.com> wrote:

Wish List

1. I want a web designer to be capable of creating and managing the templates without having to know much, if anything, about the binding system.

2. I want the framework to leverage the wealth of contextual metadata in order to determine intent (where possible) and not require a great deal of setup.

3. I should be able to change binding frameworks without rewriting my entire client application. This isn't unreasonable, it just means the framework needs to be decoupled and careful about the APIs surface area.

Good topic, as I think there's plenty of room for improvement in this space.

1. At minimum, they'd have to know how to pass variables into a template, no?  What else?

2. What intentions are you trying to utilize in the framework and for what purpose?

3. This is where an API spec is nice and handy (think CommonJS).  I think that's doable.

The binding frameworks out there right now are fairly young, and I don't think they're targeting the Web client as a hypermedia consumer.

Improving this would make client-side development a joy, in my opinion, for the kind of application you're describing.

Can you post some code showing how you'd like to use the API?  Maybe starting there, banging out the rough edges, and working backwards will be a good strategy.

--
Kevin Swiber

Projects: https://github.com/kevinswiber
Twitter: @kevinswiber

[Jim Cowart]

A few thoughts:

• I could be dreaming here, but a decent binding + templating framework using easy-to-mock request libs (like amplify, for ex) could alleviate designers from having to worry too much about messing with passing vars in to templates (though that's a reasonable expectation)
• I'm interested as well to hear more thoughts from Alex on the framework to determine intent.  I assume convention is key here
• I think it's reasonable to expect to be able to ditch this theoretical framework without destroying the app.  But moving *to* another framework is all on the developer who made the choice.  Hardly any framework out is so un-opinionated that you won't be rewriting a decent chunk of Model/viewmodel code.  I don't like it personally...but until proxies are maintstream, even js model/viewmodel objects are going to involve custom code from the framework-of-choice.

I've been working towards something that's close to what Alex is describing, and I think the key to proper decoupling is for it to be pub/sub driven in the browser.  Once i get some stuff committed I'll submit some samples of what I'm thinking.  The key blockage, IMO, once I have the pub/sub API done, is whether or not I go the route of supporting existing template engines, or roll with something new.

[Travis Smith]

On Thu, Sep 1, 2011 at 9:33 PM, Jim Cowart <m...@ifandelse.com> wrote:
> I've been working towards something that's close to what Alex is describing,
> and I think the key to proper decoupling is for it to be pub/sub driven in
> the browser.

I'm going to agree. Now I'm going to say something witty that makes it
seems like I have additional valuable input on this specifically.

Though, I'm not sure it has to be "driven" in the browser. I think
were it really shines is when the browser is connected to the backend
via pub/sub. They are on the same bus.