Why no server-side DOM?

Mark, we actually looked at that. the problem with it is that it does not
perform very well. you wind up create huge trees of nodes that are typically
not used at all. then, to actually generate the pages, you need to do a
very large tree walk. the server-side controls started out as a way to add
dynamic content - to allow you to essentially have a dom - but for the parts
of the page that you were interested in. this then evolved into the controls
we have today. we wanted a real encapsulation model and real richness in
the types of controls that you could build.

mark

"Mark Koesel" <koesel@umich.edu> wrote:
>The new Web Forms are kudos, yeah, but why not just give us
>server-side DOM?
>
>Have the ASP engine parse the HTML, and let us use the IE5 DOM
>on the server to slap the page around all we want. Or, if
>preferred, no HTML at all, and we build the document from
>scratch using document.createElement(). Or combine the two
>for an extra good time.
>
>The <asp:"control" runat="server"> paradigm has that all too
>familiar "cheesy: feel to it...
>
>And yeah, I can create an IE instance in my ASP to do this kind
>of thing so that's fine -- but I was really hoping/thinking
>that server-side DOM would be in the next ASP rev.
>
>Ya know?
>
>