Thanks Jonathan, my comments in situ :)
On Nov 5, 2:56 pm, Jonathan Klein <jonathan.n.kl...@gmail.com
> This is a clever idea, but I definitely have some questions about it. For
> one thing, you are "moving the responsibility of merging the content with
> the structure to the client browser", which is a pretty hostile and unknown
I like clever! I wouldnt agree unknown as Meob
does work today on all major browsers on all major operating systems.
I even bought myself android and mac devices to prove it.
>You are asking the client to spend more CPU cycles laying out
> the page, when they might have fewer resources available than the server.
yes true, though the same could be said of new browser features or
changes to HTML. I've not noticed an appreciable increase in page
render time as the speed is IO bound usually. Ie it takes longer to
download than it takes to process.
> In addition you are making the client download a substantial amount of
> be blocking (unless you want a nasty flash of unstyled content).
wouldn't say 18k is substantial ,and it can be further optimised by
removing debugging information. I think I could get it down to 9K of
and it would get cached on the client so its a one time hit. Sites
ultimately I would like to see the logic embedded in HTML standards
example a src attribute on container tags. ie src="~myvar" would put
> Saving CPU on the server side is a noble goal, but in reality the time that
> the server spends putting content into layouts and churning out HTML is very
> very small. Servers are a heck of a lot better at string manipulation than
> browsers are.
the cost is incremental, for low throughput web servers yes, agree
when talking about hundreds or thousands of requests per second every
improvement helps. it would be good to get some empirical data but
I dont have test facilities on those scales.
maybe CPU isnt the right way to sell this invention. my experience is
servers tend to get stuck with blocking IO and waiting threads. Less
Say a person goes to a site and views 10 pages with the same layout
, for arguments sake there is 20K of HTML of which 1K is content and
rest of structure. first hit this would be 29K, subsequent visits 1K.,
38K versus 200K. Multiply by 200tps and saving in IO is substantial.
the main benefit from my perspective is separating content from
and giving the flexibility to change the layout with very little
effort. Having been
the lead coder for a high throughput site it always amazed me that
marketting had to
come to a web coder to make UI changes. There will always be a degree
between UI and logic as the but MEOB adds a whole lot of flexibility.
on so many
> Like Dan alluded to, this would probably be used for web applications where
> this kind of thing is already happening. Browsers make Ajax calls and bring
> back JSON encoded strings which are then manipulated on the client side into
> the layout. This is efficient because you transmit fewer bytes across the
> wire (and it is what allows things like Google Instant to perform well). So
> for dynamic applications this approach makes a lot of sense,
> but if you are
> generating something like a news page which is mainly static I think you
> would be much better served to crunch the HTML on the server.
perhaps, perhaps not. depends on what you want to do. has advantages
and disadvantages like any technology.
> Just some thoughts, let me know what you think.
thanks for the feedback
I'd rather have this discussion on the basis of empirical data, but
as a proof of concept.