| Re: Embedding HTML Within a PHP Statement [message #176002 is a reply to message #175996] |
Mon, 14 November 2011 19:18   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 11/14/2011 9:01 AM, Erwin Moller wrote:
> On 11/14/2011 1:30 PM, Tim Streater wrote:
>> In article <4ec0f420$0$6915$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl>,
>> Erwin Moller
>> <Since_humans_read_this_I_am_spammed_too_much(at)spamyourself(dot)com> wrote:
>>
>>> I don't think that approach is very recommendable.
>>> At least not as a general recipe.
>
>
> Hello Tim,
>
>>
>> It won't cover many situations, I agree.
>>
>>> A few drawbacks:
>>> - Your full ajax approach results in multiple requests to the server
>>> (where one request would suffice without AJAX.).
>>
>> I would rather eat three correctly-sized meals a day than one very big
>> meal once a week.
>
> Me too.
> But your analogy doesn't explain why you think it is better.
>
> Are you stating that all-in-once versus multiple AJAX-calls is somehow
> better/easier for the server?
> Maybe lower memory-load of multiple small requests outperforms the
> higher memory load of one (bigger) request?
>
> But that is just guessing. I am curious what your rationale behind that
> statement is.
>
> Please don't respond with more food. :P
>
>
>>
>>> - It also demands the client to have Javascript enabled.
>>
>> Yes, and so what. My application has 7500 lines of PHP and 12000 or so
>> lines of javaScript. I see no prospect of being able to replace the
>> JavaScript by some clever CSS.
>
> I don't know your application of course.
> The reason I replied to your post is simply because in typical*
> situations it isn't necessarily a good approach.
>
> *By typical I mean: client/server, where:
> client=browser on some device,
> server=webserver serving HTML using PHP as language.
>
>
>>
>>> - Many searchengines and their associated crawlers don't execute
>>> Javascript, so they will be blind for that fetched content.
>>
>> While some might, and with good reason, personally I don't take the
>> needs of search engines into account.
>
> OK. Fair enough. :-)
>
>>
>>> - In many cases the back button will give unexpected results, and
>>> bookmarking a page becomes a guessing game.
>>
>> Mmm. In everything you say here, you make the mistake of assuming that
>> PHP, browser, JavaScript are components that can *only* be used in a
>> traditional browser-on-my-computer, server-somewhere-remote scenario.
>> This is an error.
>>
>
> Yes, I responded to the OP with that typical set-up in mind, since the
> OP didn't indicate anything else I saw little reason to do so.
>
> [short intermezzo at a driving school]
>
> Student: "So if I want to break I press the right pedal?"
> Driving instructor: "Correct."
>
> ...Student crashes into a wall trying to use right pedal to break...
>
> Student: "Why the $#$# did you tell me to use that right pedal?"
> Driving instructor: "Because that is where the breaks are in my 1891
> Daimler. It is a beautiful car by the way."
>
> [/short intermezzo]
>
> PS: I have no clue where the breaks actually are in a 1891 Daimler. ;-)
>
>
>>> I also fail to see why you claim "much cleaner for the user POV".
>>
>> Because reloading a page is messy and slow from the user's PoV. Instead
>> you can use AJAX to respond in a much more timely way depending what
>> they are doing. Or validate their form as they are entering it, or do
>> something like a postcode or address lookup.
>
> Yes, all the above are perfectly good examples where AJAX makes sense
> from a user POV. (I assume you validate the data again serverside.)
> I won't argue about that, and I use it myself in similar situations.
>
> But why build the better part of your document like that?
> Why fetch the main content via Ajax?
> I have seen this before, I understand how to do it, but I don't
> understand the why.
> The only valid reason I can think of is the flashing/buildup of the new
> document, but I never felt that out-weighted all the drawbacks (poor
> navigation/bookmarking are the worst).
>
>
>> And yes, in most instances
>> you can offer a degraded approach in the case where the user *has*
>> turned off JS, but then they get a poorer service and may not understand
>> why.
>
> And what about bookmarking?
> And intuitive use of the back button?
>
> Those things often feel broken to me when using AJAX-riddled websites.
>
> Regards,
> Erwin Moller
>
>
Erwin, you are correct. Bringing everything down in one swell foop is
much more efficient network-wise.
Assuming the data in both are identical, the same amount of data will be
downloaded. However, using AJAX requires multiple requests, along with
the associated network traffic, server load and file system access than
doing in one piece. Additionally, if the server is using compression,
it will almost assuredly be able to more efficiently compress one large
block than several smaller blocks, further lowering both server load and
network traffic.
Of course, that's not to mention the additional overhead on the client
to interpret and process all that javascript (which, BTW, must also be
downloaded - additional server and network traffic!).
AJAX has its uses - but using it in place of simply downloading the page
is massive abuse, IMHO.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]