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,
On Sep 1, 3:08 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> 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
Did you really mean to post this to the news group?
I'd certainly be interested in looking at the lightningDOM stuff, as I
have a project that does some js stuff
inside rhino, and being able to use the same templating api in there
as I do in my other server side
stuff would be most excellent.
cheers
On Sep 9, 1:37 pm, "Mic (BeeBole)" <tch...@gmail.com> wrote:
> Hi Rizqi, Pieter,
> 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,
> On Sep 1, 3:08 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> > 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
I'm as well very interested by lightningDOM.
Peter, Is there a link available somewhere ?
I dropped DOM rendering in PURE as I wanted it ultra fast.
Because it is for client rendering.
Server side is another story, saving time there is less an issue.
For me all the work possible to reduce the front-end time is worth the
fight.
Granted, rendering is only a part of it.
Andy Wardley of TT said in a post about PURE something like
having the same rendering engine on the server(TT) and
on the client(jemplate) was a good value.
I think it is ok for reusability.
Do you see other benefits?
Cheers,
On Sep 10, 8:17 am, Davey <geekfr...@gmail.com> wrote:
> Did you really mean to post this to the news group?
> I'd certainly be interested in looking at the lightningDOM stuff, as I
> have a project that does some js stuff
> inside rhino, and being able to use the same templating api in there
> as I do in my other server side
> stuff would be most excellent.
> cheers
> On Sep 9, 1:37 pm, "Mic (BeeBole)" <tch...@gmail.com> wrote:
> > Hi Rizqi, Pieter,
> > 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,
> > On Sep 1, 3:08 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> > > 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
specifically the benefit, is that using a serverside JS solution that
has no DOM such as rhino, would then be able to use pure on the
server. and that would allow you avoid writing different code on the
server. our jaxer already has this but to would be nice to have it in
rhinoland also.
On Sep 10, 7:32 am, "Mic (BeeBole)" <tch...@gmail.com> wrote:
> I'm as well very interested by lightningDOM.
> Peter, Is there a link available somewhere ?
> I dropped DOM rendering in PURE as I wanted it ultra fast.
> Because it is for client rendering.
> Server side is another story, saving time there is less an issue.
> For me all the work possible to reduce the front-end time is worth the
> fight.
> Granted, rendering is only a part of it.
> Andy Wardley of TT said in a post about PURE something like
> having the same rendering engine on the server(TT) and
> on the client(jemplate) was a good value.
> I think it is ok for reusability.
> Do you see other benefits?
> Cheers,
> On Sep 10, 8:17 am, Davey <geekfr...@gmail.com> wrote:
> > Mic,
> > Did you really mean to post this to the news group?
> > I'd certainly be interested in looking at the lightningDOM stuff, as I
> > have a project that does some js stuff
> > inside rhino, and being able to use the same templating api in there
> > as I do in my other server side
> > stuff would be most excellent.
> > > Hi Rizqi, Pieter,
> > > 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,
> > > On Sep 1, 3:08 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> > > > 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
> I'm as well very interested by lightningDOM.
> Peter, Is there a link available somewhere ?
I 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.
[mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On Behalf Of Mic
(BeeBole)
Sent: Wednesday, September 10, 2008 7:33 AM
To: PURE Unobtrusive Rendering Engine for HTML
Subject: [ PURE ] Re: Collaboration?
Davey,
Sure I meant it.
I'm as well very interested by lightningDOM.
Peter, Is there a link available somewhere ?
I dropped DOM rendering in PURE as I wanted it ultra fast.
Because it is for client rendering.
Server side is another story, saving time there is less an issue.
For me all the work possible to reduce the front-end time is worth the
fight.
Granted, rendering is only a part of it.
Andy Wardley of TT said in a post about PURE something like
having the same rendering engine on the server(TT) and
on the client(jemplate) was a good value.
I think it is ok for reusability.
Do you see other benefits?
Cheers,
On Sep 10, 8:17 am, Davey <geekfr...@gmail.com> wrote:
> Mic,
> Did you really mean to post this to the news group?
> I'd certainly be interested in looking at the lightningDOM stuff, as I
> have a project that does some js stuff
> inside rhino, and being able to use the same templating api in there
> as I do in my other server side
> stuff would be most excellent.
> cheers
> On Sep 9, 1:37 pm, "Mic (BeeBole)" <tch...@gmail.com> wrote:
> > Hi Rizqi, Pieter,
> > 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,
> > On Sep 1, 3:08 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> > > 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
I just read the blog, it's cool stuff. I really see an excellent
application for this in Martin Blom's ESXX project, or perhaps
mod_rhino, which provides a server side javascript stack using rhino.
one of the nice things about rhino is along with FF , Opera and Safari
(and ie8 i think) is that it has getter and setters, John resig had a
good post on that http://ejohn.org/blog/javascript-getters-and-setters/ which means in that environment you'd be able to avoid the
firstchild() method stuff and have actual properties. the other crazy
useful thing you get is the __noSuchMethod__ support
http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Global_...
I'm working on a comprehensive javascript stack (called jacd) and plan
to use ESXX to provide a JS->JAVA
interface, having a 'dom' there would be v. useful.
> > I'm as well very interested by lightningDOM.
> > Peter, Is there a link available somewhere ?
> I 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.
> [mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On Behalf Of Mic
> (BeeBole)
> Sent: Wednesday, September 10, 2008 7:33 AM
> To: PURE Unobtrusive Rendering Engine for HTML
> Subject: [ PURE ] Re: Collaboration?
> Davey,
> Sure I meant it.
> I'm as well very interested by lightningDOM.
> Peter, Is there a link available somewhere ?
> I dropped DOM rendering in PURE as I wanted it ultra fast.
> Because it is for client rendering.
> Server side is another story, saving time there is less an issue.
> For me all the work possible to reduce the front-end time is worth the
> fight.
> Granted, rendering is only a part of it.
> Andy Wardley of TT said in a post about PURE something like
> having the same rendering engine on the server(TT) and
> on the client(jemplate) was a good value.
> I think it is ok for reusability.
> Do you see other benefits?
> > Did you really mean to post this to the news group?
> > I'd certainly be interested in looking at the lightningDOM stuff, as I
> > have a project that does some js stuff
> > inside rhino, and being able to use the same templating api in there
> > as I do in my other server side
> > stuff would be most excellent.
> > > Hi Rizqi, Pieter,
> > > 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,
> > > On Sep 1, 3:08 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> > > > 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
I just read the blog, it's cool stuff. I really see an excellent
application for this in Martin Blom's ESXX project, or perhaps
mod_rhino, which provides a server side javascript stack using rhino.
one of the nice things about rhino is along with FF , Opera and Safari
(and ie8 i think) is that it has getter and setters, John resig had a
good post on that http://ejohn.org/blog/javascript-getters-and-setters/ which means in that environment you'd be able to avoid the
firstchild() method stuff and have actual properties. the other crazy
useful thing you get is the __noSuchMethod__ support
http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Global_...
I'm working on a comprehensive javascript stack (called jacd) and plan
to use ESXX to provide a JS->JAVA
interface, having a 'dom' there would be v. useful.
> > I'm as well very interested by lightningDOM.
> > Peter, Is there a link available somewhere ?
> I 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.
> [mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On Behalf Of Mic
> (BeeBole)
> Sent: Wednesday, September 10, 2008 7:33 AM
> To: PURE Unobtrusive Rendering Engine for HTML
> Subject: [ PURE ] Re: Collaboration?
> Davey,
> Sure I meant it.
> I'm as well very interested by lightningDOM.
> Peter, Is there a link available somewhere ?
> I dropped DOM rendering in PURE as I wanted it ultra fast.
> Because it is for client rendering.
> Server side is another story, saving time there is less an issue.
> For me all the work possible to reduce the front-end time is worth the
> fight.
> Granted, rendering is only a part of it.
> Andy Wardley of TT said in a post about PURE something like
> having the same rendering engine on the server(TT) and
> on the client(jemplate) was a good value.
> I think it is ok for reusability.
> Do you see other benefits?
> > Did you really mean to post this to the news group?
> > I'd certainly be interested in looking at the lightningDOM stuff, as I
> > have a project that does some js stuff
> > inside rhino, and being able to use the same templating api in there
> > as I do in my other server side
> > stuff would be most excellent.
> > > Hi Rizqi, Pieter,
> > > 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,
> > > On Sep 1, 3:08 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> > > > 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
Hi Peter, Ive looked at your post and code, It is great!
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
On Sep 11, 9:54 am, Davey <geekfr...@gmail.com> wrote:
> I just read the blog, it's cool stuff. I really see an excellent
> application for this in Martin Blom's ESXX project, or perhaps
> mod_rhino, which provides a server side javascript stack using rhino.
> one of the nice things about rhino is along with FF , Opera and Safari
> (and ie8 i think) is that it has getter and setters, John resig had a
> good post on thathttp://ejohn.org/blog/javascript-getters-and-setters/ > which means in that environment you'd be able to avoid the
> firstchild() method stuff and have actual properties. the other crazy
> useful thing you get is the __noSuchMethod__ supporthttp://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Global_...
> I'm working on a comprehensive javascript stack (called jacd) and plan
> to use ESXX to provide a JS->JAVA
> interface, having a 'dom' there would be v. useful.
> On Sep 10, 1:33 pm, "Peter Rust" <pe...@cornerstonenw.com> wrote:
> > Davey, Mic,
> > > I'm as well very interested by lightningDOM.
> > > Peter, Is there a link available somewhere ?
> > I 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.
> > [mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On Behalf Of Mic
> > (BeeBole)
> > Sent: Wednesday, September 10, 2008 7:33 AM
> > To: PURE Unobtrusive Rendering Engine for HTML
> > Subject: [ PURE ] Re: Collaboration?
> > Davey,
> > Sure I meant it.
> > I'm as well very interested by lightningDOM.
> > Peter, Is there a link available somewhere ?
> > I dropped DOM rendering in PURE as I wanted it ultra fast.
> > Because it is for client rendering.
> > Server side is another story, saving time there is less an issue.
> > For me all the work possible to reduce the front-end time is worth the
> > fight.
> > Granted, rendering is only a part of it.
> > Andy Wardley of TT said in a post about PURE something like
> > having the same rendering engine on the server(TT) and
> > on the client(jemplate) was a good value.
> > I think it is ok for reusability.
> > Do you see other benefits?
> > > Did you really mean to post this to the news group?
> > > I'd certainly be interested in looking at the lightningDOM stuff, as I
> > > have a project that does some js stuff
> > > inside rhino, and being able to use the same templating api in there
> > > as I do in my other server side
> > > stuff would be most excellent.
> > > > Hi Rizqi, Pieter,
> > > > 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,
> > > > On Sep 1, 3:08 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> > > > > 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
Hi Peter,
Thank you for these ¡3 hours! and sending this information to the
group.
I'll have a look at it and see if there are possible integration.
As you hinted serveral times, feel free to have a look at pure.js to
see if lightningDOM could improve some areas or break some current
limitations.
You reference prototype.js in your post.
Did you try to use PURE with prototype.js?
I tried, at the end of the pure.js code to overwrite the $$(...)
selector.
As it allows only to have the full document as the search context.
Cheers,
On Sep 10, 10:33 pm, "Peter Rust" <pe...@cornerstonenw.com> wrote:
> > I'm as well very interested by lightningDOM.
> > Peter, Is there a link available somewhere ?
> I 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.
> [mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On Behalf Of Mic
> (BeeBole)
> Sent: Wednesday, September 10, 2008 7:33 AM
> To: PURE Unobtrusive Rendering Engine for HTML
> Subject: [ PURE ] Re: Collaboration?
> Davey,
> Sure I meant it.
> I'm as well very interested by lightningDOM.
> Peter, Is there a link available somewhere ?
> I dropped DOM rendering in PURE as I wanted it ultra fast.
> Because it is for client rendering.
> Server side is another story, saving time there is less an issue.
> For me all the work possible to reduce the front-end time is worth the
> fight.
> Granted, rendering is only a part of it.
> Andy Wardley of TT said in a post about PURE something like
> having the same rendering engine on the server(TT) and
> on the client(jemplate) was a good value.
> I think it is ok for reusability.
> Do you see other benefits?
> > Did you really mean to post this to the news group?
> > I'd certainly be interested in looking at the lightningDOM stuff, as I
> > have a project that does some js stuff
> > inside rhino, and being able to use the same templating api in there
> > as I do in my other server side
> > stuff would be most excellent.
> > > Hi Rizqi, Pieter,
> > > 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,
> > > On Sep 1, 3:08 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> > > > 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
[mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On Behalf Of Mic
(BeeBole)
Sent: Thursday, September 11, 2008 1:18 PM
To: PURE Unobtrusive Rendering Engine for HTML
Subject: [ PURE ] Re: Collaboration?
Hi Peter,
Thank you for these ¡3 hours! and sending this information to the
group.
I'll have a look at it and see if there are possible integration.
As you hinted serveral times, feel free to have a look at pure.js to
see if lightningDOM could improve some areas or break some current
limitations.
You reference prototype.js in your post.
Did you try to use PURE with prototype.js?
I tried, at the end of the pure.js code to overwrite the $$(...)
selector.
As it allows only to have the full document as the search context.
Cheers,
On Sep 10, 10:33 pm, "Peter Rust" <pe...@cornerstonenw.com> wrote:
> Davey, Mic,
> > I'm as well very interested by lightningDOM.
> > Peter, Is there a link available somewhere ?
> I 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.
>to overwrite the $$(...) selector,
>as it allows only to have the full document as the search context
In Prototype, you can use a single element as the search context via
Element.select() <http://www.prototypejs.org/api/element/select> , for
example $('myDiv').select('.highlight'). It has the exact same syntax and
behavior as $$(). It’s a priority to me to make LightningDOM and PURE work
with both jQuery and Prototype. When John Resig finishes his
library-independent super-fast CSS Selector engine, Sizzle
<http://ajaxian.com/archives/sizzle-john-resig-has-a-new-selector-engine> ,
it might be good to make that a dependency and use it exclusively.
-- peter
From: Pure-Unobtrusive-Rendering-Engine@googlegroups.com
[mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On Behalf Of
Peter Rust
Sent: Thursday, September 11, 2008 1:47 PM
To: Pure-Unobtrusive-Rendering-Engine@googlegroups.com
Subject: [ PURE ] Re: Collaboration?
[mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On Behalf Of Mic
(BeeBole)
Sent: Thursday, September 11, 2008 1:18 PM
To: PURE Unobtrusive Rendering Engine for HTML
Subject: [ PURE ] Re: Collaboration?
Hi Peter,
Thank you for these ¡3 hours! and sending this information to the
group.
I'll have a look at it and see if there are possible integration.
As you hinted serveral times, feel free to have a look at pure.js to
see if lightningDOM could improve some areas or break some current
limitations.
You reference prototype.js in your post.
Did you try to use PURE with prototype.js?
I tried, at the end of the pure.js code to overwrite the $$(...)
selector.
As it allows only to have the full document as the search context.
Cheers,
On Sep 10, 10:33 pm, "Peter Rust" <pe...@cornerstonenw.com> wrote:
> Davey, Mic,
> > I'm as well very interested by lightningDOM.
> > Peter, Is there a link available somewhere ?
> I 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.
> >to overwrite the $$(...) selector,
> >as it allows only to have the full document as the search context
> In Prototype, you can use a single element as the search context via
> Element.select(), for example $('myDiv').select('.highlight'). It
> has the exact same syntax and behavior as $$().
Nice! thanks so much. This will make PURE compatible with prototype.js
soon.
> It’s a priority to me to make LightningDOM and PURE work with both
> jQuery and Prototype. When John Resig finishes his library- > independent super-fast CSS Selector engine, Sizzle, it might be good
> to make that a dependency and use it exclusively.
PURE was made to be independent from a specific JS framework.
And the selector functionality( pure.find ) needs to be provided by a
library (jQuery only for the moment, and soon prototype.js from your
help above).
So sizzle would come perfectly for that.
I was crossing the fingers that the browser builders would provide
this in the next releases.
I think I read somewhere Safari on the iPhone had it well already. And
some other browsers partially.
> From: Pure-Unobtrusive-Rendering-Engine@googlegroups.com [mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com > ] On Behalf Of Peter Rust
> Sent: Thursday, September 11, 2008 1:47 PM
> To: Pure-Unobtrusive-Rendering-Engine@googlegroups.com
> Subject: [ PURE ] Re: Collaboration?
> Thanks, Mic!
> I wrote a follow-up post this morning, released LightningDOM 1.3.1
> and created an interactive LightningDOM Playground.
> -- Peter
> -----Original Message-----
> From: Pure-Unobtrusive-Rendering-Engine@googlegroups.com [mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com > ] On Behalf Of Mic (BeeBole)
> Sent: Thursday, September 11, 2008 1:18 PM
> To: PURE Unobtrusive Rendering Engine for HTML
> Subject: [ PURE ] Re: Collaboration?
> Hi Peter,
> Thank you for these ¡3 hours! and sending this information to the
> group.
> I'll have a look at it and see if there are possible integration.
> As you hinted serveral times, feel free to have a look at pure.js to
> see if lightningDOM could improve some areas or break some current
> limitations.
> You reference prototype.js in your post.
> Did you try to use PURE with prototype.js?
> I tried, at the end of the pure.js code to overwrite the $$(...)
> selector.
> As it allows only to have the full document as the search context.
> > > I'm as well very interested by lightningDOM.
> > > Peter, Is there a link available somewhere ?
> > I 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.
> > [mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On
> Behalf Of Mic
> > (BeeBole)
> > Sent: Wednesday, September 10, 2008 7:33 AM
> > To: PURE Unobtrusive Rendering Engine for HTML
> > Subject: [ PURE ] Re: Collaboration?
> > Davey,
> > Sure I meant it.
> > I'm as well very interested by lightningDOM.
> > Peter, Is there a link available somewhere ?
> > I dropped DOM rendering in PURE as I wanted it ultra fast.
> > Because it is for client rendering.
> > Server side is another story, saving time there is less an issue.
> > For me all the work possible to reduce the front-end time is worth
> the
> > fight.
> > Granted, rendering is only a part of it.
> > Andy Wardley of TT said in a post about PURE something like
> > having the same rendering engine on the server(TT) and
> > on the client(jemplate) was a good value.
> > I think it is ok for reusability.
> > Do you see other benefits?
> > > Did you really mean to post this to the news group?
> > > I'd certainly be interested in looking at the lightningDOM
> stuff, as I
> > > have a project that does some js stuff
> > > inside rhino, and being able to use the same templating api in
> there
> > > as I do in my other server side
> > > stuff would be most excellent.
> > > > Hi Rizqi, Pieter,
> > > > 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,
> > > > On Sep 1, 3:08 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> > > > > 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.
The underpinning of Sizzle is simply the fact that the major browser
vendors have agreed on implementing the standard Selector API, so the
speed comes from the fact that it can leverage much more of the native
code, I believe John implemented some extra ID related performance
stuff on top of that. I'm looking forward to having it to play with
server side with Jaxer, as we have guaranteed Mozilla DOM and so as
soon as FF3.1 goes public, we'll huge performance boost with that.
so looking ahead, i see three great performance things.
1. Jit/VM based js getting super fast
2. DOM traverse/manipulate going native (and fast)
3. the ECMASCRIPT 3.1 native JSON support (in ie8 now, partial in FF3)
making json super fast.
these three trends really enforce the rational behind templating with
only DOM and JS.
fun times!
On Sep 11, 2:23 pm, Mic Cvilic <tch...@gmail.com> wrote:
> > >to overwrite the $$(...) selector,
> > >as it allows only to have the full document as the search context
> > In Prototype, you can use a single element as the search context via
> > Element.select(), for example $('myDiv').select('.highlight'). It
> > has the exact same syntax and behavior as $$().
> Nice! thanks so much. This will make PURE compatible with prototype.js
> soon.
> > It’s a priority to me to make LightningDOM and PURE work with both
> > jQuery and Prototype. When John Resig finishes his library-
> > independent super-fast CSS Selector engine, Sizzle, it might be good
> > to make that a dependency and use it exclusively.
> PURE was made to be independent from a specific JS framework.
> And the selector functionality( pure.find ) needs to be provided by a
> library (jQuery only for the moment, and soon prototype.js from your
> help above).
> So sizzle would come perfectly for that.
> I was crossing the fingers that the browser builders would provide
> this in the next releases.
> I think I read somewhere Safari on the iPhone had it well already. And
> some other browsers partially.
> > -- peter
> > From: Pure-Unobtrusive-Rendering-Engine@googlegroups.com [mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com
> > ] On Behalf Of Peter Rust
> > Sent: Thursday, September 11, 2008 1:47 PM
> > To: Pure-Unobtrusive-Rendering-Engine@googlegroups.com
> > Subject: [ PURE ] Re: Collaboration?
> > Thanks, Mic!
> > I wrote a follow-up post this morning, released LightningDOM 1.3.1
> > and created an interactive LightningDOM Playground.
> > -- Peter
> > -----Original Message-----
> > From: Pure-Unobtrusive-Rendering-Engine@googlegroups.com [mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com
> > ] On Behalf Of Mic (BeeBole)
> > Sent: Thursday, September 11, 2008 1:18 PM
> > To: PURE Unobtrusive Rendering Engine for HTML
> > Subject: [ PURE ] Re: Collaboration?
> > Hi Peter,
> > Thank you for these ¡3 hours! and sending this information to the
> > group.
> > I'll have a look at it and see if there are possible integration.
> > As you hinted serveral times, feel free to have a look at pure.js to
> > see if lightningDOM could improve some areas or break some current
> > limitations.
> > You reference prototype.js in your post.
> > Did you try to use PURE with prototype.js?
> > I tried, at the end of the pure.js code to overwrite the $$(...)
> > selector.
> > As it allows only to have the full document as the search context.
> > > > I'm as well very interested by lightningDOM.
> > > > Peter, Is there a link available somewhere ?
> > > I 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.
> > > [mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On
> > Behalf Of Mic
> > > (BeeBole)
> > > Sent: Wednesday, September 10, 2008 7:33 AM
> > > To: PURE Unobtrusive Rendering Engine for HTML
> > > Subject: [ PURE ] Re: Collaboration?
> > > Davey,
> > > Sure I meant it.
> > > I'm as well very interested by lightningDOM.
> > > Peter, Is there a link available somewhere ?
> > > I dropped DOM rendering in PURE as I wanted it ultra fast.
> > > Because it is for client rendering.
> > > Server side is another story, saving time there is less an issue.
> > > For me all the work possible to reduce the front-end time is worth
> > the
> > > fight.
> > > Granted, rendering is only a part of it.
> > > Andy Wardley of TT said in a post about PURE something like
> > > having the same rendering engine on the server(TT) and
> > > on the client(jemplate) was a good value.
> > > I think it is ok for reusability.
> > > Do you see other benefits?
> > > > Did you really mean to post this to the news group?
> > > > I'd certainly be interested in looking at the lightningDOM
> > stuff, as I
> > > > have a project that does some js stuff
> > > > inside rhino, and being able to use the same templating api in
> > there
> > > > as I do in my other server side
> > > > stuff would be most excellent.
> > > > > Hi Rizqi, Pieter,
> > > > > 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,
> > > > > On Sep 1, 3:08 pm, Rizqi Ahmad <raid...@yahoo.de> wrote:
> > > > > > 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
Hi Peter,
Sorry I was quite busy with the release of the new revision.
Coming back to ligthningDOM.
If I understood well, it converts the element to an array and I think
I got the power of this.
Especially for recursion.
Here below is the process of PURE.
As you know well lightningDOM, please have a look and see where it
could help.
You tell in your posts that you are not sure about beeing able to make
an array of any HTML.
What are the know limitation of lightningDOM?
Thanks for sharing your work,
Mic
- - - - - - - - - - - -
pure.map() - output a DOM object
apply the directives to the HTML: a directive becomes an attribute
pure:something="..."
pure.utils.nodeWalk() - output a DOM object
traverse the tree and map the auto-rendering, place the node values,
and wrap the repetition in a <pure:repeat> node.
pure.compile() - output a String as a JS code
convert the element to a string, split at each "pure:" and build the
js
On Sep 11, 10:46 pm, "Peter Rust" <pe...@cornerstonenw.com> wrote:
> [mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On Behalf Of Mic
> (BeeBole)
> Sent: Thursday, September 11, 2008 1:18 PM
> To: PURE Unobtrusive Rendering Engine for HTML
> Subject: [ PURE ] Re: Collaboration?
> Hi Peter,
> Thank you for these ¡3 hours! and sending this information to the
> group.
> I'll have a look at it and see if there are possible integration.
> As you hinted serveral times, feel free to have a look at pure.js to
> see if lightningDOM could improve some areas or break some current
> limitations.
> You reference prototype.js in your post.
> Did you try to use PURE with prototype.js?
> I tried, at the end of the pure.js code to overwrite the $$(...)
> selector.
> As it allows only to have the full document as the search context.
> Cheers,
> On Sep 10, 10:33 pm, "Peter Rust" <pe...@cornerstonenw.com> wrote:
> > Davey, Mic,
> > > I'm as well very interested by lightningDOM.
> > > Peter, Is there a link available somewhere ?
> > I 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.
> Sorry I was quite busy with the release of the new revision
That’s ok, I’ve been busy as well. But I’m still working & thinking about
client-side templating/data-mapping and following the email groups closely.
> If I understood well, it converts the element to an array and I think
> I got the power of this. Especially for recursion.
Yes, it converts the element to an array of strings, under the hood, so that
it can be very fast. This is similar to your compile() process, which
generates an array of strings. The difference is that compile() only
generates a separate string if it needs to, only where the “pure:”
attributes are. LightningDOM, on the other hand, has a separate string for
every element. And, after generating a separate string for every element, it
is still editable, via the same API as the DOM: LightningDOMNode.attributes,
LightningDOMNode.innerHTML, LightningDOMNode.className, etc.
The benefits of the compile() approach:
· It has slightly faster startup because you only need to split
where there are “pure:” attributes.
· It uses slightly less memory (fewer strings in the array)
· It join()s the final HTML slightly faster (fewer strings in the
array)
The benefits of the LightningDOM approach:
· It allows you to remove all the string operations
(parsing/splitting/regexing) into a separate layer.
· It can be used by a variety of templating and data-mapping engines
and approaches.
· If it is a separate layer shared by multiple templating engines,
it can be better optimized and tested.
· It exposes the same API as the DOM, so if the DOM is faster than
innerHTML in some browsers, your code can switch between them.
· The map()ing and nodeWalk()ing is faster because they’re
manipulating LightningDOM nodes, not DOM ones
· It is more flexible, allowing for user-defined onPostTemplate or
onPreTemplate node manipulations
· It is more flexible, allowing for partial updates (re-templating
the HTML for a particular sub-element without re-templating the whole thing)
In your current architecture, directives are mapped to the DOM, you nodeWalk
the DOM and then compile to JS/strings. Then if render() is called and it’s
already been compiled, you just execute the compiled functions. In a
LightningDOM-based architecture, you would first parse the DOM into a
LightningDOM structure and keep that structure in memory. Whenever render()
is called, you would nodeWalk the LightningDOMNodes based on the directives
and generate the final HTML via LightningDOM’s .outerHTML() method.
> What are the know limitation of lightningDOM?
I’ve just tested it on my own projects/templates, so there are probably some
nodeTypes (comments) and some IE-isms (unclosed <li> tags) that I haven’t
coded for. This is just a matter of getting it out there in beta form and me
being responsive to fix bugs that crop up. As far as possible limitations in
the fundamental design/architecture, there are two things.
1) It isn’t currently a perfect drop-in replacement for the DOM because
properties like .innerHTML and .nextSibling have to be “functionalized” into
.innerHTML() and .nextSibling(). I have thought of a way to possibly fix
this (my most recent blog post), but I would have to test it to see if there
is a performance tradeoff.
2) I think the nested-arrays internal data structure is too
highly-grained for the best performance and I think it would be faster if I
replace it with a single one dimension array. This would require caching
some parsed data (className, id, endTagIndex, etc) in a separate, paired
data structure (possibly an array to start out, but perhaps moving into an
object tree if point 1 turns out to be valid.
I have a project that needs more speed, so I’ll be profiling and seeing if
option #2 will give me what I need. I might even be able to work on it
today.
To experiment with integrating the LightningDOM, we don’t have to do the
whole architecture change. We could begin by simply doing the map() and
nodeWalk() on LightningDOMNodes, rather than on the DOM directly. If this
goes well (we see a speed increase, squash bugs, like the feel of things),
then we could look at possible further integration.
-- Peter Rust
Developer, Cornerstone Systems
PS: it’s theoretically possible to “precompile” the LightningDOM for further
speed increases by doing the parsing beforehand and sending a pre-JSONified
LightningDOM data structure to the client. My hunch is that this isn’t
necessary and isn’t worth the effort, but people may want/need a
pre-compiled option…
[mailto:Pure-Unobtrusive-Rendering-Engine@googlegroups.com] On Behalf Of Mic
(BeeBole)
Sent: Wednesday, September 17, 2008 9:04 AM
To: PURE Unobtrusive Rendering Engine for HTML
Subject: [ PURE ] Re: Collaboration?
Hi Peter,
Sorry I was quite busy with the release of the new revision.
Coming back to ligthningDOM.
If I understood well, it converts the element to an array and I think
I got the power of this.
Especially for recursion.
Here below is the process of PURE.
As you know well lightningDOM, please have a look and see where it
could help.
You tell in your posts that you are not sure about beeing able to make
an array of any HTML.
What are the know limitation of lightningDOM?
Thanks for sharing your work,
Mic
- - - - - - - - - - - -
pure.map() - output a DOM object
apply the directives to the HTML: a directive becomes an attribute
pure:something="..."
pure.utils.nodeWalk() - output a DOM object
traverse the tree and map the auto-rendering, place the node values,
and wrap the repetition in a <pure:repeat> node.
pure.compile() - output a String as a JS code
convert the element to a string, split at each "pure:" and build the
js
On Sep 11, 10:46 pm, "Peter Rust" <pe...@cornerstonenw.com> wrote:
|
