Skip to content
This repository has been archived by the owner on Mar 3, 2023. It is now read-only.

add html implementation #2

Closed
jed opened this issue Oct 25, 2012 · 4 comments
Closed

add html implementation #2

jed opened this issue Oct 25, 2012 · 4 comments

Comments

@jed
Copy link
Owner

jed commented Oct 25, 2012

i'd like to have HTML generation and DOM generation in the same library, to enable use on both server and client, and to allow client rendering to take place using innerHTML where faster.

but.

i am unsure how to implement it. seems to me there are two choices:

  1. have two parallel DOM builders DSLs, one that generates HTML and one that generates a DOM, like this:
domo.dom.<nodeName>
domo.html.<nodeName>
  1. have one DOM builder DSL that creates lightweight mock DOM objects, with the following methods:
Node.prototype.toDOM = function(document) {}
Node.prototype.toHTML = function() {}

the first is probably more efficient because there is no intermediate object generation, and easier to use because there is less API surface area and DOM objects are returned directly.

the second is probably cleaner, since no code needs to be duplicated for each approach, and creation of intermediate objects would allow more methods to be introduced if/when needed.

@WebReflection
Copy link

Node is already a DOM element so Node#toDOM looks redundant to me. toHTML looks like outerHTML property to me ... how about mocking on the server through require? that was my proposal about .. var document; if(!document) document = require('./document').document; which will work with node and browsers, isn't it?

@jed
Copy link
Owner Author

jed commented Oct 29, 2012

one problem is that it probably makes sense for the browser to generate HTML as well, since it's apparently much faster doing that than using DOM operations to create element for IE < 9, which means the HTML needs to be generated without a DOM.

is the perf improvement on IE worth the abstraction for everyone else?

@jed
Copy link
Owner Author

jed commented Oct 29, 2012

(if not, your approach is certainly the best!)

@WebReflection
Copy link

this library looks a one shot operation per template, not a library to manipulate DOM, isn't it? I would not bother too much about IE < 9 then, those browsers are going to disappear soon while IE 10 for W8 requires already hell of hardware so it's going to be fast. Said that, I would try to understand adoption percentage and where ( client or server or both ) and when IE will become a bottleneck, if ever, you can improve it :-)

jed added a commit that referenced this issue Oct 31, 2012
@jed jed closed this as completed Oct 31, 2012
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants