NYCPHP Meetup

[Hans Zaunere]

> > The Javascript then takes each element from the array and manipulates the
> > DOM as appropriate.  Why not just stuff things in innerHTML you may ask?
> > Because that's not granular enough, and should the user be interactive with
> > that particular element, the user has just lost his current state.
> 
> Maybe you need a javascript template system? That way you would only
> be passing data in JSON, and then coercing that into a template on the
> client side. Template may == DOM-building-function if that's more
> suitable than string replacement and innerHTML stuffing.
> 
> In other words, if the client knows how to add events to a calendar
> (using DOM), then you can just send a stream of event details using
> JSON. Very lightweight on the server side, and you're not mixing
> markup and data anymore.
> 
> As a bonus, that approach sets you up for thinking in terms of a local
> database, which leads to offline functionality.

So I think I see what you're saying.  Keep all markup (aside from perhaps the initial request) off the server.

I thought about this, and played around with it a bit.  There are a couple of problems, or at least contradictions...

-- everyone I talk to says do as much as you can on the server

-- and with good reason, since complex JS is just a hack after another

-- if I do only receive raw "bare-metal" data points via JSON from the server, it seems that the JS complexity gets astronomic, which has obvious problems and frankly greatly reduces overall application agility in my opinion (ie, markup structure, visual appearance, and application logic are once again lumped together).

Seems as though it's 2003 again...

Is this what you mean by JS templating, or is there some techniques/examples that are better/easier/faster/cheaper?

H