Collaboration?
Peter Rust
First off, I like the way you think. I've been a big evangelist of
client-side templating and data-binding in my workplace for the past
couple years. Making the binding automatic and overridable is also
beautiful.
I wrote a data-binding layer (now in its second version) for a project
(www.projectrecon.net), but haven't released or documented the data-
binding layer publicly. Now that others are in almost the exact same
space (Chain.js and PURE - http://beebole.com/pure/), I'd rather not
create a third option for the public. Instead, I'd like to study the
differences, discuss the various advantages and disadvantages of the
differences and contribute any code or differences of approach into
the two already-public projects.
One of the significant differences that comes up right away is that
your project has a high priority on not blowing away event-handlers by
re-generating a lot of templated markup and stuffing it into
the .innerHTML property. I can see the value in this, but there are
times when there is so much HTML that the .innerHTML approach is the
only one that is fast enough. When there is such a large amount of
HTML, you want to attach a single click event-handler on the container
anyway, because attaching an event-handler for, say, 200 elements,
takes far too long. Possibly one approach would be to detect if there
are any event-handlers -- and if there are, preserve them and take the
slower approach.
I wrote (yet another) layer underneath my data-mapper called
LightningDOM, which simulates the DOM API, but really is a super-fast
javascript wrapper around arrays of HTML strings. The benefit of this
is that the code could easily switch back-and-forth between the true
DOM and the arrays-of-strings-based LightningDOM, without too much
stress on the data-mapper layer itself.
Anyway, let me know if you're interested in collaboration and input.
I'd love to discuss these (and other) differences and work together at
building the best client-side templating/data-mapping system possible.
-- Peter Rust
Developer, Cornerstone Systems
Rizqi Ahmad
thank you for your interest! it would be great to be able to work with
you!
may be we could replace the dom with lightningDOM. but I want to
maintain the compatibility with jQuery,since it is based on jquery.
send me email!
On Sep 1, 7:04 am, Peter Rust <pe...@cornerstonenw.com> wrote:
> Rizqi,
>
> First off, I like the way you think. I've been a big evangelist of
> client-side templating and data-binding in my workplace for the past
> couple years. Making the binding automatic and overridable is also
> beautiful.
>
> I wrote a data-binding layer (now in its second version) for a project
> (www.projectrecon.net), but haven't released or documented the data-
> binding layer publicly. Now that others are in almost the exact same
Mic (BeeBole)
I'm Mic from the PURE project.
First of all, thanks for fighting for client side rendering too.
Our efforts go to the same direction. Even if we are in a kind of
competition game.
Ideas from one project will benefit to the other. So in the end that's
a good thing.
The first version of PURE was DOM based for simplicity, elegance and
to keep a tree based logic.
Then as the screens of our app went bigger and more complex the
performance were unacceptable so I switched back to innerHTML.
A bit sad, but I quickly felt home, as this was the way I've built web
apps for years with XSLT+XML sending the result to div.innerHTML's
I'm intrigued as attaching events was not an issue with XSLT.
They were set during the transformation as well as the html. So there
was no costly attach calls after transforming.
We were developing for the quite picky big corporations. They all use
almost exclusively IE 6/7 and we didn't experience memory leaks this
way.
In our last release I've set an example on how to attach events the
same way we were using it with XSLT.
If you have some time, I'd like to have your opinion on it. Do I miss
something?
Cheers,
Rizqi Ahmad
I too did consider innerHTML in the past because of its speed. But I
found that it doesn't offer much flexibility that DOM offers.
My focus on chain.js is to be as flexible as possible, so you can
create various interfaces and widgets with it. One of the possible
direction of chain.js is providing interaction services like
http://github.com/raid-ox/interaction.js/wikis/
I think it is difficult to do things like that using innerHTML, since
the whole content is rendered each time an one of item is updated.
Chain.js only generate the items once, and updates them whenever it is
needed. So, you might have some initial lags, but only at the
beginning.
I am afraid implementing interaction.js using innerHTML would be too
hackish. Do you think it is possible to do thinks like this without
DOM ? http://code.riiv.net/demos/tree/
I do not have any real world experience with huge amount of data. But
I personally think it can be solved using paging and dynamic loading
(DOM allows you to update parts of the content). Besides I am sure
that in the next 2 years the situation will be different.
Its just my humble opinion. May be we can find a better solution to
balance the speed and the flexibility.
Do you have an Idea?
Thanks for posting
Rizqi
Mic Cvilic
> found that it doesn't offer much flexibility that DOM offers.
disappointing. Especially FF and IE.
> My focus on chain.js is to be as flexible as possible, so you can
> create various interfaces and widgets with it. One of the possible
> direction of chain.js is providing interaction services like
> http://github.com/raid-ox/interaction.js/wikis/
Initially with PURE I was just looking to replace XSLT as we moved from
xml to JSON. That's obviously an interesting direction.
>
> I think it is difficult to do things like that using innerHTML, since
> the whole content is rendered each time an one of item is updated.
> Chain.js only generate the items once, and updates them whenever it is
> needed. So, you might have some initial lags, but only at the
> beginning.
If a screen is heavy, that can become more than a lag. However all
is about the way the app is developed. If people know they'll use the
DOM
a lot, they can design it accordingly and everything could be fine.
>
>
> I am afraid implementing interaction.js using innerHTML would be too
> hackish. Do you think it is possible to do thinks like this without
> DOM ? http://code.riiv.net/demos/tree/
I see you coming here :)
The recursion is natural when you have tree structures such as DOM.
Anyway, I implemented a tree in xslt+js with innerHTML, so I have to
check back how it was done to see if this could be implemented in PURE.
When I have a tree I'll send it to you...
> I do not have any real world experience with huge amount of data. But
> I personally think it can be solved using paging and dynamic loading
> (DOM allows you to update parts of the content). Besides I am sure
> that in the next 2 years the situation will be different.
Totally agree. Things will be different in 2 years time when the major
browsers will have a faster DOM and installed in enough computers.
But 2 years is very long in web units. So the innerHTML functionality
of PURE is here to help me to build quick apps, today, while waiting
for better browsers.
But my guess is that something like or better than SVG could be
more interesting, and avoid us all becoming flex developers in 5
years :)
>
>
> Its just my humble opinion. May be we can find a better solution to
> balance the speed and the flexibility.
We could say about our projects:
- chain.js is fast enough to be very flexible
- PURE is enough flexible to be very fast
So depending on what people are looking for, they have options.
As all is open here, this can be very constructive.
>
> Do you have an Idea?
>
> Thanks for posting
Cheers,
Peter Rust
> it would be great to be able to work with you!
Thanks!
> maybe we could replace the dom with lightningDOM
> but I want to maintain the compatibility with jQuery,since it is based on
jquery.
Certainly. Though I've been using Prototype, I've been following jQuery
development and I realize how large the jQuery community is. Maintaining
jQuery compatibility is a high priority for me as well.
I just spent the past three hours merging two versions to get a "best of"
version (LightningDOM 1.3) and writing an extensive blog post introducing
LightningDOM and donating it to the PURE and Chain.js projects.
As I hope I made clear in the post, my primary reason in going public with
LightningDOM is in hopes that PURE or Chain.js will find it useful in some
way and merge the best code or ideas from it into their libraries. If there
is any interest in this, I will gladly donate (some of) my time in helping
perform the merge and helping maintain the LightningDOM layer. The best-case
scenario would be that the LightningDOM will ignite some ideas on how to
merge the two libraries while maintaing the speed of PURE and the power of
Chain.js.
The LightningDOM is not a data-mapper or a templater. It is a layer on which
a data-mapper or templating engine can be built -- a layer that gives you
performant DOM-like access to a large HTML string.
Here is the blog post:
http://blog.cornerstonenw.com/2008/09/10/donating-lightningdom/, which
contains a link to the code. I would love to hear your comments and
suggestions.
-- Peter Rust
Developer, Cornerstone Systems
-----Original Message-----
From: chainjs group [mailto:nor...@googlegroups.com]
Sent: Tuesday, September 02, 2008 3:18 AM
To: chainjs digest subscribers
Subject: 5 new messages in 2 topics - digest
chainjs
http://groups.google.com/group/chainjs?hl=en
Today's topics:
* Collaboration? - 2 messages, 2 authors
http://groups.google.com/group/chainjs/browse_thread/thread/5c1a957404b75f80
?hl=en
* Chaining same data twice? - 3 messages, 2 authors
http://groups.google.com/group/chainjs/browse_thread/thread/7eb4c12b414eb8af
?hl=en
============================================================================
==
TOPIC: Collaboration?
http://groups.google.com/group/chainjs/browse_thread/thread/5c1a957404b75f80
?hl=en
============================================================================
==
== 1 of 2 ==
Date: Sun, Aug 31 2008 10:04 pm
From: Peter Rust
Rizqi,
First off, I like the way you think. I've been a big evangelist of
client-side templating and data-binding in my workplace for the past
couple years. Making the binding automatic and overridable is also
beautiful.
I wrote a data-binding layer (now in its second version) for a project
(www.projectrecon.net), but haven't released or documented the data-
binding layer publicly. Now that others are in almost the exact same
space (Chain.js and PURE - http://beebole.com/pure/), I'd rather not
create a third option for the public. Instead, I'd like to study the
differences, discuss the various advantages and disadvantages of the
differences and contribute any code or differences of approach into
the two already-public projects.
One of the significant differences that comes up right away is that
your project has a high priority on not blowing away event-handlers by
re-generating a lot of templated markup and stuffing it into
the .innerHTML property. I can see the value in this, but there are
times when there is so much HTML that the .innerHTML approach is the
only one that is fast enough. When there is such a large amount of
HTML, you want to attach a single click event-handler on the container
anyway, because attaching an event-handler for, say, 200 elements,
takes far too long. Possibly one approach would be to detect if there
are any event-handlers -- and if there are, preserve them and take the
slower approach.
I wrote (yet another) layer underneath my data-mapper called
LightningDOM, which simulates the DOM API, but really is a super-fast
javascript wrapper around arrays of HTML strings. The benefit of this
is that the code could easily switch back-and-forth between the true
DOM and the arrays-of-strings-based LightningDOM, without too much
stress on the data-mapper layer itself.
Anyway, let me know if you're interested in collaboration and input.
I'd love to discuss these (and other) differences and work together at
building the best client-side templating/data-mapping system possible.
-- Peter Rust
Developer, Cornerstone Systems
== 2 of 2 ==
Date: Mon, Sep 1 2008 6:08 am
From: Rizqi Ahmad
Hi Peter,
thank you for your interest! it would be great to be able to work with
you!
may be we could replace the dom with lightningDOM. but I want to
maintain the compatibility with jQuery,since it is based on jquery.
send me email!
On Sep 1, 7:04 am, Peter Rust <pe...@cornerstonenw.com> wrote:
> Rizqi,
>
> First off, I like the way you think. I've been a big evangelist of
> client-side templating and data-binding in my workplace for the past
> couple years. Making the binding automatic and overridable is also
> beautiful.
>
> I wrote a data-binding layer (now in its second version) for a project
> (www.projectrecon.net), but haven't released or documented the data-
> binding layer publicly. Now that others are in almost the exact same
> space (Chain.js and PURE -http://beebole.com/pure/), I'd rather not
> create a third option for the public. Instead, I'd like to study the
> differences, discuss the various advantages and disadvantages of the
> differences and contribute any code or differences of approach into
> the two already-public projects.
>
> One of the significant differences that comes up right away is that
> your project has a high priority on not blowing away event-handlers by
> re-generating a lot of templated markup and stuffing it into
> the .innerHTML property. I can see the value in this, but there are
> times when there is so much HTML that the .innerHTML approach is the
> only one that is fast enough. When there is such a large amount of
> HTML, you want to attach a single click event-handler on the container
> anyway, because attaching an event-handler for, say, 200 elements,
> takes far too long. Possibly one approach would be to detect if there
> are any event-handlers -- and if there are, preserve them and take the
> slower approach.
>
> I wrote (yet another) layer underneath my data-mapper called
> LightningDOM, which simulates the DOM API, but really is a super-fast
> javascript wrapper around arrays of HTML strings. The benefit of this
> is that the code could easily switch back-and-forth between the true
> DOM and the arrays-of-strings-based LightningDOM, without too much
> stress on the data-mapper layer itself.
>
> Anyway, let me know if you're interested in collaboration and input.
> I'd love to discuss these (and other) differences and work together at
> building the best client-side templating/data-mapping system possible.
>
> -- Peter Rust
> Developer, Cornerstone Systems
============================================================================
==
TOPIC: Chaining same data twice?
http://groups.google.com/group/chainjs/browse_thread/thread/7eb4c12b414eb8af
?hl=en
============================================================================
==
== 1 of 3 ==
Date: Mon, Sep 1 2008 9:08 am
From: Eshan
I have the following markup:
<body>
Hello,
<span id="hello" class="user">
<span class="firstname"></span>
<span class="lastname"></span>
</span>!
Goodbye
<span id="goodbye" class="user">
<span class="firstname"></span>
<span class="lastname"></span>
</span>!
</body>
The following lines populate both sections properly:
$('#hello').item(user).chain();
$('#goodbye').item(user).chain();
But this line does not:
$('.user').item(user).chain();
Is this working as intended?
== 2 of 3 ==
Date: Mon, Sep 1 2008 9:36 am
From: Rizqi Ahmad
yeah, there are some limitation regarding multiple elements. currently
you have to do $('.user').each(function(){$(this).chain()})
On Sep 1, 6:08 pm, Eshan <eshan.shahja...@gmail.com> wrote:
> I have the following markup:
>
> <body>
> Hello,
> <span id="hello" class="user">
> <span class="firstname"></span>
> <span class="lastname"></span>
> </span>!
>
> Goodbye
> <span id="goodbye" class="user">
> <span class="firstname"></span>
> <span class="lastname"></span>
> </span>!
> </body>
>
> The following lines populate both sections properly:
>
> $('#hello').item(user).chain();
> $('#goodbye').item(user).chain();
>
> But this line does not:
>
> $('.user').item(user).chain();
>
> Is this working as intended?
== 3 of 3 ==
Date: Mon, Sep 1 2008 8:07 pm
From: Eshan
Thanks, $('.user').each(function(){$(this).item(user).chain()}); did
work.
On Sep 1, 12:36 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> yeah, there are some limitation regarding multiple elements. currently
> you have to do $('.user').each(function(){$(this).chain()})
>
> On Sep 1, 6:08 pm, Eshan <eshan.shahja...@gmail.com> wrote:
>
> > I have the following markup:
>
> > <body>
> > Hello,
> > <span id="hello" class="user">
> > <span class="firstname"></span>
> > <span class="lastname"></span>
> > </span>!
>
> > Goodbye
> > <span id="goodbye" class="user">
> > <span class="firstname"></span>
> > <span class="lastname"></span>
> > </span>!
> > </body>
>
> > The following lines populate both sections properly:
>
> > $('#hello').item(user).chain();
> > $('#goodbye').item(user).chain();
>
> > But this line does not:
>
> > $('.user').item(user).chain();
>
> > Is this working as intended?
============================================================================
==
You received this message because you are subscribed to the Google Groups
"chainjs"
group.
To post to this group, send email to cha...@googlegroups.com or visit
http://groups.google.com/group/chainjs?hl=en
To unsubscribe from this group, send email to
chainjs+u...@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/chainjs/subscribe?hl=en
To report abuse, send email explaining the problem to ab...@googlegroups.com
============================================================================
==
Google Groups: http://groups.google.com?hl=en
Jimmy Vu
I've tested with LightningDOM, yet it seems not work as desired.
This is an example that just mimics what you wrote in the post.
http://javascriptly.com/examples/lightning_dom/index.html
Did I miss something?
--Jimmy
Rizqi Ahmad
Wow thank you for donating LightningDOM to us!
I will evaluate LightningDOM soon.
> > ?hl=en<http://groups.google.com/group/chainjs/browse_thread/thread/5c1a95740...>
>
> > ?hl=en<http://groups.google.com/group/chainjs/browse_thread/thread/7eb4c12b4...>
>
> > ============================================================================
> > ==
> > TOPIC: Collaboration?
>
> >http://groups.google.com/group/chainjs/browse_thread/thread/5c1a95740...
> > ?hl=en<http://groups.google.com/group/chainjs/browse_thread/thread/5c1a95740...>
> > ============================================================================
> > ==
>
> > == 1 of 2 ==
> > Date: Sun, Aug 31 2008 10:04 pm
> > From: Peter Rust
>
> > Rizqi,
>
> > First off, I like the way you think. I've been a big evangelist of
> > client-side templating and data-binding in my workplace for the past
> > couple years. Making the binding automatic and overridable is also
> > beautiful.
>
> > I wrote a data-binding layer (now in its second version) for a project
> > (www.projectrecon.net), but haven't released or documented the data-
> > binding layer publicly. Now that others are in almost the exact same
> > ?hl=en<http://groups.google.com/group/chainjs/browse_thread/thread/7eb4c12b4...>
>
> read more »
Rizqi Ahmad
But since the future direction of chain.js is in creating highly
dynamic interfaces (beginning with interaction.js
http://github.com/raid-ox/interaction.js/wikis/demos) I am afraid that
it will be difficult to integrate LightningDOM to this project. The
design philosophy of chain.js differs to what PURE has. I think it
will be much easier to integrate it to PURE than to chain.js.
But again I appreciate your donation very much and would like to
integrate it if only I could. Porting Chain.js self to LightningDOM
would be possible, but do you think it is possible to port
interaction.js too?
Any thought appreciated.
Rizqi
>
> read more »
Peter Rust
Jimmy,
> yet it seems not work as desired
Thanks for testing the LightningDOM and for pointing this out. I fixed the problem and blogged about it this morning.
Rizqi,
> do you think it is possible to port interaction.js too?
I think it may. I’m often doing pretty fine-grained stuff with it – regenerating just a small portion of the markup using the .innerHTML() of a nested element, rather than the .outerHTML() of the whole container. I’ll study the way interaction.js works and let you know what I find.
-- Peter Rust
Developer, Cornerstone Systems
Rizqi Ahmad
For now I think I will do partial code optimization as suggested by
Sindre. But may be I will consider LightningDOM for future versions.
On Sep 11, 7:57 pm, "Peter Rust" <pe...@cornerstonenw.com> wrote:
> Jimmy,
>
> > yet it seems not work as desired
>
> Thanks for testing the LightningDOM and for pointing this out. I fixed the
> problem and blogged
>
> Rizqi,
>
> > do you think it is possible to port interaction.js too?
>
> http://groups.google.com/group/chainjs/browse_thread/thread/5c1a95740...
> <http://groups.google.com/group/chainjs/browse_thread/thread/5c1a95740...
> 0?hl=en>
> * Chaining same data twice? - 3 messages, 2 authors
>
> <http://groups.google.com/group/chainjs/browse_thread/thread/7eb4c12b4...
> f?hl=en>
> ?hl=en
>
> ============================================================================
> ==
> TOPIC: Collaboration?http://groups.google.com/group/chainjs/browse_thread/thread/5c1a95740...
> <http://groups.google.com/group/chainjs/browse_thread/thread/5c1a95740...
> 0?hl=en>
> ============================================================================
> ==
>
> == 1 of 2 ==
> Date: Sun, Aug 31 2008 10:04 pm
> From: Peter Rust
>
> Rizqi,
>
> First off, I like the way you think. I've been a big evangelist of
> client-side templating and data-binding in my workplace for the past
> couple years. Making the binding automatic and overridable is also
> beautiful.
>
> I wrote a data-binding layer (now in its second version) for a project
> (www.projectrecon.net), but haven't released or documented the data-
> binding layer publicly. Now that others are in almost the exact same
> <http://groups.google.com/group/chainjs/browse_thread/thread/7eb4c12b4...
> f?hl=en>
>
> read more »