Re: Collaboration?
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,
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
Davey
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
Mic (BeeBole)
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,
Davey
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.
Peter Rust
> I'm as well very interested by lightningDOM.
> Peter, Is there a link available somewhere ?
(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
Davey
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_Objects/Object/NoSuchMethod
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.
anyway hope to get some time to look at it.
BTW there's another non velocity template engine appeared,
http://www.matthias-georgi.de/2008/9/patroon-a-javascript-template-engine.html,
looks interesting and lightweight. but i still think that pure looks
like the best overall choice.
Davey
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_Objects/Object/NoSuchMethod
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.
anyway hope to get some time to look at it.
BTW there's another non velocity template engine appeared,
http://www.matthias-georgi.de/2008/9/patroon-a-javascript-template-engine.html,
looks interesting and lightweight. but i still think that pure looks
like the best overall choice.
On Sep 10, 1:33 pm, "Peter Rust" <pe...@cornerstonenw.com> wrote:
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
On Sep 11, 9:54 am, Davey <geekfr...@gmail.com> wrote:
> Peter,
>
> 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
> firstchild() method stuff and have actual properties. the other crazy
> 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.
>
> anyway hope to get some time to look at it.
>
Mic (BeeBole)
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,
Peter Rust
Thanks, Mic!
I wrote a follow-up post this morning, released LightningDOM 1.3.1 and created an interactive LightningDOM Playground.
-- Peter
Peter Rust
>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 $$(). 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.
-- peter
Mic Cvilic
Peter,
>to overwrite the $$(...) selector,>as it allows only to have the full document as the search contextIn 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 $$().
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.
Davey
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!
>
> read more »
Mic (BeeBole)
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:
> Thanks, Mic!
>
> I wrote a follow-up
> this morning, released LightningDOM
> <http://www.projectrecon.net/LightningDOM/LightningDOM-1.3.1.js> 1.3.1 and
> created an interactive LightningDOM
> <http://www.projectrecon.net/LightningDOM/Playground.html> Playground.
Peter Rust
Mic,
> 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…