Sorry for top posting, but here goes...

Stopping third party js from running on the client will never happen. If so, you just killed your servers thru put in attempting to handle things like google maps, google analytics and other fun things coming out of companies like that ( google, zoho etc ). Your server will never handle a large load like that for any number of users.

Using third party items ( js, images, flash and other embedded items ) is what makes the Internet so efficient. The nature of distributed systems allows the whole system to suceed.

What you are describing is nothing more than poor coding and a lack of data validation, which unfortunately is endemic to many sites with lots of people being able to build stuff with GUI tools like dreamweaver. That's why it pays to hire a pro, not the teenager down the street. They don't have the basic understanding of what and what not to do, what things are dangerous to allow nor how to sanatize data to ensure that the site or the users are not gonna get screwed.

Professionals, mostly, pay attention to the details that surround making a site work. It's what we get paid for.


Sent from my iPod

On Mar 23, 2009, at 20:24, "Michael A. Peters" <> wrote:

Sancar Saran wrote:
Probably a bit off topic and
The Game is over man.
Javascript coming with flank speed. Next generation JS Framworks will take html generation jobs from server side.

No it won't.
People are getting sick and tired of allowing third scripts to modify the DOM - browsers are becoming and will continue to become more restrictive with what JavaScript is allowed to do, and that's a good thing, because a lot of evil is done with JavaScript.

Most hacks now are XSS exploits - taking advantage of the fact that users are too stupid to understand that enabling JavaScript is no different than executing e-mail attachments automatically.

Just like users *and e-mail clients* wised up during the e-mail virus/worm craze of the late 90s (IE I love you etc.) - users and browsers are wising up as well.

Generating your content server side is not subject to what the browser and/or user allow scripts to do client side, heavy DHTML like what some are experimenting with will go the way of the dodo bird.

I suspect that in the future, perhaps not this exactly but something like this will be common place - a script node will have a new attribute, the value of which is an id that must exist in the DOM before the script is run. The script will only be allowed to modify the DOM elements that matches that id and it's children. Script nodes without that attribute won't be allowed to modify the DOM at all, and the DOM elements will have a mechanism (IE an attribute tag) that can completely protect them from modification by any script., etc.

Using script to modify a document DOM will still take place, but it will be a lot more difficult, and more likely to fail due to browser/ user imposed limitations. Thus creating the DOM will take place server side where it belongs.

Maybe server side JavaScript will be a competitor to php in some situations, but server side page generation is not getting replaced by client side DHTML anytime soon.

//just my two cents and thoughts - I'm not an expert in web tech

PHP General Mailing List (
To unsubscribe, visit:

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to