-
Notifications
You must be signed in to change notification settings - Fork 19
add html implementation #2
Comments
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 .. |
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? |
(if not, your approach is certainly the best!) |
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 :-) |
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:
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.
The text was updated successfully, but these errors were encountered: