When you create a page on the server side, you are going to serialize it and send it to the browser. In the browser, we want to keep polling for updates on the queries we used to build the page.
Currently, we're able to use the DOM. We're even considering sticking an empty text node into our generated document so that when we replace, we can have a nicer transition. We can delete all the elements except for a text node that is an empty string, erasing the old element entirely. We then insert the new elements, using the one we left as a marker.
That won't serialize and become reconstituted on the browser. Comments on the other hand, can be serialized and parsed. However, the generated HTML is going to be a bit verbose, and the comments will be visible when you view source. Also, there's a chance that there will be a naming collision. I'm sure someone will troll me hard using the word semantic.
If we do add these markers using markup, we're going to have to create rules. There will have to be a containing element on which we place an id. It will have to be at least a span. It means that value will have to generate at least a span, and be entirely replaced.
One way to do this would be to make the commands we've created attributes that are attached to existing elements, but now we're getting in something fiddly. You won't be able to have a looping structure around tweets, or rather, a tag library that has collections instead of layouts. Well, we're giving up on tag libraries if that's the case.
With comments we can serialize, reconstitute on the browser. Without it we can't. The drawback is that the serialized HTML is going to be very, very ugly.
With semantic markup required, we can serialize, reconstitute on the browser, and there is no janky HTML, nor is there any sort of a document scan to find these placeholders once the document loads.
We could use paths, but those would be really fragile. Any rewriting of the DOM by other libraries, or fixes by the browser itself would break things.
Finally, there might be some way to mark the elements that constitute a replacement, and annotate them with the amount of text, in characters, to chomp before and after. Still creates a problem for our value tags.
I'm fond of the idea of tag libraries. I like the notion of giving people tags to program with instead of fiddly JavaScript functions. The price we pay for nice templates would be ugly HTML.
Hmm... One comment could be a header, instead of comment sandwich.
When you create a page on the server side, you are going to serialize it and send it to the browser. In the browser, we want to keep polling for updates on the queries we used to build the page.
Currently, we're able to use the DOM. We're even considering sticking an empty text node into our generated document so that when we replace, we can have a nicer transition. We can delete all the elements except for a text node that is an empty string, erasing the old element entirely. We then insert the new elements, using the one we left as a marker.
That won't serialize and become reconstituted on the browser. Comments on the other hand, can be serialized and parsed. However, the generated HTML is going to be a bit verbose, and the comments will be visible when you view source. Also, there's a chance that there will be a naming collision. I'm sure someone will troll me hard using the word semantic.
If we do add these markers using markup, we're going to have to create rules. There will have to be a containing element on which we place an id. It will have to be at least a span. It means that value will have to generate at least a span, and be entirely replaced.
One way to do this would be to make the commands we've created attributes that are attached to existing elements, but now we're getting in something fiddly. You won't be able to have a looping structure around tweets, or rather, a tag library that has collections instead of layouts. Well, we're giving up on tag libraries if that's the case.
With comments we can serialize, reconstitute on the browser. Without it we can't. The drawback is that the serialized HTML is going to be very, very ugly.
With semantic markup required, we can serialize, reconstitute on the browser, and there is no janky HTML, nor is there any sort of a document scan to find these placeholders once the document loads.
We could use paths, but those would be really fragile. Any rewriting of the DOM by other libraries, or fixes by the browser itself would break things.
Finally, there might be some way to mark the elements that constitute a replacement, and annotate them with the amount of text, in characters, to chomp before and after. Still creates a problem for our value tags.
I'm fond of the idea of tag libraries. I like the notion of giving people tags to program with instead of fiddly JavaScript functions. The price we pay for nice templates would be ugly HTML.
Hmm... One comment could be a header, instead of comment sandwich.